From ian at hixie.ch Tue Apr 1 11:55:24 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 18:55:24 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <20140205183607.GA56968@sideshowbarker> References: <52EDD11A.5030606@mcc.id.au> <52F03365.5050004@mcc.id.au> <52F24694.5020903@nag.co.uk> <20140205183607.GA56968@sideshowbarker> Message-ID: On Tue, 4 Feb 2014, Cameron McCormack wrote: > Ian Hickson wrote: > > I'm all for handling it in one place. What precisely do you want the > > behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- "the first > > element" may come after "the first element", and > > vice versa. Also consider when one or the other is "primary" but the > > relevant element is absent.) > > OK, how about: if the document element is an , we choose the > first in document order; if the document element is an > , we choose the first child of the document > element; otherwise, null. > > This still is going to produce "incorrect" results for things like: > > > > > blah > > > > but arguably you shouldn't be using in there anyway. It doesn't seem useful to hit that element. It's not the (SVG) document title, after all. I ended up going with: - if it's an SVG document, use the first <title> child of the root element - if it's an HTML document, use the first <title> element in tree order (that's what it used to be) For setting it uses the same element, unless there isn't one, in which case: - if it's an SVG document, append an SVG <title> to the root element - if it's an HTML document, append a <title> to the <head> Hopefully that's compatible enough. Let me know if you need something different. On Mon, 3 Feb 2014, Jonas Sicking wrote: > > An even simpler solution would be to say "we choose the first > <html:title> or <svg:title> in document order". That has the nice > property that we align SVG and HTML more. This seems to not quite match the SVG semantics, unfortunately. On Wed, 5 Feb 2014, Simon Pieters wrote: > > Is there a situation in which it is conforming to use html:title outside > the <head> in a document where the root is html:html? In > math:annotation-xml? You can certainly imagine a compound document format containing entire HTML subdocuments, <html>, <head>, <title>, and all. I'm not sure that's possible with just SVG and HTML currently though. (Maybe MathML, indeed.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 12:01:46 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 19:01:46 +0000 (UTC) Subject: [whatwg] microdata questions In-Reply-To: <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> References: <CAGYLO0+N_3BTmKM6+2XLcghm2d0GSy36xubRJKTR5KWEnGhvNg@mail.gmail.com> <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404011857230.11249@ps20323.dreamhostps.com> On Mon, 10 Feb 2014, Eric Devine wrote: > > 1. Section 5.5.1 of the Microdata spec prescribes how microdata should > be respresented as JSON, but it does provide a MIME type. I'm writing a > REST API that I would like to be able to return JSON in microdata > format, but I need the client to explicitly request this via the HTTP > Accept header. The main concern is to know when to return plain > properties as an array with one element. As a general rule I would recommend against using Accept headers to do anything. You're better off making the JSON data its own resource, IMHO. Having said that, as you noted in a later e-mail, the MIME type suggested by the HTML spec is "application/microdata+json". http://whatwg.org/html#application/microdata+json > 2. Section 5.2.4 does not provide a way to apply a property value to the > value attribute of an <option> element. Is this an oversight, or is > there simply not a convincing enough use case for the need? There's not any way currently to make for controls map to microdata. It's not clear exactly what it would mean. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jonas at sicking.cc Tue Apr 1 12:58:12 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Tue, 1 Apr 2014 12:58:12 -0700 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> Message-ID: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 3 Feb 2014, Jonas Sicking wrote: >> >> An even simpler solution would be to say "we choose the first >> <html:title> or <svg:title> in document order". That has the nice >> property that we align SVG and HTML more. > > This seems to not quite match the SVG semantics, unfortunately. Does it break existing content? If not, why not ask the SVG spec to be changed? The thread was started by one of the SVG spec editors after all. / Jonas From ian at hixie.ch Tue Apr 1 13:29:59 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 20:29:59 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404012027040.21310@ps20323.dreamhostps.com> On Tue, 1 Apr 2014, Jonas Sicking wrote: > On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Feb 2014, Jonas Sicking wrote: > >> > >> An even simpler solution would be to say "we choose the first > >> <html:title> or <svg:title> in document order". That has the nice > >> property that we align SVG and HTML more. > > > > This seems to not quite match the SVG semantics, unfortunately. > > Does it break existing content? If not, why not ask the SVG spec to be > changed? The thread was started by one of the SVG spec editors after > all. Dirk and heycam's replies to your original e-mail here suggest that this is not really viable. I mean, it'd be like changing document.title in HTML to point to the first title="" attribute in the document if it came before the first <title>. Anyway, what the spec ended up saying is in some ways even simpler, since it only looks one level deep for SVG rather than doing a deep tree search. (Is this the kind of change that you would have liked pre-flighted? I can revert the change and put out an announcement if you like. I'm not yet sure I exactly understand what kinds of changes fall into this category.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 17:02:51 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 00:02:51 +0000 (UTC) Subject: [whatwg] <keygen> and X509 client cert mime type In-Reply-To: <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> References: <2E519EB1-CB5D-48E1-8435-BEF2616E9F9C@bblfish.net> <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> Message-ID: <alpine.DEB.2.00.1404012343180.11249@ps20323.dreamhostps.com> On Tue, 25 Feb 2014, henry.story at bblfish.net wrote: > > The keygen form element does a great job of specifying how the browser > creates a public/private key pair, stores the private key in it's local > keystore. > > "When the control's form is submitted, the private key is stored in the > local keystore, and the public key is packaged and sent to the server." > > It is clear that the intention is for the server to send back a > certificate built from the public key. What I can't find is what the > mime type of the returned certificate should be. I have been using > `application/x-x509-user-cert` which seems to work for Safari, Firefox, > Opera . But I think that is not an officially supported certificate > type. application/pkix-cert seems to be that after looking it up on > iana. > > I ended up posting a bug report for Android on that. > http://code.google.com/p/android/issues/detail?id=66342 > > But now I have to check for each browser which is the type all browsers > support. To avoid people having to do this research again and again, > perhaps it would be worth specifying a mime type that all browsers > do/must support in the HTML5 spec? On Wed, 26 Feb 2014, henry.story at bblfish.net wrote: > > (1) most browsers currently understand the mime types > (a) application/x-x509-user-cert > (b) application/x-x509-ca-cert > (c) application/x-x509-email-cert > ( I have only verified (a) btw. I am assuming the others also support (b) and (c) ) > as specified here > https://wiki.mozilla.org/CA:Certificate_Download_Specification > > (2) the above mime types are not registered > http://www.iana.org/assignments/media-types/media-types.xhtml > > So really either the old mime types should be registered, or they should > be mentioned as being in use but deprecated and people should be guided > towards the application/pkix-cert I wouldn't worry too much about registered vs not registered. If the registry doesn't match the implementations, the registry is buggy. On the other hand, I also don't want to get into the business of specifying this stuff myself. I've added a link to the above MDN page to the keygen section. If there is ever something more canonical (and yet still useful and accurate), let me know and I'll update the spec. Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 11:55:24 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 18:55:24 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <20140205183607.GA56968@sideshowbarker> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> Message-ID: <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> On Tue, 4 Feb 2014, Cameron McCormack wrote: > Ian Hickson wrote: > > I'm all for handling it in one place. What precisely do you want the > > behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- "the first > > <svg:title> element" may come after "the first<html:title> element", and > > vice versa. Also consider when one or the other is "primary" but the > > relevant element is absent.) > > OK, how about: if the document element is an <html:html>, we choose the > first <html:title> in document order; if the document element is an > <svg:svg>, we choose the first child <svg:title> of the document > element; otherwise, null. > > This still is going to produce "incorrect" results for things like: > > <!DOCTYPE html> > <svg> > <foreignObject> > <title>blah > > > > but arguably you shouldn't be using in there anyway. It doesn't seem useful to hit that element. It's not the (SVG) document title, after all. I ended up going with: - if it's an SVG document, use the first <title> child of the root element - if it's an HTML document, use the first <title> element in tree order (that's what it used to be) For setting it uses the same element, unless there isn't one, in which case: - if it's an SVG document, append an SVG <title> to the root element - if it's an HTML document, append a <title> to the <head> Hopefully that's compatible enough. Let me know if you need something different. On Mon, 3 Feb 2014, Jonas Sicking wrote: > > An even simpler solution would be to say "we choose the first > <html:title> or <svg:title> in document order". That has the nice > property that we align SVG and HTML more. This seems to not quite match the SVG semantics, unfortunately. On Wed, 5 Feb 2014, Simon Pieters wrote: > > Is there a situation in which it is conforming to use html:title outside > the <head> in a document where the root is html:html? In > math:annotation-xml? You can certainly imagine a compound document format containing entire HTML subdocuments, <html>, <head>, <title>, and all. I'm not sure that's possible with just SVG and HTML currently though. (Maybe MathML, indeed.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 12:01:46 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 19:01:46 +0000 (UTC) Subject: [whatwg] microdata questions In-Reply-To: <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> References: <CAGYLO0+N_3BTmKM6+2XLcghm2d0GSy36xubRJKTR5KWEnGhvNg@mail.gmail.com> <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404011857230.11249@ps20323.dreamhostps.com> On Mon, 10 Feb 2014, Eric Devine wrote: > > 1. Section 5.5.1 of the Microdata spec prescribes how microdata should > be respresented as JSON, but it does provide a MIME type. I'm writing a > REST API that I would like to be able to return JSON in microdata > format, but I need the client to explicitly request this via the HTTP > Accept header. The main concern is to know when to return plain > properties as an array with one element. As a general rule I would recommend against using Accept headers to do anything. You're better off making the JSON data its own resource, IMHO. Having said that, as you noted in a later e-mail, the MIME type suggested by the HTML spec is "application/microdata+json". http://whatwg.org/html#application/microdata+json > 2. Section 5.2.4 does not provide a way to apply a property value to the > value attribute of an <option> element. Is this an oversight, or is > there simply not a convincing enough use case for the need? There's not any way currently to make for controls map to microdata. It's not clear exactly what it would mean. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jonas at sicking.cc Tue Apr 1 12:58:12 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Tue, 1 Apr 2014 12:58:12 -0700 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> Message-ID: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 3 Feb 2014, Jonas Sicking wrote: >> >> An even simpler solution would be to say "we choose the first >> <html:title> or <svg:title> in document order". That has the nice >> property that we align SVG and HTML more. > > This seems to not quite match the SVG semantics, unfortunately. Does it break existing content? If not, why not ask the SVG spec to be changed? The thread was started by one of the SVG spec editors after all. / Jonas From ian at hixie.ch Tue Apr 1 13:29:59 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 20:29:59 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404012027040.21310@ps20323.dreamhostps.com> On Tue, 1 Apr 2014, Jonas Sicking wrote: > On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Feb 2014, Jonas Sicking wrote: > >> > >> An even simpler solution would be to say "we choose the first > >> <html:title> or <svg:title> in document order". That has the nice > >> property that we align SVG and HTML more. > > > > This seems to not quite match the SVG semantics, unfortunately. > > Does it break existing content? If not, why not ask the SVG spec to be > changed? The thread was started by one of the SVG spec editors after > all. Dirk and heycam's replies to your original e-mail here suggest that this is not really viable. I mean, it'd be like changing document.title in HTML to point to the first title="" attribute in the document if it came before the first <title>. Anyway, what the spec ended up saying is in some ways even simpler, since it only looks one level deep for SVG rather than doing a deep tree search. (Is this the kind of change that you would have liked pre-flighted? I can revert the change and put out an announcement if you like. I'm not yet sure I exactly understand what kinds of changes fall into this category.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 17:02:51 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 00:02:51 +0000 (UTC) Subject: [whatwg] <keygen> and X509 client cert mime type In-Reply-To: <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> References: <2E519EB1-CB5D-48E1-8435-BEF2616E9F9C@bblfish.net> <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> Message-ID: <alpine.DEB.2.00.1404012343180.11249@ps20323.dreamhostps.com> On Tue, 25 Feb 2014, henry.story at bblfish.net wrote: > > The keygen form element does a great job of specifying how the browser > creates a public/private key pair, stores the private key in it's local > keystore. > > "When the control's form is submitted, the private key is stored in the > local keystore, and the public key is packaged and sent to the server." > > It is clear that the intention is for the server to send back a > certificate built from the public key. What I can't find is what the > mime type of the returned certificate should be. I have been using > `application/x-x509-user-cert` which seems to work for Safari, Firefox, > Opera . But I think that is not an officially supported certificate > type. application/pkix-cert seems to be that after looking it up on > iana. > > I ended up posting a bug report for Android on that. > http://code.google.com/p/android/issues/detail?id=66342 > > But now I have to check for each browser which is the type all browsers > support. To avoid people having to do this research again and again, > perhaps it would be worth specifying a mime type that all browsers > do/must support in the HTML5 spec? On Wed, 26 Feb 2014, henry.story at bblfish.net wrote: > > (1) most browsers currently understand the mime types > (a) application/x-x509-user-cert > (b) application/x-x509-ca-cert > (c) application/x-x509-email-cert > ( I have only verified (a) btw. I am assuming the others also support (b) and (c) ) > as specified here > https://wiki.mozilla.org/CA:Certificate_Download_Specification > > (2) the above mime types are not registered > http://www.iana.org/assignments/media-types/media-types.xhtml > > So really either the old mime types should be registered, or they should > be mentioned as being in use but deprecated and people should be guided > towards the application/pkix-cert I wouldn't worry too much about registered vs not registered. If the registry doesn't match the implementations, the registry is buggy. On the other hand, I also don't want to get into the business of specifying this stuff myself. I've added a link to the above MDN page to the keygen section. If there is ever something more canonical (and yet still useful and accurate), let me know and I'll update the spec. Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:43:08 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:43:08 +0000 (UTC) Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEEAS0O79Ko7QrxXKE8YxaVZha5Hzr_bqpAaJrb2PKHQggA@mail.gmail.com> References: <CA+dJEEAS0O79Ko7QrxXKE8YxaVZha5Hzr_bqpAaJrb2PKHQggA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021739430.11249@ps20323.dreamhostps.com> On Mon, 3 Mar 2014, Bob Owen wrote: > > The spec [...] seems to be fairly clear that if an existing window is > navigated using window.open, by a browsing context that is not the > original opener, then window.opener should remain unchanged. > > Currently, Trident (and incidentally Presto) seems to have the correct > behaviour, but Blink, WebKit and Gecko all change window.opener to the > window of the browsing context that has just caused it to navigate. I > believe this to be a very long standing difference (>10 years for Gecko > and Trident) > > I am proposing to change Gecko to match the spec, but I was advised to > raise the issue here before going ahead. > > Do people agree that window.opener should remain unchanged in this > circumstance? Did you receive any off-list feedback on this, or attempt to implement it and get any implementation experience? Having "opener" be the actual opener seems pretty intuitive to me; if there's no compat need to do otherwise, it seems like a reasonable choice. Is there a security reason to prefer the latest navigator? (At the time the spec was written, it was 2v2; the 1v3 situation we have now is the result of Presto going away and Blink forking from WebKit.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:52:14 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:52:14 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> On Mon, 3 Mar 2014, Ami Fischman wrote: > > Looks like we're back in business: > > Latest editor's draft: > http://dev.w3.org/2011/webrtc/editor/getusermedia.html Thanks. As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:57:11 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:57:11 +0000 (UTC) Subject: [whatwg] More effective model for handling resources In-Reply-To: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> References: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> On Thu, 13 Mar 2014, Tingan Ho wrote: > > Almost all web developer I know use externally linked CSS resource in > their web projects. That means that the browser needs to (1) request the > html page (2) parse the html (3) request for the CSS resource that is > linked from the html document. The problem with externally linked > resources is point three. It needs to make another request for the CSS > resource. There is a solution to this problem and that is to inline the > CSS. Though that would yield another problem: all subsequent page > request will become bigger. I believe this is being handled by the next-generation transport protocols (SPDY or whatever it's called now). I recommend approaching the relevant groups to check that your precise case has been handled. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 11:09:15 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 18:09:15 +0000 (UTC) Subject: [whatwg] inverse property mechanism for Microdata? In-Reply-To: <CAK-qy=6VGPOJshUqSg_BuVU44UUqV9WLxtJAdRUm-pnk=XDKnw@mail.gmail.com> References: <CAK-qy=7SuUq_4Ung06+1CLySJ3D7Aiv_1uyAZnJzc+jPuOcYHw@mail.gmail.com> <alpine.DEB.2.00.1401312334310.26647@ps20323.dreamhostps.com> <CAK-qy=6_ZQ5NCxVSqHraa-Lc1P88vY8BpuacLbj3_QyFpG5jnQ@mail.gmail.com> <alpine.DEB.2.00.1403172046390.31525@ps20323.dreamhostps.com> <CAK-qy=6VGPOJshUqSg_BuVU44UUqV9WLxtJAdRUm-pnk=XDKnw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021759091.11249@ps20323.dreamhostps.com> On Wed, 19 Mar 2014, Dan Brickley wrote: > > > > This is what the example would look like if I'm understanding this right: > > > > <div itemscope itemtype="http://schema.org/LocalBusiness"> > > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > > Giftware</span></h1> > > <span itemprop="description"> A superb collection of fine gifts and clothing > > to accent your stay in Mexico Beach.</span> > > Phone: <span itemprop="telephone">850-648-4200</span> > > > > <div itemscope itemtype="http://schema.org/LocalBusiness" > > itemprop-up="containedIn"> > > <h2><span itemprop="name">(Entity B) The tiny store within a > > store</span></h2> > > <span itemprop="description"> A superb collection of tiny clothes, > > from the store within the store.</span> > > Phone: <span itemprop="telephone">123-456-7890</span> > > </div> > > > > </div> > > > > It's not too bad, I guess. > > Yes. I notice that the words we were playing with at schema.org relate > to the underlying graph data model itemprop-inverse, -reverse etc., > whereas your draft name, itemprop-up is about the markup hierarchy. Yeah. I think most authors think in terms of what they see (their markup), not in terms of the data model. (I have had a _lot_ of conversations with authors where it was clear that they had no idea there was an underlying data model for the microdata that was separate from the markup.) > Yup, there are some cases where this can be addressed through the > rigorous use of entity IDs in itemid, as you sketch below. That would be > relatively new territory for schema.org and for publishers. Perhaps > there is an attribute name we can find that would leave the door open to > more use cases, e.g. "itemprop-backwards" rather than "itemprop-up". It > seems reasonable to try to address relationships between sibling > elements too. Well you'd been a new attribute to do that, unless I'm misunderstanding your proposal. Maybe you mean this attribute wouldn't point to a relative place in the markup, but would point to an identified element given by another attribute? I think that would be quite confusing. > Something like (trying out -backwards instead of -up, to allow for > non-hierarchical usage): > > <div itemid="bigshop" itemscope itemtype="http://schema.org/LocalBusiness"> > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > Giftware</span></h1> > </div> > <div itemscope itemtype="http://schema.org/Pharmacy"> > <meta itemprop-backwards="containedIn" itemid="bigshop" /> > <h2><span itemprop="name">Tiny pharmacy store within a store</span></h2> > </div> > > ? > > Can we use itemid in that way, to give a property value too? I don't > see itemid used much in the wild and the spec only mentions its use > for the item having the property, rather than using when supplying the > value of a property. itemid="" is a URL that gives the identifier of the item. We'd want to use a new attribute to do something like this; e.g.: itemrelation="containedIn bigshop" where "itemrelation" takes just two keywords, a property name and the ID (not itemid) of the target element. But that's pretty elaborate. Is there a need for this? Or is the relationship to the parent all that's needed? In your original e-mail you only suggested wanting to go up. > > Microdata actually already has a solution to this. The vocabulary can > > define an ID for each item using itemid="", and can define multiple items > > having the same ID as being the same conceptual item. Thus: > > > > <!-- first episode --> > > <div itemscope itemtype="http://schema.org/Episode"> > > ... > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"></div> > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"></div> > > </div> > > > > <!-- second episode --> > > <div itemscope itemtype="http://schema.org/Episode"> > > ... > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"></div> > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"></div> > > </div> > > > > <!-- actors --> > > <div itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"> > > ... > > </div> > > <div itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"> > > ... > > </div> > > > > This also enables the data to be spread across multiple pages without > > confusion. (This is similar to how RDF uses identifiers for everything > > -- essentially, in RDF terms, this turns the microdata item from a > > bnode into a node with a global identifier.) > > Yes, it succeeds or fails to the extent people agree on these global > identifiers. Do people not agree on them, typically? > > Your example would become: > > > > <div itemscope itemtype="http://schema.org/LocalBusiness" > > itemid="..."> > > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > > Giftware</span></h1> > > <span itemprop="description"> A superb collection of fine gifts and clothing > > to accent your stay in Mexico Beach.</span> > > Phone: <span itemprop="telephone">850-648-4200</span> > > > > <div itemscope itemtype="http://schema.org/LocalBusiness"> > > <div itemprop="containedIn" > > itemscope itemtype="http://schema.org/LocalBusiness" > > itemid="..."></div> > > <h2><span itemprop="name">(Entity B) The tiny store within a > > store</span></h2> > > <span itemprop="description"> A superb collection of tiny clothes, > > from the store within the store.</span> > > Phone: <span itemprop="telephone">123-456-7890</span> > > </div> > > > > </div> > > > > Is this not suitable for schema.org? Or is it just too much markup? > > It's in the clever-but-fragile category, I'd say. So yes, a bit too > much markup. In English this is saying something like > > "We're describing a LocalBusiness whose global ID is [xyz]; it has > certain name, description, telephone properties given here. > There is also a LocalBusiness that is containedIn a LocalBusiness > whose global ID is [xyz]; this [other] LocalBusiness has the following > name, description, telephone etc properties...." > > Just as in the English, it is rather easy to lose track of which > LocalBusiness we're talking about. I think you overstate the complexity, but ok. > >> > That is another option, similar to the parenthetical itemid="" note > >> > above -- you could just have the vocabulary define that for every > >> > property whose value is an item, the item type that that property > >> > can point to has another property with the same name plus a fixed > >> > suffix, like "-inv", that inverses the relationship. [...] > >> > >> This is easier to understand than itemref, but still involves > >> creating 100s of additional properties instead of just one new piece > >> of syntax. > > > > What do you mean by "creating additional properties" here? It's > > relatively trivial to define these with one sentence, you don't need > > to actually list them or anything. Implementing support is similarly > > easy, as far as I can tell -- you just check for the suffix or prefix > > and handle it accordingly. > > Re "you don't need to actually list them", this effectively creates two > classes of property. Real ones, and fake/pseudo properties which we're > pretending exist so that we can re-use a piece of syntax that expects a > property name. Once these pseudo properties are released into the wild, > they'll show up as if they were real. They would be real, I'm just saying that documenting them and implementing them is somewhat trivial. > What we want to avoid is saying things like: > > "You can use itemprop='containedIn-rev' to indicate a property that > means the inverse of containedIn. However this is not a first class > schema.org property, and should not be used other syntaxes (JSON etc), > data dumps, APIs etc. You should canonicalize x containedIn-rev y > into: y containedIn x., ..." Why wouldn't it be a first-class property? It could trivially be so. The implementation is easy, whatever the vocabulary it's used in. > > If you do want to go with a new property, just use the name you would > > want in the spec. I weakly recommend "itemprop-up", which is the most > > intuitive name I've seen so far for this, but if you find a better > > name just use that. I guarantee that I won't make the spec conflict > > with whatever you use, as long as you tell me what it is. :-) Assuming > > that it works well, then we would just update the spec to use that > > term directly, retroactively making the experimental content > > conforming. > > Thanks! I'll discuss this thread with the schema.org team. My guess is > that there's still a strong preference for a new property, and we'd be > happy to avoid using data-*. > > If I understand right, the outstanding area of discussion/confusion is > whether there are cases beyond simple DOM element containment where we > might want to use an inverse itemprop construction (even though we can > see how itemid everywhere might also be used). If we're only using > element hierarchy then itemprop-up could work. Did you reach any conclusions in these discussions? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bobowencode at gmail.com Wed Apr 2 13:16:58 2014 From: bobowencode at gmail.com (Bob Owen) Date: Wed, 2 Apr 2014 21:16:58 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> On 2 April 2014 18:43, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Mar 2014, Bob Owen wrote: > > > > The spec [...] seems to be fairly clear that if an existing window is > > navigated using window.open, by a browsing context that is not the > > original opener, then window.opener should remain unchanged. > > > > Currently, Trident (and incidentally Presto) seems to have the correct > > behaviour, but Blink, WebKit and Gecko all change window.opener to the > > window of the browsing context that has just caused it to navigate. I > > believe this to be a very long standing difference (>10 years for Gecko > > and Trident) > > > > I am proposing to change Gecko to match the spec, but I was advised to > > raise the issue here before going ahead. > > > > Do people agree that window.opener should remain unchanged in this > > circumstance? > > Did you receive any off-list feedback on this, or attempt to implement it > and get any implementation experience? Thanks for getting back to me Ian. No, no other feedback. I have a patch for it, but haven't pursued it any further. I could investigate putting the change in for Firefox Nightly, if you think that might help with finding any compat issues. > Having "opener" be the actual opener seems pretty intuitive to me; if > there's no compat need to do otherwise, it seems like a reasonable choice. > > Is there a security reason to prefer the latest navigator? Agreed, the specified behaviour makes sense to me, if only because of the name. The fact that you can also use window.open for subsequent navigation (which leads to the different behaviours), muddies the water a bit, but that's a genie that would definitely refuse to go back in the bottle. Over security reasons, although I don't have any concrete examples, I would have thought that either could possibly cause problems, if the opposite behaviour was expected. So, consistency is probably the most important thing. I can also see that both pieces of information (original opener and last navigator) might be useful. So, maybe the other could be added either way. From ian at hixie.ch Wed Apr 2 13:56:38 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 20:56:38 +0000 (UTC) Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> On Wed, 5 Mar 2014, Qebui Nehebkau wrote: > On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson <ian at hixie.ch> wrote: > > I think the arguments you've presented so far suggest "address-levelN" > > for N=1..4, with 4=region and 3=locality, is probably the simplest > > thing to do. I was hoping there might be other people with opinions, > > to give us different perspectives on this, but it seems nobody else > > cares. :-( > > Since you asked, I think the whole endeavour (of trying to tokenise an > address) is pointless and should be abandoned outright. :) In principle I agree, but in practice I think we have to work with the reality that that is what people are doing. > Short of my ideal of *only* offering the full address (as used on a > label) as an opaque string, I think it would be most reasonable to > consider the 'locality' field itself to be a fully-specified opaque > string, including whatever information is necessary to completely > identify the location from the region level (such as the prefecture and > district), rather than a single level. > > Failing all that, I would at least prefer for the fields to have names > instead of abstract numbering, because people are likely to be confused > about the order, no matter which end is the 'widest'. It also seems more > intuitive, to me, for the 'locality', as, after all, 'local', to be the > most specific level. Would people not be confused by names in the same way? On Wed, 5 Mar 2014, Qebui Nehebkau wrote: > > Right, "impose", certainly not. But, perhaps, (one hopes,) "encourage"? > Or at least "refuse to explicitly support anything else". Does > autocomplete *need* to support people who are already doing it wrong? > But I'm probably just being too utopian; it happens. Well if we don't support pretty much every form out there, the feature isn't particularly useful. On Tue, 4 Mar 2014, Kevin Marks wrote: > > > > > > > > > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "address-level4" > > > > > > > > "address-level3" > > > > > > > > "address-level2" / "locality" > > > > > > > > "address-level1" / "region" > > > > > > > > "country-name" > > > > > > > > > > > > This could work. It has the synonym issue (having multiple fields > > > > > > that mean the same thing is often the source of confusion). > > > > > > > > > > > > > > Or we could do: > > > > > > > > > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "subsublocality" > > > > > > > > "sublocality" > > > > > > > > "locality" > > > > > > > > "region" > > > > > > > > "country-name" > > > > > > > > > > > > This could work. It avoids the synonym problem. > > > > > > > > > > Yes, this alternative works, but in my opinion is not preferable. > > > Because these words don't really mean anything. Nor do numbers. I think we don't really have any chance of giving meaning to the names here either way. On Tue, 4 Mar 2014, Evan Stade wrote: > > "dependent-locality" and "locality" have a fairly precise meaning in the > UK. Also in a natural-language conversation, if you ask me what "region" > of the country I live in, I'd say "New England", "the Midwest", or some > such; certainly not the state where I reside. The descriptions for these > tokens are currently pretty specific, for example they say a city would > be a locality. But this is not true for Beijing or some other cities. To > fix the descriptions, we'd have to change them to something like > "region: the highest level administrative region below country in the > address" and "locality: the second-highest level administrative region > below country in the address", "sub-locality: the third-highest level > administrative region [...]". With you so far. > At this point, one wonders why the tokens aren't just [something]1, > [something]2, etc. I don't understand how you get there. Why would you wonder this? > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "locality" > > > > > > > > "subsubregion" > > > > > > > > "subregion" > > > > > > > > "region" > > > > > > > > "country-name" > > > > I don't understand why you think authors will think they need to > > include "subregion", but won't think they need to include > > "address-level3". > > I think they'll assume subregion returns something for the US if it's > sandwiched between "region" and "locality", because county is in between > state and city. But in reality, subregion will return nothing. But why does this not apply to the numeric version? > > Having synonyms is really bad. It leads to huge amounts of confusion. > > This is why I'm trying to avoid having synonyms for the address-level* > > stuff. We should definitely not add some just to introduce a slightly > > better name. > > My suggestion is to change the address-line1 to street-address-line1, > not to have synonyms. Chrome would then support address-line1 for a > limited period of time, but outside the spec. There's no "outside the spec". The spec tries to describe reality. If you implement something, then that's the reality, and that's what the spec would say, and therefore we'd have a synonym. > If you are avidly anti-synonym for the address-level* stuff, and don't > want to change "region" and "locality", then I guess the next best > naming scheme in my mind would be "region", "locality", "locality2", > "locality3". But we also need to update the descriptions as mentioned > above. I don't understand why "locality2" is better than "sublocality", nor why it's better to add things above locality than between locality and region. The numbering seems really prone to mistakes (I mean, I've been making mistakes with it this entire thread unintentionally, for example). > > > Why is that better than 1=region, 2=locality, except to a US-centric > > > viewpoint? This would lead to a weird situation where (a) you > > > couldn't expand past 4 levels without changing the meaning of > > > previous levels and (b) a country such as the US would have > > > address-level4 and address-level3 but no address-level2 or > > > address-level1. > > > > Well, at least as far as (a) goes, we have no way to know where > > governments are going to introduce new levels. Who's to say that the > > US won't introduce something between states and towns? This problem > > exists whatever we do. Maybe the US and the EU will merge and there'll > > be a new field between "country-name" and "region". Who knows. > > One can dream... > > You're right that changing political circumstances might put us in an > awkward situation no matter what we do. But it seems to me the most > likely scenario is that a government would add more administrative > levels at the most granular level. Why? It seems just as likely that we'll add levels between "country" and "region". For instance, the example above. Or, in a few years, when there are parts of countries in space, maybe there'll be a planetoid name between the country and the region. Or maybe that will go on the other side of the country. I think trying to guess how things will be extended is a fool's errand. If we use numbers, we paint ourselves into a corner with extensions anywhere but at the deepest level. Fundamentally, studying all the alternatives we've considered so far, they all suck. - some have weird names like "subsubregion". - some use numbers - some have synonyms - some leave gaps in addresses for some locales where it's not obvious where the gap should be - some are non-trivial to extend later I think I'm going to just go with more or less what you first proposed: "address-line1" | "address-line2" |- "street-address" "address-line3" | "address-level4" "address-level3" "address-level2" / "locality" "address-level1" / "region" "country-name" That is, make "locality" and "region" synonyms for two new fields, add two more, and say in the spec that different locales have different numbers of levels and that as many should be included as are appropriate, starting with level1 as the widest administrative division. I've filed a bug on this topic; if I can get agreement from other vendors, then I'll go ahead and spec this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235 On Wed, 5 Mar 2014, Edward O'Connor wrote: > > The techniques browsers use for autofilling auth information would > benefit enormously from some additional autocomplete="" values. The wiki > page Ilya mentioned captures the use cases pretty well. I think these > are the critical ones that capture the most common cases: > > # Passwords > > On "change your password" forms, which <input type=password> is your > current password? Which is the new password? Browsers want to avoid > filling the old password into the new or confirm password fields. > Additionally, distinguishing such fields would help tools that generate > passwords. These are useful on both sign-up and change password forms. > > <input type=password> - your current password > <input type=password autocomplete=new> - a new password > <input type=password autocomplete=confirm> - the new password, again > > Next to the other autocomplete values, "new" and "confirm" don't look > descriptive enough. "new-password" and "confirm-password", maybe? > "<input type=password autocomplete=new-password>" feels redundant and > verbose to me. Is there any reason to have two fields here, why not just "new" both times? Also, should we have an "old" field for the old password, or is the lack of an autofill field sufficient? I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236 It needs multiple vendors on board to make progress. > # Usernames > > Lots of websites use email addresses as usernames. Tools should be able > to distinguish email-used-as-username fields from other email fields. > This can also help on "forgot password"/"forgot username" forms. > > <inpyt type=text autocomplete=username> - your username on this site > <input type=email> - your preferred email address > <inpyt type=email autocomplete=username> - your username on this site, > not your preferred email > address > <input type=url autocomplete=username> - OpenID This seems reasonable. I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25237 It needs multiple vendors on board to make progress. > Also, consider the case of login forms without username fields. You see > this sort of thing a lot these days, when sites remember who was last > logged in: > > <form> > <label>Password for hober: <input type=password name=pw></label> > <p>Not hober? <a href=...>Click here to sign in</a>. > </form> > > It's difficult for tools to manage the user's auth info for such pages. > How can tools discover what the username is? The obvious solution, in a > world with autocomplete=username, would be to add <input type=hidden > autocomplete=username name=username value=hober> to the form. So far, autocomplete="" hasn't applied to <input type=hidden>. This would be a bit weird, giving it a different meaning than usual (providing information to the UA, rather than getting information from the UA). I'm a bit skeptical of this kind of overloading. Not sure what the right solution is, though. On Fri, 7 Mar 2014, Garrett Casto wrote: > > Another related issue that would be nice to address would be allowing > sites to positively assert that authentication succeeded. For sites that > authenticate client side via XHR, standardizing something like > window.external.AutoCompleteSaveForm() would be very helpful. For sites > that validate server side, I'm less sure what the correct avenue to > convey this information would be (response code, header, ...). I'm > assuming that this will be more contentious than adding username and > password attribution and I don't want to hold that up, but I would like > to see opinions on this. I actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. For the pure JS case, an API (probably on the <form> itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 For the real submission case, I guess what we want is a way to say "autocomplete=off" after the fact, basically. An HTTP header seems like the most obvious solution. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 Again, these need multiple vendors on board to make progress. On Mon, 10 Mar 2014, Evan Stade wrote: > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=?cc-number? the browser might provide an experience tailored > for a payment flow, or if there?s an element with autocomplete=?bday? the > browser might use an experience that?s tailored for sharing identiy. > > We?ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element.requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: ?transactionAmount? > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: ?transactionCurrency? > value: string > description: a valid ISO 4217 currency code that describes the currency > for transactionAmount. If not provided, the default is ?USD?. > > Justification? There are upper bounds on certain payment instruments, > for example different credit cards have different credit limits; a debit > card is linked to a bank account with a certain balance. It?s a much > preferable user experience to be able to catch these problems earlier > rather than waiting for the merchant to attempt the transaction and have > it fail (or have a user?s account overdrawn). Concretely, Chromium wants > to handle transactions over $2000 differently from transactions under > that amount. > > Does this seem reasonable? The requestAutocomplete() API is a Chrome proprietary feature right now so it's sort of acadmic, but: Why would this only apply to requestAutocomplete()? Surely it would be just as important for the case where the user agent is filling in a form without using that API. Also, I don't understand how these are supposed to work. How is the browser supposed to know the balance on my credit cards or bank accounts? How is the browser supposed to know which of my cards are good for USD and which are good for GBP? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 14:00:33 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 21:00:33 +0000 (UTC) Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> References: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404022057240.21310@ps20323.dreamhostps.com> On Wed, 2 Apr 2014, Bob Owen wrote: > > > > Did you receive any off-list feedback on this, or attempt to implement > > it and get any implementation experience? > > Thanks for getting back to me Ian. > No, no other feedback. > I have a patch for it, but haven't pursued it any further. > I could investigate putting the change in for Firefox Nightly, if you think > that might help with finding any compat issues. Well as far as I'm concerned, I would encourage you to try to converge on the spec behaviour. If it turns out there are compatibility issues, that would be good to know. If not, then at least we win more interoperability. > I can also see that both pieces of information (original opener and last > navigator) might be useful. So, maybe the other could be added either > way. I haven't heard any author demand for it, so I haven't added it, but indeed, if this is something authors have a use for, we could add it. It's worth noting that there are many many ways to navigate a browsing context beyond window.open(), e.g. <a target="">, window.location, drag-and-drop of a link, window.history.go(), etc. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bobowencode at gmail.com Wed Apr 2 15:09:00 2014 From: bobowencode at gmail.com (Bob Owen) Date: Wed, 2 Apr 2014 23:09:00 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> On 2 April 2014 22:00, Ian Hickson <ian at hixie.ch> wrote: > It's worth noting that there are many many ways to navigate a browsing > context beyond window.open(), e.g. <a target="">, window.location, > drag-and-drop of a link, window.history.go(), etc. Absolutely, if we were to converge on the spec for the current opener and people felt that last navigator would be useful, then it would need to be updated in all cases. Although, the history case might hold the original state. Anyway, getting way ahead of myself. I'll see if there are any more opinions, then look to move Gecko towards the spec and see if any compat issues arise. From tingan87 at gmail.com Wed Apr 2 21:37:33 2014 From: tingan87 at gmail.com (Tingan Ho) Date: Thu, 3 Apr 2014 12:37:33 +0800 Subject: [whatwg] More effective model for handling resources In-Reply-To: <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> References: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> Message-ID: <CAOr4atVY-mv1aCMwdY0ijz3vPcsYLdQzb_dgu5kx8kTkDSOXuQ@mail.gmail.com> Hi Ian, I believe this is being handled by the next-generation transport protocols > (SPDY or whatever it's called now). I recommend approaching the relevant > groups to check that your precise case has been handled. I just found out that SPDY Server Push and Cookies could accomplish the above mentioned caching. Cookies will take care of information providing. And the server just uses Server Push to push content. On Thu, Apr 3, 2014 at 1:57 AM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 13 Mar 2014, Tingan Ho wrote: > > > > Almost all web developer I know use externally linked CSS resource in > > their web projects. That means that the browser needs to (1) request the > > html page (2) parse the html (3) request for the CSS resource that is > > linked from the html document. The problem with externally linked > > resources is point three. It needs to make another request for the CSS > > resource. There is a solution to this problem and that is to inline the > > CSS. Though that would yield another problem: all subsequent page > > request will become bigger. > > I believe this is being handled by the next-generation transport protocols > (SPDY or whatever it's called now). I recommend approaching the relevant > groups to check that your precise case has been handled. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- Sincerely, Tingan Ho From lists at scratchdisk.com Wed Apr 2 23:21:38 2014 From: lists at scratchdisk.com (=?iso-8859-1?Q?J=FCrg_Lehni?=) Date: Thu, 3 Apr 2014 08:21:38 +0200 Subject: [whatwg] Grouping in canvas 2d In-Reply-To: <alpine.DEB.2.00.1403141808380.32463@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <CAGN7qDBHT_fitzzsrnGe6exCWr1Fc4mXSnY=_KW7fNjkoB6-KA@mail.gmail.com> <CABpaAqTdv4TaDpXj4jksL+jeDVqv9cKyVvxJO1nridR9Zwq66Q@mail.gmail.com> <CAGN7qDA9BfpOCqzAmbwooJ_aSw8cbLT-G_-can61K05Q7YsLMw@mail.gmail.com> <73A19694-2AB0-4948-8B4B-A5ED820B2444@scratchdisk.com> <alpine.DEB.2.00.1403141808380.32463@ps20323.dreamhostps.com> Message-ID: <6D69D840-D0F2-4547-AB63-8288C2E51A1D@scratchdisk.com> Here another simple example: When both filling and stroking a path and then drawing it with with an opacity of less than 100%, the path will be rendered differently than in an SVG (a large stroke width will make the issue more apparent): - In Canvas, both the fill and the stroke will be rendered with the given opacity, and the fill will shine through the inner half of the stroke. - In SVG, the stroke will cover the fill, and the fill will not shine through the inner half of the stroke, regardless of the opacity. If you'd like to emulate the SVG behavior in Canvas (which we happen to do in Paper.js), then the only way to do so currently is to draw the path's fill and stroke at 100% opacity into a separate canvas, and then blit the whole thing over with the given opacity. This is *much* slower than directly drawing into the Canvas, and happens to be one of the worst bottlenecks in Paper.js I would really appreciate a solution to this problem. J?rg On Mar 14, 2014, at 19:09 , Ian Hickson <ian at hixie.ch> wrote: > Can you elaborate on what precisely the performance bottleneck is? I was > looking through this thread but I can't find a description of the use > cases it addresses, so it's hard to evaluate the proposals. From mkwst at google.com Thu Apr 3 02:49:20 2014 From: mkwst at google.com (Mike West) Date: Thu, 3 Apr 2014 11:49:20 +0200 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <CAKXHy=cm3F1noHs1SM4XSOpno4aB1GPQ9mhjyva9v+6EU9v3HA@mail.gmail.com> On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson <ian at hixie.ch> wrote: > > Also, consider the case of login forms without username fields. You see > > this sort of thing a lot these days, when sites remember who was last > > logged in: > > > > <form> > > <label>Password for hober: <input type=password name=pw></label> > > <p>Not hober? <a href=...>Click here to sign in</a>. > > </form> > > > > It's difficult for tools to manage the user's auth info for such pages. > > How can tools discover what the username is? The obvious solution, in a > > world with autocomplete=username, would be to add <input type=hidden > > autocomplete=username name=username value=hober> to the form. > > So far, autocomplete="" hasn't applied to <input type=hidden>. This would > be a bit weird, giving it a different meaning than usual (providing > information to the UA, rather than getting information from the UA). I'm a > bit skeptical of this kind of overloading. > > Not sure what the right solution is, though. > As Garrett noted, this is already a solution Google is using, though not with explicit syntax, just taking advantage of existing heuristics. Paving this (potential) cowpath isn't really that weird. That said, an alternative might be to add a mechanism of associating autocompletion metadata with the field in order to give the UA enough context to fill it in. For example, if a password is being requested for a known username, that username could be added as an new "autocomplete-username" attribute (similar to the 'data-*' construct HTML already supports): <input type="password" autocomplete-username="hober"> -mike -- Mike West <mkwst at google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) From andy at pigsonthewing.org.uk Thu Apr 3 03:22:48 2014 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu, 3 Apr 2014 11:22:48 +0100 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <CABiXOEmndoUXWk1nWk00RyFsA6g2M8M0ZOofTctP+_oxC4odvQ@mail.gmail.com> [General point, so not quoting anyone in particular] [Resending to list, apologies to Ian] Why would you define any address components other than those in vCard, a standard with massive implementation and interoperable with most address book applications and services? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk From creis at chromium.org Thu Apr 3 11:28:15 2014 From: creis at chromium.org (Charlie Reis) Date: Thu, 3 Apr 2014 11:28:15 -0700 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> References: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> Message-ID: <CAH+8MBaU3NSq+WvZ2iG8n_-EAaSBZTA_fYOLoMw0NkFpRf4MiA@mail.gmail.com> On Wed, Apr 2, 2014 at 3:09 PM, Bob Owen <bobowencode at gmail.com> wrote: > On 2 April 2014 22:00, Ian Hickson <ian at hixie.ch> wrote: > > > It's worth noting that there are many many ways to navigate a browsing > > context beyond window.open(), e.g. <a target="">, window.location, > > drag-and-drop of a link, window.history.go(), etc. > > Absolutely, if we were to converge on the spec for the current opener and > people felt that last navigator would be useful, then it would need to be > updated in all cases. > Although, the history case might hold the original state. > > Anyway, getting way ahead of myself. > I'll see if there are any more opinions, then look to move Gecko towards > the spec and see if any compat issues arise. > For what it's worth, I think we'd be open to changing Blink to match the spec as well, if you don't find any compat issues. Charlie From bobowencode at gmail.com Fri Apr 4 01:40:50 2014 From: bobowencode at gmail.com (Bob Owen) Date: Fri, 4 Apr 2014 09:40:50 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEEDiH1N_9rex+Dq_8nzQrCVnpa8djiJGsc1xP3zHCLLY4g@mail.gmail.com> On 3 April 2014 19:28, Charlie Reis <creis at chromium.org> wrote: > For what it's worth, I think we'd be open to changing Blink to match the spec as well, if you don't find any compat issues. I'd say it's worth a lot, thanks Charlie. From faulkner.steve at gmail.com Sat Apr 5 00:59:03 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Sat, 5 Apr 2014 08:59:03 +0100 Subject: [whatwg] summary/details - proposal Message-ID: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> note: bringing this to the whatwg list to elicit feedback from implementers and other interested parties that are not involved in the discussion at the W3C Currently the implementation(s) of summary/details elements do not match the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element In the spec, the details element is interactive content, the summary is not, its a summary, caption, or legend. in webkit/blink the summary element is the interactive element (when pressed it opens/closes the details element) This is good because it provides a large default hit region to activate the control example to try in chrome/safari/opera http://codepen.io/stevef/pen/CyauJ/ So as the spec/implementations are at odds, the implementations need to change to match the spec or the spec needs to change to match implementations or the spec needs to change to accommodate the positive aspects of the current implementations while allowing for other use cases An issue with current implementations is that when the summary element includes other interactive elements (as it is allowed to), clicking on them results in the details element being opened/closed (although this can be overcome via scripting). example to try in chrome/safari/opera http://codepen.io/stevef/pen/xjJiy/ Issues with the current spec text: The interactive part of the details element is the disclosure triangle ? which is supposed to be an anonymous control in the shadow DOM The <summary> itself is not interactive, so only the triangle provides the actionable control. the summary text which is effectively the label for control does not activate the control. There is no method provided to associate a label with the anonymous control that can (a) provide an increased hit region and (b) provide an explicitly associated label for the anonymous control. Given that what we want to provide for the use case of having controls inside the summary, after discussion around the issue[1], I have proposed the following: <details> <summary id=x> <label for=x>Foo</label> </summary> ... </details> what this does is provide the author with the ability to add an explicit label (providing the acc name) to the details control which also increases the click region for improved accessibility/usability, while still allowing interactive content inside the summary element. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25140 feedback welcome! -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From dschulze at adobe.com Sat Apr 5 09:01:19 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sat, 5 Apr 2014 16:01:19 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() Message-ID: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> Hi, I looked at the behavior of negative width or height for the rect() and strokeRect() functions. All browsers normalize the passed parameters for strokeRect() to have positive width and height. strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) http://jsfiddle.net/za945/ Just WebKit seems to normalize for rect() as well: http://jsfiddle.net/VT4MG/ The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. Greetings, Dirk From cabanier at gmail.com Sat Apr 5 18:23:06 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 5 Apr 2014 18:23:06 -0700 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> Message-ID: <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > Hi, > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > strokeRect(90,10,-80,80) --> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ I'm unsure why such a rectangle is defined as a straight line. > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ > > The behavior of normalizing is not specified. Especially it seems odd that > the behavior for fillRect()/strokeRect() should differ from rect(). So we > should either normalize for all functions or don't do it for all IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for rect() > is important for filling with different winding rules as well. It is not > just stroking with dash arrays that is effected. > yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect From ian at hixie.ch Sat Apr 5 21:11:20 2014 From: ian at hixie.ch (Ian Hickson) Date: Sun, 6 Apr 2014 04:11:20 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> On Sat, 5 Apr 2014, Steve Faulkner wrote: > > The <summary> itself is not interactive, so only the triangle provides > the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). > Given that what we want to provide for the use case of having controls > inside the summary, after discussion around the issue, I have proposed > the following: > > <details> > <summary id=x> <label for=x>Foo</label> </summary> > ... > </details> That's way more complicated than necessary for authors, not to mention all the problems it would cause with the existing <label> definitions. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dschulze at adobe.com Sat Apr 5 23:00:50 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 06:00:50 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> Message-ID: <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > Hi, > > I looked at the behavior of negative width or height for the rect() and strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have positive width and height. > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ > >> It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ >> I'm unsure why such a rectangle is defined as a straight line. You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ > > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ > > The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. > >> yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw ?in that order? for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. Greetings, Dirk > > 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect From dschulze at adobe.com Sat Apr 5 23:23:36 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 06:23:36 +0000 Subject: [whatwg] Canvas Computing text metrics Message-ID: <69477B5B-A7A4-4674-B267-09EC2499C1F0@adobe.com> Hi, The spec says that the object TextMetrics[1] must return font and actual text metrics. All things require information from the font or the font system. In many cases either font or font system just do not provide these information. Instead of assuming that all information are accessible by the browser, it might be useful to define some heuristics that can be used. In WebKit and Blink we support the CSS dominant-baseline property in SVG that requires similar metrics as well[2]. Even SVG does not specify the heuristics yet and instead leaves that up to the browser. WebKit and Blink use the heuristics described in the documentation from Apache FOP[1]. Should these be used as fallback heuristics? Note: Many browsers might use heuristics by default since they can?t get all necessary font metrics at all. Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#textmetrics [2] http://www.w3.org/TR/SVG11/text.html#TextAlignmentProperties [3] http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling From cabanier at gmail.com Sat Apr 5 23:24:19 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 5 Apr 2014 23:24:19 -0700 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> Message-ID: <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > > > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > > Hi, > > > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > > > strokeRect(90,10,-80,80) --> strokeRect(10,10,80,80) > > > > http://jsfiddle.net/za945/ > > > >> It also seems that only firefox is following the spec [1] when width or > height are 0: http://jsfiddle.net/za945/2/ > >> I'm unsure why such a rectangle is defined as a straight line. > > You mean you would rather let it draw a one dimensional rectangle? So for > the dimension that is not zero, you would see two overlapping lines + the 0 > dimensional sides? > yes That seems indeed to be the case for IE, Safari and Blink: > http://jsfiddle.net/Gh9XK/ > > > > > Just WebKit seems to normalize for rect() as well: > > > > http://jsfiddle.net/VT4MG/ > > > > The behavior of normalizing is not specified. Especially it seems odd > that the behavior for fillRect()/strokeRect() should differ from rect(). So > we should either normalize for all functions or don't do it for all IMO. > > > > Note: fillRect() and clearRect() are not affected. The behavior for > rect() is important for filling with different winding rules as well. It is > not just stroking with dash arrays that is effected. > > > >> yes, the spec needs to say "in that order" as it does for fillRect and > strokeRect. > > Ok, that means you would be in favor not to normalize. Again, all current > browser normalize and do NOT draw "in that order" for fillRect() and > strokeRect(). That means you would require to give up the currently > interoperable behavior. > I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) I would be in favor to change the blink/webkit behavior as the specified one makes more sense. From dschulze at adobe.com Sun Apr 6 00:04:46 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 07:04:46 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> Message-ID: <872B4940-A589-46D1-B72B-B302E7FCC1E3@adobe.com> On Apr 6, 2014, at 8:24 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > > > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > > Hi, > > > > I looked at the behavior of negative width or height for the rect() and strokeRect() functions. > > > > All browsers normalize the passed parameters for strokeRect() to have positive width and height. > > > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > > > http://jsfiddle.net/za945/ > > > >> It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ > >> I'm unsure why such a rectangle is defined as a straight line. > > You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? > > yes > > That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ > > > > > Just WebKit seems to normalize for rect() as well: > > > > http://jsfiddle.net/VT4MG/ > > > > The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. > > > > Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. > > > >> yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. > > Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw ?in that order? for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. > > I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ > Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) Firefox has a strange different behavior if dash >= gap. If the gap is smaller it behaves like IE, Blink and WebKit. This also answers your question: Your example renders in IE the same as in WebKit and Blink. Greetings, Dirk > > I would be in favor to change the blink/webkit behavior as the specified one makes more sense. From ian at hixie.ch Tue Apr 1 11:55:24 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 18:55:24 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <20140205183607.GA56968@sideshowbarker> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> Message-ID: <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> On Tue, 4 Feb 2014, Cameron McCormack wrote: > Ian Hickson wrote: > > I'm all for handling it in one place. What precisely do you want the > > behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- "the first > > <svg:title> element" may come after "the first<html:title> element", and > > vice versa. Also consider when one or the other is "primary" but the > > relevant element is absent.) > > OK, how about: if the document element is an <html:html>, we choose the > first <html:title> in document order; if the document element is an > <svg:svg>, we choose the first child <svg:title> of the document > element; otherwise, null. > > This still is going to produce "incorrect" results for things like: > > <!DOCTYPE html> > <svg> > <foreignObject> > <title>blah > > > > but arguably you shouldn't be using in there anyway. It doesn't seem useful to hit that element. It's not the (SVG) document title, after all. I ended up going with: - if it's an SVG document, use the first <title> child of the root element - if it's an HTML document, use the first <title> element in tree order (that's what it used to be) For setting it uses the same element, unless there isn't one, in which case: - if it's an SVG document, append an SVG <title> to the root element - if it's an HTML document, append a <title> to the <head> Hopefully that's compatible enough. Let me know if you need something different. On Mon, 3 Feb 2014, Jonas Sicking wrote: > > An even simpler solution would be to say "we choose the first > <html:title> or <svg:title> in document order". That has the nice > property that we align SVG and HTML more. This seems to not quite match the SVG semantics, unfortunately. On Wed, 5 Feb 2014, Simon Pieters wrote: > > Is there a situation in which it is conforming to use html:title outside > the <head> in a document where the root is html:html? In > math:annotation-xml? You can certainly imagine a compound document format containing entire HTML subdocuments, <html>, <head>, <title>, and all. I'm not sure that's possible with just SVG and HTML currently though. (Maybe MathML, indeed.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 12:01:46 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 19:01:46 +0000 (UTC) Subject: [whatwg] microdata questions In-Reply-To: <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> References: <CAGYLO0+N_3BTmKM6+2XLcghm2d0GSy36xubRJKTR5KWEnGhvNg@mail.gmail.com> <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404011857230.11249@ps20323.dreamhostps.com> On Mon, 10 Feb 2014, Eric Devine wrote: > > 1. Section 5.5.1 of the Microdata spec prescribes how microdata should > be respresented as JSON, but it does provide a MIME type. I'm writing a > REST API that I would like to be able to return JSON in microdata > format, but I need the client to explicitly request this via the HTTP > Accept header. The main concern is to know when to return plain > properties as an array with one element. As a general rule I would recommend against using Accept headers to do anything. You're better off making the JSON data its own resource, IMHO. Having said that, as you noted in a later e-mail, the MIME type suggested by the HTML spec is "application/microdata+json". http://whatwg.org/html#application/microdata+json > 2. Section 5.2.4 does not provide a way to apply a property value to the > value attribute of an <option> element. Is this an oversight, or is > there simply not a convincing enough use case for the need? There's not any way currently to make for controls map to microdata. It's not clear exactly what it would mean. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jonas at sicking.cc Tue Apr 1 12:58:12 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Tue, 1 Apr 2014 12:58:12 -0700 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> Message-ID: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 3 Feb 2014, Jonas Sicking wrote: >> >> An even simpler solution would be to say "we choose the first >> <html:title> or <svg:title> in document order". That has the nice >> property that we align SVG and HTML more. > > This seems to not quite match the SVG semantics, unfortunately. Does it break existing content? If not, why not ask the SVG spec to be changed? The thread was started by one of the SVG spec editors after all. / Jonas From ian at hixie.ch Tue Apr 1 13:29:59 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 20:29:59 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404012027040.21310@ps20323.dreamhostps.com> On Tue, 1 Apr 2014, Jonas Sicking wrote: > On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Feb 2014, Jonas Sicking wrote: > >> > >> An even simpler solution would be to say "we choose the first > >> <html:title> or <svg:title> in document order". That has the nice > >> property that we align SVG and HTML more. > > > > This seems to not quite match the SVG semantics, unfortunately. > > Does it break existing content? If not, why not ask the SVG spec to be > changed? The thread was started by one of the SVG spec editors after > all. Dirk and heycam's replies to your original e-mail here suggest that this is not really viable. I mean, it'd be like changing document.title in HTML to point to the first title="" attribute in the document if it came before the first <title>. Anyway, what the spec ended up saying is in some ways even simpler, since it only looks one level deep for SVG rather than doing a deep tree search. (Is this the kind of change that you would have liked pre-flighted? I can revert the change and put out an announcement if you like. I'm not yet sure I exactly understand what kinds of changes fall into this category.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 17:02:51 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 00:02:51 +0000 (UTC) Subject: [whatwg] <keygen> and X509 client cert mime type In-Reply-To: <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> References: <2E519EB1-CB5D-48E1-8435-BEF2616E9F9C@bblfish.net> <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> Message-ID: <alpine.DEB.2.00.1404012343180.11249@ps20323.dreamhostps.com> On Tue, 25 Feb 2014, henry.story at bblfish.net wrote: > > The keygen form element does a great job of specifying how the browser > creates a public/private key pair, stores the private key in it's local > keystore. > > "When the control's form is submitted, the private key is stored in the > local keystore, and the public key is packaged and sent to the server." > > It is clear that the intention is for the server to send back a > certificate built from the public key. What I can't find is what the > mime type of the returned certificate should be. I have been using > `application/x-x509-user-cert` which seems to work for Safari, Firefox, > Opera . But I think that is not an officially supported certificate > type. application/pkix-cert seems to be that after looking it up on > iana. > > I ended up posting a bug report for Android on that. > http://code.google.com/p/android/issues/detail?id=66342 > > But now I have to check for each browser which is the type all browsers > support. To avoid people having to do this research again and again, > perhaps it would be worth specifying a mime type that all browsers > do/must support in the HTML5 spec? On Wed, 26 Feb 2014, henry.story at bblfish.net wrote: > > (1) most browsers currently understand the mime types > (a) application/x-x509-user-cert > (b) application/x-x509-ca-cert > (c) application/x-x509-email-cert > ( I have only verified (a) btw. I am assuming the others also support (b) and (c) ) > as specified here > https://wiki.mozilla.org/CA:Certificate_Download_Specification > > (2) the above mime types are not registered > http://www.iana.org/assignments/media-types/media-types.xhtml > > So really either the old mime types should be registered, or they should > be mentioned as being in use but deprecated and people should be guided > towards the application/pkix-cert I wouldn't worry too much about registered vs not registered. If the registry doesn't match the implementations, the registry is buggy. On the other hand, I also don't want to get into the business of specifying this stuff myself. I've added a link to the above MDN page to the keygen section. If there is ever something more canonical (and yet still useful and accurate), let me know and I'll update the spec. Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:43:08 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:43:08 +0000 (UTC) Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEEAS0O79Ko7QrxXKE8YxaVZha5Hzr_bqpAaJrb2PKHQggA@mail.gmail.com> References: <CA+dJEEAS0O79Ko7QrxXKE8YxaVZha5Hzr_bqpAaJrb2PKHQggA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021739430.11249@ps20323.dreamhostps.com> On Mon, 3 Mar 2014, Bob Owen wrote: > > The spec [...] seems to be fairly clear that if an existing window is > navigated using window.open, by a browsing context that is not the > original opener, then window.opener should remain unchanged. > > Currently, Trident (and incidentally Presto) seems to have the correct > behaviour, but Blink, WebKit and Gecko all change window.opener to the > window of the browsing context that has just caused it to navigate. I > believe this to be a very long standing difference (>10 years for Gecko > and Trident) > > I am proposing to change Gecko to match the spec, but I was advised to > raise the issue here before going ahead. > > Do people agree that window.opener should remain unchanged in this > circumstance? Did you receive any off-list feedback on this, or attempt to implement it and get any implementation experience? Having "opener" be the actual opener seems pretty intuitive to me; if there's no compat need to do otherwise, it seems like a reasonable choice. Is there a security reason to prefer the latest navigator? (At the time the spec was written, it was 2v2; the 1v3 situation we have now is the result of Presto going away and Blink forking from WebKit.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:52:14 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:52:14 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> On Mon, 3 Mar 2014, Ami Fischman wrote: > > Looks like we're back in business: > > Latest editor's draft: > http://dev.w3.org/2011/webrtc/editor/getusermedia.html Thanks. As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:57:11 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:57:11 +0000 (UTC) Subject: [whatwg] More effective model for handling resources In-Reply-To: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> References: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> On Thu, 13 Mar 2014, Tingan Ho wrote: > > Almost all web developer I know use externally linked CSS resource in > their web projects. That means that the browser needs to (1) request the > html page (2) parse the html (3) request for the CSS resource that is > linked from the html document. The problem with externally linked > resources is point three. It needs to make another request for the CSS > resource. There is a solution to this problem and that is to inline the > CSS. Though that would yield another problem: all subsequent page > request will become bigger. I believe this is being handled by the next-generation transport protocols (SPDY or whatever it's called now). I recommend approaching the relevant groups to check that your precise case has been handled. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 11:09:15 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 18:09:15 +0000 (UTC) Subject: [whatwg] inverse property mechanism for Microdata? In-Reply-To: <CAK-qy=6VGPOJshUqSg_BuVU44UUqV9WLxtJAdRUm-pnk=XDKnw@mail.gmail.com> References: <CAK-qy=7SuUq_4Ung06+1CLySJ3D7Aiv_1uyAZnJzc+jPuOcYHw@mail.gmail.com> <alpine.DEB.2.00.1401312334310.26647@ps20323.dreamhostps.com> <CAK-qy=6_ZQ5NCxVSqHraa-Lc1P88vY8BpuacLbj3_QyFpG5jnQ@mail.gmail.com> <alpine.DEB.2.00.1403172046390.31525@ps20323.dreamhostps.com> <CAK-qy=6VGPOJshUqSg_BuVU44UUqV9WLxtJAdRUm-pnk=XDKnw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021759091.11249@ps20323.dreamhostps.com> On Wed, 19 Mar 2014, Dan Brickley wrote: > > > > This is what the example would look like if I'm understanding this right: > > > > <div itemscope itemtype="http://schema.org/LocalBusiness"> > > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > > Giftware</span></h1> > > <span itemprop="description"> A superb collection of fine gifts and clothing > > to accent your stay in Mexico Beach.</span> > > Phone: <span itemprop="telephone">850-648-4200</span> > > > > <div itemscope itemtype="http://schema.org/LocalBusiness" > > itemprop-up="containedIn"> > > <h2><span itemprop="name">(Entity B) The tiny store within a > > store</span></h2> > > <span itemprop="description"> A superb collection of tiny clothes, > > from the store within the store.</span> > > Phone: <span itemprop="telephone">123-456-7890</span> > > </div> > > > > </div> > > > > It's not too bad, I guess. > > Yes. I notice that the words we were playing with at schema.org relate > to the underlying graph data model itemprop-inverse, -reverse etc., > whereas your draft name, itemprop-up is about the markup hierarchy. Yeah. I think most authors think in terms of what they see (their markup), not in terms of the data model. (I have had a _lot_ of conversations with authors where it was clear that they had no idea there was an underlying data model for the microdata that was separate from the markup.) > Yup, there are some cases where this can be addressed through the > rigorous use of entity IDs in itemid, as you sketch below. That would be > relatively new territory for schema.org and for publishers. Perhaps > there is an attribute name we can find that would leave the door open to > more use cases, e.g. "itemprop-backwards" rather than "itemprop-up". It > seems reasonable to try to address relationships between sibling > elements too. Well you'd been a new attribute to do that, unless I'm misunderstanding your proposal. Maybe you mean this attribute wouldn't point to a relative place in the markup, but would point to an identified element given by another attribute? I think that would be quite confusing. > Something like (trying out -backwards instead of -up, to allow for > non-hierarchical usage): > > <div itemid="bigshop" itemscope itemtype="http://schema.org/LocalBusiness"> > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > Giftware</span></h1> > </div> > <div itemscope itemtype="http://schema.org/Pharmacy"> > <meta itemprop-backwards="containedIn" itemid="bigshop" /> > <h2><span itemprop="name">Tiny pharmacy store within a store</span></h2> > </div> > > ? > > Can we use itemid in that way, to give a property value too? I don't > see itemid used much in the wild and the spec only mentions its use > for the item having the property, rather than using when supplying the > value of a property. itemid="" is a URL that gives the identifier of the item. We'd want to use a new attribute to do something like this; e.g.: itemrelation="containedIn bigshop" where "itemrelation" takes just two keywords, a property name and the ID (not itemid) of the target element. But that's pretty elaborate. Is there a need for this? Or is the relationship to the parent all that's needed? In your original e-mail you only suggested wanting to go up. > > Microdata actually already has a solution to this. The vocabulary can > > define an ID for each item using itemid="", and can define multiple items > > having the same ID as being the same conceptual item. Thus: > > > > <!-- first episode --> > > <div itemscope itemtype="http://schema.org/Episode"> > > ... > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"></div> > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"></div> > > </div> > > > > <!-- second episode --> > > <div itemscope itemtype="http://schema.org/Episode"> > > ... > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"></div> > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"></div> > > </div> > > > > <!-- actors --> > > <div itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"> > > ... > > </div> > > <div itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"> > > ... > > </div> > > > > This also enables the data to be spread across multiple pages without > > confusion. (This is similar to how RDF uses identifiers for everything > > -- essentially, in RDF terms, this turns the microdata item from a > > bnode into a node with a global identifier.) > > Yes, it succeeds or fails to the extent people agree on these global > identifiers. Do people not agree on them, typically? > > Your example would become: > > > > <div itemscope itemtype="http://schema.org/LocalBusiness" > > itemid="..."> > > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > > Giftware</span></h1> > > <span itemprop="description"> A superb collection of fine gifts and clothing > > to accent your stay in Mexico Beach.</span> > > Phone: <span itemprop="telephone">850-648-4200</span> > > > > <div itemscope itemtype="http://schema.org/LocalBusiness"> > > <div itemprop="containedIn" > > itemscope itemtype="http://schema.org/LocalBusiness" > > itemid="..."></div> > > <h2><span itemprop="name">(Entity B) The tiny store within a > > store</span></h2> > > <span itemprop="description"> A superb collection of tiny clothes, > > from the store within the store.</span> > > Phone: <span itemprop="telephone">123-456-7890</span> > > </div> > > > > </div> > > > > Is this not suitable for schema.org? Or is it just too much markup? > > It's in the clever-but-fragile category, I'd say. So yes, a bit too > much markup. In English this is saying something like > > "We're describing a LocalBusiness whose global ID is [xyz]; it has > certain name, description, telephone properties given here. > There is also a LocalBusiness that is containedIn a LocalBusiness > whose global ID is [xyz]; this [other] LocalBusiness has the following > name, description, telephone etc properties...." > > Just as in the English, it is rather easy to lose track of which > LocalBusiness we're talking about. I think you overstate the complexity, but ok. > >> > That is another option, similar to the parenthetical itemid="" note > >> > above -- you could just have the vocabulary define that for every > >> > property whose value is an item, the item type that that property > >> > can point to has another property with the same name plus a fixed > >> > suffix, like "-inv", that inverses the relationship. [...] > >> > >> This is easier to understand than itemref, but still involves > >> creating 100s of additional properties instead of just one new piece > >> of syntax. > > > > What do you mean by "creating additional properties" here? It's > > relatively trivial to define these with one sentence, you don't need > > to actually list them or anything. Implementing support is similarly > > easy, as far as I can tell -- you just check for the suffix or prefix > > and handle it accordingly. > > Re "you don't need to actually list them", this effectively creates two > classes of property. Real ones, and fake/pseudo properties which we're > pretending exist so that we can re-use a piece of syntax that expects a > property name. Once these pseudo properties are released into the wild, > they'll show up as if they were real. They would be real, I'm just saying that documenting them and implementing them is somewhat trivial. > What we want to avoid is saying things like: > > "You can use itemprop='containedIn-rev' to indicate a property that > means the inverse of containedIn. However this is not a first class > schema.org property, and should not be used other syntaxes (JSON etc), > data dumps, APIs etc. You should canonicalize x containedIn-rev y > into: y containedIn x., ..." Why wouldn't it be a first-class property? It could trivially be so. The implementation is easy, whatever the vocabulary it's used in. > > If you do want to go with a new property, just use the name you would > > want in the spec. I weakly recommend "itemprop-up", which is the most > > intuitive name I've seen so far for this, but if you find a better > > name just use that. I guarantee that I won't make the spec conflict > > with whatever you use, as long as you tell me what it is. :-) Assuming > > that it works well, then we would just update the spec to use that > > term directly, retroactively making the experimental content > > conforming. > > Thanks! I'll discuss this thread with the schema.org team. My guess is > that there's still a strong preference for a new property, and we'd be > happy to avoid using data-*. > > If I understand right, the outstanding area of discussion/confusion is > whether there are cases beyond simple DOM element containment where we > might want to use an inverse itemprop construction (even though we can > see how itemid everywhere might also be used). If we're only using > element hierarchy then itemprop-up could work. Did you reach any conclusions in these discussions? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bobowencode at gmail.com Wed Apr 2 13:16:58 2014 From: bobowencode at gmail.com (Bob Owen) Date: Wed, 2 Apr 2014 21:16:58 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> On 2 April 2014 18:43, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Mar 2014, Bob Owen wrote: > > > > The spec [...] seems to be fairly clear that if an existing window is > > navigated using window.open, by a browsing context that is not the > > original opener, then window.opener should remain unchanged. > > > > Currently, Trident (and incidentally Presto) seems to have the correct > > behaviour, but Blink, WebKit and Gecko all change window.opener to the > > window of the browsing context that has just caused it to navigate. I > > believe this to be a very long standing difference (>10 years for Gecko > > and Trident) > > > > I am proposing to change Gecko to match the spec, but I was advised to > > raise the issue here before going ahead. > > > > Do people agree that window.opener should remain unchanged in this > > circumstance? > > Did you receive any off-list feedback on this, or attempt to implement it > and get any implementation experience? Thanks for getting back to me Ian. No, no other feedback. I have a patch for it, but haven't pursued it any further. I could investigate putting the change in for Firefox Nightly, if you think that might help with finding any compat issues. > Having "opener" be the actual opener seems pretty intuitive to me; if > there's no compat need to do otherwise, it seems like a reasonable choice. > > Is there a security reason to prefer the latest navigator? Agreed, the specified behaviour makes sense to me, if only because of the name. The fact that you can also use window.open for subsequent navigation (which leads to the different behaviours), muddies the water a bit, but that's a genie that would definitely refuse to go back in the bottle. Over security reasons, although I don't have any concrete examples, I would have thought that either could possibly cause problems, if the opposite behaviour was expected. So, consistency is probably the most important thing. I can also see that both pieces of information (original opener and last navigator) might be useful. So, maybe the other could be added either way. From ian at hixie.ch Wed Apr 2 13:56:38 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 20:56:38 +0000 (UTC) Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> On Wed, 5 Mar 2014, Qebui Nehebkau wrote: > On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson <ian at hixie.ch> wrote: > > I think the arguments you've presented so far suggest "address-levelN" > > for N=1..4, with 4=region and 3=locality, is probably the simplest > > thing to do. I was hoping there might be other people with opinions, > > to give us different perspectives on this, but it seems nobody else > > cares. :-( > > Since you asked, I think the whole endeavour (of trying to tokenise an > address) is pointless and should be abandoned outright. :) In principle I agree, but in practice I think we have to work with the reality that that is what people are doing. > Short of my ideal of *only* offering the full address (as used on a > label) as an opaque string, I think it would be most reasonable to > consider the 'locality' field itself to be a fully-specified opaque > string, including whatever information is necessary to completely > identify the location from the region level (such as the prefecture and > district), rather than a single level. > > Failing all that, I would at least prefer for the fields to have names > instead of abstract numbering, because people are likely to be confused > about the order, no matter which end is the 'widest'. It also seems more > intuitive, to me, for the 'locality', as, after all, 'local', to be the > most specific level. Would people not be confused by names in the same way? On Wed, 5 Mar 2014, Qebui Nehebkau wrote: > > Right, "impose", certainly not. But, perhaps, (one hopes,) "encourage"? > Or at least "refuse to explicitly support anything else". Does > autocomplete *need* to support people who are already doing it wrong? > But I'm probably just being too utopian; it happens. Well if we don't support pretty much every form out there, the feature isn't particularly useful. On Tue, 4 Mar 2014, Kevin Marks wrote: > > > > > > > > > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "address-level4" > > > > > > > > "address-level3" > > > > > > > > "address-level2" / "locality" > > > > > > > > "address-level1" / "region" > > > > > > > > "country-name" > > > > > > > > > > > > This could work. It has the synonym issue (having multiple fields > > > > > > that mean the same thing is often the source of confusion). > > > > > > > > > > > > > > Or we could do: > > > > > > > > > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "subsublocality" > > > > > > > > "sublocality" > > > > > > > > "locality" > > > > > > > > "region" > > > > > > > > "country-name" > > > > > > > > > > > > This could work. It avoids the synonym problem. > > > > > > > > > > Yes, this alternative works, but in my opinion is not preferable. > > > Because these words don't really mean anything. Nor do numbers. I think we don't really have any chance of giving meaning to the names here either way. On Tue, 4 Mar 2014, Evan Stade wrote: > > "dependent-locality" and "locality" have a fairly precise meaning in the > UK. Also in a natural-language conversation, if you ask me what "region" > of the country I live in, I'd say "New England", "the Midwest", or some > such; certainly not the state where I reside. The descriptions for these > tokens are currently pretty specific, for example they say a city would > be a locality. But this is not true for Beijing or some other cities. To > fix the descriptions, we'd have to change them to something like > "region: the highest level administrative region below country in the > address" and "locality: the second-highest level administrative region > below country in the address", "sub-locality: the third-highest level > administrative region [...]". With you so far. > At this point, one wonders why the tokens aren't just [something]1, > [something]2, etc. I don't understand how you get there. Why would you wonder this? > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "locality" > > > > > > > > "subsubregion" > > > > > > > > "subregion" > > > > > > > > "region" > > > > > > > > "country-name" > > > > I don't understand why you think authors will think they need to > > include "subregion", but won't think they need to include > > "address-level3". > > I think they'll assume subregion returns something for the US if it's > sandwiched between "region" and "locality", because county is in between > state and city. But in reality, subregion will return nothing. But why does this not apply to the numeric version? > > Having synonyms is really bad. It leads to huge amounts of confusion. > > This is why I'm trying to avoid having synonyms for the address-level* > > stuff. We should definitely not add some just to introduce a slightly > > better name. > > My suggestion is to change the address-line1 to street-address-line1, > not to have synonyms. Chrome would then support address-line1 for a > limited period of time, but outside the spec. There's no "outside the spec". The spec tries to describe reality. If you implement something, then that's the reality, and that's what the spec would say, and therefore we'd have a synonym. > If you are avidly anti-synonym for the address-level* stuff, and don't > want to change "region" and "locality", then I guess the next best > naming scheme in my mind would be "region", "locality", "locality2", > "locality3". But we also need to update the descriptions as mentioned > above. I don't understand why "locality2" is better than "sublocality", nor why it's better to add things above locality than between locality and region. The numbering seems really prone to mistakes (I mean, I've been making mistakes with it this entire thread unintentionally, for example). > > > Why is that better than 1=region, 2=locality, except to a US-centric > > > viewpoint? This would lead to a weird situation where (a) you > > > couldn't expand past 4 levels without changing the meaning of > > > previous levels and (b) a country such as the US would have > > > address-level4 and address-level3 but no address-level2 or > > > address-level1. > > > > Well, at least as far as (a) goes, we have no way to know where > > governments are going to introduce new levels. Who's to say that the > > US won't introduce something between states and towns? This problem > > exists whatever we do. Maybe the US and the EU will merge and there'll > > be a new field between "country-name" and "region". Who knows. > > One can dream... > > You're right that changing political circumstances might put us in an > awkward situation no matter what we do. But it seems to me the most > likely scenario is that a government would add more administrative > levels at the most granular level. Why? It seems just as likely that we'll add levels between "country" and "region". For instance, the example above. Or, in a few years, when there are parts of countries in space, maybe there'll be a planetoid name between the country and the region. Or maybe that will go on the other side of the country. I think trying to guess how things will be extended is a fool's errand. If we use numbers, we paint ourselves into a corner with extensions anywhere but at the deepest level. Fundamentally, studying all the alternatives we've considered so far, they all suck. - some have weird names like "subsubregion". - some use numbers - some have synonyms - some leave gaps in addresses for some locales where it's not obvious where the gap should be - some are non-trivial to extend later I think I'm going to just go with more or less what you first proposed: "address-line1" | "address-line2" |- "street-address" "address-line3" | "address-level4" "address-level3" "address-level2" / "locality" "address-level1" / "region" "country-name" That is, make "locality" and "region" synonyms for two new fields, add two more, and say in the spec that different locales have different numbers of levels and that as many should be included as are appropriate, starting with level1 as the widest administrative division. I've filed a bug on this topic; if I can get agreement from other vendors, then I'll go ahead and spec this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235 On Wed, 5 Mar 2014, Edward O'Connor wrote: > > The techniques browsers use for autofilling auth information would > benefit enormously from some additional autocomplete="" values. The wiki > page Ilya mentioned captures the use cases pretty well. I think these > are the critical ones that capture the most common cases: > > # Passwords > > On "change your password" forms, which <input type=password> is your > current password? Which is the new password? Browsers want to avoid > filling the old password into the new or confirm password fields. > Additionally, distinguishing such fields would help tools that generate > passwords. These are useful on both sign-up and change password forms. > > <input type=password> - your current password > <input type=password autocomplete=new> - a new password > <input type=password autocomplete=confirm> - the new password, again > > Next to the other autocomplete values, "new" and "confirm" don't look > descriptive enough. "new-password" and "confirm-password", maybe? > "<input type=password autocomplete=new-password>" feels redundant and > verbose to me. Is there any reason to have two fields here, why not just "new" both times? Also, should we have an "old" field for the old password, or is the lack of an autofill field sufficient? I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236 It needs multiple vendors on board to make progress. > # Usernames > > Lots of websites use email addresses as usernames. Tools should be able > to distinguish email-used-as-username fields from other email fields. > This can also help on "forgot password"/"forgot username" forms. > > <inpyt type=text autocomplete=username> - your username on this site > <input type=email> - your preferred email address > <inpyt type=email autocomplete=username> - your username on this site, > not your preferred email > address > <input type=url autocomplete=username> - OpenID This seems reasonable. I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25237 It needs multiple vendors on board to make progress. > Also, consider the case of login forms without username fields. You see > this sort of thing a lot these days, when sites remember who was last > logged in: > > <form> > <label>Password for hober: <input type=password name=pw></label> > <p>Not hober? <a href=...>Click here to sign in</a>. > </form> > > It's difficult for tools to manage the user's auth info for such pages. > How can tools discover what the username is? The obvious solution, in a > world with autocomplete=username, would be to add <input type=hidden > autocomplete=username name=username value=hober> to the form. So far, autocomplete="" hasn't applied to <input type=hidden>. This would be a bit weird, giving it a different meaning than usual (providing information to the UA, rather than getting information from the UA). I'm a bit skeptical of this kind of overloading. Not sure what the right solution is, though. On Fri, 7 Mar 2014, Garrett Casto wrote: > > Another related issue that would be nice to address would be allowing > sites to positively assert that authentication succeeded. For sites that > authenticate client side via XHR, standardizing something like > window.external.AutoCompleteSaveForm() would be very helpful. For sites > that validate server side, I'm less sure what the correct avenue to > convey this information would be (response code, header, ...). I'm > assuming that this will be more contentious than adding username and > password attribution and I don't want to hold that up, but I would like > to see opinions on this. I actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. For the pure JS case, an API (probably on the <form> itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 For the real submission case, I guess what we want is a way to say "autocomplete=off" after the fact, basically. An HTTP header seems like the most obvious solution. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 Again, these need multiple vendors on board to make progress. On Mon, 10 Mar 2014, Evan Stade wrote: > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=?cc-number? the browser might provide an experience tailored > for a payment flow, or if there?s an element with autocomplete=?bday? the > browser might use an experience that?s tailored for sharing identiy. > > We?ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element.requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: ?transactionAmount? > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: ?transactionCurrency? > value: string > description: a valid ISO 4217 currency code that describes the currency > for transactionAmount. If not provided, the default is ?USD?. > > Justification? There are upper bounds on certain payment instruments, > for example different credit cards have different credit limits; a debit > card is linked to a bank account with a certain balance. It?s a much > preferable user experience to be able to catch these problems earlier > rather than waiting for the merchant to attempt the transaction and have > it fail (or have a user?s account overdrawn). Concretely, Chromium wants > to handle transactions over $2000 differently from transactions under > that amount. > > Does this seem reasonable? The requestAutocomplete() API is a Chrome proprietary feature right now so it's sort of acadmic, but: Why would this only apply to requestAutocomplete()? Surely it would be just as important for the case where the user agent is filling in a form without using that API. Also, I don't understand how these are supposed to work. How is the browser supposed to know the balance on my credit cards or bank accounts? How is the browser supposed to know which of my cards are good for USD and which are good for GBP? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 14:00:33 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 21:00:33 +0000 (UTC) Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> References: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404022057240.21310@ps20323.dreamhostps.com> On Wed, 2 Apr 2014, Bob Owen wrote: > > > > Did you receive any off-list feedback on this, or attempt to implement > > it and get any implementation experience? > > Thanks for getting back to me Ian. > No, no other feedback. > I have a patch for it, but haven't pursued it any further. > I could investigate putting the change in for Firefox Nightly, if you think > that might help with finding any compat issues. Well as far as I'm concerned, I would encourage you to try to converge on the spec behaviour. If it turns out there are compatibility issues, that would be good to know. If not, then at least we win more interoperability. > I can also see that both pieces of information (original opener and last > navigator) might be useful. So, maybe the other could be added either > way. I haven't heard any author demand for it, so I haven't added it, but indeed, if this is something authors have a use for, we could add it. It's worth noting that there are many many ways to navigate a browsing context beyond window.open(), e.g. <a target="">, window.location, drag-and-drop of a link, window.history.go(), etc. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bobowencode at gmail.com Wed Apr 2 15:09:00 2014 From: bobowencode at gmail.com (Bob Owen) Date: Wed, 2 Apr 2014 23:09:00 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> On 2 April 2014 22:00, Ian Hickson <ian at hixie.ch> wrote: > It's worth noting that there are many many ways to navigate a browsing > context beyond window.open(), e.g. <a target="">, window.location, > drag-and-drop of a link, window.history.go(), etc. Absolutely, if we were to converge on the spec for the current opener and people felt that last navigator would be useful, then it would need to be updated in all cases. Although, the history case might hold the original state. Anyway, getting way ahead of myself. I'll see if there are any more opinions, then look to move Gecko towards the spec and see if any compat issues arise. From tingan87 at gmail.com Wed Apr 2 21:37:33 2014 From: tingan87 at gmail.com (Tingan Ho) Date: Thu, 3 Apr 2014 12:37:33 +0800 Subject: [whatwg] More effective model for handling resources In-Reply-To: <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> References: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> Message-ID: <CAOr4atVY-mv1aCMwdY0ijz3vPcsYLdQzb_dgu5kx8kTkDSOXuQ@mail.gmail.com> Hi Ian, I believe this is being handled by the next-generation transport protocols > (SPDY or whatever it's called now). I recommend approaching the relevant > groups to check that your precise case has been handled. I just found out that SPDY Server Push and Cookies could accomplish the above mentioned caching. Cookies will take care of information providing. And the server just uses Server Push to push content. On Thu, Apr 3, 2014 at 1:57 AM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 13 Mar 2014, Tingan Ho wrote: > > > > Almost all web developer I know use externally linked CSS resource in > > their web projects. That means that the browser needs to (1) request the > > html page (2) parse the html (3) request for the CSS resource that is > > linked from the html document. The problem with externally linked > > resources is point three. It needs to make another request for the CSS > > resource. There is a solution to this problem and that is to inline the > > CSS. Though that would yield another problem: all subsequent page > > request will become bigger. > > I believe this is being handled by the next-generation transport protocols > (SPDY or whatever it's called now). I recommend approaching the relevant > groups to check that your precise case has been handled. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- Sincerely, Tingan Ho From lists at scratchdisk.com Wed Apr 2 23:21:38 2014 From: lists at scratchdisk.com (=?iso-8859-1?Q?J=FCrg_Lehni?=) Date: Thu, 3 Apr 2014 08:21:38 +0200 Subject: [whatwg] Grouping in canvas 2d In-Reply-To: <alpine.DEB.2.00.1403141808380.32463@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <CAGN7qDBHT_fitzzsrnGe6exCWr1Fc4mXSnY=_KW7fNjkoB6-KA@mail.gmail.com> <CABpaAqTdv4TaDpXj4jksL+jeDVqv9cKyVvxJO1nridR9Zwq66Q@mail.gmail.com> <CAGN7qDA9BfpOCqzAmbwooJ_aSw8cbLT-G_-can61K05Q7YsLMw@mail.gmail.com> <73A19694-2AB0-4948-8B4B-A5ED820B2444@scratchdisk.com> <alpine.DEB.2.00.1403141808380.32463@ps20323.dreamhostps.com> Message-ID: <6D69D840-D0F2-4547-AB63-8288C2E51A1D@scratchdisk.com> Here another simple example: When both filling and stroking a path and then drawing it with with an opacity of less than 100%, the path will be rendered differently than in an SVG (a large stroke width will make the issue more apparent): - In Canvas, both the fill and the stroke will be rendered with the given opacity, and the fill will shine through the inner half of the stroke. - In SVG, the stroke will cover the fill, and the fill will not shine through the inner half of the stroke, regardless of the opacity. If you'd like to emulate the SVG behavior in Canvas (which we happen to do in Paper.js), then the only way to do so currently is to draw the path's fill and stroke at 100% opacity into a separate canvas, and then blit the whole thing over with the given opacity. This is *much* slower than directly drawing into the Canvas, and happens to be one of the worst bottlenecks in Paper.js I would really appreciate a solution to this problem. J?rg On Mar 14, 2014, at 19:09 , Ian Hickson <ian at hixie.ch> wrote: > Can you elaborate on what precisely the performance bottleneck is? I was > looking through this thread but I can't find a description of the use > cases it addresses, so it's hard to evaluate the proposals. From mkwst at google.com Thu Apr 3 02:49:20 2014 From: mkwst at google.com (Mike West) Date: Thu, 3 Apr 2014 11:49:20 +0200 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <CAKXHy=cm3F1noHs1SM4XSOpno4aB1GPQ9mhjyva9v+6EU9v3HA@mail.gmail.com> On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson <ian at hixie.ch> wrote: > > Also, consider the case of login forms without username fields. You see > > this sort of thing a lot these days, when sites remember who was last > > logged in: > > > > <form> > > <label>Password for hober: <input type=password name=pw></label> > > <p>Not hober? <a href=...>Click here to sign in</a>. > > </form> > > > > It's difficult for tools to manage the user's auth info for such pages. > > How can tools discover what the username is? The obvious solution, in a > > world with autocomplete=username, would be to add <input type=hidden > > autocomplete=username name=username value=hober> to the form. > > So far, autocomplete="" hasn't applied to <input type=hidden>. This would > be a bit weird, giving it a different meaning than usual (providing > information to the UA, rather than getting information from the UA). I'm a > bit skeptical of this kind of overloading. > > Not sure what the right solution is, though. > As Garrett noted, this is already a solution Google is using, though not with explicit syntax, just taking advantage of existing heuristics. Paving this (potential) cowpath isn't really that weird. That said, an alternative might be to add a mechanism of associating autocompletion metadata with the field in order to give the UA enough context to fill it in. For example, if a password is being requested for a known username, that username could be added as an new "autocomplete-username" attribute (similar to the 'data-*' construct HTML already supports): <input type="password" autocomplete-username="hober"> -mike -- Mike West <mkwst at google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) From andy at pigsonthewing.org.uk Thu Apr 3 03:22:48 2014 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu, 3 Apr 2014 11:22:48 +0100 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <CABiXOEmndoUXWk1nWk00RyFsA6g2M8M0ZOofTctP+_oxC4odvQ@mail.gmail.com> [General point, so not quoting anyone in particular] [Resending to list, apologies to Ian] Why would you define any address components other than those in vCard, a standard with massive implementation and interoperable with most address book applications and services? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk From creis at chromium.org Thu Apr 3 11:28:15 2014 From: creis at chromium.org (Charlie Reis) Date: Thu, 3 Apr 2014 11:28:15 -0700 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> References: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> Message-ID: <CAH+8MBaU3NSq+WvZ2iG8n_-EAaSBZTA_fYOLoMw0NkFpRf4MiA@mail.gmail.com> On Wed, Apr 2, 2014 at 3:09 PM, Bob Owen <bobowencode at gmail.com> wrote: > On 2 April 2014 22:00, Ian Hickson <ian at hixie.ch> wrote: > > > It's worth noting that there are many many ways to navigate a browsing > > context beyond window.open(), e.g. <a target="">, window.location, > > drag-and-drop of a link, window.history.go(), etc. > > Absolutely, if we were to converge on the spec for the current opener and > people felt that last navigator would be useful, then it would need to be > updated in all cases. > Although, the history case might hold the original state. > > Anyway, getting way ahead of myself. > I'll see if there are any more opinions, then look to move Gecko towards > the spec and see if any compat issues arise. > For what it's worth, I think we'd be open to changing Blink to match the spec as well, if you don't find any compat issues. Charlie From bobowencode at gmail.com Fri Apr 4 01:40:50 2014 From: bobowencode at gmail.com (Bob Owen) Date: Fri, 4 Apr 2014 09:40:50 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEEDiH1N_9rex+Dq_8nzQrCVnpa8djiJGsc1xP3zHCLLY4g@mail.gmail.com> On 3 April 2014 19:28, Charlie Reis <creis at chromium.org> wrote: > For what it's worth, I think we'd be open to changing Blink to match the spec as well, if you don't find any compat issues. I'd say it's worth a lot, thanks Charlie. From faulkner.steve at gmail.com Sat Apr 5 00:59:03 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Sat, 5 Apr 2014 08:59:03 +0100 Subject: [whatwg] summary/details - proposal Message-ID: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> note: bringing this to the whatwg list to elicit feedback from implementers and other interested parties that are not involved in the discussion at the W3C Currently the implementation(s) of summary/details elements do not match the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element In the spec, the details element is interactive content, the summary is not, its a summary, caption, or legend. in webkit/blink the summary element is the interactive element (when pressed it opens/closes the details element) This is good because it provides a large default hit region to activate the control example to try in chrome/safari/opera http://codepen.io/stevef/pen/CyauJ/ So as the spec/implementations are at odds, the implementations need to change to match the spec or the spec needs to change to match implementations or the spec needs to change to accommodate the positive aspects of the current implementations while allowing for other use cases An issue with current implementations is that when the summary element includes other interactive elements (as it is allowed to), clicking on them results in the details element being opened/closed (although this can be overcome via scripting). example to try in chrome/safari/opera http://codepen.io/stevef/pen/xjJiy/ Issues with the current spec text: The interactive part of the details element is the disclosure triangle ? which is supposed to be an anonymous control in the shadow DOM The <summary> itself is not interactive, so only the triangle provides the actionable control. the summary text which is effectively the label for control does not activate the control. There is no method provided to associate a label with the anonymous control that can (a) provide an increased hit region and (b) provide an explicitly associated label for the anonymous control. Given that what we want to provide for the use case of having controls inside the summary, after discussion around the issue[1], I have proposed the following: <details> <summary id=x> <label for=x>Foo</label> </summary> ... </details> what this does is provide the author with the ability to add an explicit label (providing the acc name) to the details control which also increases the click region for improved accessibility/usability, while still allowing interactive content inside the summary element. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25140 feedback welcome! -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From dschulze at adobe.com Sat Apr 5 09:01:19 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sat, 5 Apr 2014 16:01:19 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() Message-ID: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> Hi, I looked at the behavior of negative width or height for the rect() and strokeRect() functions. All browsers normalize the passed parameters for strokeRect() to have positive width and height. strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) http://jsfiddle.net/za945/ Just WebKit seems to normalize for rect() as well: http://jsfiddle.net/VT4MG/ The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. Greetings, Dirk From cabanier at gmail.com Sat Apr 5 18:23:06 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 5 Apr 2014 18:23:06 -0700 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> Message-ID: <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > Hi, > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > strokeRect(90,10,-80,80) --> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ I'm unsure why such a rectangle is defined as a straight line. > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ > > The behavior of normalizing is not specified. Especially it seems odd that > the behavior for fillRect()/strokeRect() should differ from rect(). So we > should either normalize for all functions or don't do it for all IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for rect() > is important for filling with different winding rules as well. It is not > just stroking with dash arrays that is effected. > yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect From ian at hixie.ch Sat Apr 5 21:11:20 2014 From: ian at hixie.ch (Ian Hickson) Date: Sun, 6 Apr 2014 04:11:20 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> On Sat, 5 Apr 2014, Steve Faulkner wrote: > > The <summary> itself is not interactive, so only the triangle provides > the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). > Given that what we want to provide for the use case of having controls > inside the summary, after discussion around the issue, I have proposed > the following: > > <details> > <summary id=x> <label for=x>Foo</label> </summary> > ... > </details> That's way more complicated than necessary for authors, not to mention all the problems it would cause with the existing <label> definitions. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dschulze at adobe.com Sat Apr 5 23:00:50 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 06:00:50 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> Message-ID: <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > Hi, > > I looked at the behavior of negative width or height for the rect() and strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have positive width and height. > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ > >> It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ >> I'm unsure why such a rectangle is defined as a straight line. You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ > > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ > > The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. > >> yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw ?in that order? for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. Greetings, Dirk > > 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect From dschulze at adobe.com Sat Apr 5 23:23:36 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 06:23:36 +0000 Subject: [whatwg] Canvas Computing text metrics Message-ID: <69477B5B-A7A4-4674-B267-09EC2499C1F0@adobe.com> Hi, The spec says that the object TextMetrics[1] must return font and actual text metrics. All things require information from the font or the font system. In many cases either font or font system just do not provide these information. Instead of assuming that all information are accessible by the browser, it might be useful to define some heuristics that can be used. In WebKit and Blink we support the CSS dominant-baseline property in SVG that requires similar metrics as well[2]. Even SVG does not specify the heuristics yet and instead leaves that up to the browser. WebKit and Blink use the heuristics described in the documentation from Apache FOP[1]. Should these be used as fallback heuristics? Note: Many browsers might use heuristics by default since they can?t get all necessary font metrics at all. Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#textmetrics [2] http://www.w3.org/TR/SVG11/text.html#TextAlignmentProperties [3] http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling From cabanier at gmail.com Sat Apr 5 23:24:19 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 5 Apr 2014 23:24:19 -0700 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> Message-ID: <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > > > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > > Hi, > > > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > > > strokeRect(90,10,-80,80) --> strokeRect(10,10,80,80) > > > > http://jsfiddle.net/za945/ > > > >> It also seems that only firefox is following the spec [1] when width or > height are 0: http://jsfiddle.net/za945/2/ > >> I'm unsure why such a rectangle is defined as a straight line. > > You mean you would rather let it draw a one dimensional rectangle? So for > the dimension that is not zero, you would see two overlapping lines + the 0 > dimensional sides? > yes That seems indeed to be the case for IE, Safari and Blink: > http://jsfiddle.net/Gh9XK/ > > > > > Just WebKit seems to normalize for rect() as well: > > > > http://jsfiddle.net/VT4MG/ > > > > The behavior of normalizing is not specified. Especially it seems odd > that the behavior for fillRect()/strokeRect() should differ from rect(). So > we should either normalize for all functions or don't do it for all IMO. > > > > Note: fillRect() and clearRect() are not affected. The behavior for > rect() is important for filling with different winding rules as well. It is > not just stroking with dash arrays that is effected. > > > >> yes, the spec needs to say "in that order" as it does for fillRect and > strokeRect. > > Ok, that means you would be in favor not to normalize. Again, all current > browser normalize and do NOT draw "in that order" for fillRect() and > strokeRect(). That means you would require to give up the currently > interoperable behavior. > I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) I would be in favor to change the blink/webkit behavior as the specified one makes more sense. From dschulze at adobe.com Sun Apr 6 00:04:46 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 07:04:46 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> Message-ID: <872B4940-A589-46D1-B72B-B302E7FCC1E3@adobe.com> On Apr 6, 2014, at 8:24 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > > > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > > Hi, > > > > I looked at the behavior of negative width or height for the rect() and strokeRect() functions. > > > > All browsers normalize the passed parameters for strokeRect() to have positive width and height. > > > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > > > http://jsfiddle.net/za945/ > > > >> It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ > >> I'm unsure why such a rectangle is defined as a straight line. > > You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? > > yes > > That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ > > > > > Just WebKit seems to normalize for rect() as well: > > > > http://jsfiddle.net/VT4MG/ > > > > The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. > > > > Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. > > > >> yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. > > Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw ?in that order? for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. > > I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ > Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) Firefox has a strange different behavior if dash >= gap. If the gap is smaller it behaves like IE, Blink and WebKit. This also answers your question: Your example renders in IE the same as in WebKit and Blink. Greetings, Dirk > > I would be in favor to change the blink/webkit behavior as the specified one makes more sense. From harald at alvestrand.no Mon Apr 7 07:24:23 2014 From: harald at alvestrand.no (Harald Alvestrand) Date: Mon, 07 Apr 2014 16:24:23 +0200 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> Message-ID: <5342B517.1080401@alvestrand.no> On 04/02/2014 07:52 PM, Ian Hickson wrote: > On Mon, 3 Mar 2014, Ami Fischman wrote: >> Looks like we're back in business: >> >> Latest editor's draft: >> http://dev.w3.org/2011/webrtc/editor/getusermedia.html > Thanks. > > As a user, this scares me a lot. Why isn't it up to me to control this? I > don't understand the security model here at all. I don't want random Web > pages to know that they can pipe audio to the remote speakers in my > bedroom from my laptop, but if we just expose all the audio output > devices, that's exactly what will be possible. > > Without a much clearer security model, I don't think it's a good idea to > add any APIs. > Would it make sense to group the access to sinks in with access to sources - that is, "this page wants access to your cameras, microphones and audio output devices"? (either on a per-device basis or as an all-or-nothing prompting) From junov at google.com Mon Apr 7 08:07:34 2014 From: junov at google.com (Justin Novosad) Date: Mon, 7 Apr 2014 11:07:34 -0400 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDCijrx_3Rfk2mFThkBc7NignwXoFHhd3fnkL9_5QPE-rQ@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> <872B4940-A589-46D1-B72B-B302E7FCC1E3@adobe.com> <CABpaAqSm=9gAT6TfbJ7RHOcSDMcxy32Enj-txyV-yN=tF8H3JA@mail.gmail.com> <CAGN7qDCijrx_3Rfk2mFThkBc7NignwXoFHhd3fnkL9_5QPE-rQ@mail.gmail.com> Message-ID: <CABpaAqRVUa0-xeoRrBUik22GyYeY1Z0e3FBx=LLpEhryfnAJ5w@mail.gmail.com> On Mon, Apr 7, 2014 at 10:47 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Mon, Apr 7, 2014 at 7:29 AM, Justin Novosad <junov at google.com> wrote: > >> Putting myself the the web devs shoes... If I negate the height of a >> rect, what would I expect? My first though: a horizontally flipped mirror >> image of the rect. >> >> Now, what does the spec say? >> a) rect(): respect the flipped vertex order >> > > yes, except it doesn't explicitly say "in that order" so a UA could > implement it in a different one. > Okay. Nonetheless the spec already does define the order, it just does not insist that it must be respected. > > > >> b) strokeRect(): respect the flipped vertex order >> c) fillRect(): unaffected by vertex order. >> > > Where do you see that fillRect is not affected? > It does not say so explicitly, but it is implied. The coloring of pixels is governed by the fillStyle, which is not affected vertex order. > >> d) fillStyle and strokeStyle style application is independent of the >> primitive, mapping is controlled by CTM (and a pattern matrix) >> >> I find the spec is consistent with itself as it is currently worded. If >> you want to flip a rect (or any other geometry for that matter), you can >> either flip everything together using the CTM, or flip its parts (the >> vertices and the styles) individually. >> I think that having the styles automatically flip when the rect is >> inverted would have an undesirable consequence: It would break consistency >> with path rendering (how do you define the notion inverted geometry for a >> general, possibly self-intersecting, path?) >> > > I'm unsure why we would switch geometry. Are you referring to the dashing? > Dashing is one thing that would be affected. I think some implementations are currently in a non-compliant state probably because the line dashing feature was added recently. Back when strokeRect was originally implemented, we could get away with blindly normalizing rectangles because there was no impact on the rendering result. The other thing that is affected is fill rule application. For example, if you have a path that contains two intersecting rectangles and you are filling in with the nonzero rule. If one of the two rectangles is flipped, then the intersection region should be unfilled. If the rectangles are "normalized" internally by the implementation, then you will get the wrong (non spec compliant) result. > > >> On Sun, Apr 6, 2014 at 3:04 AM, Dirk Schulze <dschulze at adobe.com> wrote: >> >>> >>> On Apr 6, 2014, at 8:24 AM, Rik Cabanier <cabanier at gmail.com> wrote: >>> >>> > >>> > >>> > >>> > On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> >>> wrote: >>> > >>> > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: >>> > >>> > > >>> > > >>> > > >>> > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> >>> wrote: >>> > > Hi, >>> > > >>> > > I looked at the behavior of negative width or height for the rect() >>> and strokeRect() functions. >>> > > >>> > > All browsers normalize the passed parameters for strokeRect() to >>> have positive width and height. >>> > > >>> > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) >>> > > >>> > > http://jsfiddle.net/za945/ >>> > > >>> > >> It also seems that only firefox is following the spec [1] when >>> width or height are 0: http://jsfiddle.net/za945/2/ >>> > >> I'm unsure why such a rectangle is defined as a straight line. >>> > >>> > You mean you would rather let it draw a one dimensional rectangle? So >>> for the dimension that is not zero, you would see two overlapping lines + >>> the 0 dimensional sides? >>> > >>> > yes >>> > >>> > That seems indeed to be the case for IE, Safari and Blink: >>> http://jsfiddle.net/Gh9XK/ >>> > >>> > > >>> > > Just WebKit seems to normalize for rect() as well: >>> > > >>> > > http://jsfiddle.net/VT4MG/ >>> > > >>> > > The behavior of normalizing is not specified. Especially it seems >>> odd that the behavior for fillRect()/strokeRect() should differ from >>> rect(). So we should either normalize for all functions or don?t do it for >>> all IMO. >>> > > >>> > > Note: fillRect() and clearRect() are not affected. The behavior for >>> rect() is important for filling with different winding rules as well. It is >>> not just stroking with dash arrays that is effected. >>> > > >>> > >> yes, the spec needs to say "in that order" as it does for fillRect >>> and strokeRect. >>> > >>> > Ok, that means you would be in favor not to normalize. Again, all >>> current browser normalize and do NOT draw ?in that order? for fillRect() >>> and strokeRect(). That means you would require to give up the currently >>> interoperable behavior. >>> > >>> > I changed your test a bit so you can more easily see the >>> normalisation: http://jsfiddle.net/za945/3/ >>> > Safari and Chrome are doing as you say, but Firefox does not. (I don't >>> have IE to test) >>> >>> Firefox has a strange different behavior if dash >= gap. If the gap is >>> smaller it behaves like IE, Blink and WebKit. This also answers your >>> question: Your example renders in IE the same as in WebKit and Blink. >>> >>> Greetings, >>> Dirk >>> >>> > >>> > I would be in favor to change the blink/webkit behavior as the >>> specified one makes more sense. >>> >>> >> > From fischman at chromium.org Mon Apr 7 08:53:27 2014 From: fischman at chromium.org (Ami Fischman) Date: Mon, 7 Apr 2014 08:53:27 -0700 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> Message-ID: <CAHuR8a9Q6+FSmMVCXUoy79CLMhuHz=yLuNHA_xLjicvE4kAa7w@mail.gmail.com> Thanks Ian. I pinged public-media-capture about this and https://www.w3.org/Bugs/Public/show_bug.cgi?id=25245 is now tracking making that spec better specified. On Wed, Apr 2, 2014 at 10:52 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 3 Mar 2014, Ami Fischman wrote: > > > > Looks like we're back in business: > > > > Latest editor's draft: > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html > > Thanks. > > As a user, this scares me a lot. Why isn't it up to me to control this? I > don't understand the security model here at all. I don't want random Web > pages to know that they can pipe audio to the remote speakers in my > bedroom from my laptop, but if we just expose all the audio output > devices, that's exactly what will be possible. > > Without a much clearer security model, I don't think it's a good idea to > add any APIs. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 09:20:27 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 16:20:27 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342B517.1080401@alvestrand.no> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> Message-ID: <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Harald Alvestrand wrote: > On 04/02/2014 07:52 PM, Ian Hickson wrote: > > On Mon, 3 Mar 2014, Ami Fischman wrote: > > > Looks like we're back in business: > > > > > > Latest editor's draft: > > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html > > > > As a user, this scares me a lot. Why isn't it up to me to control > > this? I don't understand the security model here at all. I don't want > > random Web pages to know that they can pipe audio to the remote > > speakers in my bedroom from my laptop, but if we just expose all the > > audio output devices, that's exactly what will be possible. > > > > Without a much clearer security model, I don't think it's a good idea > > to add any APIs. > > Would it make sense to group the access to sinks in with access to > sources - that is, "this page wants access to your cameras, microphones > and audio output devices"? > > (either on a per-device basis or as an all-or-nothing prompting) Wouldn't that be an implementation detail? When I was first desigining the API for WebRTC (years ago, before it got rather unceremoniously forked by the W3C), the security design I had come up with was basically that the UA would show a panel of devices, and the user would drag-and-drop them into the page to give the page access to them. (Or equivalent UI, e.g. tapping on the relevant device icons to activate them for the page.) This would let me, as a user, specify that on my laptop YouTube can play video on my TV (assuming we extend this stuff to support video over Miracast/AirPlay/WiDi/DIAL/Chromecast/DLNA) while not allowing it to send audio to my bedroom, while simultaneously having Amazon's Cloud Player sending its music to my bedroom, but not allowing it to use my microphone. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From harald at alvestrand.no Mon Apr 7 10:28:45 2014 From: harald at alvestrand.no (Harald Alvestrand) Date: Mon, 07 Apr 2014 19:28:45 +0200 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> Message-ID: <5342E04D.3010301@alvestrand.no> On 04/07/2014 06:20 PM, Ian Hickson wrote: > On Mon, 7 Apr 2014, Harald Alvestrand wrote: >> On 04/02/2014 07:52 PM, Ian Hickson wrote: >>> On Mon, 3 Mar 2014, Ami Fischman wrote: >>>> Looks like we're back in business: >>>> >>>> Latest editor's draft: >>>> http://dev.w3.org/2011/webrtc/editor/getusermedia.html >>> As a user, this scares me a lot. Why isn't it up to me to control >>> this? I don't understand the security model here at all. I don't want >>> random Web pages to know that they can pipe audio to the remote >>> speakers in my bedroom from my laptop, but if we just expose all the >>> audio output devices, that's exactly what will be possible. >>> >>> Without a much clearer security model, I don't think it's a good idea >>> to add any APIs. >> Would it make sense to group the access to sinks in with access to >> sources - that is, "this page wants access to your cameras, microphones >> and audio output devices"? >> >> (either on a per-device basis or as an all-or-nothing prompting) > Wouldn't that be an implementation detail? The details are an implementation detail. Whether sinks should be treated at the same level as sources, higher level or lower level of protection is probably a somewhat higher level issue. > > When I was first desigining the API for WebRTC (years ago, before it got > rather unceremoniously forked by the W3C), the security design I had come > up with was basically that the UA would show a panel of devices, and the > user would drag-and-drop them into the page to give the page access to > them. (Or equivalent UI, e.g. tapping on the relevant device icons to > activate them for the page.) This was considered, but rejected. The consensus opinion at WebRTC and MediaCapture seemed to be that the ability to let an app say "which of these 5 microphones do you want?" is more amenable to creating good apps than leaving this UI to the browser chrome. > > This would let me, as a user, specify that on my laptop YouTube can play > video on my TV (assuming we extend this stuff to support video over > Miracast/AirPlay/WiDi/DIAL/Chromecast/DLNA) while not allowing it to send > audio to my bedroom, while simultaneously having Amazon's Cloud Player > sending its music to my bedroom, but not allowing it to use my microphone. > From faulkner.steve at gmail.com Sun Apr 6 12:50:49 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Sun, 6 Apr 2014 20:50:49 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > The <summary> itself is not interactive, so only the triangle provides > > the actionable control. > > The spec doesn't disallow making clicks on (non-interactive) parts of the > summary defer to the disclosure triangle. Browsers should just match > platform conventions, where applicable, and otherwise make whatever is > considered the best choice for users (such as making such content also > trigger the disclosure triangle). > > Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. It also provides the best choice for users, large click area and focus ring, Its also simple for authors in the majority of use cases. while on Mac OSX only the disclosure triangle (approx 13X13px) itself is clickable and has a focus rectangle. > <details> > <summary id=x> <label for=x>Foo</label> </summary> > ... > </details> That's way more complicated than necessary for authors, how so? with the current definition how do authors provide a label for the disclosure widget when summary also contains controls with labels? in the absence of browser making "clicks on (non-interactive) parts of the summary defer to the disclosure triangle." how is an author supposed to do this? > not to mention all > the problems it would cause with the existing <label> definitions. > may be making the details element a labelable control would be simpler, as its be definition an interactive control. would it cause problems for existing <label> definitions? <details id=x> <summary> <label for=x>Foo</label> </summary> ... </details> > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 10:37:29 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 17:37:29 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342E04D.3010301@alvestrand.no> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> Message-ID: <alpine.DEB.2.00.1404071735580.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Harald Alvestrand wrote: > > The consensus opinion at WebRTC and MediaCapture seemed to be that the > ability to let an app say "which of these 5 microphones do you want?" is > more amenable to creating good apps than leaving this UI to the browser > chrome. Seems to me that the privacy aspects (the fingerprinting vulnerabilities from exposing this data), and the abuse aspects (giving hostile sites the ability to access all the user's devices if any are made available) would trump this. Surely we can rely on user agents to provide nice UIs. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sun Apr 6 13:08:16 2014 From: ian at hixie.ch (Ian Hickson) Date: Sun, 6 Apr 2014 20:08:16 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> On Sun, 6 Apr 2014, Steve Faulkner wrote: > On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > > > The <summary> itself is not interactive, so only the triangle > > > provides the actionable control. > > > > The spec doesn't disallow making clicks on (non-interactive) parts of > > the summary defer to the disclosure triangle. Browsers should just > > match platform conventions, where applicable, and otherwise make > > whatever is considered the best choice for users (such as making such > > content also trigger the disclosure triangle). > > Platform conventions for disclosure type widgets vary, on windows for > example, the current implementations match the convention. The conventions on Windows are all over the place: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx ...but I doubt that this matches any of the Windows conventions: | when the summary element includes other interactive elements (as it is | allowed to), clicking on them results in the details element being | opened/closed > > > <details> > > > <summary id=x> <label for=x>Foo</label> </summary> > > > ... > > > </details> > > > > That's way more complicated than necessary for authors, > > how so? All that should be necessary is: <details> <summary> Foo </summary> ... </details> Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. > with the current definition how do authors provide a label for the > disclosure widget when summary also contains controls with labels? If doing so matches the platform conventions, any non-interactive text in the <summary> would open the widget. > in the absence of browser making "clicks on (non-interactive) parts of > the summary defer to the disclosure triangle." how is an author supposed > to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From faulkner.steve at gmail.com Mon Apr 7 11:50:51 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Mon, 7 Apr 2014 19:50:51 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 6 April 2014 21:08, Ian Hickson <ian at hixie.ch> wrote: > On Sun, 6 Apr 2014, Steve Faulkner wrote: > > On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > > > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > > > > > The <summary> itself is not interactive, so only the triangle > > > > provides the actionable control. > > > > > > The spec doesn't disallow making clicks on (non-interactive) parts of > > > the summary defer to the disclosure triangle. Browsers should just > > > match platform conventions, where applicable, and otherwise make > > > whatever is considered the best choice for users (such as making such > > > content also trigger the disclosure triangle). > > > > Platform conventions for disclosure type widgets vary, on windows for > > example, the current implementations match the convention. > > The conventions on Windows are all over the place: > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx > > ...but I doubt that this matches any of the Windows conventions: > > | when the summary element includes other interactive elements (as it is > | allowed to), clicking on them results in the details element being > | opened/closed > Not what I said, but the current implementations use of <summary> as the interactive element matches, the first example under usage patterns http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx#patterns > > > > > > <details> > > > > <summary id=x> <label for=x>Foo</label> </summary> > > > > ... > > > > </details> > > > > > > That's way more complicated than necessary for authors, > > > > how so? > > All that should be necessary is: > > <details> > <summary> Foo </summary> > ... > </details> > > Adding two attributes and an elements is thus more complicated than > necessary. This seems pretty unambiguous to me. > for the case <details> <summary> Foo <input> Bar </summary> ... </details> whats the disclosure label? what about? <details> <summary> <label><input> Bar </label></summary> ... </details> > > in the absence of browser making "clicks on (non-interactive) parts of > > the summary defer to the disclosure triangle." how is an author supposed > > to do this? > > The author isn't supposed to do this. The whole point of semantic controls > like this is that the user agent is the one that picks the user interface. > does this also extend to the author being able to provide an accessible name for the control? > > Once we start talking about custom widgets, we're in the space of Web > components, at which point the author can do whatever the author wants. > yeah, its a shame that the design of some html features don't provide the flexibility to allow authors to fix user agent specific design deficits without recourse to web components > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 12:06:15 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 19:06:15 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Steve Faulkner wrote: > > > > All that should be necessary is: > > > > <details> > > <summary> Foo </summary> > > ... > > </details> > > > > Adding two attributes and an elements is thus more complicated than > > necessary. This seems pretty unambiguous to me. > > for the case > > <details> > <summary> Foo <input> Bar </summary> > ... > </details> > > whats the disclosure label? The text "Foo", a text field, and the text "Bar". If by "disclosure label" you mean the parts which, on certain platforms, when clicked, would toggle the open state, then that depends on the platform, but I would expect the "Foo" and "Bar" text to be good candidates, since they're otherwise inert. > what about? > > <details> > <summary> <label><input> Bar </label></summary> > ... > </details> Here there's no non-interactive text, so there's no text to target. > > > in the absence of browser making "clicks on (non-interactive) parts > > > of the summary defer to the disclosure triangle." how is an author > > > supposed to do this? > > > > The author isn't supposed to do this. The whole point of semantic > > controls like this is that the user agent is the one that picks the > > user interface. > > does this also extend to the author being able to provide an accessible > name for the control? Should there be a particular need for an accessible name for the <details> control, ARIA can be used to set the name. But I must admit to not understanding why you would need that in practice, if the page is well written. (I find most pages that use accessible labels in situations such as this tend to be poorly written for non-AT users.) > > Once we start talking about custom widgets, we're in the space of Web > > components, at which point the author can do whatever the author > > wants. > > yeah, its a shame that the design of some html features don't provide > the flexibility to allow authors to fix user agent specific design > deficits without recourse to web components Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dyoung at pobox.com Mon Apr 7 12:30:16 2014 From: dyoung at pobox.com (David Young) Date: Mon, 7 Apr 2014 14:30:16 -0500 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342E04D.3010301@alvestrand.no> References: <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> Message-ID: <20140407193016.GE7959@pobox.com> On Mon, Apr 07, 2014 at 07:28:45PM +0200, Harald Alvestrand wrote: > On 04/07/2014 06:20 PM, Ian Hickson wrote: > >When I was first desigining the API for WebRTC (years ago, before it got > >rather unceremoniously forked by the W3C), the security design I had come > >up with was basically that the UA would show a panel of devices, and the > >user would drag-and-drop them into the page to give the page access to > >them. (Or equivalent UI, e.g. tapping on the relevant device icons to > >activate them for the page.) > > This was considered, but rejected. > The consensus opinion at WebRTC and MediaCapture seemed to be that > the ability to let an app say "which of these 5 microphones do you > want?" is more amenable to creating good apps than leaving this UI > to the browser chrome. If the app disregards or misunderstands the user's input, what keeps it from using the wrong microphone? How do I disconnect a microphone from an app? How do I know which microphones are connected to which apps? Ian's proposal seems to offer this visibility and control to the user. Dave -- David Young dyoung at pobox.com Urbana, IL (217) 721-9981 From cabanier at gmail.com Tue Apr 8 04:18:22 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 04:18:22 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDCitrYeR+zoh8B+FdGyF6mQL5Pvkd=UjbdKD_Urtw_vBg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 12 Mar 2014, Rik Cabanier wrote: > > On Wed, Mar 12, 2014 at 3:44 PM, Ian Hickson wrote: > > > On Thu, 28 Nov 2013, Rik Cabanier wrote: > > > > On Thu, Nov 28, 2013 at 8:30 AM, J?rg Lehni wrote: > > > > > > > > > > I meant to say that it I think it would make more sense if the > > > > > path was in the current transformation matrix, so it would > > > > > represent the same coordinate values in which it was drawn, and > > > > > could be used in the same 'context' of transformations applied to > > > > > the drawing context later on. > > > > > > > > No worries, it *is* confusing. For instance, if you emit coordinates > > > > and then scale the matrix by 2, those coordinates from > > > > getCurrentPath will have a scale of .5 applied. > > > > > > That's rather confusing, and a pretty good reason not to have a way to > > > go from the current default path to an explicit Path, IMHO. > > > > > > Transformations affect the building of the current default path at > > > each step of the way, which is really a very confusing API. The Path > > > API on the other hand doesn't have this problem -- it has no > > > transformation matrix. It's only when you use Path objects that they > > > get transformed. > > > > This happens transparently to the author so it's not confusing. > > I've been confused by it multiple times over the years, and I wrote the > spec. I am confident in calling it confusing. > Only when you think about it :-) > > For instance: > > > > ctx.rect(0,0,10,10); > > ctx.scale(2,2); <- should not affect geometry of the previous rect > > ctx.stroke(); <- linewidth is scaled by 2, but rect is still 10x10 > > It's confusing because it's not at all clear why this doesn't result in > two rectangles of different sizes: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > ctx.scale(2,2); > ctx.stroke(); > > ...while this does: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > ctx.beginPath(); > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > > It appears to be the same path in both cases, after all. > Maybe you can think about drawing paths like drawing in a graphics application. - moveTo, lineTo, etc = drawing line segments in the document - scale = hitting the magnifying glass/zooming - translate = panning the document (0,0) is the upper left of the screen - coordinates in path segments/rect = coordinates on the screen It would be very surprising that line art would change when zooming in or out or panning. From faulkner.steve at gmail.com Tue Apr 8 05:25:14 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Tue, 8 Apr 2014 13:25:14 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> On 7 April 2014 20:06, Ian Hickson <ian at hixie.ch> wrote: > Should there be a particular need for an accessible name for the <details> > control, ARIA can be used to set the name. But I must admit to not > understanding why you would need that in practice, if the page is well > written. (I find most pages that use accessible labels in situations such > as this tend to be poorly written for non-AT users.) > All controls are expected to have an accessible name and it is expected that the author is able to assign one. this is accessibility 101 across all platforms. Lack of an accessible name or a generic accessible name or an ambiguous accessible name causes issues for users. What's the mechanism by which the anonymous control for details can be assigned an accessible name? Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. avoiding unnecessary recourse to web component use is a reasonable and expected goal - built in vs bolt on accessibility is better. Having to use a web component to overcome the inability to make a html control usable without relying on CSS and Js and ARIA is unfortunate, and as you said yesterday "once you're using custom components you've pretty much sacrificed the ability for the web to work without css and js, especially if you don't have a fallback element..." http://krijnhoetmer.nl/irc-logs/whatwg/20140407#l-396 -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From cabanier at gmail.com Tue Apr 8 09:14:50 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 09:14:50 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDAaNR6_TgZMQq2tnE8NgAoWqBDrUB+_ELZqMCPxGWe6Mg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > So this is not how most implementations currently have it defined. > > > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > > definitely do store the path in user coordinates. The spec currently > > > > says otherwise [1] though. > > > > > > I'm not sure what you're referring to here. > > > > All graphics backends for canvas that I can inspect, don't apply the CTM > > to the current path when you call a painting operator. Instead, the path > > is passed as segments in the current CTM and the graphics library will > > apply the transform to the segments. > > Right. That's what the spec says too, for the current default path. No, the spec says this: For CanvasRenderingContext2D objects, the points passed to the methods, and the resulting lines added to current default path by these methods, must be transformed according to the current transformation matrix before being added to the path. > This is the confusing behaviour to which I was referring. The "Path" API > (or > Path2D or whatever we call it) doesn't have this problem. > That is correct. The Path2D object is in user space and can be passed directly to the graphics API (along with the CTM). > ... > > > > var s = new Shape(); > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > > Shape(ctx.currentPath)); > > > > ... > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke > calls? > > > > That does not work as the second addHitRegion will remove the control and > > id from the first one. > > The 'add' operation is needed to get a union of the region shapes. > > Just use two different IDs with two different addHitRegion() calls. That's > a lot less complicated than having a whole new API. > That doesn't work if you want to have the same control for the 2 areas, from the spec for addHitRegion: If there is a previous region with this control, remove it from the scratch bitmap's hit region list; then, if it had a parent region, decrement that hit region's child count by one. Even if you don't use the control, it would be strange to have 2 separate hit regions for something that represents 1 object. > > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > ... > > > > > copy, and would help memory consummation and performance. > > > > > > I don't really understand the use case here. > > > > Jurg was just talking about an optimization (so you don't have to make > > an internal copy) > > Sure, but that doesn't answer the question of what the use case is. > >From my recent experiments with porting canvg ( https://code.google.com/p/canvg/) to use Path2D, they have a routine that continually plays a path into the context which is called from a routine that does the fill, clip or stroke. Because that routine can't simply set the current path, a lot more changes were needed. Some pseudocode that shows the added complexity, without currentPath: function drawpath() { if(Path2DSupported) { return myPath; } else for(...) { ctx.moveTo/lineTo/... } } function fillpath() { var p = drawpath(); if(p) ctx.fill(p); else ctx.fill(); } with currentPath: function drawpath() { if(Path2DSupported) { // only 2 extra lines of code ctx.currentPath = myPath; } else for(...) { ctx.moveTo/lineTo/... } function fillpath() { drawpath(); ctx.fill(); } > On Wed, 12 Mar 2014, Rik Cabanier wrote: > ... > > > You say, here are some paths, here are some fill rules, here are some > > > operations you should perform, now give me back a path that describes > > > the result given a particular fill rule. > > > > I think you're collapsing a couple of different concepts here: > > > > path + fillrule -> shape > > union of shapes -> shape > > shape can be converted to a path > > I'm saying "shape" is an unnecessary primitive. You can do it all with > paths. > > union of (path + fillrule)s -> path > No, that makes no sense. What would you get when combining a path with a fillrule and no fillrule? > > > A shape is just a path with a fill rule, essentially. > > > > So, a path can now have a fillrule? Sorry, that makes no sense. > > I'm saying a shape is just the combination of a fill rule and a path. The > path is just a path, the fill rule is just a fill rule. > After applying a fillrule, there is no longer a path. You can *convert* it back to a path that describes the outline of the shape if you want, but that is something different. The way you've defined things now, you can apply another fill rule on a path with a fill rule. What would the result of that be? > > > Anything you can do > > > with one you can do with the other. > > > > You can't add segments from one shape to another as shapes represent > > regions. > > Likewise, you can't union, intersect or xor path segments. > > But you can union, intersect, or xor lists of pairs of paths and > fillrules. > would you start throwing when doing these operations on paths without fill rules? > ... > > > > > "Wrong" meaning: > > if the author has a bunch of geometry and wants to put it in 1 path > object > > so he can just execute 1 fill operation, he might be under the impression > > that "adding" the geometry will just work. > > Well, sure, an author might be under any number of false impressions. > > The API has a way for a bunch of paths to be merged with a single fillrule > to generate a new path with no crossing subpaths (which is also fillrule > agnostic), essentially giving you the union of the shapes represented by > those paths interpreted with that fillrule. > Is this the API you're referring to? path = new Path2D(paths [, fillRule ] ) The first argument could point to paths that need different winding rules so this won't work. What if one of the paths already had a fill rule? This doesn't seem implementable/stable. > There are very few use cases where you want to add partial path segments > > together but I agree that there are some cases that it's useful to have. > > I disagree that there few such cases. Pretty much any time you create a > path, you are adding partial path segments together. Whether you do so > using one Path object all at once or multiple Path objects that you later > add together is just a matter of programming style. > It's the multiple path objects use case that is unclear to me. Is there any tool/library that does this? Looking at Adobe's graphics applications, there isn't anything like it. Looking at graphics APIs, I don't see any calls that combine paths directly. hmm, it seems the spec has changed. It didn't used to start with "Create a new path that describes the edge of the areas" With the new wording, the last sentence should be updated: Subpaths in the newly created path must wind clockwise, regardless of the direction of paths in path. Since you now create 'holes', the separate paths need to be reoriented like you specify in other parts. > ... > > > > I want them removed because they will most likely not behave in the > > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > > expect that there is 'interference' between them. > > > > > > I don't see why not. It's exactly what happens today if you were to > > > just add the same path creation statements together into the current > > > default path and fill or stroke that. > > > > Sure but who does that? > > It's how all paths are built, as far as I can tell. I don't see how else > you could build a path that consists of more than one line. > > addPath() is useful for shifting a path according to a transform. > Why not just transform() then? addPathByStrokingPath() is for creating a stroked path. > addText() is for writing text. > > I don't see how removing any of them is a win. > Yes, they are useful. The issue is that they are not implementable as currently specified. > > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > ... > > > > > > > > > How would you get a point? the width is scaled to 0. > > > > > > That's how you get a point -- scale(0,0) essentially reverts > > > everything to a zero dimensional point. > > > > OK, but the width of the point is also transformed to 0 so you get > > nothing. > > Points are always zero-width, by definition. > You can still stroke it though and get a point of the strokewidth. > ... > > However the way you defined those APIs does not make sense and will not > > give the result that authors want. > > The way to make this point would be to start from the use case, describe > the desired effect, show the "obvious" way to achieve this using the API, > and then demonstrate how it doesn't match the desired effect. > The obvious way is to go with Shape2D. It's not because I invented it; many advanced graphics APIs came offer this (including D2D and skia) > ... > > > So, it's not realistic to add this to the Path2D object. > > I don't really see why it's unrealistic. In most cases, the user agent > doesn't actually have to do any work -- e.g. if all that you're doing is > merging two paths so that you can fill them simultaneously later, the UA > can just keep the two paths as is and, when necessary, fill them. > > For cases where you really want to have this effect -- e.g. when you want > to get the outline of the dashed outline of text -- then I don't really > see any way to work around it. > That is true. That is why I proposed to make the interface more limited for now until there is a time that this functionality is available. >From Ian Hickson: > I don't think the spec should be written with a particular > implementation in mind, nor should it dictate one. I agree it shouldn't (and doesn't) dictate one. But it's crazy to not consider implementations at all when writing a spec. That way lies madness like requiring O(N^2) algorithms and solving the halting problem and all kinds of other disasters (all of which I've seen in real proposals). > > The reason for that is that even though a UA could emulate the union by > > doing multiple fill operations, Path2D allows you to stroke another path > > object. At that point, you really have to do planarization. By defining > > a Shape2D object and not allowing it to be stroked, we can work around > > this. > > Sure, by limiting the feature set dramatically we can avoid the cases > where you have to do the hard work, but we also lose a bunch of features. > For now. They can be added later. Until then, this is confusing implementors. > ... > > > > Where is the union of fill regions specified? All I see is segments > > aggregation. > > One of the Path constructors takes an array of paths and a fill rule. > See above. > > > > No one has implemented them and they are confusing the browser > > > > vendors. > > > > > > I don't think they're confusing anyone. > > > > The blink people were looking at adding this until they thought it > > through and realized that it wouldn't work. > > Realised what wouldn't work? As far as I'm aware, there's nothing that > wouldn't work. > See this thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/168925.html I think you already addressed some of the concerns. Doing the planarization is now the problem so we can't implement this. > ... > > How can you make that statement? No one has implemented them yet. > > What do you mean by "stable"? > > I assumed you meant "hasn't been changing a lot". The spec hasn't been > changing a lot, so it seems pretty stable. > You've been making a lot of changes lately so this not quite true. Because you wrote it a long time ago and nobody looked at it until now, doesn't mean that it is stable. From ian at hixie.ch Mon Apr 7 15:35:50 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 22:35:50 +0000 (UTC) Subject: [whatwg] <canvas> feedback In-Reply-To: <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> (Note: I started responding to this feedback last week, so this is missing responses to feedback sent in the last few days. Sorry about that. I'll get to that feedback in due course as well!) On Mon, 3 Mar 2014, Justin Novosad wrote: > > Say you create a new document using > document.implementation.createHTMLDocument(), you get a document without > a browsing context. This means that style and layout will never be > calculated on the document. Some of those calculations are context > dependent, so they can't even be resolved. Now, what about canvas > elements? If JS code draws to a canvas that is in a document with no > browsing context, what should happen? It should draw. In theory, anywhere in the canvas API where it depends on computed styles, it has prose saying what should happen if the computed style cannot be used. This is needed for display:none canvases, for 2D contexts in workers, and for the case you describe. > For example, there is no locale for font family resolution I'm not clear on what you mean by "locale" here. What is the locale that a displayed <canvas> in a Document in a browsing context has, that a non-displayed <canvas> outside a Document and without a browsing context does not have? > and it is not possible to resolve font sizes in physical length units > unless the document is associated with a view. Why not? The canvas has a pixel density (currently always 1:1), no? > My 2 cents: specifying fallback behaviors for all use cases that are > context dependent could be tedious and I have yet to see a real-world > use case that requires being able to paint a canvas in a frame-less > document. Therefore, I think the spec should clearly state <canvas> > elements that are in a document without a browsing context are unusable. > Not sure what the exact behavior should be though. Should an exception > be thrown upon trying to use the rendering context? Perhaps canvas draws > should fail silently, and using the canvas as an image source should > give transparent black pixels? As far as I can tell, this is all already specified, and it just gets treated like a normal canvas. On Wed, 5 Mar 2014, Rik Cabanier wrote: > > Testing all browsers (except IE since > document.implementation.createHTMLDocument() doesn't work) they seem to > handle canvas contexts with no browsing context except when you use > text. Chrome crashes, firefox throws an exception and Safari draws the > text with a very small scale I don't really understand why this is problematic in practice. What does a browsing context provide that is needed for rendering text that a user agent couldn't fake for itself in other contexts? We're definitely going to need text in worker canvases. On Thu, 6 Mar 2014, Justin Novosad wrote: > > Thanks for checking. The reason I started this thread is that I just > recently solved the crash in Chrome, and I wasn't satisfied with my > resolution. I just added an early exit, so Chrome 35 will fail silently > on calls that depend on style resolution when the canvas has no browsing > context. So now we have three different behaviors. Yay! > > I don't think the Safari behavior is the right thing to do because it > will never match the developer's intent. I agree. The developer's intent is that text be drawn as specified in the API. Why would we do anything else? On Wed, 12 Mar 2014, Rik Cabanier wrote: > On Wed, Mar 12, 2014 at 3:44 PM, Ian Hickson wrote: > > On Thu, 28 Nov 2013, Rik Cabanier wrote: > > > On Thu, Nov 28, 2013 at 8:30 AM, J?rg Lehni wrote: > > > > > > > > I meant to say that it I think it would make more sense if the > > > > path was in the current transformation matrix, so it would > > > > represent the same coordinate values in which it was drawn, and > > > > could be used in the same 'context' of transformations applied to > > > > the drawing context later on. > > > > > > No worries, it *is* confusing. For instance, if you emit coordinates > > > and then scale the matrix by 2, those coordinates from > > > getCurrentPath will have a scale of .5 applied. > > > > That's rather confusing, and a pretty good reason not to have a way to > > go from the current default path to an explicit Path, IMHO. > > > > Transformations affect the building of the current default path at > > each step of the way, which is really a very confusing API. The Path > > API on the other hand doesn't have this problem -- it has no > > transformation matrix. It's only when you use Path objects that they > > get transformed. > > This happens transparently to the author so it's not confusing. I've been confused by it multiple times over the years, and I wrote the spec. I am confident in calling it confusing. > For instance: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); <- should not affect geometry of the previous rect > ctx.stroke(); <- linewidth is scaled by 2, but rect is still 10x10 It's confusing because it's not at all clear why this doesn't result in two rectangles of different sizes: ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); ctx.scale(2,2); ctx.stroke(); ...while this does: ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); ctx.beginPath(); ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); It appears to be the same path in both cases, after all. > > > > So this is not how most implementations currently have it defined. > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > definitely do store the path in user coordinates. The spec currently > > > says otherwise [1] though. > > > > I'm not sure what you're referring to here. > > All graphics backends for canvas that I can inspect, don't apply the CTM > to the current path when you call a painting operator. Instead, the path > is passed as segments in the current CTM and the graphics library will > apply the transform to the segments. Right. That's what the spec says too, for the current default path. This is the confusing behaviour to which I was referring. The "Path" API (or Path2D or whatever we call it) doesn't have this problem. > > > Another use case is to allow authors to quickly migrate to hit regions. > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); > > > ... // lots of complex drawing operation for a control > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); > > > > > > > > > To migrate that to a region (with my proposed shape interface [1]): > > > > > > var s = new Shape(); > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > Shape(ctx.currentPath)); > > > ... > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke calls? > > That does not work as the second addHitRegion will remove the control and > id from the first one. > The 'add' operation is needed to get a union of the region shapes. Just use two different IDs with two different addHitRegion() calls. That's a lot less complicated than having a whole new API. > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > > > > > > Instead of using getCurrentPath and setCurrentPath methods as a > > > solution, this could perhaps be solved by returning the internal > > > path instead of a copy, but with a flag that would prevent further > > > alterations on it. > > > > > > The setter of the currentPath accessor / data member could then make > > > the copy instead when a new path is to be set. > > > > > > This would also make sense from a a caching point of view, where > > > storing the currentPath for caching might not actually mean that it > > > will be used again in the future (e.g. because the path's geometry > > > changes completely on each frame of an animation), so copying only > > > when setting would postpone the actual work of having to make the > > > copy, and would help memory consummation and performance. > > > > I don't really understand the use case here. > > Jurg was just talking about an optimization (so you don't have to make > an internal copy) Sure, but that doesn't answer the question of what the use case is. On Wed, 12 Mar 2014, Rik Cabanier wrote: > > > > > > > > You can do unions and so forth with just paths, no need for > > > > regions. > > > > > > How would you do a union with paths? If you mean that you can just > > > aggregate the segments, sure but that doesn't seem very useful. > > > > You say, here are some paths, here are some fill rules, here are some > > operations you should perform, now give me back a path that describes > > the result given a particular fill rule. > > I think you're collapsing a couple of different concepts here: > > path + fillrule -> shape > union of shapes -> shape > shape can be converted to a path I'm saying "shape" is an unnecessary primitive. You can do it all with paths. union of (path + fillrule)s -> path > > A shape is just a path with a fill rule, essentially. > > So, a path can now have a fillrule? Sorry, that makes no sense. I'm saying a shape is just the combination of a fill rule and a path. The path is just a path, the fill rule is just a fill rule. > > Anything you can do > > with one you can do with the other. > > You can't add segments from one shape to another as shapes represent > regions. > Likewise, you can't union, intersect or xor path segments. But you can union, intersect, or xor lists of pairs of paths and fillrules. > > > > > The path object should represent the path in the graphics state. > > > > > You can't add a stroked path or text outline to the graphics > > > > > state and then fill/stroke it. > > > > > > > > Why not? > > > > > > As designed today, you could fill it, as long as you use non-zero > > > winding. If you use even-odd, the results will be very wrong. (ie > > > where joins and line segments meet, there will be white regions) > > > > I think "wrong" here implies a value judgement that's unwarranted. > > "Wrong" meaning: > if the author has a bunch of geometry and wants to put it in 1 path object > so he can just execute 1 fill operation, he might be under the impression > that "adding" the geometry will just work. Well, sure, an author might be under any number of false impressions. The API has a way for a bunch of paths to be merged with a single fillrule to generate a new path with no crossing subpaths (which is also fillrule agnostic), essentially giving you the union of the shapes represented by those paths interpreted with that fillrule. > There are very few use cases where you want to add partial path segments > together but I agree that there are some cases that it's useful to have. I disagree that there few such cases. Pretty much any time you create a path, you are adding partial path segments together. Whether you do so using one Path object all at once or multiple Path objects that you later add together is just a matter of programming style. > > > Stroking will be completely wrong too, because joins and end caps > > > are drawn separately, so they would be stroked as separate paths. > > > This will not give you the effect of a double-stroked path. > > > > I don't understand why you think joins and end caps are drawn > > separately. That is not what the spec requires. > > Sure it does, for instance from > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path > : > > The round value means that a filled arc connecting the two > aforementioned corners of the join, abutting (and not overlapping) the > aforementioned triangle, with the diameter equal to the line width and > the origin at the point of the join, must be added at joins. > > If you mean, "drawn with a separate fill call", yes that is true. > What I meant was that they are drawn as a separate closed path that will > interact with other paths as soon as there are different winding rules or > "holes". The word "filled" is a bit misleading here (I've removed it), but I don't see why that led you to the conclusion you reached. The step in question begins with "Create a new path that describes the edge of the areas that would be covered if a straight line of length equal to the styles lineWidth was swept along each path in path while being kept at an angle such that the line is orthogonal to the path being swept, replacing each point with the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, and replacing each join with the join necessary to satisfy the styles lineJoin type, as defined below", which seems pretty unambiguous. > > > > We seem to be going around in circles. We're in agreement that > > > > eventually we should add APIs for combining paths such that we get > > > > the equivalent of the union of their fill regions. I agree that > > > > converting text into paths is non-trivial (lots of stuff browsers > > > > do is non-trivial, that's kind of the point -- if it was trivial, > > > > we could leave it for authors). But I don't see how we get from > > > > there to you wanting the existing APIs removed. > > > > > > I want them removed because they will most likely not behave in the > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > expect that there is 'interference' between them. > > > > I don't see why not. It's exactly what happens today if you were to > > just add the same path creation statements together into the current > > default path and fill or stroke that. > > Sure but who does that? It's how all paths are built, as far as I can tell. I don't see how else you could build a path that consists of more than one line. addPath() is useful for shifting a path according to a transform. addPathByStrokingPath() is for creating a stroked path. addText() is for writing text. I don't see how removing any of them is a win. > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > > > > > > > > > > However, for your example, I'm unsure what the right solution > > > > > is. The canvas specification is silent on what the behavior is > > > > > for non-invertible matrices. > > > > > > > > What question do you think the spec doesn't answer? > > > > > > > > > I think setting scale(0,0) or another matrix operation that is > > > > > not reversible, should remove drawing operations from the state > > > > > because: - how would you stroke with such a matrix? > > > > > > > > You'd get a point. > > > > > > How would you get a point? the width is scaled to 0. > > > > That's how you get a point -- scale(0,0) essentially reverts > > everything to a zero dimensional point. > > OK, but the width of the point is also transformed to 0 so you get > nothing. Points are always zero-width, by definition. > We've gone over this several times now. > The APIs that you define, have use cases and I agree with them. > However the way you defined those APIs does not make sense and will not > give the result that authors want. The way to make this point would be to start from the use case, describe the desired effect, show the "obvious" way to achieve this using the API, and then demonstrate how it doesn't match the desired effect. > What you specified there is called "planarization". This is when you > calculate the intersections within and between closed shapes and remove the > line segments that are filled on both sides. > By specifying this: > > The subpaths in merged path must be oriented such that for any point, the > number of times a half-infinite straight line drawn from that point crosses > a subpath is even if and only if the number of times a half-infinite > straight line drawn from that same point crosses a subpath going in one > direction is equal to the number of times it crosses a subpath going in the > other direction. > > and relying on segment removal, you also get the same fill behavior for > even-odd. (Meaning that the end result can be used with either winding rule) > This is not something that is needed for just text but also when you do a > union of shapes. > > The bad news is that this algorithm is very expensive and there are few > libraries that do a decent job (I only know of 1). > So, it's not realistic to add this to the Path2D object. I don't really see why it's unrealistic. In most cases, the user agent doesn't actually have to do any work -- e.g. if all that you're doing is merging two paths so that you can fill them simultaneously later, the UA can just keep the two paths as is and, when necessary, fill them. For cases where you really want to have this effect -- e.g. when you want to get the outline of the dashed outline of text -- then I don't really see any way to work around it. > The reason for that is that even though a UA could emulate the union by > doing multiple fill operations, Path2D allows you to stroke another path > object. At that point, you really have to do planarization. By defining > a Shape2D object and not allowing it to be stroked, we can work around > this. Sure, by limiting the feature set dramatically we can avoid the cases where you have to do the hard work, but we also lose a bunch of features. > > I don't think the arguments for removing these are compelling. The > > problems with the APIs have been addressed (e.g. there's no ambiguity > > in the case of overlapping text), the use cases are clear (e.g. > > drawing text around an arc or drawing a label along a line graph's > > line), and the API now supports the constructs to do unions of fill > > regions. > > Where is the union of fill regions specified? All I see is segments > aggregation. One of the Path constructors takes an array of paths and a fill rule. > > > No one has implemented them and they are confusing the browser > > > vendors. > > > > I don't think they're confusing anyone. > > The blink people were looking at adding this until they thought it > through and realized that it wouldn't work. Realised what wouldn't work? As far as I'm aware, there's nothing that wouldn't work. > > > Until we have support for shapes, the output of these methods won't > > > be stable. > > > > These methods have been very stable. They have barely changed since > > they were added, except for some minor tweaks to fix bugs. > > How can you make that statement? No one has implemented them yet. What do you mean by "stable"? I assumed you meant "hasn't been changing a lot". The spec hasn't been changing a lot, so it seems pretty stable. On Fri, 14 Mar 2014, Justin Novosad wrote: > On Fri, Mar 14, 2014 at 2:29 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > If the bug is that Chrome resamples the image in an ugly way, then > > that's a bug with Chrome. As the bug says, browsers are allowed to > > pick whatever algorithm they want -- it's a quality-of-implementation > > issue. But if the result is ugly, that's a low quality implementation. > > Yes, and if we fixed it to make it prettier, people would complain about > a performance regression. It is impossible to make everyone happy right > now. Would be nice to have some kind of speed versus quality hint. The problem with a hint is that it will be set incorrectly, and so instead of having something that's mostly pretty but mostly fast for everyone, you'd end up with something that's slow on sites that need things to be fast, and things that are ugly on sites that need things to be pretty. In general I think it is very unwise for us to design APIs with hints that have subtle effects on developer machines but that can cripple performance on low-end devices. Instead, we should use adaptive algorithms, for example always using the prettiest algorithms unless we find that frame rate is suffering, and then stepping down to faster algorithms. On Wed, 26 Mar 2014, K. Gadd wrote: > > As I mentioned to Ryosuke off-list, I think the > interpolateEndpointsCleanly attribute is a (relatively) simple solution > to the problem I have with the current spec, and it doesn't > overcomplicate things or make it hard to improve filtering in the > future. It's also trivial to feature-detect, which means I can use it > when available and fallback to a temporary canvas otherwise. I think > providing this option would also make it easier to solve situations > where applications rely on the getImageData output after rendering a > scaled bitmap. > > I'd probably call it something (to me) clearer about semantics, though, > like 'sampleInsideRectangle' Here you are suggesting a feature that would override the requirement in the spec that reads "When the filtering algorithm requires a pixel value from outside the source rectangle but inside the original image data, then the value from the original image data must be used", right? What would you replace it with, exactly? Transparent black? The value from the nearest edge pixel inside the rectangle? Can you elaborate on the use case? On Fri, 14 Mar 2014, Rik Cabanier wrote: > On Fri, Mar 14, 2014 at 11:09 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 4 Dec 2013, J?rg Lehni wrote: > > > > > > Implementing [layering/grouping] would help us greatly to optimize > > > aspects of Paper.js, as double buffering into separate canvases is > > > very slow and costly. > > > > Can you elaborate on what precisely the performance bottleneck is? I > > was looking through this thread but I can't find a description of the > > use cases it addresses, so it's hard to evaluate the proposals. > > Let's say you're drawing a scene and there is a bunch of artwork that > you want to apply a multiply effect or opacity to. With today's code, it > would look something like this: > > var bigcanvas = document.getElementById("c"); > var ctx = bigcanvas.getContext("2d"); > ctx.moveto();.... // drawing underlying scene > > ctx.globalAlpha(.5); > var c = document.createElement("canvas"); > ctx2 = c.getContext("2d"); > ctx2.moveto();.... // drawing scene that needs the effect > ctx.drawImage(c, 0, 0); > > With layers, it would become: > > var bigcanvas = document.getElementById("c"); > var ctx = bigcanvas.getContext("2d"); > ctx.moveto();.... // drawing underlying scene > > ctx.globalAlpha(.5); > ctx.beginLayer(); > ctx.moveto();.... // drawing scene that needs the effect > ctx.endLayer(); > > So, with layers you > - avoid creating (expensive) DOM elements Not really though, right? I mean, the user agent still has to create the intermediate bitmap to apply the effects to. > - simplify the drawing (especially when there's a transformation) Why would it be simpler? There's a bug tracking this feature currently: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22704 On Fri, 14 Mar 2014, Rik Cabanier wrote: > > Path2D has now landed in Blink [1]. Blink also implemented the 'addPath' > method. > WebKit just landed a patch to rename Path to Path2D, remove currentPath and > add fill/stroke/clip with a path [2]. > A patch is under review for Firefox to add Path2D. > > Given this, can we change the spec to reflect the new name? > > 1: https://codereview.chromium.org/178673002/ > 2: https://webkit.org/b/130236 > 3: https://bugzilla.mozilla.org/show_bug.cgi?id=830734 Done. On Tue, 18 Mar 2014, J?rg Lehni wrote: > > So is currentPath going away then for sure? Will there still be a way to > to retrieve a Path2D representation of the path being drawn by the long > existing drawing commands on the context? > > I quite liked how I could use it for caching, in case the browser > supported that feature, and check wether I have a cached path the next > time I need to draw it, falling back on redrawing it using the same > drawing commands. Doing the same by feature-detecting the Path(2D) > constructor and building separate drawing approaches based on its > existence results in much more complicated code. Why is it so complicated? Here's an example of how you could do it, assuming you wanted to cache certain paths function myCircle(p) { p.moveTo(0,0); // etc... } function fillPath(c, callback) { if (window.Path2D) { var p; if (pathIsAlreadyCached(callback.name)) { p = getCachedPath(callback.name); } else { p = new Path2D(); callback(p); saveCachedPath(p, callback.name); } c.fill(p); } else { c.beginPath(); callback(c); c.fill(); } } fillPath(c, myCircle); On Tue, 18 Mar 2014, Dirk Schulze wrote: > > I am still in favor for a setter and getter as well. It had the benefit > that you were able to transform the context and it affected drawing > commands as well. It is more complicated to create a second Path2D > object and add it to a previous path with a transform. I'm not sure I understand what you mean. The interactions of transforms and path building on the 2D context was one of the biggest problems that the Path objects are intended to side-step. On Fri, 14 Mar 2014, Rik Cabanier wrote: > > > > Event retargetting now explicitly applies to "the control represented > > by the region", which is always null if the given control is now a > > text field. > > Does this change the eventTarget attribute on the event object [1]. It changes the "target" attribute, if that's what you mean. (See step 3 of the dispatch algorithm in DOM.) > > > More generally, is this event rerouting supposed to be able to > > > trigger browser default event handling behavior, or only DOM event > > > dispatch? > > > > As it was specified, I don't see how it could trigger default actions > > of anything other than the canvas and its ancestors. The canvas hook > > ran in the middle of the "When a pointing device is clicked, the user > > agent must run these steps" algorithm, which refers to the origin > > target, not the rerouted target. > > > > I've now changed this so that it does in fact trigger the default > > action if applicable. > > This will still just reroute events, right? Not sure what you mean by "just". > For instance, if the fallback element is a <a href="...">, will clicking > on the region cause the browser to follow the hyperlink? Yes. > > On Wed, 5 Mar 2014, Robert O'Callahan wrote: > > > > > > The problem is that if these retargeted events can trigger default > > > browser behavior, the browser has to be able to compute the position > > > of the event relative to the new target DOM node, and it's not clear > > > how to do that. > > > > I've made it explicit that the elements that can get clicks targetted > > to them only include elements that don't have subregions. In > > particular, image maps and image buttons are excluded. > > Thanks for updating the spec. It's getting quite complex though :-( > Maybe it's simpler to just add the id to the event and leave the canvas > element as the target? Since this is not a major feature, the complexity > might stop implementors. I don't understand what part you think is complicated here. Can you elaborate? > > > Currently, the specification states that if you create a region and > > > then create another region that completely covers region, the first > > > region is removed from the hit region list [1] > > > > > > This is a complex operation that involves either drawing the regions > > > to a bitmaps and counting pixels, or path intersection. > > > > There's two trivial ways to implement this, depending on whether the > > hit regions are backed by a bitmap (the simplest and fastest solution > > but uses a lot of memory) or a region list (slower, but much more > > memory efficient). In the case of a bitmap, you just draw on the new > > region, and the old region is no longer in the bitmap, so it's > > trivially gone. > > > > In the case of a list, you put the new region ahead of the old region > > so that you never actually get around to checking the old region. > > The following step still needs to run though: > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#garbage-collect-the-regions > > Let victim be the first hit region in list to have an empty set of > pixels and a zero child count, if any. > > If this was implemented with a bitmap, the only way to figure this out > is to walk the individual pixels (= expensive). This is garbage collection, it doesn't have to run often. When it _is_ run, it's actually pretty fast -- in the bitmap case, for example, you just need to walk the bitmap and for every pixel with a defined region mark the region as non-empty. This is O(N) with the size of the bitmap, but with a _very_ low constant factor (lower than recolourising a bitmap, say, which is something we expect authors to do in JS). > We should also not forget that a11y needs the bounding box of the hit > region which also means constantly walking of the pixels. Not "constantly". This kind of thing is trivially cacheable. It's also relatively simple to just check the pixels you're about to overwrite and note those regions as needing updating; when you _do_ update them, they can only have gotten smaller so you can just walk the edge of the bounding rectangle until you hit a pixel on each side. Plus, the bounding box doesn't have to be updated often -- the user isn't going to be jumping to the area every ten milliseconds or anything, and even if the user did, using a slightly out-of-date bounding box is fine (it'll just be bigger than strictly necessary). > > > It is also unintuitive because an author might expect that he could > > > remove the second region and still have the first region active. > > > > That would be inconsistent with how canvas works. Canvas is an > > immediate-mode API. If you draw on the canvas, and then clear it, you > > don't get back what was there before. > > What if an author doesn't clear it but just calls fillRect or is smart > and just invalidates/redraws portions of the canvas? Hit regions should > keep state, regardless of the canvas pixels. Those would just work, as far as I can tell. Do you have a concrete example? > > > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/thread.html#36556 > > > > > > It looks like that thread never came to a conclusion. > > > > Is there anything specifically that was raised in that thread that you > > think hasn't been responded to? > > Well, you had the last response but I don't think it came to a > conclusion :-) If people don't respond to my requests for clarification or if they don't disagree with the last thing I say, then that's a conclusion... > At the time, I was under the impression that we could mimic it with > paths but when I read the spec closer, the step that removes the region > pixels is too complex to implement and unintuitive for authors [2] As discussed earlier in this thread, it's easy to implement this using a list of paths, you just draw the cleared pixels as a new region on the top of your list. I don't see what's unintuitive here. > > > The arguments against using a bitmap presentation still stand: - it > > > will be too expensive to keep an actual copy of the canvas pixels in > > > memory to do hit testing > > > > It's actually pretty common to do exactly this. Note that you don't > > necessarily need a bitmap that has the same bit depth or pixel density > > as the visible bitmap. > > Where else does this happen? A Google search for "hit test bitmap" shows some examples, but unfortunately it's a hard topic to search for -- I kept running into examples of people trying to do collision detection with bitmaps instead! > Creating a canvas bitmap for constant reading will also be extremely > costly since so many implementations run canvas operations on the GPU. > I'm unsure if anyone supports a 8 bit backbuffer so at best, the hit > region bitmap is half the size. This is too expensive. Don't forget that this doesn't have to be a very high fidelity bitmap. It doesn't get any anti-aliasing, it has no alpha transparency, there's no bitmap drawing, it doesn't necessarily have to be full-density, either (it's unlikely that authors are going to have hit regions that are half a CSS pixel high, for instance). It's quite plausible to do all the work for this bitmap in software on the CPU, as far as I can tell. You can also use a hybrid approach, with the most recent regions added to a list, and the list regularly compressed down to a bitmap when the CPU load is low, or on a separate thread, such that the bitmap generation cost is a non-issue, while still not having to pay the cost of having all the regions in a long list, and while having the GC computations described earlier be reasonably straight-forward to compute (modulo inter-thread communication, which is always fun). > > > - if you have to mimic the behavior with paths, you need access to > > > expensive/difficult path manipulation algorithms > > > > The maths for determining if a region is contained in another region > > is pretty well understood at this point, as far as I can tell. > > It's still a hard problem. Looking at Firefox' and Apple's > implementation, I don't know how they could determine if a path is > contained within another path. Google has a library in development. We > looked at it 6 months ago and it had many issues. Our job is to implement these hard problems so that authors don't have to. > > > Hit regions should be redesigned so they work on the path geometry > > > as opposed to pixels. We already have the necessary code to do hit > > > testing on paths (see isPointInPath) > > > > isPointInPath() works on pixels just like hit regions works on pixels. > > No, this is not how it's implemented. > WebKit, Blink and Firefox use the geometry of the path. They don't use > pixels. That's an implementation detail. My point is that to an author, it's all pixels. The API takes in two coordinates, and gives you a boolean result. > > On Wed, 12 Mar 2014, Dirk Schulze wrote: > > > > > > In SVG we tried to avoid having hit testing based on pixel values > > > obviously for performance reasons. > > > > SVG is a retained-mode API, so naturally it has a different model. > > I don't see why. A browser draws the SVG DOM to a screen bitmap and then > does hit testing with fine paths. Canvas could do the exact same thing. If Canvas and SVG do "the exact same thing", then we should drop one. The whole point of <canvas> is to be an immediate-mode API that complements SVG. > People think of this API as populating a hit region OM. Why not go this > route? What people? > > > clearRect is currently defined as a subtraction mechanism for hit > > > regions [1]. > > > > > > It's unlikely that a UA will implement hit regions using pixels so > > > this would have to be done using path subtraction which is > > > expensive. > > > > I'm not sure why you think it's expensive. It's trivial to just add a > > rectangle to the front of the list of regions. > > That is true. This does mean that if there are a lot of small clearRect > calls, the list of regions could become very long. Sure. Same with if there are a lot of rectanglular hit regions added. The model above, where you start off with a list, but regularly flatten it to a bitmap, would lower the cost of maintaining such a list. > > > Why was this special behavior added to clearRect? > > > > Because it's the most obvious mechanism for authors. You clear a part > > of the canvas, naturally that part of the canvas no longer has > > regions. > > Why is that naturally? Because nothing is rendered there any more. > So, if an author clears an area there are no more regions in it, but if > he draws over it, they are still there? Right. Same as with regular drawing. If you clear it, it's gone. If you draw on top of it, it contributes (e.g. in the colour of anti-aliased lines, showing through where the content on top is transparent, etc). > Clipping also doesn't affect regions. Hm, good point. Fixed. > > On Tue, 4 Mar 2014, Rik Cabanier wrote: > > > > > > The spec implies-- > > > > The spec doesn't imply anything. It either requires something, or > > doesn't. If you ever find yourself reading between the lines, then > > there is either a spec bug, or you are reading something that the spec > > doesn't require. > > I know that. So, if I write "the spec implies", you can assume that I > believe that the spec is incomplete. I would rather you just said "the spec doesn't say whether..." rather than "the spec implies", since the latter has a very different meaning. On Sat, 15 Mar 2014, Dirk Schulze wrote: > > I would suggest a filter attribute that takes a list of filter > operations similar to the CSS Image filter function. Similar to > shadows[2], each drawing operation would be filtered. The API looks like > this: > > partial interface CanvasRenderingContext2D { > attribute DOMString filter; > } > > A filter DOMString could looks like: ?contrast(50%) blur(3px)? > > With the combination of grouping in canvas it would be possible to > group drawing operations and filter them together. > > Filter functions include a reference to a <filter> element and a > specification of SVG filters. I am unsure if a reference do an element > within a document can cause problems. If it does, we would just not > support SVG filter references. I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25243 On Mon, 17 Mar 2014, Justin Novosad wrote: > > Hmmm, I gave this a bit more thought... To apply the construction > algorithm in transformed space, the ellipse parameters (radiusX, > radiusY, rotation) would have to be transformed. Transforming the > parameters would be intractable under a projective transform (e.g. > perspective), but since we are limitted to affine transforms, it can be > done. Now, in the case of a non-invertible CTM, we would end up with > radiusX or radiusY or both equal to zero. And what happens when you > have that? Your arcTo just turned into lineTo(x1, y1). Tada! On Mon, 17 Mar 2014, Dirk Schulze wrote: > > Why does radiusX or radiusY need to be zero? Because you define it that > way for a non-invertible matrix? That makes sense for scale(0,0). What > about infinity or NaN? If Ian didn?t update the spec then this is still > undefined and therefore up to the UA to decide. How can it be infinity or NaN? (Recall that except where otherwise specified, for the 2D context interface, any method call with a numeric argument whose value is infinite or a NaN value must be ignored.) On Mon, 17 Mar 2014, Rik Cabanier wrote: > > I'm unsure if anyone has shipped that part of the spec. There's > certainly no interop... I am loathe to keep changing this kind of thing. We settled this part of the spec years ago. Let's not go back now. If we keep changing things like this, people will (rightly) complain that they can't trust the spec. > So, what we could say is: > - when drawing paths, ignore all calls if the matrix is non-invertible > (WebKit and Blink do this) > - when filling/stroking/clipping, ignore all calls if the matrix is > non-invertible (Firefox, WebKit and Blink do this) As far as I can tell, this is unnecessary. On Mon, 17 Mar 2014, Justin Novosad wrote: > > Yes, but there is still an issue that causes problems in Blink/WebKit: > because the canvas rendering context stores its path in local > (untransformed) space, whenever the CTM changes, the path needs to be > transformed to follow the new local spcae. This transform requires the CTM > to be invertible. So now webkit and blink have a bug that causes all > previously recorded parts of the current path to be discarded when the CTM > becomes non-invertible (even if it is only temporarily non-invertible, even > if the current path is not even touched while the matrix is > non-invertible). I have a fix in flight that fixes that problem in Blink by > storing the current path in transformed coordinates instead. I've had the > fix on the back burner pending the outcome of this thread. Indeed. It's possible to pick implementation strategies that just can't be compliant; we shouldn't change the spec every time any implementor happens to make that kind of mistake, IMHO. (Of course the better long-term solution here is the Path objects, which are transform-agnostic during building.) Just to be clear, we should support this because otherwise the results are just wrong. For example, here some browsers currently show a straight line in the default state, and this causes the animation to look ugly in the transition from the first frame to the secord frame (hover over the yellow to begin the transition): http://junkyard.damowmow.com/538 Contrast this to the equivalent code with the transforms explicitly multiplied into the coordinates: http://junkyard.damowmow.com/539 I don't see why we would want these to be different. From the author's perspective, they're identical. On Thu, 20 Mar 2014, Rik Cabanier wrote: > > It would be great if we could get clarification on this. I'm not sure what needs clarifying. The spec seems clear here. > Firefox and IE are conformant per the spec when it comes to drawing paths > but not fill/stroke/clip. Can you elaborate on how Firefox doesn't match the spec for stroke and clip? For fill, it does indeed seem to ignore the rule in the spec that says that fill solid colours are unaffected by the current transformation. It has a similar impact on renderings as the examples above: http://junkyard.damowmow.com/540 > Supporting this small edge case comes at a large cost in Firefox and > likely also IE. Can you elaborate on this cost? > Many APIs in canvas are running into this issue which results in lack of > interoperability. As far as I can tell, the spec is unambiguous. Certainly it does appear that browsers haven't yet converged on what the spec says, but that isn't unusual; it takes time for browsers to converge, especially for edge cases like this where there's not much pressure (since authors tend to just work around the bugs). On Wed, 19 Mar 2014, Dirk Schulze wrote: > > I just looked at the definition of Path.addPath[1]: > > void addPath(Path path, SVGMatrix? transformation); > > SVGMatrix is nullable but can not be omitted all together. Why isn?t it > optional as well? I think it should be optional [...] That seems reasonable. Done. On Wed, 19 Mar 2014, Rik Cabanier wrote: > > [context . currentTransform] > > As currently specified, this must return a live SVGMatrix object, > meaning that as you change the CTM on the 2d context, your reference to > the SVGMatrix should change as well. > > It's unlikely that you actually want this... Why? See Chris' original proposal here: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Mar/0269.html I would be reluctant to change this to a different design without their input. On Fri, 21 Mar 2014, Joe Gregorio wrote: > On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > > > I just looked at the definition of Path.addPath[1]: > > > > void addPath(Path path, SVGMatrix? transformation); > > > > SVGMatrix is nullable but can not be omitted all together. Why isn?t it > > optional as well? I think it should be optional, especially because > > creating an SVGMatrix at the moment means writing: > > > > var matrix = document.createElementNS('http://www.w3.org/2000/svg > > ','svg').createSVGMatrix(); > > Agreed, that's painful, +1 for making it optional. Just so we're clear, even when it wasn't optional, you didn't have to do any of that. You can just pass null. (It's still not optional for some of the other methods where it's in the middle of the arguments and making it optional doesn't make much sense.) On Sat, 22 Mar 2014, Dirk Schulze wrote: > > Does some one think it would be necessary to make SVGMatrix nullable > (optional SVGMatrix?)? I think it would be superfluous. It's needed for consistency with the other methods. On Thu, 20 Mar 2014, Rik Cabanier wrote: > > addPath is currently defined on the Path2D object. [1] > Is there a reason why it's not defined on CanvasPathMethods instead? > That way this method is available on the 2d contest so you can append a > path to the current graphics state. What's the use case? On Thu, 20 Mar 2014, Dirk Schulze wrote: > > I am supportive for this idea! I agree that this would solve one of the > reasons why I came up with currentPath for WebKit in the first place. Can you elaborate on the reason for this? On Thu, 20 Mar 2014, Justin Novosad wrote: > > This would apply the CTM to the incoming path, correct? I am a little > bit concerned that this API could end up being used in ways that would > cancel some of the performance benefits (internal caching opportunities) > of Path2D objects. Right, that's why it's not currently on CanvasPathMethods. The idea is to make a clean break from the world where the transforms affect the building of the path. On Thu, 20 Mar 2014, Dirk Schulze wrote: > > Where is the difference to fill(Path2D), stroke(Path2D) and > clip(Path2D)? The path will always need to be transformed to the CTM. > Graphic libraries usually do this already for you. The addPath() > proposal is not different to that. The difference is that there, you only have one path with one transform, not different parts of the path built with different transforms. On Thu, 20 Mar 2014, Justin Novosad wrote: > > The recently added currentTransform attribute on > CanvasRenderingContext2D gives shared access to the rendering context's > transform. By "shared", I mean: > > a) this code modifies the CTM: > var matrix = context.currentTransform; > matrix.a = 2; > > b) In this code, the second line modifies matrix: > var matrix = context.currentTransform; > context.scale(2, 2); > > This behavior is probably not what most developers would expect. It's the behaviour that was requested by the pdf.js developers. :-) On Thu, 20 Mar 2014, Simon Sarris wrote: > > FF (at least Aurora/Nightlies) has for some time had mozCurrentTransform > (and mozCurrentTransformInverse), which return an Array (so not > spec-compliant, since spec wants SVGMatrix). It is not shared, so it > does not do what your a) and b) examples do. > > I agree that changing it to a getter method would be better, it would be > more intuitive and clear for developers. On Mon, 24 Mar 2014, Hwang, Dongseong wrote: > > Looking over this thread, we make a consensus not to expose > currentTransform attribute. Consensus is not how we decide things in the WHATWG. It's based on the strength of arguments. So far, it seems the arguments either way are about equal. On the one hand you have a developer asking for the current API. On the other hand you have implementors saying that the current API is bad for developers. What we need to make more progress, I think, is more concrete arguments, for example sample code that uses both APIs so we can see how authors would experience the two APIs in the real world. On Mon, 24 Mar 2014, Simon Sarris wrote: > > I think using "Current" in the naming convention is silly. The transform > just as much a part of state as lineWidth/etc, but nobody would propose > naming lineWidth something like currentLineWidth! There's no way to get > a *non-current* transformation matrix (or lineWidth), so I think the > distinction is unnecessary. > > CTM only seems like a good idea if we're worried that the name is too > long, but since "Current" is redundant/extraneous, I don't think an > initialism is worth the added layer of confusion. These are solid arguments if we agree that we should change the spec. On Sun, 23 Mar 2014, Dirk Schulze wrote: > > 1) I noticed that createImageData() is explicit that it represent a > transparent black rectangle. The constructor for ImageData is not that > explicit. Fixed. > 2) The last step of the 2nd constructor that takes an Uint8ClampedArray > says: " ? Return a new ImageData object whose width is sw, whose height > is height, and whose data is source.? > > Is data a reference to the original source or a copy of source? For the > former, there might be two ImageData objects referencing the same > ByteArray. How would that be useful? The steps say that the data is the Uint8ClampedArray "source". I've added a note making the fact that it's not a copy more explicit. On Mon, 24 Mar 2014, J?rg Lehni wrote: > > Non-scaling Strokes in Canvas. > > The request has come up multiple times on the paper.js mailing list [1], > and we will emulate this in JavaScript. > > But since this will involve baking the CTM into the path to be drawn, > and setting the CTM to the identity matrix, I was wondering if this is > something worth supporting natively for the obvious reason of improved > performance? You can do this with the new Path2D API, right? On Tue, 25 Mar 2014, Dirk Schulze wrote: > > [...] currentTransform [...] > what should be returned for a CTM that is singular (not invertible)? Even when the transform is not invertible, it's precise value is still well-defined, no? > In WebKit we do not track all transformations of the CTM that caused a > singular matrix or are following a transformation that would have caused > a singular matrix. > > Example: > > ctx.scale(0,0); > ct.translate(10,10); The matrix should be 0,0,0,0,0,0 here. It starts as 1 0 0 0 1 0 0 0 1 Then you apply a scale transform to 0,0: 1 0 0 0 0 0 0 0 0 0 1 0 x 0 0 0 = 0 0 0 0 0 1 0 0 1 0 0 1 Then you post-multiply that by the translation by 10,10: 1 0 0 0 0 0 1 0 10 0 0 0 0 1 0 x 0 0 0 x 0 1 10 = 0 0 0 0 0 1 0 0 1 0 0 1 0 0 1 ...and that's the matrix you should return. > In webkit we would not apply the transformation scale(0,0) and mark the > CTM as not-invertible instead. I do not believe this is an implementation strategy that can lead to a conforming implementation. Note that this is the same as what you would get if you did: var a = new SVGMatrix(1,0,0,1,0,0); // assuming this interface gets a constructor, anyway a = a.scale(0,0); a = a.translate(10,10); ...so this is not unique to the canvas API. On Tue, 25 Mar 2014, Justin Novosad wrote: > > I prepared a code change to that effect, but then there was talk of > changing the spec to skip path primitives when the CTM is not > invertible, which I think is a good idea. It would avoid a lot of > needless hoop jumping on the implementation side for supporting weird > edge cases that have little practical usefulness. I'm not sure I agree that they have little practical usefulness. Zeros often occur at the edges of transitions, and if we changed the spec then these transitions would require all the special-case code to go in author code instead of implementor code. On Sun, 30 Mar 2014, Dirk Schulze wrote: > > Canvas let you set alignment baselines with the textBaseline attribute > [1]. > > One of the baseline values is ?middle?. The description of the ?middle? > baseline seems to be in conflict with the definition for the > alignment-baseline property in CSS[2]. > > Canvas: The middle of the em square > CSS: [..] it may be computed using 1/2 the "x-height? > > What Canvas uses as middle is described as ?center? in CSS. Is there a > way that we can change the naming and/or definition of ?middle? in > Canvas? This seems like something that's too late to change. (I think using "middle" for what is between "top" and "bottom" makes eminent sense, though, so it doesn't seem like that big a problem.) On Mon, 31 Mar 2014, Justin Novosad wrote: > > Wow, that is confusing. How can this be fixed without breaking existing > web content? Are browsers currently compliant with the canvas spec, or > do they implement the CSS definition of middle? Looks like everyone does it per the canvas spec: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2924 The CSS 'vertical-align' property works per the CSS spec on the browsers I tested, too, FWIW: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2925 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Tue Apr 8 09:07:21 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 09:07:21 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDRtCREBBG5koWfR-PDv_=dJejfA-WOniSwygSD4YhhWg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > So this is not how most implementations currently have it defined. > > > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > > definitely do store the path in user coordinates. The spec currently > > > > says otherwise [1] though. > > > > > > I'm not sure what you're referring to here. > > > > All graphics backends for canvas that I can inspect, don't apply the CTM > > to the current path when you call a painting operator. Instead, the path > > is passed as segments in the current CTM and the graphics library will > > apply the transform to the segments. > > Right. That's what the spec says too, for the current default path. No, the spec says this: For CanvasRenderingContext2D objects, the points passed to the methods, and the resulting lines added to current default path by these methods, must be transformed according to the current transformation matrix before being added to the path. > This is the confusing behaviour to which I was referring. The "Path" API > (or > Path2D or whatever we call it) doesn't have this problem. > That is correct. The Path2D object is in user space and can be passed directly to the graphics API (along with the CTM). > > > > Another use case is to allow authors to quickly migrate to hit > regions. > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); > > > > ... // lots of complex drawing operation for a control > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); > > > > > > > > > > > > To migrate that to a region (with my proposed shape interface [1]): > > > > > > > > var s = new Shape(); > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > > Shape(ctx.currentPath)); > > > > ... > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke > calls? > > > > That does not work as the second addHitRegion will remove the control and > > id from the first one. > > The 'add' operation is needed to get a union of the region shapes. > > Just use two different IDs with two different addHitRegion() calls. That's > a lot less complicated than having a whole new API. > That doesn't work if you want to have the same control for the 2 areas, from the spec for addHitRegion: If there is a previous region with this control, remove it from the scratch bitmap's hit region list; then, if it had a parent region, decrement that hit region's child count by one. Even if you don't use the control, it would be strange to have 2 separate hit regions for something that represents 1 object. > > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > ... > > > > copy, and would help memory consummation and performance. > > > > > > I don't really understand the use case here. > > > > Jurg was just talking about an optimization (so you don't have to make > > an internal copy) > > Sure, but that doesn't answer the question of what the use case is. > >From my recent experiments with porting canvg ( https://code.google.com/p/canvg/) to use Path2D, they have a routine that continually plays a path into the context which is called from a routine that does the fill, clip or stroke. Because that routine can't simply set the current path, a lot more changes were needed. Some pseudocode that shows the added complexity, without currentPath: function drawpath() { if(Path2DSupported) { return myPath; } else for(...) { ctx.moveTo/lineTo/... } } function fillpath() { var p = drawpath(); if(p) ctx.fill(p); else ctx.fill(); } with currentPath: function drawpath() { if(Path2DSupported) { // only 2 extra lines of code ctx.currentPath = myPath; } else for(...) { ctx.moveTo/lineTo/... } function fillpath() { drawpath(); ctx.fill(); } > On Wed, 12 Mar 2014, Rik Cabanier wrote: > > > > > > > > > > You can do unions and so forth with just paths, no need for > > > > > regions. > > > > > > > > How would you do a union with paths? If you mean that you can just > > > > aggregate the segments, sure but that doesn't seem very useful. > > > > > > You say, here are some paths, here are some fill rules, here are some > > > operations you should perform, now give me back a path that describes > > > the result given a particular fill rule. > > > > I think you're collapsing a couple of different concepts here: > > > > path + fillrule -> shape > > union of shapes -> shape > > shape can be converted to a path > > I'm saying "shape" is an unnecessary primitive. You can do it all with > paths. > > union of (path + fillrule)s -> path > No, that makes no sense. What would you get when combining a path with a fillrule and no fillrule? > > > A shape is just a path with a fill rule, essentially. > > > > So, a path can now have a fillrule? Sorry, that makes no sense. > > I'm saying a shape is just the combination of a fill rule and a path. The > path is just a path, the fill rule is just a fill rule. > After applying a fillrule, there is no longer a path. You can *convert* it back to a path that describes the outline of the shape if you want, but that is something different. The way you've defined things now, you can apply another fill rule on a path with a fill rule. What would the result of that be? > > > Anything you can do > > > with one you can do with the other. > > > > You can't add segments from one shape to another as shapes represent > > regions. > > Likewise, you can't union, intersect or xor path segments. > > But you can union, intersect, or xor lists of pairs of paths and > fillrules. > would you start throwing when doing these operations on paths without fill rules? > ... > > > > "Wrong" meaning: > > if the author has a bunch of geometry and wants to put it in 1 path > object > > so he can just execute 1 fill operation, he might be under the impression > > that "adding" the geometry will just work. > > Well, sure, an author might be under any number of false impressions. > > The API has a way for a bunch of paths to be merged with a single fillrule > to generate a new path with no crossing subpaths (which is also fillrule > agnostic), essentially giving you the union of the shapes represented by > those paths interpreted with that fillrule. > Is this the API you're referring to? path = new Path2D(paths [, fillRule ] ) The first argument could point to paths that need different winding rules so this won't work. What if one of the paths already had a fill rule? This doesn't seem implementable/stable. > There are very few use cases where you want to add partial path segments > > together but I agree that there are some cases that it's useful to have. > > I disagree that there few such cases. Pretty much any time you create a > path, you are adding partial path segments together. Whether you do so > using one Path object all at once or multiple Path objects that you later > add together is just a matter of programming style. > It's the multiple path objects use case that is unclear to me. Is there any tool/library that does this? Looking at Adobe's graphics applications, there isn't anything like it. Looking at graphics APIs, I don't see any calls that combine paths directly. hmm, it seems the spec has changed. It didn't used to start with "Create a new path that describes the edge of the areas" With the new wording, the last sentence should be updated: Subpaths in the newly created path must wind clockwise, regardless of the direction of paths in path. Since you now create 'holes', the separate paths need to be reoriented like you specify in other parts. > > > > > We seem to be going around in circles. We're in agreement that > > > > > eventually we should add APIs for combining paths such that we get > > > > > the equivalent of the union of their fill regions. I agree that > > > > > converting text into paths is non-trivial (lots of stuff browsers > > > > > do is non-trivial, that's kind of the point -- if it was trivial, > > > > > we could leave it for authors). But I don't see how we get from > > > > > there to you wanting the existing APIs removed. > > > > > > > > I want them removed because they will most likely not behave in the > > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > > expect that there is 'interference' between them. > > > > > > I don't see why not. It's exactly what happens today if you were to > > > just add the same path creation statements together into the current > > > default path and fill or stroke that. > > > > Sure but who does that? > > It's how all paths are built, as far as I can tell. I don't see how else > you could build a path that consists of more than one line. > > addPath() is useful for shifting a path according to a transform. > Why not just transform() then? addPathByStrokingPath() is for creating a stroked path. > addText() is for writing text. > > I don't see how removing any of them is a win. > Yes, they are useful. The issue is that they are not implementable as currently specified. > > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > ... > > > > > > > > How would you get a point? the width is scaled to 0. > > > > > > That's how you get a point -- scale(0,0) essentially reverts > > > everything to a zero dimensional point. > > > > OK, but the width of the point is also transformed to 0 so you get > > nothing. > > Points are always zero-width, by definition. > You can still stroke it though and get a point of the strokewidth. > > We've gone over this several times now. > > The APIs that you define, have use cases and I agree with them. > > However the way you defined those APIs does not make sense and will not > > give the result that authors want. > > The way to make this point would be to start from the use case, describe > the desired effect, show the "obvious" way to achieve this using the API, > and then demonstrate how it doesn't match the desired effect. > The obvious way is to go with Shape2D. It's not because I invented it; many advanced graphics APIs came offer this (including D2D and skia) > ... > > So, it's not realistic to add this to the Path2D object. > > I don't really see why it's unrealistic. In most cases, the user agent > doesn't actually have to do any work -- e.g. if all that you're doing is > merging two paths so that you can fill them simultaneously later, the UA > can just keep the two paths as is and, when necessary, fill them. > > For cases where you really want to have this effect -- e.g. when you want > to get the outline of the dashed outline of text -- then I don't really > see any way to work around it. > That is true. That is why I proposed to make the interface more limited for now until there is a time that this functionality is available. >From Ian Hickson: > I don't think the spec should be written with a particular > implementation in mind, nor should it dictate one. I agree it shouldn't (and doesn't) dictate one. But it's crazy to not consider implementations at all when writing a spec. That way lies madness like requiring O(N^2) algorithms and solving the halting problem and all kinds of other disasters (all of which I've seen in real proposals). > > The reason for that is that even though a UA could emulate the union by > > doing multiple fill operations, Path2D allows you to stroke another path > > object. At that point, you really have to do planarization. By defining > > a Shape2D object and not allowing it to be stroked, we can work around > > this. > > Sure, by limiting the feature set dramatically we can avoid the cases > where you have to do the hard work, but we also lose a bunch of features. > For now. They can be added later. Until then, this is confusing implementors. > > > I don't think the arguments for removing these are compelling. The > > > problems with the APIs have been addressed (e.g. there's no ambiguity > > > in the case of overlapping text), the use cases are clear (e.g. > > > drawing text around an arc or drawing a label along a line graph's > > > line), and the API now supports the constructs to do unions of fill > > > regions. > > > > Where is the union of fill regions specified? All I see is segments > > aggregation. > > One of the Path constructors takes an array of paths and a fill rule. > See above. > > > > No one has implemented them and they are confusing the browser > > > > vendors. > > > > > > I don't think they're confusing anyone. > > > > The blink people were looking at adding this until they thought it > > through and realized that it wouldn't work. > > Realised what wouldn't work? As far as I'm aware, there's nothing that > wouldn't work. > See this thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/168925.html I think you already addressed some of the concerns. Doing the planarization is now the problem so we can't implement this. > > > > Until we have support for shapes, the output of these methods won't > > > > be stable. > > > > > > These methods have been very stable. They have barely changed since > > > they were added, except for some minor tweaks to fix bugs. > > > > How can you make that statement? No one has implemented them yet. > > What do you mean by "stable"? > > I assumed you meant "hasn't been changing a lot". The spec hasn't been > changing a lot, so it seems pretty stable. > You've been making a lot of changes lately so this not quite true. Because you wrote it a long time ago and nobody looked at it until now, doesn't mean that it is stable. From junov at google.com Tue Apr 8 12:25:04 2014 From: junov at google.com (Justin Novosad) Date: Tue, 8 Apr 2014 15:25:04 -0400 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> On Mon, Apr 7, 2014 at 6:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > For example, there is no locale for font family resolution > > I'm not clear on what you mean by "locale" here. What is the locale that a > displayed <canvas> in a Document in a browsing context has, that a > non-displayed <canvas> outside a Document and without a browsing context > does not have? > I am not sure exactly how this relates to the specification, but when reading the code in Blink, I saw that font family resolution goes through different paths if the view has a Korean, Chinese or Japanese locale. Some OSes allow you to have different locales on a per window basis, so you need to have a view (i.e. a browsing context) associated with the Document in order to resolve this. > > and it is not possible to resolve font sizes in physical length units > > unless the document is associated with a view. > > Why not? The canvas has a pixel density (currently always 1:1), no? > 1:1 is not a physical pixel density. To resolve a font size that is specified in physical units (e.g. millimeters or inches) you need something like a DPI value, which requires information about the output device. > > > My 2 cents: specifying fallback behaviors for all use cases that are > > context dependent could be tedious and I have yet to see a real-world > > use case that requires being able to paint a canvas in a frame-less > > document. Therefore, I think the spec should clearly state <canvas> > > elements that are in a document without a browsing context are unusable. > > Not sure what the exact behavior should be though. Should an exception > > be thrown upon trying to use the rendering context? Perhaps canvas draws > > should fail silently, and using the canvas as an image source should > > give transparent black pixels? > > As far as I can tell, this is all already specified, and it just gets > treated like a normal canvas. > Agreed. The fallback behavior is specified. But is it good enough? There will be discrepancies, sometimes large ones, between text rendered with and without a browsing context. On Wed, 5 Mar 2014, Rik Cabanier wrote: > > > > Testing all browsers (except IE since > > document.implementation.createHTMLDocument() doesn't work) they seem to > > handle canvas contexts with no browsing context except when you use > > text. Chrome crashes, firefox throws an exception and Safari draws the > > text with a very small scale > > I don't really understand why this is problematic in practice. What does a > browsing context provide that is needed for rendering text that a user > agent couldn't fake for itself in other contexts? We're definitely going > to need text in worker canvases. > It is because the browsing context serves as a bridge between the document and the OS/window manager/display device. Therefore some of the system configuration info that comes into play in font style resolution and text rendering is not accessible when the document is not associated with a browsing context. For example to know which locale to use, the document needs to be linked to a window; to know the display density (dpi) we need to know which display device will be used for displaying the document; to use subpixel text anti-aliasing, we need to know the display device's LCD configuration; etc. If we fake this information by using fallbacks and defaults, we may end up with text that looks different when rendering in a Worker or into a Document without a browsing context. If we want everything to look the same, perhaps the spec should specify how to get to a browsing context that can be used for retrieving display settings. For example, if the current document has no browsing context, use the settings from the browsing context of the global 'document' object. That would probably match the developer's intent almost all the time. > > On Fri, 14 Mar 2014, Justin Novosad wrote: > > On Fri, Mar 14, 2014 at 2:29 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > If the bug is that Chrome resamples the image in an ugly way, then > > > that's a bug with Chrome. As the bug says, browsers are allowed to > > > pick whatever algorithm they want -- it's a quality-of-implementation > > > issue. But if the result is ugly, that's a low quality implementation. > > > > Yes, and if we fixed it to make it prettier, people would complain about > > a performance regression. It is impossible to make everyone happy right > > now. Would be nice to have some kind of speed versus quality hint. > > The problem with a hint is that it will be set incorrectly, and so instead > of having something that's mostly pretty but mostly fast for everyone, > you'd end up with something that's slow on sites that need things to be > fast, and things that are ugly on sites that need things to be pretty. > > In general I think it is very unwise for us to design APIs with hints that > have subtle effects on developer machines but that can cripple performance > on low-end devices. > The point of it being a hint is that the UA is free to disregarded it precisely in that kind of situation (e.g. fallback to fastest filtering on a low-end device) > Instead, we should use adaptive algorithms, for example always using the > prettiest algorithms unless we find that frame rate is suffering, and then > stepping down to faster algorithms. > Such an adaptive algorithm implies making some kind of weighted decision to chose a reasonable compromise between quality and performance. Sounds like the perfect place to use a hint. > > > On Mon, 17 Mar 2014, Justin Novosad wrote: > > > > Yes, but there is still an issue that causes problems in Blink/WebKit: > > because the canvas rendering context stores its path in local > > (untransformed) space, whenever the CTM changes, the path needs to be > > transformed to follow the new local spcae. This transform requires the > CTM > > to be invertible. So now webkit and blink have a bug that causes all > > previously recorded parts of the current path to be discarded when the > CTM > > becomes non-invertible (even if it is only temporarily non-invertible, > even > > if the current path is not even touched while the matrix is > > non-invertible). I have a fix in flight that fixes that problem in Blink > by > > storing the current path in transformed coordinates instead. I've had the > > fix on the back burner pending the outcome of this thread. > > Indeed. It's possible to pick implementation strategies that just can't be > compliant; we shouldn't change the spec every time any implementor happens > to make that kind of mistake, IMHO. > > (Of course the better long-term solution here is the Path objects, which > are transform-agnostic during building.) > > > Just to be clear, we should support this because otherwise the results are > just wrong. For example, here some browsers currently show a straight line > in the default state, and this causes the animation to look ugly in the > transition from the first frame to the secord frame (hover over the yellow > to begin the transition): > > http://junkyard.damowmow.com/538 > > Contrast this to the equivalent code with the transforms explicitly > multiplied into the coordinates: > > http://junkyard.damowmow.com/539 > > I don't see why we would want these to be different. From the author's > perspective, they're identical. If we stick to that, there are still some behaviors that need to resolved. One issue that comes to mind is what happens if stroke or fill are called while the CTM is non-invertible? To be more precise, how would the styles be mapped? If the fillStyle is collapsed to a point, does that mean the path gets filled in transparent black? If we go down this road, we will likely uncover more questions of this nature. > On Tue, 25 Mar 2014, Justin Novosad wrote: > > > > I prepared a code change to that effect, but then there was talk of > > changing the spec to skip path primitives when the CTM is not > > invertible, which I think is a good idea. It would avoid a lot of > > needless hoop jumping on the implementation side for supporting weird > > edge cases that have little practical usefulness. > > I'm not sure I agree that they have little practical usefulness. Zeros > often occur at the edges of transitions, and if we changed the spec then > these transitions would require all the special-case code to go in author > code instead of implementor code. > Yes, I think that may be the strongest argument so far in this discussion. The examples you provided earlier illustrate it well. I would like to hear what Rik and Dirk think about this now. From jackalmage at gmail.com Tue Apr 8 13:54:39 2014 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Tue, 8 Apr 2014 13:54:39 -0700 Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> Message-ID: <CAAWBYDCAr4C-fSYx9a_y=D3aZe0_9e_UOLo5yUJrk9TXs46Meg@mail.gmail.com> On Tue, Apr 8, 2014 at 5:25 AM, Steve Faulkner <faulkner.steve at gmail.com> wrote: > avoiding unnecessary recourse to web component use is a reasonable and > expected goal - built in vs bolt on accessibility is better. Having to use > a web component to overcome the inability to make a html control usable > without relying on CSS and Js and ARIA is unfortunate, and as you said > yesterday I still don't understand. Do you think that what Hixie is saying (about clicking on non-interactive text in <summary> toggling the <details>) is wrong? The behavior that Hixie describes is roughly what implementations do today. In Blink, clicking on any bare text in the <summary> toggles the <details>, while clicking on an <input> does not. However, Blink current behavior with <label> is different - it basically ignores the presence of the <label>, as far as I can tell, and still toggles the <details> even if the <label> is redirecting the click to an <input>. I would strongly object to any suggestion that <summary> should only toggle <details> when you click on the disclosure triangle, unless you add some additional markup like <label>. That would be terrible UI. ~TJ From cabanier at gmail.com Tue Apr 8 15:10:09 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 15:10:09 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> Message-ID: <CAGN7qDDJKmx1T9_8cu--T7mAUy2uucTde+S6atnJTBe7baBQRg@mail.gmail.com> On Tue, Apr 8, 2014 at 12:25 PM, Justin Novosad <junov at google.com> wrote: > > > > > On Mon, 17 Mar 2014, Justin Novosad wrote: > > > > > > Yes, but there is still an issue that causes problems in Blink/WebKit: > > > because the canvas rendering context stores its path in local > > > (untransformed) space, whenever the CTM changes, the path needs to be > > > transformed to follow the new local spcae. This transform requires the > > CTM > > > to be invertible. So now webkit and blink have a bug that causes all > > > previously recorded parts of the current path to be discarded when the > > CTM > > > becomes non-invertible (even if it is only temporarily non-invertible, > > even > > > if the current path is not even touched while the matrix is > > > non-invertible). I have a fix in flight that fixes that problem in > Blink > > by > > > storing the current path in transformed coordinates instead. I've had > the > > > fix on the back burner pending the outcome of this thread. > > > > Indeed. It's possible to pick implementation strategies that just can't > be > > compliant; we shouldn't change the spec every time any implementor > happens > > to make that kind of mistake, IMHO. > > > > (Of course the better long-term solution here is the Path objects, which > > are transform-agnostic during building.) > > > > > > Just to be clear, we should support this because otherwise the results > are > > just wrong. For example, here some browsers currently show a straight > line > > in the default state, and this causes the animation to look ugly in the > > transition from the first frame to the secord frame (hover over the > yellow > > to begin the transition): > > > > http://junkyard.damowmow.com/538 > > > > Contrast this to the equivalent code with the transforms explicitly > > multiplied into the coordinates: > > > > http://junkyard.damowmow.com/539 > > > > I don't see why we would want these to be different. From the author's > > perspective, they're identical. > These examples are pretty far fetched. How many time do people change the CTM in the middle of a drawing operation and not change the geometry? If we stick to that, there are still some behaviors that need to resolved. > One issue that comes to mind is what happens if stroke or fill are called > while the CTM is non-invertible? To be more precise, how would the styles > be mapped? If the fillStyle is collapsed to a point, does that mean the > path gets filled in transparent black? If we go down this road, we will > likely uncover more questions of this nature. Indeed > > On Tue, 25 Mar 2014, Justin Novosad wrote: > > > > > > I prepared a code change to that effect, but then there was talk of > > > changing the spec to skip path primitives when the CTM is not > > > invertible, which I think is a good idea. It would avoid a lot of > > > needless hoop jumping on the implementation side for supporting weird > > > edge cases that have little practical usefulness. > > > > I'm not sure I agree that they have little practical usefulness. Zeros > > often occur at the edges of transitions, and if we changed the spec then > > these transitions would require all the special-case code to go in author > > code instead of implementor code. > > > > Yes, I think that may be the strongest argument so far in this discussion. > The examples you provided earlier illustrate it well. > I would like to hear what Rik and Dirk think about this now. > I looked at the webkit and chrome bug databases and I haven't found anyone who complained about their current behavior. Implementing this consistently will either add a bunch of special case code to deal with non-singular matrices or double (triple?) conversion of all segment points like firefox does. After that, fill, stroke and clip will still not work when there's a non-invertible matrix. I do not think it's worth the effort... From cabanier at gmail.com Tue Apr 8 16:50:48 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 16:50:48 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > ... > > > > > Stroking will be completely wrong too, because joins and end caps > > > > are drawn separately, so they would be stroked as separate paths. > > > > This will not give you the effect of a double-stroked path. > > > > > > I don't understand why you think joins and end caps are drawn > > > separately. That is not what the spec requires. > > > > Sure it does, for instance from > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path > > : > > > > The round value means that a filled arc connecting the two > > aforementioned corners of the join, abutting (and not overlapping) the > > aforementioned triangle, with the diameter equal to the line width and > > the origin at the point of the join, must be added at joins. > > > > If you mean, "drawn with a separate fill call", yes that is true. > > What I meant was that they are drawn as a separate closed path that will > > interact with other paths as soon as there are different winding rules or > > "holes". > > The word "filled" is a bit misleading here (I've removed it), but I don't > see why that led you to the conclusion you reached. The step in question > begins with "Create a new path that describes the edge of the areas that > would be covered if a straight line of length equal to the styles > lineWidth was swept along each path in path while being kept at an angle > such that the line is orthogonal to the path being swept, replacing each > point with the end cap necessary to satisfy the styles lineCap attribute > as described previously and elaborated below, and replacing each join with > the join necessary to satisfy the styles lineJoin type, as defined below", > which seems pretty unambiguous. > Thinking about this some more, it looks like you came around and specified stroking like I requested from the beginning. For instance, http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0354.html or http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0213.html Now that you made that change, 'addPathByStrokingPath' is specified correctly. I still don't know how it could be implemented though... (It *could* as a shape but not as a path) From cabanier at gmail.com Tue Apr 8 17:17:39 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 17:17:39 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> Message-ID: <CAGN7qDBfO_7katfwHTX+CT_HgRcEuq3AL7544y+YTJU54HbahQ@mail.gmail.com> On Tue, Apr 8, 2014 at 4:50 PM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > >> ... >> >> >> > > > Stroking will be completely wrong too, because joins and end caps >> > > > are drawn separately, so they would be stroked as separate paths. >> > > > This will not give you the effect of a double-stroked path. >> > > >> > > I don't understand why you think joins and end caps are drawn >> > > separately. That is not what the spec requires. >> > >> > Sure it does, for instance from >> > >> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path >> > : >> > >> > The round value means that a filled arc connecting the two >> > aforementioned corners of the join, abutting (and not overlapping) the >> > aforementioned triangle, with the diameter equal to the line width and >> > the origin at the point of the join, must be added at joins. >> > >> > If you mean, "drawn with a separate fill call", yes that is true. >> > What I meant was that they are drawn as a separate closed path that will >> > interact with other paths as soon as there are different winding rules >> or >> > "holes". >> >> The word "filled" is a bit misleading here (I've removed it), but I don't >> see why that led you to the conclusion you reached. The step in question >> begins with "Create a new path that describes the edge of the areas that >> would be covered if a straight line of length equal to the styles >> lineWidth was swept along each path in path while being kept at an angle >> such that the line is orthogonal to the path being swept, replacing each >> point with the end cap necessary to satisfy the styles lineCap attribute >> as described previously and elaborated below, and replacing each join with >> the join necessary to satisfy the styles lineJoin type, as defined below", >> which seems pretty unambiguous. >> > > Thinking about this some more, it looks like you came around and specified > stroking like I requested from the beginning. > For instance, > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0354.html > or > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0213.html > Now that you made that change, 'addPathByStrokingPath' is specified > correctly. I still don't know how it could be implemented though... (It > *could* as a shape but not as a path) > The spec is still confusingly written and could be misinterpreted: Create a new path that describes the edge of the areas that would be covered if a straight line of length equal to the styles lineWidth was swept along each subpath in path while being kept at an angle such that the line is orthogonal to the path being swept, replacing each point with the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, and replacing each join with the join necessary to satisfy the styles lineJoin type, as defined below. Maybe could become: Create a new path that describes the edge of the coverage of the following areas: - a straight line of length equal to the styles lineWidth that was swept along each subpath in path while being kept at an angle such that the line is orthogonal to the path being swept, - the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, - the join with the join necessary to satisfy the styles lineJoin type, as defined below. From ian at hixie.ch Tue Apr 1 11:55:24 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 18:55:24 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <20140205183607.GA56968@sideshowbarker> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> Message-ID: <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> On Tue, 4 Feb 2014, Cameron McCormack wrote: > Ian Hickson wrote: > > I'm all for handling it in one place. What precisely do you want the > > behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- "the first > > <svg:title> element" may come after "the first<html:title> element", and > > vice versa. Also consider when one or the other is "primary" but the > > relevant element is absent.) > > OK, how about: if the document element is an <html:html>, we choose the > first <html:title> in document order; if the document element is an > <svg:svg>, we choose the first child <svg:title> of the document > element; otherwise, null. > > This still is going to produce "incorrect" results for things like: > > <!DOCTYPE html> > <svg> > <foreignObject> > <title>blah > > > > but arguably you shouldn't be using in there anyway. It doesn't seem useful to hit that element. It's not the (SVG) document title, after all. I ended up going with: - if it's an SVG document, use the first <title> child of the root element - if it's an HTML document, use the first <title> element in tree order (that's what it used to be) For setting it uses the same element, unless there isn't one, in which case: - if it's an SVG document, append an SVG <title> to the root element - if it's an HTML document, append a <title> to the <head> Hopefully that's compatible enough. Let me know if you need something different. On Mon, 3 Feb 2014, Jonas Sicking wrote: > > An even simpler solution would be to say "we choose the first > <html:title> or <svg:title> in document order". That has the nice > property that we align SVG and HTML more. This seems to not quite match the SVG semantics, unfortunately. On Wed, 5 Feb 2014, Simon Pieters wrote: > > Is there a situation in which it is conforming to use html:title outside > the <head> in a document where the root is html:html? In > math:annotation-xml? You can certainly imagine a compound document format containing entire HTML subdocuments, <html>, <head>, <title>, and all. I'm not sure that's possible with just SVG and HTML currently though. (Maybe MathML, indeed.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 12:01:46 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 19:01:46 +0000 (UTC) Subject: [whatwg] microdata questions In-Reply-To: <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> References: <CAGYLO0+N_3BTmKM6+2XLcghm2d0GSy36xubRJKTR5KWEnGhvNg@mail.gmail.com> <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404011857230.11249@ps20323.dreamhostps.com> On Mon, 10 Feb 2014, Eric Devine wrote: > > 1. Section 5.5.1 of the Microdata spec prescribes how microdata should > be respresented as JSON, but it does provide a MIME type. I'm writing a > REST API that I would like to be able to return JSON in microdata > format, but I need the client to explicitly request this via the HTTP > Accept header. The main concern is to know when to return plain > properties as an array with one element. As a general rule I would recommend against using Accept headers to do anything. You're better off making the JSON data its own resource, IMHO. Having said that, as you noted in a later e-mail, the MIME type suggested by the HTML spec is "application/microdata+json". http://whatwg.org/html#application/microdata+json > 2. Section 5.2.4 does not provide a way to apply a property value to the > value attribute of an <option> element. Is this an oversight, or is > there simply not a convincing enough use case for the need? There's not any way currently to make for controls map to microdata. It's not clear exactly what it would mean. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jonas at sicking.cc Tue Apr 1 12:58:12 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Tue, 1 Apr 2014 12:58:12 -0700 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> Message-ID: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 3 Feb 2014, Jonas Sicking wrote: >> >> An even simpler solution would be to say "we choose the first >> <html:title> or <svg:title> in document order". That has the nice >> property that we align SVG and HTML more. > > This seems to not quite match the SVG semantics, unfortunately. Does it break existing content? If not, why not ask the SVG spec to be changed? The thread was started by one of the SVG spec editors after all. / Jonas From ian at hixie.ch Tue Apr 1 13:29:59 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 20:29:59 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404012027040.21310@ps20323.dreamhostps.com> On Tue, 1 Apr 2014, Jonas Sicking wrote: > On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Feb 2014, Jonas Sicking wrote: > >> > >> An even simpler solution would be to say "we choose the first > >> <html:title> or <svg:title> in document order". That has the nice > >> property that we align SVG and HTML more. > > > > This seems to not quite match the SVG semantics, unfortunately. > > Does it break existing content? If not, why not ask the SVG spec to be > changed? The thread was started by one of the SVG spec editors after > all. Dirk and heycam's replies to your original e-mail here suggest that this is not really viable. I mean, it'd be like changing document.title in HTML to point to the first title="" attribute in the document if it came before the first <title>. Anyway, what the spec ended up saying is in some ways even simpler, since it only looks one level deep for SVG rather than doing a deep tree search. (Is this the kind of change that you would have liked pre-flighted? I can revert the change and put out an announcement if you like. I'm not yet sure I exactly understand what kinds of changes fall into this category.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 17:02:51 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 00:02:51 +0000 (UTC) Subject: [whatwg] <keygen> and X509 client cert mime type In-Reply-To: <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> References: <2E519EB1-CB5D-48E1-8435-BEF2616E9F9C@bblfish.net> <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> Message-ID: <alpine.DEB.2.00.1404012343180.11249@ps20323.dreamhostps.com> On Tue, 25 Feb 2014, henry.story at bblfish.net wrote: > > The keygen form element does a great job of specifying how the browser > creates a public/private key pair, stores the private key in it's local > keystore. > > "When the control's form is submitted, the private key is stored in the > local keystore, and the public key is packaged and sent to the server." > > It is clear that the intention is for the server to send back a > certificate built from the public key. What I can't find is what the > mime type of the returned certificate should be. I have been using > `application/x-x509-user-cert` which seems to work for Safari, Firefox, > Opera . But I think that is not an officially supported certificate > type. application/pkix-cert seems to be that after looking it up on > iana. > > I ended up posting a bug report for Android on that. > http://code.google.com/p/android/issues/detail?id=66342 > > But now I have to check for each browser which is the type all browsers > support. To avoid people having to do this research again and again, > perhaps it would be worth specifying a mime type that all browsers > do/must support in the HTML5 spec? On Wed, 26 Feb 2014, henry.story at bblfish.net wrote: > > (1) most browsers currently understand the mime types > (a) application/x-x509-user-cert > (b) application/x-x509-ca-cert > (c) application/x-x509-email-cert > ( I have only verified (a) btw. I am assuming the others also support (b) and (c) ) > as specified here > https://wiki.mozilla.org/CA:Certificate_Download_Specification > > (2) the above mime types are not registered > http://www.iana.org/assignments/media-types/media-types.xhtml > > So really either the old mime types should be registered, or they should > be mentioned as being in use but deprecated and people should be guided > towards the application/pkix-cert I wouldn't worry too much about registered vs not registered. If the registry doesn't match the implementations, the registry is buggy. On the other hand, I also don't want to get into the business of specifying this stuff myself. I've added a link to the above MDN page to the keygen section. If there is ever something more canonical (and yet still useful and accurate), let me know and I'll update the spec. Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:43:08 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:43:08 +0000 (UTC) Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEEAS0O79Ko7QrxXKE8YxaVZha5Hzr_bqpAaJrb2PKHQggA@mail.gmail.com> References: <CA+dJEEAS0O79Ko7QrxXKE8YxaVZha5Hzr_bqpAaJrb2PKHQggA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021739430.11249@ps20323.dreamhostps.com> On Mon, 3 Mar 2014, Bob Owen wrote: > > The spec [...] seems to be fairly clear that if an existing window is > navigated using window.open, by a browsing context that is not the > original opener, then window.opener should remain unchanged. > > Currently, Trident (and incidentally Presto) seems to have the correct > behaviour, but Blink, WebKit and Gecko all change window.opener to the > window of the browsing context that has just caused it to navigate. I > believe this to be a very long standing difference (>10 years for Gecko > and Trident) > > I am proposing to change Gecko to match the spec, but I was advised to > raise the issue here before going ahead. > > Do people agree that window.opener should remain unchanged in this > circumstance? Did you receive any off-list feedback on this, or attempt to implement it and get any implementation experience? Having "opener" be the actual opener seems pretty intuitive to me; if there's no compat need to do otherwise, it seems like a reasonable choice. Is there a security reason to prefer the latest navigator? (At the time the spec was written, it was 2v2; the 1v3 situation we have now is the result of Presto going away and Blink forking from WebKit.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:52:14 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:52:14 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> On Mon, 3 Mar 2014, Ami Fischman wrote: > > Looks like we're back in business: > > Latest editor's draft: > http://dev.w3.org/2011/webrtc/editor/getusermedia.html Thanks. As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:57:11 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:57:11 +0000 (UTC) Subject: [whatwg] More effective model for handling resources In-Reply-To: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> References: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> On Thu, 13 Mar 2014, Tingan Ho wrote: > > Almost all web developer I know use externally linked CSS resource in > their web projects. That means that the browser needs to (1) request the > html page (2) parse the html (3) request for the CSS resource that is > linked from the html document. The problem with externally linked > resources is point three. It needs to make another request for the CSS > resource. There is a solution to this problem and that is to inline the > CSS. Though that would yield another problem: all subsequent page > request will become bigger. I believe this is being handled by the next-generation transport protocols (SPDY or whatever it's called now). I recommend approaching the relevant groups to check that your precise case has been handled. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 11:09:15 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 18:09:15 +0000 (UTC) Subject: [whatwg] inverse property mechanism for Microdata? In-Reply-To: <CAK-qy=6VGPOJshUqSg_BuVU44UUqV9WLxtJAdRUm-pnk=XDKnw@mail.gmail.com> References: <CAK-qy=7SuUq_4Ung06+1CLySJ3D7Aiv_1uyAZnJzc+jPuOcYHw@mail.gmail.com> <alpine.DEB.2.00.1401312334310.26647@ps20323.dreamhostps.com> <CAK-qy=6_ZQ5NCxVSqHraa-Lc1P88vY8BpuacLbj3_QyFpG5jnQ@mail.gmail.com> <alpine.DEB.2.00.1403172046390.31525@ps20323.dreamhostps.com> <CAK-qy=6VGPOJshUqSg_BuVU44UUqV9WLxtJAdRUm-pnk=XDKnw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021759091.11249@ps20323.dreamhostps.com> On Wed, 19 Mar 2014, Dan Brickley wrote: > > > > This is what the example would look like if I'm understanding this right: > > > > <div itemscope itemtype="http://schema.org/LocalBusiness"> > > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > > Giftware</span></h1> > > <span itemprop="description"> A superb collection of fine gifts and clothing > > to accent your stay in Mexico Beach.</span> > > Phone: <span itemprop="telephone">850-648-4200</span> > > > > <div itemscope itemtype="http://schema.org/LocalBusiness" > > itemprop-up="containedIn"> > > <h2><span itemprop="name">(Entity B) The tiny store within a > > store</span></h2> > > <span itemprop="description"> A superb collection of tiny clothes, > > from the store within the store.</span> > > Phone: <span itemprop="telephone">123-456-7890</span> > > </div> > > > > </div> > > > > It's not too bad, I guess. > > Yes. I notice that the words we were playing with at schema.org relate > to the underlying graph data model itemprop-inverse, -reverse etc., > whereas your draft name, itemprop-up is about the markup hierarchy. Yeah. I think most authors think in terms of what they see (their markup), not in terms of the data model. (I have had a _lot_ of conversations with authors where it was clear that they had no idea there was an underlying data model for the microdata that was separate from the markup.) > Yup, there are some cases where this can be addressed through the > rigorous use of entity IDs in itemid, as you sketch below. That would be > relatively new territory for schema.org and for publishers. Perhaps > there is an attribute name we can find that would leave the door open to > more use cases, e.g. "itemprop-backwards" rather than "itemprop-up". It > seems reasonable to try to address relationships between sibling > elements too. Well you'd been a new attribute to do that, unless I'm misunderstanding your proposal. Maybe you mean this attribute wouldn't point to a relative place in the markup, but would point to an identified element given by another attribute? I think that would be quite confusing. > Something like (trying out -backwards instead of -up, to allow for > non-hierarchical usage): > > <div itemid="bigshop" itemscope itemtype="http://schema.org/LocalBusiness"> > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > Giftware</span></h1> > </div> > <div itemscope itemtype="http://schema.org/Pharmacy"> > <meta itemprop-backwards="containedIn" itemid="bigshop" /> > <h2><span itemprop="name">Tiny pharmacy store within a store</span></h2> > </div> > > ? > > Can we use itemid in that way, to give a property value too? I don't > see itemid used much in the wild and the spec only mentions its use > for the item having the property, rather than using when supplying the > value of a property. itemid="" is a URL that gives the identifier of the item. We'd want to use a new attribute to do something like this; e.g.: itemrelation="containedIn bigshop" where "itemrelation" takes just two keywords, a property name and the ID (not itemid) of the target element. But that's pretty elaborate. Is there a need for this? Or is the relationship to the parent all that's needed? In your original e-mail you only suggested wanting to go up. > > Microdata actually already has a solution to this. The vocabulary can > > define an ID for each item using itemid="", and can define multiple items > > having the same ID as being the same conceptual item. Thus: > > > > <!-- first episode --> > > <div itemscope itemtype="http://schema.org/Episode"> > > ... > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"></div> > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"></div> > > </div> > > > > <!-- second episode --> > > <div itemscope itemtype="http://schema.org/Episode"> > > ... > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"></div> > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"></div> > > </div> > > > > <!-- actors --> > > <div itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"> > > ... > > </div> > > <div itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"> > > ... > > </div> > > > > This also enables the data to be spread across multiple pages without > > confusion. (This is similar to how RDF uses identifiers for everything > > -- essentially, in RDF terms, this turns the microdata item from a > > bnode into a node with a global identifier.) > > Yes, it succeeds or fails to the extent people agree on these global > identifiers. Do people not agree on them, typically? > > Your example would become: > > > > <div itemscope itemtype="http://schema.org/LocalBusiness" > > itemid="..."> > > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > > Giftware</span></h1> > > <span itemprop="description"> A superb collection of fine gifts and clothing > > to accent your stay in Mexico Beach.</span> > > Phone: <span itemprop="telephone">850-648-4200</span> > > > > <div itemscope itemtype="http://schema.org/LocalBusiness"> > > <div itemprop="containedIn" > > itemscope itemtype="http://schema.org/LocalBusiness" > > itemid="..."></div> > > <h2><span itemprop="name">(Entity B) The tiny store within a > > store</span></h2> > > <span itemprop="description"> A superb collection of tiny clothes, > > from the store within the store.</span> > > Phone: <span itemprop="telephone">123-456-7890</span> > > </div> > > > > </div> > > > > Is this not suitable for schema.org? Or is it just too much markup? > > It's in the clever-but-fragile category, I'd say. So yes, a bit too > much markup. In English this is saying something like > > "We're describing a LocalBusiness whose global ID is [xyz]; it has > certain name, description, telephone properties given here. > There is also a LocalBusiness that is containedIn a LocalBusiness > whose global ID is [xyz]; this [other] LocalBusiness has the following > name, description, telephone etc properties...." > > Just as in the English, it is rather easy to lose track of which > LocalBusiness we're talking about. I think you overstate the complexity, but ok. > >> > That is another option, similar to the parenthetical itemid="" note > >> > above -- you could just have the vocabulary define that for every > >> > property whose value is an item, the item type that that property > >> > can point to has another property with the same name plus a fixed > >> > suffix, like "-inv", that inverses the relationship. [...] > >> > >> This is easier to understand than itemref, but still involves > >> creating 100s of additional properties instead of just one new piece > >> of syntax. > > > > What do you mean by "creating additional properties" here? It's > > relatively trivial to define these with one sentence, you don't need > > to actually list them or anything. Implementing support is similarly > > easy, as far as I can tell -- you just check for the suffix or prefix > > and handle it accordingly. > > Re "you don't need to actually list them", this effectively creates two > classes of property. Real ones, and fake/pseudo properties which we're > pretending exist so that we can re-use a piece of syntax that expects a > property name. Once these pseudo properties are released into the wild, > they'll show up as if they were real. They would be real, I'm just saying that documenting them and implementing them is somewhat trivial. > What we want to avoid is saying things like: > > "You can use itemprop='containedIn-rev' to indicate a property that > means the inverse of containedIn. However this is not a first class > schema.org property, and should not be used other syntaxes (JSON etc), > data dumps, APIs etc. You should canonicalize x containedIn-rev y > into: y containedIn x., ..." Why wouldn't it be a first-class property? It could trivially be so. The implementation is easy, whatever the vocabulary it's used in. > > If you do want to go with a new property, just use the name you would > > want in the spec. I weakly recommend "itemprop-up", which is the most > > intuitive name I've seen so far for this, but if you find a better > > name just use that. I guarantee that I won't make the spec conflict > > with whatever you use, as long as you tell me what it is. :-) Assuming > > that it works well, then we would just update the spec to use that > > term directly, retroactively making the experimental content > > conforming. > > Thanks! I'll discuss this thread with the schema.org team. My guess is > that there's still a strong preference for a new property, and we'd be > happy to avoid using data-*. > > If I understand right, the outstanding area of discussion/confusion is > whether there are cases beyond simple DOM element containment where we > might want to use an inverse itemprop construction (even though we can > see how itemid everywhere might also be used). If we're only using > element hierarchy then itemprop-up could work. Did you reach any conclusions in these discussions? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bobowencode at gmail.com Wed Apr 2 13:16:58 2014 From: bobowencode at gmail.com (Bob Owen) Date: Wed, 2 Apr 2014 21:16:58 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> On 2 April 2014 18:43, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Mar 2014, Bob Owen wrote: > > > > The spec [...] seems to be fairly clear that if an existing window is > > navigated using window.open, by a browsing context that is not the > > original opener, then window.opener should remain unchanged. > > > > Currently, Trident (and incidentally Presto) seems to have the correct > > behaviour, but Blink, WebKit and Gecko all change window.opener to the > > window of the browsing context that has just caused it to navigate. I > > believe this to be a very long standing difference (>10 years for Gecko > > and Trident) > > > > I am proposing to change Gecko to match the spec, but I was advised to > > raise the issue here before going ahead. > > > > Do people agree that window.opener should remain unchanged in this > > circumstance? > > Did you receive any off-list feedback on this, or attempt to implement it > and get any implementation experience? Thanks for getting back to me Ian. No, no other feedback. I have a patch for it, but haven't pursued it any further. I could investigate putting the change in for Firefox Nightly, if you think that might help with finding any compat issues. > Having "opener" be the actual opener seems pretty intuitive to me; if > there's no compat need to do otherwise, it seems like a reasonable choice. > > Is there a security reason to prefer the latest navigator? Agreed, the specified behaviour makes sense to me, if only because of the name. The fact that you can also use window.open for subsequent navigation (which leads to the different behaviours), muddies the water a bit, but that's a genie that would definitely refuse to go back in the bottle. Over security reasons, although I don't have any concrete examples, I would have thought that either could possibly cause problems, if the opposite behaviour was expected. So, consistency is probably the most important thing. I can also see that both pieces of information (original opener and last navigator) might be useful. So, maybe the other could be added either way. From ian at hixie.ch Wed Apr 2 13:56:38 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 20:56:38 +0000 (UTC) Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> On Wed, 5 Mar 2014, Qebui Nehebkau wrote: > On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson <ian at hixie.ch> wrote: > > I think the arguments you've presented so far suggest "address-levelN" > > for N=1..4, with 4=region and 3=locality, is probably the simplest > > thing to do. I was hoping there might be other people with opinions, > > to give us different perspectives on this, but it seems nobody else > > cares. :-( > > Since you asked, I think the whole endeavour (of trying to tokenise an > address) is pointless and should be abandoned outright. :) In principle I agree, but in practice I think we have to work with the reality that that is what people are doing. > Short of my ideal of *only* offering the full address (as used on a > label) as an opaque string, I think it would be most reasonable to > consider the 'locality' field itself to be a fully-specified opaque > string, including whatever information is necessary to completely > identify the location from the region level (such as the prefecture and > district), rather than a single level. > > Failing all that, I would at least prefer for the fields to have names > instead of abstract numbering, because people are likely to be confused > about the order, no matter which end is the 'widest'. It also seems more > intuitive, to me, for the 'locality', as, after all, 'local', to be the > most specific level. Would people not be confused by names in the same way? On Wed, 5 Mar 2014, Qebui Nehebkau wrote: > > Right, "impose", certainly not. But, perhaps, (one hopes,) "encourage"? > Or at least "refuse to explicitly support anything else". Does > autocomplete *need* to support people who are already doing it wrong? > But I'm probably just being too utopian; it happens. Well if we don't support pretty much every form out there, the feature isn't particularly useful. On Tue, 4 Mar 2014, Kevin Marks wrote: > > > > > > > > > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "address-level4" > > > > > > > > "address-level3" > > > > > > > > "address-level2" / "locality" > > > > > > > > "address-level1" / "region" > > > > > > > > "country-name" > > > > > > > > > > > > This could work. It has the synonym issue (having multiple fields > > > > > > that mean the same thing is often the source of confusion). > > > > > > > > > > > > > > Or we could do: > > > > > > > > > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "subsublocality" > > > > > > > > "sublocality" > > > > > > > > "locality" > > > > > > > > "region" > > > > > > > > "country-name" > > > > > > > > > > > > This could work. It avoids the synonym problem. > > > > > > > > > > Yes, this alternative works, but in my opinion is not preferable. > > > Because these words don't really mean anything. Nor do numbers. I think we don't really have any chance of giving meaning to the names here either way. On Tue, 4 Mar 2014, Evan Stade wrote: > > "dependent-locality" and "locality" have a fairly precise meaning in the > UK. Also in a natural-language conversation, if you ask me what "region" > of the country I live in, I'd say "New England", "the Midwest", or some > such; certainly not the state where I reside. The descriptions for these > tokens are currently pretty specific, for example they say a city would > be a locality. But this is not true for Beijing or some other cities. To > fix the descriptions, we'd have to change them to something like > "region: the highest level administrative region below country in the > address" and "locality: the second-highest level administrative region > below country in the address", "sub-locality: the third-highest level > administrative region [...]". With you so far. > At this point, one wonders why the tokens aren't just [something]1, > [something]2, etc. I don't understand how you get there. Why would you wonder this? > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "locality" > > > > > > > > "subsubregion" > > > > > > > > "subregion" > > > > > > > > "region" > > > > > > > > "country-name" > > > > I don't understand why you think authors will think they need to > > include "subregion", but won't think they need to include > > "address-level3". > > I think they'll assume subregion returns something for the US if it's > sandwiched between "region" and "locality", because county is in between > state and city. But in reality, subregion will return nothing. But why does this not apply to the numeric version? > > Having synonyms is really bad. It leads to huge amounts of confusion. > > This is why I'm trying to avoid having synonyms for the address-level* > > stuff. We should definitely not add some just to introduce a slightly > > better name. > > My suggestion is to change the address-line1 to street-address-line1, > not to have synonyms. Chrome would then support address-line1 for a > limited period of time, but outside the spec. There's no "outside the spec". The spec tries to describe reality. If you implement something, then that's the reality, and that's what the spec would say, and therefore we'd have a synonym. > If you are avidly anti-synonym for the address-level* stuff, and don't > want to change "region" and "locality", then I guess the next best > naming scheme in my mind would be "region", "locality", "locality2", > "locality3". But we also need to update the descriptions as mentioned > above. I don't understand why "locality2" is better than "sublocality", nor why it's better to add things above locality than between locality and region. The numbering seems really prone to mistakes (I mean, I've been making mistakes with it this entire thread unintentionally, for example). > > > Why is that better than 1=region, 2=locality, except to a US-centric > > > viewpoint? This would lead to a weird situation where (a) you > > > couldn't expand past 4 levels without changing the meaning of > > > previous levels and (b) a country such as the US would have > > > address-level4 and address-level3 but no address-level2 or > > > address-level1. > > > > Well, at least as far as (a) goes, we have no way to know where > > governments are going to introduce new levels. Who's to say that the > > US won't introduce something between states and towns? This problem > > exists whatever we do. Maybe the US and the EU will merge and there'll > > be a new field between "country-name" and "region". Who knows. > > One can dream... > > You're right that changing political circumstances might put us in an > awkward situation no matter what we do. But it seems to me the most > likely scenario is that a government would add more administrative > levels at the most granular level. Why? It seems just as likely that we'll add levels between "country" and "region". For instance, the example above. Or, in a few years, when there are parts of countries in space, maybe there'll be a planetoid name between the country and the region. Or maybe that will go on the other side of the country. I think trying to guess how things will be extended is a fool's errand. If we use numbers, we paint ourselves into a corner with extensions anywhere but at the deepest level. Fundamentally, studying all the alternatives we've considered so far, they all suck. - some have weird names like "subsubregion". - some use numbers - some have synonyms - some leave gaps in addresses for some locales where it's not obvious where the gap should be - some are non-trivial to extend later I think I'm going to just go with more or less what you first proposed: "address-line1" | "address-line2" |- "street-address" "address-line3" | "address-level4" "address-level3" "address-level2" / "locality" "address-level1" / "region" "country-name" That is, make "locality" and "region" synonyms for two new fields, add two more, and say in the spec that different locales have different numbers of levels and that as many should be included as are appropriate, starting with level1 as the widest administrative division. I've filed a bug on this topic; if I can get agreement from other vendors, then I'll go ahead and spec this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235 On Wed, 5 Mar 2014, Edward O'Connor wrote: > > The techniques browsers use for autofilling auth information would > benefit enormously from some additional autocomplete="" values. The wiki > page Ilya mentioned captures the use cases pretty well. I think these > are the critical ones that capture the most common cases: > > # Passwords > > On "change your password" forms, which <input type=password> is your > current password? Which is the new password? Browsers want to avoid > filling the old password into the new or confirm password fields. > Additionally, distinguishing such fields would help tools that generate > passwords. These are useful on both sign-up and change password forms. > > <input type=password> - your current password > <input type=password autocomplete=new> - a new password > <input type=password autocomplete=confirm> - the new password, again > > Next to the other autocomplete values, "new" and "confirm" don't look > descriptive enough. "new-password" and "confirm-password", maybe? > "<input type=password autocomplete=new-password>" feels redundant and > verbose to me. Is there any reason to have two fields here, why not just "new" both times? Also, should we have an "old" field for the old password, or is the lack of an autofill field sufficient? I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236 It needs multiple vendors on board to make progress. > # Usernames > > Lots of websites use email addresses as usernames. Tools should be able > to distinguish email-used-as-username fields from other email fields. > This can also help on "forgot password"/"forgot username" forms. > > <inpyt type=text autocomplete=username> - your username on this site > <input type=email> - your preferred email address > <inpyt type=email autocomplete=username> - your username on this site, > not your preferred email > address > <input type=url autocomplete=username> - OpenID This seems reasonable. I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25237 It needs multiple vendors on board to make progress. > Also, consider the case of login forms without username fields. You see > this sort of thing a lot these days, when sites remember who was last > logged in: > > <form> > <label>Password for hober: <input type=password name=pw></label> > <p>Not hober? <a href=...>Click here to sign in</a>. > </form> > > It's difficult for tools to manage the user's auth info for such pages. > How can tools discover what the username is? The obvious solution, in a > world with autocomplete=username, would be to add <input type=hidden > autocomplete=username name=username value=hober> to the form. So far, autocomplete="" hasn't applied to <input type=hidden>. This would be a bit weird, giving it a different meaning than usual (providing information to the UA, rather than getting information from the UA). I'm a bit skeptical of this kind of overloading. Not sure what the right solution is, though. On Fri, 7 Mar 2014, Garrett Casto wrote: > > Another related issue that would be nice to address would be allowing > sites to positively assert that authentication succeeded. For sites that > authenticate client side via XHR, standardizing something like > window.external.AutoCompleteSaveForm() would be very helpful. For sites > that validate server side, I'm less sure what the correct avenue to > convey this information would be (response code, header, ...). I'm > assuming that this will be more contentious than adding username and > password attribution and I don't want to hold that up, but I would like > to see opinions on this. I actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. For the pure JS case, an API (probably on the <form> itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 For the real submission case, I guess what we want is a way to say "autocomplete=off" after the fact, basically. An HTTP header seems like the most obvious solution. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 Again, these need multiple vendors on board to make progress. On Mon, 10 Mar 2014, Evan Stade wrote: > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=?cc-number? the browser might provide an experience tailored > for a payment flow, or if there?s an element with autocomplete=?bday? the > browser might use an experience that?s tailored for sharing identiy. > > We?ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element.requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: ?transactionAmount? > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: ?transactionCurrency? > value: string > description: a valid ISO 4217 currency code that describes the currency > for transactionAmount. If not provided, the default is ?USD?. > > Justification? There are upper bounds on certain payment instruments, > for example different credit cards have different credit limits; a debit > card is linked to a bank account with a certain balance. It?s a much > preferable user experience to be able to catch these problems earlier > rather than waiting for the merchant to attempt the transaction and have > it fail (or have a user?s account overdrawn). Concretely, Chromium wants > to handle transactions over $2000 differently from transactions under > that amount. > > Does this seem reasonable? The requestAutocomplete() API is a Chrome proprietary feature right now so it's sort of acadmic, but: Why would this only apply to requestAutocomplete()? Surely it would be just as important for the case where the user agent is filling in a form without using that API. Also, I don't understand how these are supposed to work. How is the browser supposed to know the balance on my credit cards or bank accounts? How is the browser supposed to know which of my cards are good for USD and which are good for GBP? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 14:00:33 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 21:00:33 +0000 (UTC) Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> References: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404022057240.21310@ps20323.dreamhostps.com> On Wed, 2 Apr 2014, Bob Owen wrote: > > > > Did you receive any off-list feedback on this, or attempt to implement > > it and get any implementation experience? > > Thanks for getting back to me Ian. > No, no other feedback. > I have a patch for it, but haven't pursued it any further. > I could investigate putting the change in for Firefox Nightly, if you think > that might help with finding any compat issues. Well as far as I'm concerned, I would encourage you to try to converge on the spec behaviour. If it turns out there are compatibility issues, that would be good to know. If not, then at least we win more interoperability. > I can also see that both pieces of information (original opener and last > navigator) might be useful. So, maybe the other could be added either > way. I haven't heard any author demand for it, so I haven't added it, but indeed, if this is something authors have a use for, we could add it. It's worth noting that there are many many ways to navigate a browsing context beyond window.open(), e.g. <a target="">, window.location, drag-and-drop of a link, window.history.go(), etc. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bobowencode at gmail.com Wed Apr 2 15:09:00 2014 From: bobowencode at gmail.com (Bob Owen) Date: Wed, 2 Apr 2014 23:09:00 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> On 2 April 2014 22:00, Ian Hickson <ian at hixie.ch> wrote: > It's worth noting that there are many many ways to navigate a browsing > context beyond window.open(), e.g. <a target="">, window.location, > drag-and-drop of a link, window.history.go(), etc. Absolutely, if we were to converge on the spec for the current opener and people felt that last navigator would be useful, then it would need to be updated in all cases. Although, the history case might hold the original state. Anyway, getting way ahead of myself. I'll see if there are any more opinions, then look to move Gecko towards the spec and see if any compat issues arise. From tingan87 at gmail.com Wed Apr 2 21:37:33 2014 From: tingan87 at gmail.com (Tingan Ho) Date: Thu, 3 Apr 2014 12:37:33 +0800 Subject: [whatwg] More effective model for handling resources In-Reply-To: <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> References: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> Message-ID: <CAOr4atVY-mv1aCMwdY0ijz3vPcsYLdQzb_dgu5kx8kTkDSOXuQ@mail.gmail.com> Hi Ian, I believe this is being handled by the next-generation transport protocols > (SPDY or whatever it's called now). I recommend approaching the relevant > groups to check that your precise case has been handled. I just found out that SPDY Server Push and Cookies could accomplish the above mentioned caching. Cookies will take care of information providing. And the server just uses Server Push to push content. On Thu, Apr 3, 2014 at 1:57 AM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 13 Mar 2014, Tingan Ho wrote: > > > > Almost all web developer I know use externally linked CSS resource in > > their web projects. That means that the browser needs to (1) request the > > html page (2) parse the html (3) request for the CSS resource that is > > linked from the html document. The problem with externally linked > > resources is point three. It needs to make another request for the CSS > > resource. There is a solution to this problem and that is to inline the > > CSS. Though that would yield another problem: all subsequent page > > request will become bigger. > > I believe this is being handled by the next-generation transport protocols > (SPDY or whatever it's called now). I recommend approaching the relevant > groups to check that your precise case has been handled. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- Sincerely, Tingan Ho From lists at scratchdisk.com Wed Apr 2 23:21:38 2014 From: lists at scratchdisk.com (=?iso-8859-1?Q?J=FCrg_Lehni?=) Date: Thu, 3 Apr 2014 08:21:38 +0200 Subject: [whatwg] Grouping in canvas 2d In-Reply-To: <alpine.DEB.2.00.1403141808380.32463@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <CAGN7qDBHT_fitzzsrnGe6exCWr1Fc4mXSnY=_KW7fNjkoB6-KA@mail.gmail.com> <CABpaAqTdv4TaDpXj4jksL+jeDVqv9cKyVvxJO1nridR9Zwq66Q@mail.gmail.com> <CAGN7qDA9BfpOCqzAmbwooJ_aSw8cbLT-G_-can61K05Q7YsLMw@mail.gmail.com> <73A19694-2AB0-4948-8B4B-A5ED820B2444@scratchdisk.com> <alpine.DEB.2.00.1403141808380.32463@ps20323.dreamhostps.com> Message-ID: <6D69D840-D0F2-4547-AB63-8288C2E51A1D@scratchdisk.com> Here another simple example: When both filling and stroking a path and then drawing it with with an opacity of less than 100%, the path will be rendered differently than in an SVG (a large stroke width will make the issue more apparent): - In Canvas, both the fill and the stroke will be rendered with the given opacity, and the fill will shine through the inner half of the stroke. - In SVG, the stroke will cover the fill, and the fill will not shine through the inner half of the stroke, regardless of the opacity. If you'd like to emulate the SVG behavior in Canvas (which we happen to do in Paper.js), then the only way to do so currently is to draw the path's fill and stroke at 100% opacity into a separate canvas, and then blit the whole thing over with the given opacity. This is *much* slower than directly drawing into the Canvas, and happens to be one of the worst bottlenecks in Paper.js I would really appreciate a solution to this problem. J?rg On Mar 14, 2014, at 19:09 , Ian Hickson <ian at hixie.ch> wrote: > Can you elaborate on what precisely the performance bottleneck is? I was > looking through this thread but I can't find a description of the use > cases it addresses, so it's hard to evaluate the proposals. From mkwst at google.com Thu Apr 3 02:49:20 2014 From: mkwst at google.com (Mike West) Date: Thu, 3 Apr 2014 11:49:20 +0200 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <CAKXHy=cm3F1noHs1SM4XSOpno4aB1GPQ9mhjyva9v+6EU9v3HA@mail.gmail.com> On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson <ian at hixie.ch> wrote: > > Also, consider the case of login forms without username fields. You see > > this sort of thing a lot these days, when sites remember who was last > > logged in: > > > > <form> > > <label>Password for hober: <input type=password name=pw></label> > > <p>Not hober? <a href=...>Click here to sign in</a>. > > </form> > > > > It's difficult for tools to manage the user's auth info for such pages. > > How can tools discover what the username is? The obvious solution, in a > > world with autocomplete=username, would be to add <input type=hidden > > autocomplete=username name=username value=hober> to the form. > > So far, autocomplete="" hasn't applied to <input type=hidden>. This would > be a bit weird, giving it a different meaning than usual (providing > information to the UA, rather than getting information from the UA). I'm a > bit skeptical of this kind of overloading. > > Not sure what the right solution is, though. > As Garrett noted, this is already a solution Google is using, though not with explicit syntax, just taking advantage of existing heuristics. Paving this (potential) cowpath isn't really that weird. That said, an alternative might be to add a mechanism of associating autocompletion metadata with the field in order to give the UA enough context to fill it in. For example, if a password is being requested for a known username, that username could be added as an new "autocomplete-username" attribute (similar to the 'data-*' construct HTML already supports): <input type="password" autocomplete-username="hober"> -mike -- Mike West <mkwst at google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) From andy at pigsonthewing.org.uk Thu Apr 3 03:22:48 2014 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu, 3 Apr 2014 11:22:48 +0100 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <CABiXOEmndoUXWk1nWk00RyFsA6g2M8M0ZOofTctP+_oxC4odvQ@mail.gmail.com> [General point, so not quoting anyone in particular] [Resending to list, apologies to Ian] Why would you define any address components other than those in vCard, a standard with massive implementation and interoperable with most address book applications and services? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk From creis at chromium.org Thu Apr 3 11:28:15 2014 From: creis at chromium.org (Charlie Reis) Date: Thu, 3 Apr 2014 11:28:15 -0700 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> References: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> Message-ID: <CAH+8MBaU3NSq+WvZ2iG8n_-EAaSBZTA_fYOLoMw0NkFpRf4MiA@mail.gmail.com> On Wed, Apr 2, 2014 at 3:09 PM, Bob Owen <bobowencode at gmail.com> wrote: > On 2 April 2014 22:00, Ian Hickson <ian at hixie.ch> wrote: > > > It's worth noting that there are many many ways to navigate a browsing > > context beyond window.open(), e.g. <a target="">, window.location, > > drag-and-drop of a link, window.history.go(), etc. > > Absolutely, if we were to converge on the spec for the current opener and > people felt that last navigator would be useful, then it would need to be > updated in all cases. > Although, the history case might hold the original state. > > Anyway, getting way ahead of myself. > I'll see if there are any more opinions, then look to move Gecko towards > the spec and see if any compat issues arise. > For what it's worth, I think we'd be open to changing Blink to match the spec as well, if you don't find any compat issues. Charlie From bobowencode at gmail.com Fri Apr 4 01:40:50 2014 From: bobowencode at gmail.com (Bob Owen) Date: Fri, 4 Apr 2014 09:40:50 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEEDiH1N_9rex+Dq_8nzQrCVnpa8djiJGsc1xP3zHCLLY4g@mail.gmail.com> On 3 April 2014 19:28, Charlie Reis <creis at chromium.org> wrote: > For what it's worth, I think we'd be open to changing Blink to match the spec as well, if you don't find any compat issues. I'd say it's worth a lot, thanks Charlie. From faulkner.steve at gmail.com Sat Apr 5 00:59:03 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Sat, 5 Apr 2014 08:59:03 +0100 Subject: [whatwg] summary/details - proposal Message-ID: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> note: bringing this to the whatwg list to elicit feedback from implementers and other interested parties that are not involved in the discussion at the W3C Currently the implementation(s) of summary/details elements do not match the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element In the spec, the details element is interactive content, the summary is not, its a summary, caption, or legend. in webkit/blink the summary element is the interactive element (when pressed it opens/closes the details element) This is good because it provides a large default hit region to activate the control example to try in chrome/safari/opera http://codepen.io/stevef/pen/CyauJ/ So as the spec/implementations are at odds, the implementations need to change to match the spec or the spec needs to change to match implementations or the spec needs to change to accommodate the positive aspects of the current implementations while allowing for other use cases An issue with current implementations is that when the summary element includes other interactive elements (as it is allowed to), clicking on them results in the details element being opened/closed (although this can be overcome via scripting). example to try in chrome/safari/opera http://codepen.io/stevef/pen/xjJiy/ Issues with the current spec text: The interactive part of the details element is the disclosure triangle ? which is supposed to be an anonymous control in the shadow DOM The <summary> itself is not interactive, so only the triangle provides the actionable control. the summary text which is effectively the label for control does not activate the control. There is no method provided to associate a label with the anonymous control that can (a) provide an increased hit region and (b) provide an explicitly associated label for the anonymous control. Given that what we want to provide for the use case of having controls inside the summary, after discussion around the issue[1], I have proposed the following: <details> <summary id=x> <label for=x>Foo</label> </summary> ... </details> what this does is provide the author with the ability to add an explicit label (providing the acc name) to the details control which also increases the click region for improved accessibility/usability, while still allowing interactive content inside the summary element. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25140 feedback welcome! -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From dschulze at adobe.com Sat Apr 5 09:01:19 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sat, 5 Apr 2014 16:01:19 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() Message-ID: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> Hi, I looked at the behavior of negative width or height for the rect() and strokeRect() functions. All browsers normalize the passed parameters for strokeRect() to have positive width and height. strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) http://jsfiddle.net/za945/ Just WebKit seems to normalize for rect() as well: http://jsfiddle.net/VT4MG/ The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. Greetings, Dirk From cabanier at gmail.com Sat Apr 5 18:23:06 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 5 Apr 2014 18:23:06 -0700 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> Message-ID: <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > Hi, > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > strokeRect(90,10,-80,80) --> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ I'm unsure why such a rectangle is defined as a straight line. > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ > > The behavior of normalizing is not specified. Especially it seems odd that > the behavior for fillRect()/strokeRect() should differ from rect(). So we > should either normalize for all functions or don't do it for all IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for rect() > is important for filling with different winding rules as well. It is not > just stroking with dash arrays that is effected. > yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect From ian at hixie.ch Sat Apr 5 21:11:20 2014 From: ian at hixie.ch (Ian Hickson) Date: Sun, 6 Apr 2014 04:11:20 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> On Sat, 5 Apr 2014, Steve Faulkner wrote: > > The <summary> itself is not interactive, so only the triangle provides > the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). > Given that what we want to provide for the use case of having controls > inside the summary, after discussion around the issue, I have proposed > the following: > > <details> > <summary id=x> <label for=x>Foo</label> </summary> > ... > </details> That's way more complicated than necessary for authors, not to mention all the problems it would cause with the existing <label> definitions. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dschulze at adobe.com Sat Apr 5 23:00:50 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 06:00:50 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> Message-ID: <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > Hi, > > I looked at the behavior of negative width or height for the rect() and strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have positive width and height. > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ > >> It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ >> I'm unsure why such a rectangle is defined as a straight line. You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ > > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ > > The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. > >> yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw ?in that order? for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. Greetings, Dirk > > 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect From dschulze at adobe.com Sat Apr 5 23:23:36 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 06:23:36 +0000 Subject: [whatwg] Canvas Computing text metrics Message-ID: <69477B5B-A7A4-4674-B267-09EC2499C1F0@adobe.com> Hi, The spec says that the object TextMetrics[1] must return font and actual text metrics. All things require information from the font or the font system. In many cases either font or font system just do not provide these information. Instead of assuming that all information are accessible by the browser, it might be useful to define some heuristics that can be used. In WebKit and Blink we support the CSS dominant-baseline property in SVG that requires similar metrics as well[2]. Even SVG does not specify the heuristics yet and instead leaves that up to the browser. WebKit and Blink use the heuristics described in the documentation from Apache FOP[1]. Should these be used as fallback heuristics? Note: Many browsers might use heuristics by default since they can?t get all necessary font metrics at all. Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#textmetrics [2] http://www.w3.org/TR/SVG11/text.html#TextAlignmentProperties [3] http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling From cabanier at gmail.com Sat Apr 5 23:24:19 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 5 Apr 2014 23:24:19 -0700 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> Message-ID: <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > > > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > > Hi, > > > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > > > strokeRect(90,10,-80,80) --> strokeRect(10,10,80,80) > > > > http://jsfiddle.net/za945/ > > > >> It also seems that only firefox is following the spec [1] when width or > height are 0: http://jsfiddle.net/za945/2/ > >> I'm unsure why such a rectangle is defined as a straight line. > > You mean you would rather let it draw a one dimensional rectangle? So for > the dimension that is not zero, you would see two overlapping lines + the 0 > dimensional sides? > yes That seems indeed to be the case for IE, Safari and Blink: > http://jsfiddle.net/Gh9XK/ > > > > > Just WebKit seems to normalize for rect() as well: > > > > http://jsfiddle.net/VT4MG/ > > > > The behavior of normalizing is not specified. Especially it seems odd > that the behavior for fillRect()/strokeRect() should differ from rect(). So > we should either normalize for all functions or don't do it for all IMO. > > > > Note: fillRect() and clearRect() are not affected. The behavior for > rect() is important for filling with different winding rules as well. It is > not just stroking with dash arrays that is effected. > > > >> yes, the spec needs to say "in that order" as it does for fillRect and > strokeRect. > > Ok, that means you would be in favor not to normalize. Again, all current > browser normalize and do NOT draw "in that order" for fillRect() and > strokeRect(). That means you would require to give up the currently > interoperable behavior. > I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) I would be in favor to change the blink/webkit behavior as the specified one makes more sense. From dschulze at adobe.com Sun Apr 6 00:04:46 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 07:04:46 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> Message-ID: <872B4940-A589-46D1-B72B-B302E7FCC1E3@adobe.com> On Apr 6, 2014, at 8:24 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > > > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > > Hi, > > > > I looked at the behavior of negative width or height for the rect() and strokeRect() functions. > > > > All browsers normalize the passed parameters for strokeRect() to have positive width and height. > > > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > > > http://jsfiddle.net/za945/ > > > >> It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ > >> I'm unsure why such a rectangle is defined as a straight line. > > You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? > > yes > > That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ > > > > > Just WebKit seems to normalize for rect() as well: > > > > http://jsfiddle.net/VT4MG/ > > > > The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. > > > > Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. > > > >> yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. > > Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw ?in that order? for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. > > I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ > Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) Firefox has a strange different behavior if dash >= gap. If the gap is smaller it behaves like IE, Blink and WebKit. This also answers your question: Your example renders in IE the same as in WebKit and Blink. Greetings, Dirk > > I would be in favor to change the blink/webkit behavior as the specified one makes more sense. From harald at alvestrand.no Mon Apr 7 07:24:23 2014 From: harald at alvestrand.no (Harald Alvestrand) Date: Mon, 07 Apr 2014 16:24:23 +0200 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> Message-ID: <5342B517.1080401@alvestrand.no> On 04/02/2014 07:52 PM, Ian Hickson wrote: > On Mon, 3 Mar 2014, Ami Fischman wrote: >> Looks like we're back in business: >> >> Latest editor's draft: >> http://dev.w3.org/2011/webrtc/editor/getusermedia.html > Thanks. > > As a user, this scares me a lot. Why isn't it up to me to control this? I > don't understand the security model here at all. I don't want random Web > pages to know that they can pipe audio to the remote speakers in my > bedroom from my laptop, but if we just expose all the audio output > devices, that's exactly what will be possible. > > Without a much clearer security model, I don't think it's a good idea to > add any APIs. > Would it make sense to group the access to sinks in with access to sources - that is, "this page wants access to your cameras, microphones and audio output devices"? (either on a per-device basis or as an all-or-nothing prompting) From junov at google.com Mon Apr 7 08:07:34 2014 From: junov at google.com (Justin Novosad) Date: Mon, 7 Apr 2014 11:07:34 -0400 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDCijrx_3Rfk2mFThkBc7NignwXoFHhd3fnkL9_5QPE-rQ@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> <872B4940-A589-46D1-B72B-B302E7FCC1E3@adobe.com> <CABpaAqSm=9gAT6TfbJ7RHOcSDMcxy32Enj-txyV-yN=tF8H3JA@mail.gmail.com> <CAGN7qDCijrx_3Rfk2mFThkBc7NignwXoFHhd3fnkL9_5QPE-rQ@mail.gmail.com> Message-ID: <CABpaAqRVUa0-xeoRrBUik22GyYeY1Z0e3FBx=LLpEhryfnAJ5w@mail.gmail.com> On Mon, Apr 7, 2014 at 10:47 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Mon, Apr 7, 2014 at 7:29 AM, Justin Novosad <junov at google.com> wrote: > >> Putting myself the the web devs shoes... If I negate the height of a >> rect, what would I expect? My first though: a horizontally flipped mirror >> image of the rect. >> >> Now, what does the spec say? >> a) rect(): respect the flipped vertex order >> > > yes, except it doesn't explicitly say "in that order" so a UA could > implement it in a different one. > Okay. Nonetheless the spec already does define the order, it just does not insist that it must be respected. > > > >> b) strokeRect(): respect the flipped vertex order >> c) fillRect(): unaffected by vertex order. >> > > Where do you see that fillRect is not affected? > It does not say so explicitly, but it is implied. The coloring of pixels is governed by the fillStyle, which is not affected vertex order. > >> d) fillStyle and strokeStyle style application is independent of the >> primitive, mapping is controlled by CTM (and a pattern matrix) >> >> I find the spec is consistent with itself as it is currently worded. If >> you want to flip a rect (or any other geometry for that matter), you can >> either flip everything together using the CTM, or flip its parts (the >> vertices and the styles) individually. >> I think that having the styles automatically flip when the rect is >> inverted would have an undesirable consequence: It would break consistency >> with path rendering (how do you define the notion inverted geometry for a >> general, possibly self-intersecting, path?) >> > > I'm unsure why we would switch geometry. Are you referring to the dashing? > Dashing is one thing that would be affected. I think some implementations are currently in a non-compliant state probably because the line dashing feature was added recently. Back when strokeRect was originally implemented, we could get away with blindly normalizing rectangles because there was no impact on the rendering result. The other thing that is affected is fill rule application. For example, if you have a path that contains two intersecting rectangles and you are filling in with the nonzero rule. If one of the two rectangles is flipped, then the intersection region should be unfilled. If the rectangles are "normalized" internally by the implementation, then you will get the wrong (non spec compliant) result. > > >> On Sun, Apr 6, 2014 at 3:04 AM, Dirk Schulze <dschulze at adobe.com> wrote: >> >>> >>> On Apr 6, 2014, at 8:24 AM, Rik Cabanier <cabanier at gmail.com> wrote: >>> >>> > >>> > >>> > >>> > On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> >>> wrote: >>> > >>> > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: >>> > >>> > > >>> > > >>> > > >>> > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> >>> wrote: >>> > > Hi, >>> > > >>> > > I looked at the behavior of negative width or height for the rect() >>> and strokeRect() functions. >>> > > >>> > > All browsers normalize the passed parameters for strokeRect() to >>> have positive width and height. >>> > > >>> > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) >>> > > >>> > > http://jsfiddle.net/za945/ >>> > > >>> > >> It also seems that only firefox is following the spec [1] when >>> width or height are 0: http://jsfiddle.net/za945/2/ >>> > >> I'm unsure why such a rectangle is defined as a straight line. >>> > >>> > You mean you would rather let it draw a one dimensional rectangle? So >>> for the dimension that is not zero, you would see two overlapping lines + >>> the 0 dimensional sides? >>> > >>> > yes >>> > >>> > That seems indeed to be the case for IE, Safari and Blink: >>> http://jsfiddle.net/Gh9XK/ >>> > >>> > > >>> > > Just WebKit seems to normalize for rect() as well: >>> > > >>> > > http://jsfiddle.net/VT4MG/ >>> > > >>> > > The behavior of normalizing is not specified. Especially it seems >>> odd that the behavior for fillRect()/strokeRect() should differ from >>> rect(). So we should either normalize for all functions or don?t do it for >>> all IMO. >>> > > >>> > > Note: fillRect() and clearRect() are not affected. The behavior for >>> rect() is important for filling with different winding rules as well. It is >>> not just stroking with dash arrays that is effected. >>> > > >>> > >> yes, the spec needs to say "in that order" as it does for fillRect >>> and strokeRect. >>> > >>> > Ok, that means you would be in favor not to normalize. Again, all >>> current browser normalize and do NOT draw ?in that order? for fillRect() >>> and strokeRect(). That means you would require to give up the currently >>> interoperable behavior. >>> > >>> > I changed your test a bit so you can more easily see the >>> normalisation: http://jsfiddle.net/za945/3/ >>> > Safari and Chrome are doing as you say, but Firefox does not. (I don't >>> have IE to test) >>> >>> Firefox has a strange different behavior if dash >= gap. If the gap is >>> smaller it behaves like IE, Blink and WebKit. This also answers your >>> question: Your example renders in IE the same as in WebKit and Blink. >>> >>> Greetings, >>> Dirk >>> >>> > >>> > I would be in favor to change the blink/webkit behavior as the >>> specified one makes more sense. >>> >>> >> > From fischman at chromium.org Mon Apr 7 08:53:27 2014 From: fischman at chromium.org (Ami Fischman) Date: Mon, 7 Apr 2014 08:53:27 -0700 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> Message-ID: <CAHuR8a9Q6+FSmMVCXUoy79CLMhuHz=yLuNHA_xLjicvE4kAa7w@mail.gmail.com> Thanks Ian. I pinged public-media-capture about this and https://www.w3.org/Bugs/Public/show_bug.cgi?id=25245 is now tracking making that spec better specified. On Wed, Apr 2, 2014 at 10:52 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 3 Mar 2014, Ami Fischman wrote: > > > > Looks like we're back in business: > > > > Latest editor's draft: > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html > > Thanks. > > As a user, this scares me a lot. Why isn't it up to me to control this? I > don't understand the security model here at all. I don't want random Web > pages to know that they can pipe audio to the remote speakers in my > bedroom from my laptop, but if we just expose all the audio output > devices, that's exactly what will be possible. > > Without a much clearer security model, I don't think it's a good idea to > add any APIs. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 09:20:27 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 16:20:27 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342B517.1080401@alvestrand.no> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> Message-ID: <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Harald Alvestrand wrote: > On 04/02/2014 07:52 PM, Ian Hickson wrote: > > On Mon, 3 Mar 2014, Ami Fischman wrote: > > > Looks like we're back in business: > > > > > > Latest editor's draft: > > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html > > > > As a user, this scares me a lot. Why isn't it up to me to control > > this? I don't understand the security model here at all. I don't want > > random Web pages to know that they can pipe audio to the remote > > speakers in my bedroom from my laptop, but if we just expose all the > > audio output devices, that's exactly what will be possible. > > > > Without a much clearer security model, I don't think it's a good idea > > to add any APIs. > > Would it make sense to group the access to sinks in with access to > sources - that is, "this page wants access to your cameras, microphones > and audio output devices"? > > (either on a per-device basis or as an all-or-nothing prompting) Wouldn't that be an implementation detail? When I was first desigining the API for WebRTC (years ago, before it got rather unceremoniously forked by the W3C), the security design I had come up with was basically that the UA would show a panel of devices, and the user would drag-and-drop them into the page to give the page access to them. (Or equivalent UI, e.g. tapping on the relevant device icons to activate them for the page.) This would let me, as a user, specify that on my laptop YouTube can play video on my TV (assuming we extend this stuff to support video over Miracast/AirPlay/WiDi/DIAL/Chromecast/DLNA) while not allowing it to send audio to my bedroom, while simultaneously having Amazon's Cloud Player sending its music to my bedroom, but not allowing it to use my microphone. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From harald at alvestrand.no Mon Apr 7 10:28:45 2014 From: harald at alvestrand.no (Harald Alvestrand) Date: Mon, 07 Apr 2014 19:28:45 +0200 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> Message-ID: <5342E04D.3010301@alvestrand.no> On 04/07/2014 06:20 PM, Ian Hickson wrote: > On Mon, 7 Apr 2014, Harald Alvestrand wrote: >> On 04/02/2014 07:52 PM, Ian Hickson wrote: >>> On Mon, 3 Mar 2014, Ami Fischman wrote: >>>> Looks like we're back in business: >>>> >>>> Latest editor's draft: >>>> http://dev.w3.org/2011/webrtc/editor/getusermedia.html >>> As a user, this scares me a lot. Why isn't it up to me to control >>> this? I don't understand the security model here at all. I don't want >>> random Web pages to know that they can pipe audio to the remote >>> speakers in my bedroom from my laptop, but if we just expose all the >>> audio output devices, that's exactly what will be possible. >>> >>> Without a much clearer security model, I don't think it's a good idea >>> to add any APIs. >> Would it make sense to group the access to sinks in with access to >> sources - that is, "this page wants access to your cameras, microphones >> and audio output devices"? >> >> (either on a per-device basis or as an all-or-nothing prompting) > Wouldn't that be an implementation detail? The details are an implementation detail. Whether sinks should be treated at the same level as sources, higher level or lower level of protection is probably a somewhat higher level issue. > > When I was first desigining the API for WebRTC (years ago, before it got > rather unceremoniously forked by the W3C), the security design I had come > up with was basically that the UA would show a panel of devices, and the > user would drag-and-drop them into the page to give the page access to > them. (Or equivalent UI, e.g. tapping on the relevant device icons to > activate them for the page.) This was considered, but rejected. The consensus opinion at WebRTC and MediaCapture seemed to be that the ability to let an app say "which of these 5 microphones do you want?" is more amenable to creating good apps than leaving this UI to the browser chrome. > > This would let me, as a user, specify that on my laptop YouTube can play > video on my TV (assuming we extend this stuff to support video over > Miracast/AirPlay/WiDi/DIAL/Chromecast/DLNA) while not allowing it to send > audio to my bedroom, while simultaneously having Amazon's Cloud Player > sending its music to my bedroom, but not allowing it to use my microphone. > From faulkner.steve at gmail.com Sun Apr 6 12:50:49 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Sun, 6 Apr 2014 20:50:49 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > The <summary> itself is not interactive, so only the triangle provides > > the actionable control. > > The spec doesn't disallow making clicks on (non-interactive) parts of the > summary defer to the disclosure triangle. Browsers should just match > platform conventions, where applicable, and otherwise make whatever is > considered the best choice for users (such as making such content also > trigger the disclosure triangle). > > Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. It also provides the best choice for users, large click area and focus ring, Its also simple for authors in the majority of use cases. while on Mac OSX only the disclosure triangle (approx 13X13px) itself is clickable and has a focus rectangle. > <details> > <summary id=x> <label for=x>Foo</label> </summary> > ... > </details> That's way more complicated than necessary for authors, how so? with the current definition how do authors provide a label for the disclosure widget when summary also contains controls with labels? in the absence of browser making "clicks on (non-interactive) parts of the summary defer to the disclosure triangle." how is an author supposed to do this? > not to mention all > the problems it would cause with the existing <label> definitions. > may be making the details element a labelable control would be simpler, as its be definition an interactive control. would it cause problems for existing <label> definitions? <details id=x> <summary> <label for=x>Foo</label> </summary> ... </details> > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 10:37:29 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 17:37:29 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342E04D.3010301@alvestrand.no> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> Message-ID: <alpine.DEB.2.00.1404071735580.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Harald Alvestrand wrote: > > The consensus opinion at WebRTC and MediaCapture seemed to be that the > ability to let an app say "which of these 5 microphones do you want?" is > more amenable to creating good apps than leaving this UI to the browser > chrome. Seems to me that the privacy aspects (the fingerprinting vulnerabilities from exposing this data), and the abuse aspects (giving hostile sites the ability to access all the user's devices if any are made available) would trump this. Surely we can rely on user agents to provide nice UIs. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sun Apr 6 13:08:16 2014 From: ian at hixie.ch (Ian Hickson) Date: Sun, 6 Apr 2014 20:08:16 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> On Sun, 6 Apr 2014, Steve Faulkner wrote: > On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > > > The <summary> itself is not interactive, so only the triangle > > > provides the actionable control. > > > > The spec doesn't disallow making clicks on (non-interactive) parts of > > the summary defer to the disclosure triangle. Browsers should just > > match platform conventions, where applicable, and otherwise make > > whatever is considered the best choice for users (such as making such > > content also trigger the disclosure triangle). > > Platform conventions for disclosure type widgets vary, on windows for > example, the current implementations match the convention. The conventions on Windows are all over the place: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx ...but I doubt that this matches any of the Windows conventions: | when the summary element includes other interactive elements (as it is | allowed to), clicking on them results in the details element being | opened/closed > > > <details> > > > <summary id=x> <label for=x>Foo</label> </summary> > > > ... > > > </details> > > > > That's way more complicated than necessary for authors, > > how so? All that should be necessary is: <details> <summary> Foo </summary> ... </details> Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. > with the current definition how do authors provide a label for the > disclosure widget when summary also contains controls with labels? If doing so matches the platform conventions, any non-interactive text in the <summary> would open the widget. > in the absence of browser making "clicks on (non-interactive) parts of > the summary defer to the disclosure triangle." how is an author supposed > to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From faulkner.steve at gmail.com Mon Apr 7 11:50:51 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Mon, 7 Apr 2014 19:50:51 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 6 April 2014 21:08, Ian Hickson <ian at hixie.ch> wrote: > On Sun, 6 Apr 2014, Steve Faulkner wrote: > > On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > > > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > > > > > The <summary> itself is not interactive, so only the triangle > > > > provides the actionable control. > > > > > > The spec doesn't disallow making clicks on (non-interactive) parts of > > > the summary defer to the disclosure triangle. Browsers should just > > > match platform conventions, where applicable, and otherwise make > > > whatever is considered the best choice for users (such as making such > > > content also trigger the disclosure triangle). > > > > Platform conventions for disclosure type widgets vary, on windows for > > example, the current implementations match the convention. > > The conventions on Windows are all over the place: > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx > > ...but I doubt that this matches any of the Windows conventions: > > | when the summary element includes other interactive elements (as it is > | allowed to), clicking on them results in the details element being > | opened/closed > Not what I said, but the current implementations use of <summary> as the interactive element matches, the first example under usage patterns http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx#patterns > > > > > > <details> > > > > <summary id=x> <label for=x>Foo</label> </summary> > > > > ... > > > > </details> > > > > > > That's way more complicated than necessary for authors, > > > > how so? > > All that should be necessary is: > > <details> > <summary> Foo </summary> > ... > </details> > > Adding two attributes and an elements is thus more complicated than > necessary. This seems pretty unambiguous to me. > for the case <details> <summary> Foo <input> Bar </summary> ... </details> whats the disclosure label? what about? <details> <summary> <label><input> Bar </label></summary> ... </details> > > in the absence of browser making "clicks on (non-interactive) parts of > > the summary defer to the disclosure triangle." how is an author supposed > > to do this? > > The author isn't supposed to do this. The whole point of semantic controls > like this is that the user agent is the one that picks the user interface. > does this also extend to the author being able to provide an accessible name for the control? > > Once we start talking about custom widgets, we're in the space of Web > components, at which point the author can do whatever the author wants. > yeah, its a shame that the design of some html features don't provide the flexibility to allow authors to fix user agent specific design deficits without recourse to web components > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 12:06:15 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 19:06:15 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Steve Faulkner wrote: > > > > All that should be necessary is: > > > > <details> > > <summary> Foo </summary> > > ... > > </details> > > > > Adding two attributes and an elements is thus more complicated than > > necessary. This seems pretty unambiguous to me. > > for the case > > <details> > <summary> Foo <input> Bar </summary> > ... > </details> > > whats the disclosure label? The text "Foo", a text field, and the text "Bar". If by "disclosure label" you mean the parts which, on certain platforms, when clicked, would toggle the open state, then that depends on the platform, but I would expect the "Foo" and "Bar" text to be good candidates, since they're otherwise inert. > what about? > > <details> > <summary> <label><input> Bar </label></summary> > ... > </details> Here there's no non-interactive text, so there's no text to target. > > > in the absence of browser making "clicks on (non-interactive) parts > > > of the summary defer to the disclosure triangle." how is an author > > > supposed to do this? > > > > The author isn't supposed to do this. The whole point of semantic > > controls like this is that the user agent is the one that picks the > > user interface. > > does this also extend to the author being able to provide an accessible > name for the control? Should there be a particular need for an accessible name for the <details> control, ARIA can be used to set the name. But I must admit to not understanding why you would need that in practice, if the page is well written. (I find most pages that use accessible labels in situations such as this tend to be poorly written for non-AT users.) > > Once we start talking about custom widgets, we're in the space of Web > > components, at which point the author can do whatever the author > > wants. > > yeah, its a shame that the design of some html features don't provide > the flexibility to allow authors to fix user agent specific design > deficits without recourse to web components Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dyoung at pobox.com Mon Apr 7 12:30:16 2014 From: dyoung at pobox.com (David Young) Date: Mon, 7 Apr 2014 14:30:16 -0500 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342E04D.3010301@alvestrand.no> References: <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> Message-ID: <20140407193016.GE7959@pobox.com> On Mon, Apr 07, 2014 at 07:28:45PM +0200, Harald Alvestrand wrote: > On 04/07/2014 06:20 PM, Ian Hickson wrote: > >When I was first desigining the API for WebRTC (years ago, before it got > >rather unceremoniously forked by the W3C), the security design I had come > >up with was basically that the UA would show a panel of devices, and the > >user would drag-and-drop them into the page to give the page access to > >them. (Or equivalent UI, e.g. tapping on the relevant device icons to > >activate them for the page.) > > This was considered, but rejected. > The consensus opinion at WebRTC and MediaCapture seemed to be that > the ability to let an app say "which of these 5 microphones do you > want?" is more amenable to creating good apps than leaving this UI > to the browser chrome. If the app disregards or misunderstands the user's input, what keeps it from using the wrong microphone? How do I disconnect a microphone from an app? How do I know which microphones are connected to which apps? Ian's proposal seems to offer this visibility and control to the user. Dave -- David Young dyoung at pobox.com Urbana, IL (217) 721-9981 From cabanier at gmail.com Tue Apr 8 04:18:22 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 04:18:22 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDCitrYeR+zoh8B+FdGyF6mQL5Pvkd=UjbdKD_Urtw_vBg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 12 Mar 2014, Rik Cabanier wrote: > > On Wed, Mar 12, 2014 at 3:44 PM, Ian Hickson wrote: > > > On Thu, 28 Nov 2013, Rik Cabanier wrote: > > > > On Thu, Nov 28, 2013 at 8:30 AM, J?rg Lehni wrote: > > > > > > > > > > I meant to say that it I think it would make more sense if the > > > > > path was in the current transformation matrix, so it would > > > > > represent the same coordinate values in which it was drawn, and > > > > > could be used in the same 'context' of transformations applied to > > > > > the drawing context later on. > > > > > > > > No worries, it *is* confusing. For instance, if you emit coordinates > > > > and then scale the matrix by 2, those coordinates from > > > > getCurrentPath will have a scale of .5 applied. > > > > > > That's rather confusing, and a pretty good reason not to have a way to > > > go from the current default path to an explicit Path, IMHO. > > > > > > Transformations affect the building of the current default path at > > > each step of the way, which is really a very confusing API. The Path > > > API on the other hand doesn't have this problem -- it has no > > > transformation matrix. It's only when you use Path objects that they > > > get transformed. > > > > This happens transparently to the author so it's not confusing. > > I've been confused by it multiple times over the years, and I wrote the > spec. I am confident in calling it confusing. > Only when you think about it :-) > > For instance: > > > > ctx.rect(0,0,10,10); > > ctx.scale(2,2); <- should not affect geometry of the previous rect > > ctx.stroke(); <- linewidth is scaled by 2, but rect is still 10x10 > > It's confusing because it's not at all clear why this doesn't result in > two rectangles of different sizes: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > ctx.scale(2,2); > ctx.stroke(); > > ...while this does: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > ctx.beginPath(); > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > > It appears to be the same path in both cases, after all. > Maybe you can think about drawing paths like drawing in a graphics application. - moveTo, lineTo, etc = drawing line segments in the document - scale = hitting the magnifying glass/zooming - translate = panning the document (0,0) is the upper left of the screen - coordinates in path segments/rect = coordinates on the screen It would be very surprising that line art would change when zooming in or out or panning. From faulkner.steve at gmail.com Tue Apr 8 05:25:14 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Tue, 8 Apr 2014 13:25:14 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> On 7 April 2014 20:06, Ian Hickson <ian at hixie.ch> wrote: > Should there be a particular need for an accessible name for the <details> > control, ARIA can be used to set the name. But I must admit to not > understanding why you would need that in practice, if the page is well > written. (I find most pages that use accessible labels in situations such > as this tend to be poorly written for non-AT users.) > All controls are expected to have an accessible name and it is expected that the author is able to assign one. this is accessibility 101 across all platforms. Lack of an accessible name or a generic accessible name or an ambiguous accessible name causes issues for users. What's the mechanism by which the anonymous control for details can be assigned an accessible name? Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. avoiding unnecessary recourse to web component use is a reasonable and expected goal - built in vs bolt on accessibility is better. Having to use a web component to overcome the inability to make a html control usable without relying on CSS and Js and ARIA is unfortunate, and as you said yesterday "once you're using custom components you've pretty much sacrificed the ability for the web to work without css and js, especially if you don't have a fallback element..." http://krijnhoetmer.nl/irc-logs/whatwg/20140407#l-396 -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From cabanier at gmail.com Tue Apr 8 09:14:50 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 09:14:50 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDAaNR6_TgZMQq2tnE8NgAoWqBDrUB+_ELZqMCPxGWe6Mg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > So this is not how most implementations currently have it defined. > > > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > > definitely do store the path in user coordinates. The spec currently > > > > says otherwise [1] though. > > > > > > I'm not sure what you're referring to here. > > > > All graphics backends for canvas that I can inspect, don't apply the CTM > > to the current path when you call a painting operator. Instead, the path > > is passed as segments in the current CTM and the graphics library will > > apply the transform to the segments. > > Right. That's what the spec says too, for the current default path. No, the spec says this: For CanvasRenderingContext2D objects, the points passed to the methods, and the resulting lines added to current default path by these methods, must be transformed according to the current transformation matrix before being added to the path. > This is the confusing behaviour to which I was referring. The "Path" API > (or > Path2D or whatever we call it) doesn't have this problem. > That is correct. The Path2D object is in user space and can be passed directly to the graphics API (along with the CTM). > ... > > > > var s = new Shape(); > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > > Shape(ctx.currentPath)); > > > > ... > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke > calls? > > > > That does not work as the second addHitRegion will remove the control and > > id from the first one. > > The 'add' operation is needed to get a union of the region shapes. > > Just use two different IDs with two different addHitRegion() calls. That's > a lot less complicated than having a whole new API. > That doesn't work if you want to have the same control for the 2 areas, from the spec for addHitRegion: If there is a previous region with this control, remove it from the scratch bitmap's hit region list; then, if it had a parent region, decrement that hit region's child count by one. Even if you don't use the control, it would be strange to have 2 separate hit regions for something that represents 1 object. > > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > ... > > > > > copy, and would help memory consummation and performance. > > > > > > I don't really understand the use case here. > > > > Jurg was just talking about an optimization (so you don't have to make > > an internal copy) > > Sure, but that doesn't answer the question of what the use case is. > >From my recent experiments with porting canvg ( https://code.google.com/p/canvg/) to use Path2D, they have a routine that continually plays a path into the context which is called from a routine that does the fill, clip or stroke. Because that routine can't simply set the current path, a lot more changes were needed. Some pseudocode that shows the added complexity, without currentPath: function drawpath() { if(Path2DSupported) { return myPath; } else for(...) { ctx.moveTo/lineTo/... } } function fillpath() { var p = drawpath(); if(p) ctx.fill(p); else ctx.fill(); } with currentPath: function drawpath() { if(Path2DSupported) { // only 2 extra lines of code ctx.currentPath = myPath; } else for(...) { ctx.moveTo/lineTo/... } function fillpath() { drawpath(); ctx.fill(); } > On Wed, 12 Mar 2014, Rik Cabanier wrote: > ... > > > You say, here are some paths, here are some fill rules, here are some > > > operations you should perform, now give me back a path that describes > > > the result given a particular fill rule. > > > > I think you're collapsing a couple of different concepts here: > > > > path + fillrule -> shape > > union of shapes -> shape > > shape can be converted to a path > > I'm saying "shape" is an unnecessary primitive. You can do it all with > paths. > > union of (path + fillrule)s -> path > No, that makes no sense. What would you get when combining a path with a fillrule and no fillrule? > > > A shape is just a path with a fill rule, essentially. > > > > So, a path can now have a fillrule? Sorry, that makes no sense. > > I'm saying a shape is just the combination of a fill rule and a path. The > path is just a path, the fill rule is just a fill rule. > After applying a fillrule, there is no longer a path. You can *convert* it back to a path that describes the outline of the shape if you want, but that is something different. The way you've defined things now, you can apply another fill rule on a path with a fill rule. What would the result of that be? > > > Anything you can do > > > with one you can do with the other. > > > > You can't add segments from one shape to another as shapes represent > > regions. > > Likewise, you can't union, intersect or xor path segments. > > But you can union, intersect, or xor lists of pairs of paths and > fillrules. > would you start throwing when doing these operations on paths without fill rules? > ... > > > > > "Wrong" meaning: > > if the author has a bunch of geometry and wants to put it in 1 path > object > > so he can just execute 1 fill operation, he might be under the impression > > that "adding" the geometry will just work. > > Well, sure, an author might be under any number of false impressions. > > The API has a way for a bunch of paths to be merged with a single fillrule > to generate a new path with no crossing subpaths (which is also fillrule > agnostic), essentially giving you the union of the shapes represented by > those paths interpreted with that fillrule. > Is this the API you're referring to? path = new Path2D(paths [, fillRule ] ) The first argument could point to paths that need different winding rules so this won't work. What if one of the paths already had a fill rule? This doesn't seem implementable/stable. > There are very few use cases where you want to add partial path segments > > together but I agree that there are some cases that it's useful to have. > > I disagree that there few such cases. Pretty much any time you create a > path, you are adding partial path segments together. Whether you do so > using one Path object all at once or multiple Path objects that you later > add together is just a matter of programming style. > It's the multiple path objects use case that is unclear to me. Is there any tool/library that does this? Looking at Adobe's graphics applications, there isn't anything like it. Looking at graphics APIs, I don't see any calls that combine paths directly. hmm, it seems the spec has changed. It didn't used to start with "Create a new path that describes the edge of the areas" With the new wording, the last sentence should be updated: Subpaths in the newly created path must wind clockwise, regardless of the direction of paths in path. Since you now create 'holes', the separate paths need to be reoriented like you specify in other parts. > ... > > > > I want them removed because they will most likely not behave in the > > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > > expect that there is 'interference' between them. > > > > > > I don't see why not. It's exactly what happens today if you were to > > > just add the same path creation statements together into the current > > > default path and fill or stroke that. > > > > Sure but who does that? > > It's how all paths are built, as far as I can tell. I don't see how else > you could build a path that consists of more than one line. > > addPath() is useful for shifting a path according to a transform. > Why not just transform() then? addPathByStrokingPath() is for creating a stroked path. > addText() is for writing text. > > I don't see how removing any of them is a win. > Yes, they are useful. The issue is that they are not implementable as currently specified. > > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > ... > > > > > > > > > How would you get a point? the width is scaled to 0. > > > > > > That's how you get a point -- scale(0,0) essentially reverts > > > everything to a zero dimensional point. > > > > OK, but the width of the point is also transformed to 0 so you get > > nothing. > > Points are always zero-width, by definition. > You can still stroke it though and get a point of the strokewidth. > ... > > However the way you defined those APIs does not make sense and will not > > give the result that authors want. > > The way to make this point would be to start from the use case, describe > the desired effect, show the "obvious" way to achieve this using the API, > and then demonstrate how it doesn't match the desired effect. > The obvious way is to go with Shape2D. It's not because I invented it; many advanced graphics APIs came offer this (including D2D and skia) > ... > > > So, it's not realistic to add this to the Path2D object. > > I don't really see why it's unrealistic. In most cases, the user agent > doesn't actually have to do any work -- e.g. if all that you're doing is > merging two paths so that you can fill them simultaneously later, the UA > can just keep the two paths as is and, when necessary, fill them. > > For cases where you really want to have this effect -- e.g. when you want > to get the outline of the dashed outline of text -- then I don't really > see any way to work around it. > That is true. That is why I proposed to make the interface more limited for now until there is a time that this functionality is available. >From Ian Hickson: > I don't think the spec should be written with a particular > implementation in mind, nor should it dictate one. I agree it shouldn't (and doesn't) dictate one. But it's crazy to not consider implementations at all when writing a spec. That way lies madness like requiring O(N^2) algorithms and solving the halting problem and all kinds of other disasters (all of which I've seen in real proposals). > > The reason for that is that even though a UA could emulate the union by > > doing multiple fill operations, Path2D allows you to stroke another path > > object. At that point, you really have to do planarization. By defining > > a Shape2D object and not allowing it to be stroked, we can work around > > this. > > Sure, by limiting the feature set dramatically we can avoid the cases > where you have to do the hard work, but we also lose a bunch of features. > For now. They can be added later. Until then, this is confusing implementors. > ... > > > > Where is the union of fill regions specified? All I see is segments > > aggregation. > > One of the Path constructors takes an array of paths and a fill rule. > See above. > > > > No one has implemented them and they are confusing the browser > > > > vendors. > > > > > > I don't think they're confusing anyone. > > > > The blink people were looking at adding this until they thought it > > through and realized that it wouldn't work. > > Realised what wouldn't work? As far as I'm aware, there's nothing that > wouldn't work. > See this thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/168925.html I think you already addressed some of the concerns. Doing the planarization is now the problem so we can't implement this. > ... > > How can you make that statement? No one has implemented them yet. > > What do you mean by "stable"? > > I assumed you meant "hasn't been changing a lot". The spec hasn't been > changing a lot, so it seems pretty stable. > You've been making a lot of changes lately so this not quite true. Because you wrote it a long time ago and nobody looked at it until now, doesn't mean that it is stable. From ian at hixie.ch Mon Apr 7 15:35:50 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 22:35:50 +0000 (UTC) Subject: [whatwg] <canvas> feedback In-Reply-To: <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> (Note: I started responding to this feedback last week, so this is missing responses to feedback sent in the last few days. Sorry about that. I'll get to that feedback in due course as well!) On Mon, 3 Mar 2014, Justin Novosad wrote: > > Say you create a new document using > document.implementation.createHTMLDocument(), you get a document without > a browsing context. This means that style and layout will never be > calculated on the document. Some of those calculations are context > dependent, so they can't even be resolved. Now, what about canvas > elements? If JS code draws to a canvas that is in a document with no > browsing context, what should happen? It should draw. In theory, anywhere in the canvas API where it depends on computed styles, it has prose saying what should happen if the computed style cannot be used. This is needed for display:none canvases, for 2D contexts in workers, and for the case you describe. > For example, there is no locale for font family resolution I'm not clear on what you mean by "locale" here. What is the locale that a displayed <canvas> in a Document in a browsing context has, that a non-displayed <canvas> outside a Document and without a browsing context does not have? > and it is not possible to resolve font sizes in physical length units > unless the document is associated with a view. Why not? The canvas has a pixel density (currently always 1:1), no? > My 2 cents: specifying fallback behaviors for all use cases that are > context dependent could be tedious and I have yet to see a real-world > use case that requires being able to paint a canvas in a frame-less > document. Therefore, I think the spec should clearly state <canvas> > elements that are in a document without a browsing context are unusable. > Not sure what the exact behavior should be though. Should an exception > be thrown upon trying to use the rendering context? Perhaps canvas draws > should fail silently, and using the canvas as an image source should > give transparent black pixels? As far as I can tell, this is all already specified, and it just gets treated like a normal canvas. On Wed, 5 Mar 2014, Rik Cabanier wrote: > > Testing all browsers (except IE since > document.implementation.createHTMLDocument() doesn't work) they seem to > handle canvas contexts with no browsing context except when you use > text. Chrome crashes, firefox throws an exception and Safari draws the > text with a very small scale I don't really understand why this is problematic in practice. What does a browsing context provide that is needed for rendering text that a user agent couldn't fake for itself in other contexts? We're definitely going to need text in worker canvases. On Thu, 6 Mar 2014, Justin Novosad wrote: > > Thanks for checking. The reason I started this thread is that I just > recently solved the crash in Chrome, and I wasn't satisfied with my > resolution. I just added an early exit, so Chrome 35 will fail silently > on calls that depend on style resolution when the canvas has no browsing > context. So now we have three different behaviors. Yay! > > I don't think the Safari behavior is the right thing to do because it > will never match the developer's intent. I agree. The developer's intent is that text be drawn as specified in the API. Why would we do anything else? On Wed, 12 Mar 2014, Rik Cabanier wrote: > On Wed, Mar 12, 2014 at 3:44 PM, Ian Hickson wrote: > > On Thu, 28 Nov 2013, Rik Cabanier wrote: > > > On Thu, Nov 28, 2013 at 8:30 AM, J?rg Lehni wrote: > > > > > > > > I meant to say that it I think it would make more sense if the > > > > path was in the current transformation matrix, so it would > > > > represent the same coordinate values in which it was drawn, and > > > > could be used in the same 'context' of transformations applied to > > > > the drawing context later on. > > > > > > No worries, it *is* confusing. For instance, if you emit coordinates > > > and then scale the matrix by 2, those coordinates from > > > getCurrentPath will have a scale of .5 applied. > > > > That's rather confusing, and a pretty good reason not to have a way to > > go from the current default path to an explicit Path, IMHO. > > > > Transformations affect the building of the current default path at > > each step of the way, which is really a very confusing API. The Path > > API on the other hand doesn't have this problem -- it has no > > transformation matrix. It's only when you use Path objects that they > > get transformed. > > This happens transparently to the author so it's not confusing. I've been confused by it multiple times over the years, and I wrote the spec. I am confident in calling it confusing. > For instance: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); <- should not affect geometry of the previous rect > ctx.stroke(); <- linewidth is scaled by 2, but rect is still 10x10 It's confusing because it's not at all clear why this doesn't result in two rectangles of different sizes: ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); ctx.scale(2,2); ctx.stroke(); ...while this does: ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); ctx.beginPath(); ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); It appears to be the same path in both cases, after all. > > > > So this is not how most implementations currently have it defined. > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > definitely do store the path in user coordinates. The spec currently > > > says otherwise [1] though. > > > > I'm not sure what you're referring to here. > > All graphics backends for canvas that I can inspect, don't apply the CTM > to the current path when you call a painting operator. Instead, the path > is passed as segments in the current CTM and the graphics library will > apply the transform to the segments. Right. That's what the spec says too, for the current default path. This is the confusing behaviour to which I was referring. The "Path" API (or Path2D or whatever we call it) doesn't have this problem. > > > Another use case is to allow authors to quickly migrate to hit regions. > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); > > > ... // lots of complex drawing operation for a control > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); > > > > > > > > > To migrate that to a region (with my proposed shape interface [1]): > > > > > > var s = new Shape(); > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > Shape(ctx.currentPath)); > > > ... > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke calls? > > That does not work as the second addHitRegion will remove the control and > id from the first one. > The 'add' operation is needed to get a union of the region shapes. Just use two different IDs with two different addHitRegion() calls. That's a lot less complicated than having a whole new API. > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > > > > > > Instead of using getCurrentPath and setCurrentPath methods as a > > > solution, this could perhaps be solved by returning the internal > > > path instead of a copy, but with a flag that would prevent further > > > alterations on it. > > > > > > The setter of the currentPath accessor / data member could then make > > > the copy instead when a new path is to be set. > > > > > > This would also make sense from a a caching point of view, where > > > storing the currentPath for caching might not actually mean that it > > > will be used again in the future (e.g. because the path's geometry > > > changes completely on each frame of an animation), so copying only > > > when setting would postpone the actual work of having to make the > > > copy, and would help memory consummation and performance. > > > > I don't really understand the use case here. > > Jurg was just talking about an optimization (so you don't have to make > an internal copy) Sure, but that doesn't answer the question of what the use case is. On Wed, 12 Mar 2014, Rik Cabanier wrote: > > > > > > > > You can do unions and so forth with just paths, no need for > > > > regions. > > > > > > How would you do a union with paths? If you mean that you can just > > > aggregate the segments, sure but that doesn't seem very useful. > > > > You say, here are some paths, here are some fill rules, here are some > > operations you should perform, now give me back a path that describes > > the result given a particular fill rule. > > I think you're collapsing a couple of different concepts here: > > path + fillrule -> shape > union of shapes -> shape > shape can be converted to a path I'm saying "shape" is an unnecessary primitive. You can do it all with paths. union of (path + fillrule)s -> path > > A shape is just a path with a fill rule, essentially. > > So, a path can now have a fillrule? Sorry, that makes no sense. I'm saying a shape is just the combination of a fill rule and a path. The path is just a path, the fill rule is just a fill rule. > > Anything you can do > > with one you can do with the other. > > You can't add segments from one shape to another as shapes represent > regions. > Likewise, you can't union, intersect or xor path segments. But you can union, intersect, or xor lists of pairs of paths and fillrules. > > > > > The path object should represent the path in the graphics state. > > > > > You can't add a stroked path or text outline to the graphics > > > > > state and then fill/stroke it. > > > > > > > > Why not? > > > > > > As designed today, you could fill it, as long as you use non-zero > > > winding. If you use even-odd, the results will be very wrong. (ie > > > where joins and line segments meet, there will be white regions) > > > > I think "wrong" here implies a value judgement that's unwarranted. > > "Wrong" meaning: > if the author has a bunch of geometry and wants to put it in 1 path object > so he can just execute 1 fill operation, he might be under the impression > that "adding" the geometry will just work. Well, sure, an author might be under any number of false impressions. The API has a way for a bunch of paths to be merged with a single fillrule to generate a new path with no crossing subpaths (which is also fillrule agnostic), essentially giving you the union of the shapes represented by those paths interpreted with that fillrule. > There are very few use cases where you want to add partial path segments > together but I agree that there are some cases that it's useful to have. I disagree that there few such cases. Pretty much any time you create a path, you are adding partial path segments together. Whether you do so using one Path object all at once or multiple Path objects that you later add together is just a matter of programming style. > > > Stroking will be completely wrong too, because joins and end caps > > > are drawn separately, so they would be stroked as separate paths. > > > This will not give you the effect of a double-stroked path. > > > > I don't understand why you think joins and end caps are drawn > > separately. That is not what the spec requires. > > Sure it does, for instance from > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path > : > > The round value means that a filled arc connecting the two > aforementioned corners of the join, abutting (and not overlapping) the > aforementioned triangle, with the diameter equal to the line width and > the origin at the point of the join, must be added at joins. > > If you mean, "drawn with a separate fill call", yes that is true. > What I meant was that they are drawn as a separate closed path that will > interact with other paths as soon as there are different winding rules or > "holes". The word "filled" is a bit misleading here (I've removed it), but I don't see why that led you to the conclusion you reached. The step in question begins with "Create a new path that describes the edge of the areas that would be covered if a straight line of length equal to the styles lineWidth was swept along each path in path while being kept at an angle such that the line is orthogonal to the path being swept, replacing each point with the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, and replacing each join with the join necessary to satisfy the styles lineJoin type, as defined below", which seems pretty unambiguous. > > > > We seem to be going around in circles. We're in agreement that > > > > eventually we should add APIs for combining paths such that we get > > > > the equivalent of the union of their fill regions. I agree that > > > > converting text into paths is non-trivial (lots of stuff browsers > > > > do is non-trivial, that's kind of the point -- if it was trivial, > > > > we could leave it for authors). But I don't see how we get from > > > > there to you wanting the existing APIs removed. > > > > > > I want them removed because they will most likely not behave in the > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > expect that there is 'interference' between them. > > > > I don't see why not. It's exactly what happens today if you were to > > just add the same path creation statements together into the current > > default path and fill or stroke that. > > Sure but who does that? It's how all paths are built, as far as I can tell. I don't see how else you could build a path that consists of more than one line. addPath() is useful for shifting a path according to a transform. addPathByStrokingPath() is for creating a stroked path. addText() is for writing text. I don't see how removing any of them is a win. > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > > > > > > > > > > However, for your example, I'm unsure what the right solution > > > > > is. The canvas specification is silent on what the behavior is > > > > > for non-invertible matrices. > > > > > > > > What question do you think the spec doesn't answer? > > > > > > > > > I think setting scale(0,0) or another matrix operation that is > > > > > not reversible, should remove drawing operations from the state > > > > > because: - how would you stroke with such a matrix? > > > > > > > > You'd get a point. > > > > > > How would you get a point? the width is scaled to 0. > > > > That's how you get a point -- scale(0,0) essentially reverts > > everything to a zero dimensional point. > > OK, but the width of the point is also transformed to 0 so you get > nothing. Points are always zero-width, by definition. > We've gone over this several times now. > The APIs that you define, have use cases and I agree with them. > However the way you defined those APIs does not make sense and will not > give the result that authors want. The way to make this point would be to start from the use case, describe the desired effect, show the "obvious" way to achieve this using the API, and then demonstrate how it doesn't match the desired effect. > What you specified there is called "planarization". This is when you > calculate the intersections within and between closed shapes and remove the > line segments that are filled on both sides. > By specifying this: > > The subpaths in merged path must be oriented such that for any point, the > number of times a half-infinite straight line drawn from that point crosses > a subpath is even if and only if the number of times a half-infinite > straight line drawn from that same point crosses a subpath going in one > direction is equal to the number of times it crosses a subpath going in the > other direction. > > and relying on segment removal, you also get the same fill behavior for > even-odd. (Meaning that the end result can be used with either winding rule) > This is not something that is needed for just text but also when you do a > union of shapes. > > The bad news is that this algorithm is very expensive and there are few > libraries that do a decent job (I only know of 1). > So, it's not realistic to add this to the Path2D object. I don't really see why it's unrealistic. In most cases, the user agent doesn't actually have to do any work -- e.g. if all that you're doing is merging two paths so that you can fill them simultaneously later, the UA can just keep the two paths as is and, when necessary, fill them. For cases where you really want to have this effect -- e.g. when you want to get the outline of the dashed outline of text -- then I don't really see any way to work around it. > The reason for that is that even though a UA could emulate the union by > doing multiple fill operations, Path2D allows you to stroke another path > object. At that point, you really have to do planarization. By defining > a Shape2D object and not allowing it to be stroked, we can work around > this. Sure, by limiting the feature set dramatically we can avoid the cases where you have to do the hard work, but we also lose a bunch of features. > > I don't think the arguments for removing these are compelling. The > > problems with the APIs have been addressed (e.g. there's no ambiguity > > in the case of overlapping text), the use cases are clear (e.g. > > drawing text around an arc or drawing a label along a line graph's > > line), and the API now supports the constructs to do unions of fill > > regions. > > Where is the union of fill regions specified? All I see is segments > aggregation. One of the Path constructors takes an array of paths and a fill rule. > > > No one has implemented them and they are confusing the browser > > > vendors. > > > > I don't think they're confusing anyone. > > The blink people were looking at adding this until they thought it > through and realized that it wouldn't work. Realised what wouldn't work? As far as I'm aware, there's nothing that wouldn't work. > > > Until we have support for shapes, the output of these methods won't > > > be stable. > > > > These methods have been very stable. They have barely changed since > > they were added, except for some minor tweaks to fix bugs. > > How can you make that statement? No one has implemented them yet. What do you mean by "stable"? I assumed you meant "hasn't been changing a lot". The spec hasn't been changing a lot, so it seems pretty stable. On Fri, 14 Mar 2014, Justin Novosad wrote: > On Fri, Mar 14, 2014 at 2:29 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > If the bug is that Chrome resamples the image in an ugly way, then > > that's a bug with Chrome. As the bug says, browsers are allowed to > > pick whatever algorithm they want -- it's a quality-of-implementation > > issue. But if the result is ugly, that's a low quality implementation. > > Yes, and if we fixed it to make it prettier, people would complain about > a performance regression. It is impossible to make everyone happy right > now. Would be nice to have some kind of speed versus quality hint. The problem with a hint is that it will be set incorrectly, and so instead of having something that's mostly pretty but mostly fast for everyone, you'd end up with something that's slow on sites that need things to be fast, and things that are ugly on sites that need things to be pretty. In general I think it is very unwise for us to design APIs with hints that have subtle effects on developer machines but that can cripple performance on low-end devices. Instead, we should use adaptive algorithms, for example always using the prettiest algorithms unless we find that frame rate is suffering, and then stepping down to faster algorithms. On Wed, 26 Mar 2014, K. Gadd wrote: > > As I mentioned to Ryosuke off-list, I think the > interpolateEndpointsCleanly attribute is a (relatively) simple solution > to the problem I have with the current spec, and it doesn't > overcomplicate things or make it hard to improve filtering in the > future. It's also trivial to feature-detect, which means I can use it > when available and fallback to a temporary canvas otherwise. I think > providing this option would also make it easier to solve situations > where applications rely on the getImageData output after rendering a > scaled bitmap. > > I'd probably call it something (to me) clearer about semantics, though, > like 'sampleInsideRectangle' Here you are suggesting a feature that would override the requirement in the spec that reads "When the filtering algorithm requires a pixel value from outside the source rectangle but inside the original image data, then the value from the original image data must be used", right? What would you replace it with, exactly? Transparent black? The value from the nearest edge pixel inside the rectangle? Can you elaborate on the use case? On Fri, 14 Mar 2014, Rik Cabanier wrote: > On Fri, Mar 14, 2014 at 11:09 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 4 Dec 2013, J?rg Lehni wrote: > > > > > > Implementing [layering/grouping] would help us greatly to optimize > > > aspects of Paper.js, as double buffering into separate canvases is > > > very slow and costly. > > > > Can you elaborate on what precisely the performance bottleneck is? I > > was looking through this thread but I can't find a description of the > > use cases it addresses, so it's hard to evaluate the proposals. > > Let's say you're drawing a scene and there is a bunch of artwork that > you want to apply a multiply effect or opacity to. With today's code, it > would look something like this: > > var bigcanvas = document.getElementById("c"); > var ctx = bigcanvas.getContext("2d"); > ctx.moveto();.... // drawing underlying scene > > ctx.globalAlpha(.5); > var c = document.createElement("canvas"); > ctx2 = c.getContext("2d"); > ctx2.moveto();.... // drawing scene that needs the effect > ctx.drawImage(c, 0, 0); > > With layers, it would become: > > var bigcanvas = document.getElementById("c"); > var ctx = bigcanvas.getContext("2d"); > ctx.moveto();.... // drawing underlying scene > > ctx.globalAlpha(.5); > ctx.beginLayer(); > ctx.moveto();.... // drawing scene that needs the effect > ctx.endLayer(); > > So, with layers you > - avoid creating (expensive) DOM elements Not really though, right? I mean, the user agent still has to create the intermediate bitmap to apply the effects to. > - simplify the drawing (especially when there's a transformation) Why would it be simpler? There's a bug tracking this feature currently: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22704 On Fri, 14 Mar 2014, Rik Cabanier wrote: > > Path2D has now landed in Blink [1]. Blink also implemented the 'addPath' > method. > WebKit just landed a patch to rename Path to Path2D, remove currentPath and > add fill/stroke/clip with a path [2]. > A patch is under review for Firefox to add Path2D. > > Given this, can we change the spec to reflect the new name? > > 1: https://codereview.chromium.org/178673002/ > 2: https://webkit.org/b/130236 > 3: https://bugzilla.mozilla.org/show_bug.cgi?id=830734 Done. On Tue, 18 Mar 2014, J?rg Lehni wrote: > > So is currentPath going away then for sure? Will there still be a way to > to retrieve a Path2D representation of the path being drawn by the long > existing drawing commands on the context? > > I quite liked how I could use it for caching, in case the browser > supported that feature, and check wether I have a cached path the next > time I need to draw it, falling back on redrawing it using the same > drawing commands. Doing the same by feature-detecting the Path(2D) > constructor and building separate drawing approaches based on its > existence results in much more complicated code. Why is it so complicated? Here's an example of how you could do it, assuming you wanted to cache certain paths function myCircle(p) { p.moveTo(0,0); // etc... } function fillPath(c, callback) { if (window.Path2D) { var p; if (pathIsAlreadyCached(callback.name)) { p = getCachedPath(callback.name); } else { p = new Path2D(); callback(p); saveCachedPath(p, callback.name); } c.fill(p); } else { c.beginPath(); callback(c); c.fill(); } } fillPath(c, myCircle); On Tue, 18 Mar 2014, Dirk Schulze wrote: > > I am still in favor for a setter and getter as well. It had the benefit > that you were able to transform the context and it affected drawing > commands as well. It is more complicated to create a second Path2D > object and add it to a previous path with a transform. I'm not sure I understand what you mean. The interactions of transforms and path building on the 2D context was one of the biggest problems that the Path objects are intended to side-step. On Fri, 14 Mar 2014, Rik Cabanier wrote: > > > > Event retargetting now explicitly applies to "the control represented > > by the region", which is always null if the given control is now a > > text field. > > Does this change the eventTarget attribute on the event object [1]. It changes the "target" attribute, if that's what you mean. (See step 3 of the dispatch algorithm in DOM.) > > > More generally, is this event rerouting supposed to be able to > > > trigger browser default event handling behavior, or only DOM event > > > dispatch? > > > > As it was specified, I don't see how it could trigger default actions > > of anything other than the canvas and its ancestors. The canvas hook > > ran in the middle of the "When a pointing device is clicked, the user > > agent must run these steps" algorithm, which refers to the origin > > target, not the rerouted target. > > > > I've now changed this so that it does in fact trigger the default > > action if applicable. > > This will still just reroute events, right? Not sure what you mean by "just". > For instance, if the fallback element is a <a href="...">, will clicking > on the region cause the browser to follow the hyperlink? Yes. > > On Wed, 5 Mar 2014, Robert O'Callahan wrote: > > > > > > The problem is that if these retargeted events can trigger default > > > browser behavior, the browser has to be able to compute the position > > > of the event relative to the new target DOM node, and it's not clear > > > how to do that. > > > > I've made it explicit that the elements that can get clicks targetted > > to them only include elements that don't have subregions. In > > particular, image maps and image buttons are excluded. > > Thanks for updating the spec. It's getting quite complex though :-( > Maybe it's simpler to just add the id to the event and leave the canvas > element as the target? Since this is not a major feature, the complexity > might stop implementors. I don't understand what part you think is complicated here. Can you elaborate? > > > Currently, the specification states that if you create a region and > > > then create another region that completely covers region, the first > > > region is removed from the hit region list [1] > > > > > > This is a complex operation that involves either drawing the regions > > > to a bitmaps and counting pixels, or path intersection. > > > > There's two trivial ways to implement this, depending on whether the > > hit regions are backed by a bitmap (the simplest and fastest solution > > but uses a lot of memory) or a region list (slower, but much more > > memory efficient). In the case of a bitmap, you just draw on the new > > region, and the old region is no longer in the bitmap, so it's > > trivially gone. > > > > In the case of a list, you put the new region ahead of the old region > > so that you never actually get around to checking the old region. > > The following step still needs to run though: > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#garbage-collect-the-regions > > Let victim be the first hit region in list to have an empty set of > pixels and a zero child count, if any. > > If this was implemented with a bitmap, the only way to figure this out > is to walk the individual pixels (= expensive). This is garbage collection, it doesn't have to run often. When it _is_ run, it's actually pretty fast -- in the bitmap case, for example, you just need to walk the bitmap and for every pixel with a defined region mark the region as non-empty. This is O(N) with the size of the bitmap, but with a _very_ low constant factor (lower than recolourising a bitmap, say, which is something we expect authors to do in JS). > We should also not forget that a11y needs the bounding box of the hit > region which also means constantly walking of the pixels. Not "constantly". This kind of thing is trivially cacheable. It's also relatively simple to just check the pixels you're about to overwrite and note those regions as needing updating; when you _do_ update them, they can only have gotten smaller so you can just walk the edge of the bounding rectangle until you hit a pixel on each side. Plus, the bounding box doesn't have to be updated often -- the user isn't going to be jumping to the area every ten milliseconds or anything, and even if the user did, using a slightly out-of-date bounding box is fine (it'll just be bigger than strictly necessary). > > > It is also unintuitive because an author might expect that he could > > > remove the second region and still have the first region active. > > > > That would be inconsistent with how canvas works. Canvas is an > > immediate-mode API. If you draw on the canvas, and then clear it, you > > don't get back what was there before. > > What if an author doesn't clear it but just calls fillRect or is smart > and just invalidates/redraws portions of the canvas? Hit regions should > keep state, regardless of the canvas pixels. Those would just work, as far as I can tell. Do you have a concrete example? > > > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/thread.html#36556 > > > > > > It looks like that thread never came to a conclusion. > > > > Is there anything specifically that was raised in that thread that you > > think hasn't been responded to? > > Well, you had the last response but I don't think it came to a > conclusion :-) If people don't respond to my requests for clarification or if they don't disagree with the last thing I say, then that's a conclusion... > At the time, I was under the impression that we could mimic it with > paths but when I read the spec closer, the step that removes the region > pixels is too complex to implement and unintuitive for authors [2] As discussed earlier in this thread, it's easy to implement this using a list of paths, you just draw the cleared pixels as a new region on the top of your list. I don't see what's unintuitive here. > > > The arguments against using a bitmap presentation still stand: - it > > > will be too expensive to keep an actual copy of the canvas pixels in > > > memory to do hit testing > > > > It's actually pretty common to do exactly this. Note that you don't > > necessarily need a bitmap that has the same bit depth or pixel density > > as the visible bitmap. > > Where else does this happen? A Google search for "hit test bitmap" shows some examples, but unfortunately it's a hard topic to search for -- I kept running into examples of people trying to do collision detection with bitmaps instead! > Creating a canvas bitmap for constant reading will also be extremely > costly since so many implementations run canvas operations on the GPU. > I'm unsure if anyone supports a 8 bit backbuffer so at best, the hit > region bitmap is half the size. This is too expensive. Don't forget that this doesn't have to be a very high fidelity bitmap. It doesn't get any anti-aliasing, it has no alpha transparency, there's no bitmap drawing, it doesn't necessarily have to be full-density, either (it's unlikely that authors are going to have hit regions that are half a CSS pixel high, for instance). It's quite plausible to do all the work for this bitmap in software on the CPU, as far as I can tell. You can also use a hybrid approach, with the most recent regions added to a list, and the list regularly compressed down to a bitmap when the CPU load is low, or on a separate thread, such that the bitmap generation cost is a non-issue, while still not having to pay the cost of having all the regions in a long list, and while having the GC computations described earlier be reasonably straight-forward to compute (modulo inter-thread communication, which is always fun). > > > - if you have to mimic the behavior with paths, you need access to > > > expensive/difficult path manipulation algorithms > > > > The maths for determining if a region is contained in another region > > is pretty well understood at this point, as far as I can tell. > > It's still a hard problem. Looking at Firefox' and Apple's > implementation, I don't know how they could determine if a path is > contained within another path. Google has a library in development. We > looked at it 6 months ago and it had many issues. Our job is to implement these hard problems so that authors don't have to. > > > Hit regions should be redesigned so they work on the path geometry > > > as opposed to pixels. We already have the necessary code to do hit > > > testing on paths (see isPointInPath) > > > > isPointInPath() works on pixels just like hit regions works on pixels. > > No, this is not how it's implemented. > WebKit, Blink and Firefox use the geometry of the path. They don't use > pixels. That's an implementation detail. My point is that to an author, it's all pixels. The API takes in two coordinates, and gives you a boolean result. > > On Wed, 12 Mar 2014, Dirk Schulze wrote: > > > > > > In SVG we tried to avoid having hit testing based on pixel values > > > obviously for performance reasons. > > > > SVG is a retained-mode API, so naturally it has a different model. > > I don't see why. A browser draws the SVG DOM to a screen bitmap and then > does hit testing with fine paths. Canvas could do the exact same thing. If Canvas and SVG do "the exact same thing", then we should drop one. The whole point of <canvas> is to be an immediate-mode API that complements SVG. > People think of this API as populating a hit region OM. Why not go this > route? What people? > > > clearRect is currently defined as a subtraction mechanism for hit > > > regions [1]. > > > > > > It's unlikely that a UA will implement hit regions using pixels so > > > this would have to be done using path subtraction which is > > > expensive. > > > > I'm not sure why you think it's expensive. It's trivial to just add a > > rectangle to the front of the list of regions. > > That is true. This does mean that if there are a lot of small clearRect > calls, the list of regions could become very long. Sure. Same with if there are a lot of rectanglular hit regions added. The model above, where you start off with a list, but regularly flatten it to a bitmap, would lower the cost of maintaining such a list. > > > Why was this special behavior added to clearRect? > > > > Because it's the most obvious mechanism for authors. You clear a part > > of the canvas, naturally that part of the canvas no longer has > > regions. > > Why is that naturally? Because nothing is rendered there any more. > So, if an author clears an area there are no more regions in it, but if > he draws over it, they are still there? Right. Same as with regular drawing. If you clear it, it's gone. If you draw on top of it, it contributes (e.g. in the colour of anti-aliased lines, showing through where the content on top is transparent, etc). > Clipping also doesn't affect regions. Hm, good point. Fixed. > > On Tue, 4 Mar 2014, Rik Cabanier wrote: > > > > > > The spec implies-- > > > > The spec doesn't imply anything. It either requires something, or > > doesn't. If you ever find yourself reading between the lines, then > > there is either a spec bug, or you are reading something that the spec > > doesn't require. > > I know that. So, if I write "the spec implies", you can assume that I > believe that the spec is incomplete. I would rather you just said "the spec doesn't say whether..." rather than "the spec implies", since the latter has a very different meaning. On Sat, 15 Mar 2014, Dirk Schulze wrote: > > I would suggest a filter attribute that takes a list of filter > operations similar to the CSS Image filter function. Similar to > shadows[2], each drawing operation would be filtered. The API looks like > this: > > partial interface CanvasRenderingContext2D { > attribute DOMString filter; > } > > A filter DOMString could looks like: ?contrast(50%) blur(3px)? > > With the combination of grouping in canvas it would be possible to > group drawing operations and filter them together. > > Filter functions include a reference to a <filter> element and a > specification of SVG filters. I am unsure if a reference do an element > within a document can cause problems. If it does, we would just not > support SVG filter references. I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25243 On Mon, 17 Mar 2014, Justin Novosad wrote: > > Hmmm, I gave this a bit more thought... To apply the construction > algorithm in transformed space, the ellipse parameters (radiusX, > radiusY, rotation) would have to be transformed. Transforming the > parameters would be intractable under a projective transform (e.g. > perspective), but since we are limitted to affine transforms, it can be > done. Now, in the case of a non-invertible CTM, we would end up with > radiusX or radiusY or both equal to zero. And what happens when you > have that? Your arcTo just turned into lineTo(x1, y1). Tada! On Mon, 17 Mar 2014, Dirk Schulze wrote: > > Why does radiusX or radiusY need to be zero? Because you define it that > way for a non-invertible matrix? That makes sense for scale(0,0). What > about infinity or NaN? If Ian didn?t update the spec then this is still > undefined and therefore up to the UA to decide. How can it be infinity or NaN? (Recall that except where otherwise specified, for the 2D context interface, any method call with a numeric argument whose value is infinite or a NaN value must be ignored.) On Mon, 17 Mar 2014, Rik Cabanier wrote: > > I'm unsure if anyone has shipped that part of the spec. There's > certainly no interop... I am loathe to keep changing this kind of thing. We settled this part of the spec years ago. Let's not go back now. If we keep changing things like this, people will (rightly) complain that they can't trust the spec. > So, what we could say is: > - when drawing paths, ignore all calls if the matrix is non-invertible > (WebKit and Blink do this) > - when filling/stroking/clipping, ignore all calls if the matrix is > non-invertible (Firefox, WebKit and Blink do this) As far as I can tell, this is unnecessary. On Mon, 17 Mar 2014, Justin Novosad wrote: > > Yes, but there is still an issue that causes problems in Blink/WebKit: > because the canvas rendering context stores its path in local > (untransformed) space, whenever the CTM changes, the path needs to be > transformed to follow the new local spcae. This transform requires the CTM > to be invertible. So now webkit and blink have a bug that causes all > previously recorded parts of the current path to be discarded when the CTM > becomes non-invertible (even if it is only temporarily non-invertible, even > if the current path is not even touched while the matrix is > non-invertible). I have a fix in flight that fixes that problem in Blink by > storing the current path in transformed coordinates instead. I've had the > fix on the back burner pending the outcome of this thread. Indeed. It's possible to pick implementation strategies that just can't be compliant; we shouldn't change the spec every time any implementor happens to make that kind of mistake, IMHO. (Of course the better long-term solution here is the Path objects, which are transform-agnostic during building.) Just to be clear, we should support this because otherwise the results are just wrong. For example, here some browsers currently show a straight line in the default state, and this causes the animation to look ugly in the transition from the first frame to the secord frame (hover over the yellow to begin the transition): http://junkyard.damowmow.com/538 Contrast this to the equivalent code with the transforms explicitly multiplied into the coordinates: http://junkyard.damowmow.com/539 I don't see why we would want these to be different. From the author's perspective, they're identical. On Thu, 20 Mar 2014, Rik Cabanier wrote: > > It would be great if we could get clarification on this. I'm not sure what needs clarifying. The spec seems clear here. > Firefox and IE are conformant per the spec when it comes to drawing paths > but not fill/stroke/clip. Can you elaborate on how Firefox doesn't match the spec for stroke and clip? For fill, it does indeed seem to ignore the rule in the spec that says that fill solid colours are unaffected by the current transformation. It has a similar impact on renderings as the examples above: http://junkyard.damowmow.com/540 > Supporting this small edge case comes at a large cost in Firefox and > likely also IE. Can you elaborate on this cost? > Many APIs in canvas are running into this issue which results in lack of > interoperability. As far as I can tell, the spec is unambiguous. Certainly it does appear that browsers haven't yet converged on what the spec says, but that isn't unusual; it takes time for browsers to converge, especially for edge cases like this where there's not much pressure (since authors tend to just work around the bugs). On Wed, 19 Mar 2014, Dirk Schulze wrote: > > I just looked at the definition of Path.addPath[1]: > > void addPath(Path path, SVGMatrix? transformation); > > SVGMatrix is nullable but can not be omitted all together. Why isn?t it > optional as well? I think it should be optional [...] That seems reasonable. Done. On Wed, 19 Mar 2014, Rik Cabanier wrote: > > [context . currentTransform] > > As currently specified, this must return a live SVGMatrix object, > meaning that as you change the CTM on the 2d context, your reference to > the SVGMatrix should change as well. > > It's unlikely that you actually want this... Why? See Chris' original proposal here: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Mar/0269.html I would be reluctant to change this to a different design without their input. On Fri, 21 Mar 2014, Joe Gregorio wrote: > On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > > > I just looked at the definition of Path.addPath[1]: > > > > void addPath(Path path, SVGMatrix? transformation); > > > > SVGMatrix is nullable but can not be omitted all together. Why isn?t it > > optional as well? I think it should be optional, especially because > > creating an SVGMatrix at the moment means writing: > > > > var matrix = document.createElementNS('http://www.w3.org/2000/svg > > ','svg').createSVGMatrix(); > > Agreed, that's painful, +1 for making it optional. Just so we're clear, even when it wasn't optional, you didn't have to do any of that. You can just pass null. (It's still not optional for some of the other methods where it's in the middle of the arguments and making it optional doesn't make much sense.) On Sat, 22 Mar 2014, Dirk Schulze wrote: > > Does some one think it would be necessary to make SVGMatrix nullable > (optional SVGMatrix?)? I think it would be superfluous. It's needed for consistency with the other methods. On Thu, 20 Mar 2014, Rik Cabanier wrote: > > addPath is currently defined on the Path2D object. [1] > Is there a reason why it's not defined on CanvasPathMethods instead? > That way this method is available on the 2d contest so you can append a > path to the current graphics state. What's the use case? On Thu, 20 Mar 2014, Dirk Schulze wrote: > > I am supportive for this idea! I agree that this would solve one of the > reasons why I came up with currentPath for WebKit in the first place. Can you elaborate on the reason for this? On Thu, 20 Mar 2014, Justin Novosad wrote: > > This would apply the CTM to the incoming path, correct? I am a little > bit concerned that this API could end up being used in ways that would > cancel some of the performance benefits (internal caching opportunities) > of Path2D objects. Right, that's why it's not currently on CanvasPathMethods. The idea is to make a clean break from the world where the transforms affect the building of the path. On Thu, 20 Mar 2014, Dirk Schulze wrote: > > Where is the difference to fill(Path2D), stroke(Path2D) and > clip(Path2D)? The path will always need to be transformed to the CTM. > Graphic libraries usually do this already for you. The addPath() > proposal is not different to that. The difference is that there, you only have one path with one transform, not different parts of the path built with different transforms. On Thu, 20 Mar 2014, Justin Novosad wrote: > > The recently added currentTransform attribute on > CanvasRenderingContext2D gives shared access to the rendering context's > transform. By "shared", I mean: > > a) this code modifies the CTM: > var matrix = context.currentTransform; > matrix.a = 2; > > b) In this code, the second line modifies matrix: > var matrix = context.currentTransform; > context.scale(2, 2); > > This behavior is probably not what most developers would expect. It's the behaviour that was requested by the pdf.js developers. :-) On Thu, 20 Mar 2014, Simon Sarris wrote: > > FF (at least Aurora/Nightlies) has for some time had mozCurrentTransform > (and mozCurrentTransformInverse), which return an Array (so not > spec-compliant, since spec wants SVGMatrix). It is not shared, so it > does not do what your a) and b) examples do. > > I agree that changing it to a getter method would be better, it would be > more intuitive and clear for developers. On Mon, 24 Mar 2014, Hwang, Dongseong wrote: > > Looking over this thread, we make a consensus not to expose > currentTransform attribute. Consensus is not how we decide things in the WHATWG. It's based on the strength of arguments. So far, it seems the arguments either way are about equal. On the one hand you have a developer asking for the current API. On the other hand you have implementors saying that the current API is bad for developers. What we need to make more progress, I think, is more concrete arguments, for example sample code that uses both APIs so we can see how authors would experience the two APIs in the real world. On Mon, 24 Mar 2014, Simon Sarris wrote: > > I think using "Current" in the naming convention is silly. The transform > just as much a part of state as lineWidth/etc, but nobody would propose > naming lineWidth something like currentLineWidth! There's no way to get > a *non-current* transformation matrix (or lineWidth), so I think the > distinction is unnecessary. > > CTM only seems like a good idea if we're worried that the name is too > long, but since "Current" is redundant/extraneous, I don't think an > initialism is worth the added layer of confusion. These are solid arguments if we agree that we should change the spec. On Sun, 23 Mar 2014, Dirk Schulze wrote: > > 1) I noticed that createImageData() is explicit that it represent a > transparent black rectangle. The constructor for ImageData is not that > explicit. Fixed. > 2) The last step of the 2nd constructor that takes an Uint8ClampedArray > says: " ? Return a new ImageData object whose width is sw, whose height > is height, and whose data is source.? > > Is data a reference to the original source or a copy of source? For the > former, there might be two ImageData objects referencing the same > ByteArray. How would that be useful? The steps say that the data is the Uint8ClampedArray "source". I've added a note making the fact that it's not a copy more explicit. On Mon, 24 Mar 2014, J?rg Lehni wrote: > > Non-scaling Strokes in Canvas. > > The request has come up multiple times on the paper.js mailing list [1], > and we will emulate this in JavaScript. > > But since this will involve baking the CTM into the path to be drawn, > and setting the CTM to the identity matrix, I was wondering if this is > something worth supporting natively for the obvious reason of improved > performance? You can do this with the new Path2D API, right? On Tue, 25 Mar 2014, Dirk Schulze wrote: > > [...] currentTransform [...] > what should be returned for a CTM that is singular (not invertible)? Even when the transform is not invertible, it's precise value is still well-defined, no? > In WebKit we do not track all transformations of the CTM that caused a > singular matrix or are following a transformation that would have caused > a singular matrix. > > Example: > > ctx.scale(0,0); > ct.translate(10,10); The matrix should be 0,0,0,0,0,0 here. It starts as 1 0 0 0 1 0 0 0 1 Then you apply a scale transform to 0,0: 1 0 0 0 0 0 0 0 0 0 1 0 x 0 0 0 = 0 0 0 0 0 1 0 0 1 0 0 1 Then you post-multiply that by the translation by 10,10: 1 0 0 0 0 0 1 0 10 0 0 0 0 1 0 x 0 0 0 x 0 1 10 = 0 0 0 0 0 1 0 0 1 0 0 1 0 0 1 ...and that's the matrix you should return. > In webkit we would not apply the transformation scale(0,0) and mark the > CTM as not-invertible instead. I do not believe this is an implementation strategy that can lead to a conforming implementation. Note that this is the same as what you would get if you did: var a = new SVGMatrix(1,0,0,1,0,0); // assuming this interface gets a constructor, anyway a = a.scale(0,0); a = a.translate(10,10); ...so this is not unique to the canvas API. On Tue, 25 Mar 2014, Justin Novosad wrote: > > I prepared a code change to that effect, but then there was talk of > changing the spec to skip path primitives when the CTM is not > invertible, which I think is a good idea. It would avoid a lot of > needless hoop jumping on the implementation side for supporting weird > edge cases that have little practical usefulness. I'm not sure I agree that they have little practical usefulness. Zeros often occur at the edges of transitions, and if we changed the spec then these transitions would require all the special-case code to go in author code instead of implementor code. On Sun, 30 Mar 2014, Dirk Schulze wrote: > > Canvas let you set alignment baselines with the textBaseline attribute > [1]. > > One of the baseline values is ?middle?. The description of the ?middle? > baseline seems to be in conflict with the definition for the > alignment-baseline property in CSS[2]. > > Canvas: The middle of the em square > CSS: [..] it may be computed using 1/2 the "x-height? > > What Canvas uses as middle is described as ?center? in CSS. Is there a > way that we can change the naming and/or definition of ?middle? in > Canvas? This seems like something that's too late to change. (I think using "middle" for what is between "top" and "bottom" makes eminent sense, though, so it doesn't seem like that big a problem.) On Mon, 31 Mar 2014, Justin Novosad wrote: > > Wow, that is confusing. How can this be fixed without breaking existing > web content? Are browsers currently compliant with the canvas spec, or > do they implement the CSS definition of middle? Looks like everyone does it per the canvas spec: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2924 The CSS 'vertical-align' property works per the CSS spec on the browsers I tested, too, FWIW: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2925 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Tue Apr 8 09:07:21 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 09:07:21 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDRtCREBBG5koWfR-PDv_=dJejfA-WOniSwygSD4YhhWg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > So this is not how most implementations currently have it defined. > > > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > > definitely do store the path in user coordinates. The spec currently > > > > says otherwise [1] though. > > > > > > I'm not sure what you're referring to here. > > > > All graphics backends for canvas that I can inspect, don't apply the CTM > > to the current path when you call a painting operator. Instead, the path > > is passed as segments in the current CTM and the graphics library will > > apply the transform to the segments. > > Right. That's what the spec says too, for the current default path. No, the spec says this: For CanvasRenderingContext2D objects, the points passed to the methods, and the resulting lines added to current default path by these methods, must be transformed according to the current transformation matrix before being added to the path. > This is the confusing behaviour to which I was referring. The "Path" API > (or > Path2D or whatever we call it) doesn't have this problem. > That is correct. The Path2D object is in user space and can be passed directly to the graphics API (along with the CTM). > > > > Another use case is to allow authors to quickly migrate to hit > regions. > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); > > > > ... // lots of complex drawing operation for a control > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); > > > > > > > > > > > > To migrate that to a region (with my proposed shape interface [1]): > > > > > > > > var s = new Shape(); > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > > Shape(ctx.currentPath)); > > > > ... > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke > calls? > > > > That does not work as the second addHitRegion will remove the control and > > id from the first one. > > The 'add' operation is needed to get a union of the region shapes. > > Just use two different IDs with two different addHitRegion() calls. That's > a lot less complicated than having a whole new API. > That doesn't work if you want to have the same control for the 2 areas, from the spec for addHitRegion: If there is a previous region with this control, remove it from the scratch bitmap's hit region list; then, if it had a parent region, decrement that hit region's child count by one. Even if you don't use the control, it would be strange to have 2 separate hit regions for something that represents 1 object. > > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > ... > > > > copy, and would help memory consummation and performance. > > > > > > I don't really understand the use case here. > > > > Jurg was just talking about an optimization (so you don't have to make > > an internal copy) > > Sure, but that doesn't answer the question of what the use case is. > >From my recent experiments with porting canvg ( https://code.google.com/p/canvg/) to use Path2D, they have a routine that continually plays a path into the context which is called from a routine that does the fill, clip or stroke. Because that routine can't simply set the current path, a lot more changes were needed. Some pseudocode that shows the added complexity, without currentPath: function drawpath() { if(Path2DSupported) { return myPath; } else for(...) { ctx.moveTo/lineTo/... } } function fillpath() { var p = drawpath(); if(p) ctx.fill(p); else ctx.fill(); } with currentPath: function drawpath() { if(Path2DSupported) { // only 2 extra lines of code ctx.currentPath = myPath; } else for(...) { ctx.moveTo/lineTo/... } function fillpath() { drawpath(); ctx.fill(); } > On Wed, 12 Mar 2014, Rik Cabanier wrote: > > > > > > > > > > You can do unions and so forth with just paths, no need for > > > > > regions. > > > > > > > > How would you do a union with paths? If you mean that you can just > > > > aggregate the segments, sure but that doesn't seem very useful. > > > > > > You say, here are some paths, here are some fill rules, here are some > > > operations you should perform, now give me back a path that describes > > > the result given a particular fill rule. > > > > I think you're collapsing a couple of different concepts here: > > > > path + fillrule -> shape > > union of shapes -> shape > > shape can be converted to a path > > I'm saying "shape" is an unnecessary primitive. You can do it all with > paths. > > union of (path + fillrule)s -> path > No, that makes no sense. What would you get when combining a path with a fillrule and no fillrule? > > > A shape is just a path with a fill rule, essentially. > > > > So, a path can now have a fillrule? Sorry, that makes no sense. > > I'm saying a shape is just the combination of a fill rule and a path. The > path is just a path, the fill rule is just a fill rule. > After applying a fillrule, there is no longer a path. You can *convert* it back to a path that describes the outline of the shape if you want, but that is something different. The way you've defined things now, you can apply another fill rule on a path with a fill rule. What would the result of that be? > > > Anything you can do > > > with one you can do with the other. > > > > You can't add segments from one shape to another as shapes represent > > regions. > > Likewise, you can't union, intersect or xor path segments. > > But you can union, intersect, or xor lists of pairs of paths and > fillrules. > would you start throwing when doing these operations on paths without fill rules? > ... > > > > "Wrong" meaning: > > if the author has a bunch of geometry and wants to put it in 1 path > object > > so he can just execute 1 fill operation, he might be under the impression > > that "adding" the geometry will just work. > > Well, sure, an author might be under any number of false impressions. > > The API has a way for a bunch of paths to be merged with a single fillrule > to generate a new path with no crossing subpaths (which is also fillrule > agnostic), essentially giving you the union of the shapes represented by > those paths interpreted with that fillrule. > Is this the API you're referring to? path = new Path2D(paths [, fillRule ] ) The first argument could point to paths that need different winding rules so this won't work. What if one of the paths already had a fill rule? This doesn't seem implementable/stable. > There are very few use cases where you want to add partial path segments > > together but I agree that there are some cases that it's useful to have. > > I disagree that there few such cases. Pretty much any time you create a > path, you are adding partial path segments together. Whether you do so > using one Path object all at once or multiple Path objects that you later > add together is just a matter of programming style. > It's the multiple path objects use case that is unclear to me. Is there any tool/library that does this? Looking at Adobe's graphics applications, there isn't anything like it. Looking at graphics APIs, I don't see any calls that combine paths directly. hmm, it seems the spec has changed. It didn't used to start with "Create a new path that describes the edge of the areas" With the new wording, the last sentence should be updated: Subpaths in the newly created path must wind clockwise, regardless of the direction of paths in path. Since you now create 'holes', the separate paths need to be reoriented like you specify in other parts. > > > > > We seem to be going around in circles. We're in agreement that > > > > > eventually we should add APIs for combining paths such that we get > > > > > the equivalent of the union of their fill regions. I agree that > > > > > converting text into paths is non-trivial (lots of stuff browsers > > > > > do is non-trivial, that's kind of the point -- if it was trivial, > > > > > we could leave it for authors). But I don't see how we get from > > > > > there to you wanting the existing APIs removed. > > > > > > > > I want them removed because they will most likely not behave in the > > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > > expect that there is 'interference' between them. > > > > > > I don't see why not. It's exactly what happens today if you were to > > > just add the same path creation statements together into the current > > > default path and fill or stroke that. > > > > Sure but who does that? > > It's how all paths are built, as far as I can tell. I don't see how else > you could build a path that consists of more than one line. > > addPath() is useful for shifting a path according to a transform. > Why not just transform() then? addPathByStrokingPath() is for creating a stroked path. > addText() is for writing text. > > I don't see how removing any of them is a win. > Yes, they are useful. The issue is that they are not implementable as currently specified. > > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > ... > > > > > > > > How would you get a point? the width is scaled to 0. > > > > > > That's how you get a point -- scale(0,0) essentially reverts > > > everything to a zero dimensional point. > > > > OK, but the width of the point is also transformed to 0 so you get > > nothing. > > Points are always zero-width, by definition. > You can still stroke it though and get a point of the strokewidth. > > We've gone over this several times now. > > The APIs that you define, have use cases and I agree with them. > > However the way you defined those APIs does not make sense and will not > > give the result that authors want. > > The way to make this point would be to start from the use case, describe > the desired effect, show the "obvious" way to achieve this using the API, > and then demonstrate how it doesn't match the desired effect. > The obvious way is to go with Shape2D. It's not because I invented it; many advanced graphics APIs came offer this (including D2D and skia) > ... > > So, it's not realistic to add this to the Path2D object. > > I don't really see why it's unrealistic. In most cases, the user agent > doesn't actually have to do any work -- e.g. if all that you're doing is > merging two paths so that you can fill them simultaneously later, the UA > can just keep the two paths as is and, when necessary, fill them. > > For cases where you really want to have this effect -- e.g. when you want > to get the outline of the dashed outline of text -- then I don't really > see any way to work around it. > That is true. That is why I proposed to make the interface more limited for now until there is a time that this functionality is available. >From Ian Hickson: > I don't think the spec should be written with a particular > implementation in mind, nor should it dictate one. I agree it shouldn't (and doesn't) dictate one. But it's crazy to not consider implementations at all when writing a spec. That way lies madness like requiring O(N^2) algorithms and solving the halting problem and all kinds of other disasters (all of which I've seen in real proposals). > > The reason for that is that even though a UA could emulate the union by > > doing multiple fill operations, Path2D allows you to stroke another path > > object. At that point, you really have to do planarization. By defining > > a Shape2D object and not allowing it to be stroked, we can work around > > this. > > Sure, by limiting the feature set dramatically we can avoid the cases > where you have to do the hard work, but we also lose a bunch of features. > For now. They can be added later. Until then, this is confusing implementors. > > > I don't think the arguments for removing these are compelling. The > > > problems with the APIs have been addressed (e.g. there's no ambiguity > > > in the case of overlapping text), the use cases are clear (e.g. > > > drawing text around an arc or drawing a label along a line graph's > > > line), and the API now supports the constructs to do unions of fill > > > regions. > > > > Where is the union of fill regions specified? All I see is segments > > aggregation. > > One of the Path constructors takes an array of paths and a fill rule. > See above. > > > > No one has implemented them and they are confusing the browser > > > > vendors. > > > > > > I don't think they're confusing anyone. > > > > The blink people were looking at adding this until they thought it > > through and realized that it wouldn't work. > > Realised what wouldn't work? As far as I'm aware, there's nothing that > wouldn't work. > See this thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/168925.html I think you already addressed some of the concerns. Doing the planarization is now the problem so we can't implement this. > > > > Until we have support for shapes, the output of these methods won't > > > > be stable. > > > > > > These methods have been very stable. They have barely changed since > > > they were added, except for some minor tweaks to fix bugs. > > > > How can you make that statement? No one has implemented them yet. > > What do you mean by "stable"? > > I assumed you meant "hasn't been changing a lot". The spec hasn't been > changing a lot, so it seems pretty stable. > You've been making a lot of changes lately so this not quite true. Because you wrote it a long time ago and nobody looked at it until now, doesn't mean that it is stable. From junov at google.com Tue Apr 8 12:25:04 2014 From: junov at google.com (Justin Novosad) Date: Tue, 8 Apr 2014 15:25:04 -0400 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> On Mon, Apr 7, 2014 at 6:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > For example, there is no locale for font family resolution > > I'm not clear on what you mean by "locale" here. What is the locale that a > displayed <canvas> in a Document in a browsing context has, that a > non-displayed <canvas> outside a Document and without a browsing context > does not have? > I am not sure exactly how this relates to the specification, but when reading the code in Blink, I saw that font family resolution goes through different paths if the view has a Korean, Chinese or Japanese locale. Some OSes allow you to have different locales on a per window basis, so you need to have a view (i.e. a browsing context) associated with the Document in order to resolve this. > > and it is not possible to resolve font sizes in physical length units > > unless the document is associated with a view. > > Why not? The canvas has a pixel density (currently always 1:1), no? > 1:1 is not a physical pixel density. To resolve a font size that is specified in physical units (e.g. millimeters or inches) you need something like a DPI value, which requires information about the output device. > > > My 2 cents: specifying fallback behaviors for all use cases that are > > context dependent could be tedious and I have yet to see a real-world > > use case that requires being able to paint a canvas in a frame-less > > document. Therefore, I think the spec should clearly state <canvas> > > elements that are in a document without a browsing context are unusable. > > Not sure what the exact behavior should be though. Should an exception > > be thrown upon trying to use the rendering context? Perhaps canvas draws > > should fail silently, and using the canvas as an image source should > > give transparent black pixels? > > As far as I can tell, this is all already specified, and it just gets > treated like a normal canvas. > Agreed. The fallback behavior is specified. But is it good enough? There will be discrepancies, sometimes large ones, between text rendered with and without a browsing context. On Wed, 5 Mar 2014, Rik Cabanier wrote: > > > > Testing all browsers (except IE since > > document.implementation.createHTMLDocument() doesn't work) they seem to > > handle canvas contexts with no browsing context except when you use > > text. Chrome crashes, firefox throws an exception and Safari draws the > > text with a very small scale > > I don't really understand why this is problematic in practice. What does a > browsing context provide that is needed for rendering text that a user > agent couldn't fake for itself in other contexts? We're definitely going > to need text in worker canvases. > It is because the browsing context serves as a bridge between the document and the OS/window manager/display device. Therefore some of the system configuration info that comes into play in font style resolution and text rendering is not accessible when the document is not associated with a browsing context. For example to know which locale to use, the document needs to be linked to a window; to know the display density (dpi) we need to know which display device will be used for displaying the document; to use subpixel text anti-aliasing, we need to know the display device's LCD configuration; etc. If we fake this information by using fallbacks and defaults, we may end up with text that looks different when rendering in a Worker or into a Document without a browsing context. If we want everything to look the same, perhaps the spec should specify how to get to a browsing context that can be used for retrieving display settings. For example, if the current document has no browsing context, use the settings from the browsing context of the global 'document' object. That would probably match the developer's intent almost all the time. > > On Fri, 14 Mar 2014, Justin Novosad wrote: > > On Fri, Mar 14, 2014 at 2:29 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > If the bug is that Chrome resamples the image in an ugly way, then > > > that's a bug with Chrome. As the bug says, browsers are allowed to > > > pick whatever algorithm they want -- it's a quality-of-implementation > > > issue. But if the result is ugly, that's a low quality implementation. > > > > Yes, and if we fixed it to make it prettier, people would complain about > > a performance regression. It is impossible to make everyone happy right > > now. Would be nice to have some kind of speed versus quality hint. > > The problem with a hint is that it will be set incorrectly, and so instead > of having something that's mostly pretty but mostly fast for everyone, > you'd end up with something that's slow on sites that need things to be > fast, and things that are ugly on sites that need things to be pretty. > > In general I think it is very unwise for us to design APIs with hints that > have subtle effects on developer machines but that can cripple performance > on low-end devices. > The point of it being a hint is that the UA is free to disregarded it precisely in that kind of situation (e.g. fallback to fastest filtering on a low-end device) > Instead, we should use adaptive algorithms, for example always using the > prettiest algorithms unless we find that frame rate is suffering, and then > stepping down to faster algorithms. > Such an adaptive algorithm implies making some kind of weighted decision to chose a reasonable compromise between quality and performance. Sounds like the perfect place to use a hint. > > > On Mon, 17 Mar 2014, Justin Novosad wrote: > > > > Yes, but there is still an issue that causes problems in Blink/WebKit: > > because the canvas rendering context stores its path in local > > (untransformed) space, whenever the CTM changes, the path needs to be > > transformed to follow the new local spcae. This transform requires the > CTM > > to be invertible. So now webkit and blink have a bug that causes all > > previously recorded parts of the current path to be discarded when the > CTM > > becomes non-invertible (even if it is only temporarily non-invertible, > even > > if the current path is not even touched while the matrix is > > non-invertible). I have a fix in flight that fixes that problem in Blink > by > > storing the current path in transformed coordinates instead. I've had the > > fix on the back burner pending the outcome of this thread. > > Indeed. It's possible to pick implementation strategies that just can't be > compliant; we shouldn't change the spec every time any implementor happens > to make that kind of mistake, IMHO. > > (Of course the better long-term solution here is the Path objects, which > are transform-agnostic during building.) > > > Just to be clear, we should support this because otherwise the results are > just wrong. For example, here some browsers currently show a straight line > in the default state, and this causes the animation to look ugly in the > transition from the first frame to the secord frame (hover over the yellow > to begin the transition): > > http://junkyard.damowmow.com/538 > > Contrast this to the equivalent code with the transforms explicitly > multiplied into the coordinates: > > http://junkyard.damowmow.com/539 > > I don't see why we would want these to be different. From the author's > perspective, they're identical. If we stick to that, there are still some behaviors that need to resolved. One issue that comes to mind is what happens if stroke or fill are called while the CTM is non-invertible? To be more precise, how would the styles be mapped? If the fillStyle is collapsed to a point, does that mean the path gets filled in transparent black? If we go down this road, we will likely uncover more questions of this nature. > On Tue, 25 Mar 2014, Justin Novosad wrote: > > > > I prepared a code change to that effect, but then there was talk of > > changing the spec to skip path primitives when the CTM is not > > invertible, which I think is a good idea. It would avoid a lot of > > needless hoop jumping on the implementation side for supporting weird > > edge cases that have little practical usefulness. > > I'm not sure I agree that they have little practical usefulness. Zeros > often occur at the edges of transitions, and if we changed the spec then > these transitions would require all the special-case code to go in author > code instead of implementor code. > Yes, I think that may be the strongest argument so far in this discussion. The examples you provided earlier illustrate it well. I would like to hear what Rik and Dirk think about this now. From jackalmage at gmail.com Tue Apr 8 13:54:39 2014 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Tue, 8 Apr 2014 13:54:39 -0700 Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> Message-ID: <CAAWBYDCAr4C-fSYx9a_y=D3aZe0_9e_UOLo5yUJrk9TXs46Meg@mail.gmail.com> On Tue, Apr 8, 2014 at 5:25 AM, Steve Faulkner <faulkner.steve at gmail.com> wrote: > avoiding unnecessary recourse to web component use is a reasonable and > expected goal - built in vs bolt on accessibility is better. Having to use > a web component to overcome the inability to make a html control usable > without relying on CSS and Js and ARIA is unfortunate, and as you said > yesterday I still don't understand. Do you think that what Hixie is saying (about clicking on non-interactive text in <summary> toggling the <details>) is wrong? The behavior that Hixie describes is roughly what implementations do today. In Blink, clicking on any bare text in the <summary> toggles the <details>, while clicking on an <input> does not. However, Blink current behavior with <label> is different - it basically ignores the presence of the <label>, as far as I can tell, and still toggles the <details> even if the <label> is redirecting the click to an <input>. I would strongly object to any suggestion that <summary> should only toggle <details> when you click on the disclosure triangle, unless you add some additional markup like <label>. That would be terrible UI. ~TJ From cabanier at gmail.com Tue Apr 8 15:10:09 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 15:10:09 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> Message-ID: <CAGN7qDDJKmx1T9_8cu--T7mAUy2uucTde+S6atnJTBe7baBQRg@mail.gmail.com> On Tue, Apr 8, 2014 at 12:25 PM, Justin Novosad <junov at google.com> wrote: > > > > > On Mon, 17 Mar 2014, Justin Novosad wrote: > > > > > > Yes, but there is still an issue that causes problems in Blink/WebKit: > > > because the canvas rendering context stores its path in local > > > (untransformed) space, whenever the CTM changes, the path needs to be > > > transformed to follow the new local spcae. This transform requires the > > CTM > > > to be invertible. So now webkit and blink have a bug that causes all > > > previously recorded parts of the current path to be discarded when the > > CTM > > > becomes non-invertible (even if it is only temporarily non-invertible, > > even > > > if the current path is not even touched while the matrix is > > > non-invertible). I have a fix in flight that fixes that problem in > Blink > > by > > > storing the current path in transformed coordinates instead. I've had > the > > > fix on the back burner pending the outcome of this thread. > > > > Indeed. It's possible to pick implementation strategies that just can't > be > > compliant; we shouldn't change the spec every time any implementor > happens > > to make that kind of mistake, IMHO. > > > > (Of course the better long-term solution here is the Path objects, which > > are transform-agnostic during building.) > > > > > > Just to be clear, we should support this because otherwise the results > are > > just wrong. For example, here some browsers currently show a straight > line > > in the default state, and this causes the animation to look ugly in the > > transition from the first frame to the secord frame (hover over the > yellow > > to begin the transition): > > > > http://junkyard.damowmow.com/538 > > > > Contrast this to the equivalent code with the transforms explicitly > > multiplied into the coordinates: > > > > http://junkyard.damowmow.com/539 > > > > I don't see why we would want these to be different. From the author's > > perspective, they're identical. > These examples are pretty far fetched. How many time do people change the CTM in the middle of a drawing operation and not change the geometry? If we stick to that, there are still some behaviors that need to resolved. > One issue that comes to mind is what happens if stroke or fill are called > while the CTM is non-invertible? To be more precise, how would the styles > be mapped? If the fillStyle is collapsed to a point, does that mean the > path gets filled in transparent black? If we go down this road, we will > likely uncover more questions of this nature. Indeed > > On Tue, 25 Mar 2014, Justin Novosad wrote: > > > > > > I prepared a code change to that effect, but then there was talk of > > > changing the spec to skip path primitives when the CTM is not > > > invertible, which I think is a good idea. It would avoid a lot of > > > needless hoop jumping on the implementation side for supporting weird > > > edge cases that have little practical usefulness. > > > > I'm not sure I agree that they have little practical usefulness. Zeros > > often occur at the edges of transitions, and if we changed the spec then > > these transitions would require all the special-case code to go in author > > code instead of implementor code. > > > > Yes, I think that may be the strongest argument so far in this discussion. > The examples you provided earlier illustrate it well. > I would like to hear what Rik and Dirk think about this now. > I looked at the webkit and chrome bug databases and I haven't found anyone who complained about their current behavior. Implementing this consistently will either add a bunch of special case code to deal with non-singular matrices or double (triple?) conversion of all segment points like firefox does. After that, fill, stroke and clip will still not work when there's a non-invertible matrix. I do not think it's worth the effort... From cabanier at gmail.com Tue Apr 8 16:50:48 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 16:50:48 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > ... > > > > > Stroking will be completely wrong too, because joins and end caps > > > > are drawn separately, so they would be stroked as separate paths. > > > > This will not give you the effect of a double-stroked path. > > > > > > I don't understand why you think joins and end caps are drawn > > > separately. That is not what the spec requires. > > > > Sure it does, for instance from > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path > > : > > > > The round value means that a filled arc connecting the two > > aforementioned corners of the join, abutting (and not overlapping) the > > aforementioned triangle, with the diameter equal to the line width and > > the origin at the point of the join, must be added at joins. > > > > If you mean, "drawn with a separate fill call", yes that is true. > > What I meant was that they are drawn as a separate closed path that will > > interact with other paths as soon as there are different winding rules or > > "holes". > > The word "filled" is a bit misleading here (I've removed it), but I don't > see why that led you to the conclusion you reached. The step in question > begins with "Create a new path that describes the edge of the areas that > would be covered if a straight line of length equal to the styles > lineWidth was swept along each path in path while being kept at an angle > such that the line is orthogonal to the path being swept, replacing each > point with the end cap necessary to satisfy the styles lineCap attribute > as described previously and elaborated below, and replacing each join with > the join necessary to satisfy the styles lineJoin type, as defined below", > which seems pretty unambiguous. > Thinking about this some more, it looks like you came around and specified stroking like I requested from the beginning. For instance, http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0354.html or http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0213.html Now that you made that change, 'addPathByStrokingPath' is specified correctly. I still don't know how it could be implemented though... (It *could* as a shape but not as a path) From cabanier at gmail.com Tue Apr 8 17:17:39 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 17:17:39 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> Message-ID: <CAGN7qDBfO_7katfwHTX+CT_HgRcEuq3AL7544y+YTJU54HbahQ@mail.gmail.com> On Tue, Apr 8, 2014 at 4:50 PM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > >> ... >> >> >> > > > Stroking will be completely wrong too, because joins and end caps >> > > > are drawn separately, so they would be stroked as separate paths. >> > > > This will not give you the effect of a double-stroked path. >> > > >> > > I don't understand why you think joins and end caps are drawn >> > > separately. That is not what the spec requires. >> > >> > Sure it does, for instance from >> > >> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path >> > : >> > >> > The round value means that a filled arc connecting the two >> > aforementioned corners of the join, abutting (and not overlapping) the >> > aforementioned triangle, with the diameter equal to the line width and >> > the origin at the point of the join, must be added at joins. >> > >> > If you mean, "drawn with a separate fill call", yes that is true. >> > What I meant was that they are drawn as a separate closed path that will >> > interact with other paths as soon as there are different winding rules >> or >> > "holes". >> >> The word "filled" is a bit misleading here (I've removed it), but I don't >> see why that led you to the conclusion you reached. The step in question >> begins with "Create a new path that describes the edge of the areas that >> would be covered if a straight line of length equal to the styles >> lineWidth was swept along each path in path while being kept at an angle >> such that the line is orthogonal to the path being swept, replacing each >> point with the end cap necessary to satisfy the styles lineCap attribute >> as described previously and elaborated below, and replacing each join with >> the join necessary to satisfy the styles lineJoin type, as defined below", >> which seems pretty unambiguous. >> > > Thinking about this some more, it looks like you came around and specified > stroking like I requested from the beginning. > For instance, > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0354.html > or > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0213.html > Now that you made that change, 'addPathByStrokingPath' is specified > correctly. I still don't know how it could be implemented though... (It > *could* as a shape but not as a path) > The spec is still confusingly written and could be misinterpreted: Create a new path that describes the edge of the areas that would be covered if a straight line of length equal to the styles lineWidth was swept along each subpath in path while being kept at an angle such that the line is orthogonal to the path being swept, replacing each point with the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, and replacing each join with the join necessary to satisfy the styles lineJoin type, as defined below. Maybe could become: Create a new path that describes the edge of the coverage of the following areas: - a straight line of length equal to the styles lineWidth that was swept along each subpath in path while being kept at an angle such that the line is orthogonal to the path being swept, - the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, - the join with the join necessary to satisfy the styles lineJoin type, as defined below. From junov at google.com Wed Apr 9 07:14:42 2014 From: junov at google.com (Justin Novosad) Date: Wed, 9 Apr 2014 10:14:42 -0400 Subject: [whatwg] <canvas> feedback In-Reply-To: <CAGN7qDDJKmx1T9_8cu--T7mAUy2uucTde+S6atnJTBe7baBQRg@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> <CAGN7qDDJKmx1T9_8cu--T7mAUy2uucTde+S6atnJTBe7baBQRg@mail.gmail.com> Message-ID: <CABpaAqSfmKu2mkeZg39Nn_OeOaSWdW0ZwvGuhq0+jiYWq_v0PQ@mail.gmail.com> On Tue, Apr 8, 2014 at 6:10 PM, Rik Cabanier <cabanier at gmail.com> wrote: > > > On Tue, 25 Mar 2014, Justin Novosad wrote: >> > > >> > > I prepared a code change to that effect, but then there was talk of >> > > changing the spec to skip path primitives when the CTM is not >> > > invertible, which I think is a good idea. It would avoid a lot of >> > > needless hoop jumping on the implementation side for supporting weird >> > > edge cases that have little practical usefulness. >> > >> > I'm not sure I agree that they have little practical usefulness. Zeros >> > often occur at the edges of transitions, and if we changed the spec then >> > these transitions would require all the special-case code to go in >> author >> > code instead of implementor code. >> > >> >> Yes, I think that may be the strongest argument so far in this discussion. >> The examples you provided earlier illustrate it well. >> I would like to hear what Rik and Dirk think about this now. >> > > I looked at the webkit and chrome bug databases and I haven't found anyone > who complained about their current behavior. > Implementing this consistently will either add a bunch of special case > code to deal with non-singular matrices or double (triple?) conversion of > all segment points like firefox does. After that, fill, stroke and clip > will still not work when there's a non-invertible matrix. > > I do not think it's worth the effort... > If I did not feel bad about using laziness as an argument, I might agree. :-) From fantasai.lists at inkedblade.net Wed Apr 9 13:48:52 2014 From: fantasai.lists at inkedblade.net (fantasai) Date: Wed, 09 Apr 2014 13:48:52 -0700 Subject: [whatwg] [CSSWG][css-scoping] CSS Scoping FPWD Published Message-ID: <5345B234.2020603@inkedblade.net> The CSS WG has published a First Public Working Draft of the CSS Scoping Module Level 1: http://www.w3.org/TR/css-scoping-1/ This specification defines various scoping/encapsulation mechanisms for CSS, including scoped styles and the @scope rule, Shadow DOM selectors, and page/region-based styling. It is an early-stage working draft, and the features described therein are not well-baked and may change dramatically or be removed. The CSSWG encourages comments on both design and details of these features. Please send any comments to this mailing list, <www-style at w3.org>, and please, prefix the subject line with [css-scoping] (as I did on this message). For the CSS WG, ~fantasai From faulkner.steve at gmail.com Thu Apr 10 08:49:55 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Thu, 10 Apr 2014 16:49:55 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <CAAWBYDCAr4C-fSYx9a_y=D3aZe0_9e_UOLo5yUJrk9TXs46Meg@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> <CAAWBYDCAr4C-fSYx9a_y=D3aZe0_9e_UOLo5yUJrk9TXs46Meg@mail.gmail.com> Message-ID: <CA+ri+V=3xcOHhnxO=q9UVaNhg4UU4w3QmhjZXjkCHjOAHVN5WA@mail.gmail.com> On 8 April 2014 21:54, Tab Atkins Jr. <jackalmage at gmail.com> wrote: > I still don't understand. Do you think that what Hixie is saying > (about clicking on non-interactive text in <summary> toggling the > <details>) is wrong? > nope. > > The behavior that Hixie describes is roughly what implementations do > today. In Blink, clicking on any bare text in the <summary> toggles > the <details>, while clicking on an <input> does not. However, Blink > current behavior with <label> is different - it basically ignores the > presence of the <label>, as far as I can tell, and still toggles the > <details> even if the <label> is redirecting the click to an <input>. > Implementations today have the summary element as the focusable/interactive element. this has several pros/cons what I am trying to achieve is to have the pros defined as part of the feature. I would strongly object to any suggestion that <summary> should only > toggle <details> when you click on the disclosure triangle, > I cannot agree more, which is why I have brought up the issue here and elsewhere. Hixie talks about platform conventions and UAs deciding, and as I have pointed out several times the OSX platform convention is just what you describe. and as you say "would be terrible UI." unless you > add some additional markup like <label>. That would be terrible UI. > I would prefer that the summary element acted as the label the disclosure triangle of the details element, thus providing a reasonable default click area and focus are and source for the accessible name of the control. I see a few issues, which is why I have suggested allowing the use of <label> (to provide both a clickable area that can be assigned by the author and provide an explicit method to assign an accessible name) 1. When the summary element also includes links or other controls each with their own accessible name, providing an unambiguous accessible name for the disclosure triangle becomes problematic. 2. I have observed that assigning an accessible name for a control in the shadow DOM from the DOM is not possible. Thus my question to the list/hixie: "What's the mechanism by which the anonymous control for details can be assigned an accessible name?" -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From ian at hixie.ch Tue Apr 1 11:55:24 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 18:55:24 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <20140205183607.GA56968@sideshowbarker> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> Message-ID: <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> On Tue, 4 Feb 2014, Cameron McCormack wrote: > Ian Hickson wrote: > > I'm all for handling it in one place. What precisely do you want the > > behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- "the first > > <svg:title> element" may come after "the first<html:title> element", and > > vice versa. Also consider when one or the other is "primary" but the > > relevant element is absent.) > > OK, how about: if the document element is an <html:html>, we choose the > first <html:title> in document order; if the document element is an > <svg:svg>, we choose the first child <svg:title> of the document > element; otherwise, null. > > This still is going to produce "incorrect" results for things like: > > <!DOCTYPE html> > <svg> > <foreignObject> > <title>blah > > > > but arguably you shouldn't be using in there anyway. It doesn't seem useful to hit that element. It's not the (SVG) document title, after all. I ended up going with: - if it's an SVG document, use the first <title> child of the root element - if it's an HTML document, use the first <title> element in tree order (that's what it used to be) For setting it uses the same element, unless there isn't one, in which case: - if it's an SVG document, append an SVG <title> to the root element - if it's an HTML document, append a <title> to the <head> Hopefully that's compatible enough. Let me know if you need something different. On Mon, 3 Feb 2014, Jonas Sicking wrote: > > An even simpler solution would be to say "we choose the first > <html:title> or <svg:title> in document order". That has the nice > property that we align SVG and HTML more. This seems to not quite match the SVG semantics, unfortunately. On Wed, 5 Feb 2014, Simon Pieters wrote: > > Is there a situation in which it is conforming to use html:title outside > the <head> in a document where the root is html:html? In > math:annotation-xml? You can certainly imagine a compound document format containing entire HTML subdocuments, <html>, <head>, <title>, and all. I'm not sure that's possible with just SVG and HTML currently though. (Maybe MathML, indeed.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 12:01:46 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 19:01:46 +0000 (UTC) Subject: [whatwg] microdata questions In-Reply-To: <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> References: <CAGYLO0+N_3BTmKM6+2XLcghm2d0GSy36xubRJKTR5KWEnGhvNg@mail.gmail.com> <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404011857230.11249@ps20323.dreamhostps.com> On Mon, 10 Feb 2014, Eric Devine wrote: > > 1. Section 5.5.1 of the Microdata spec prescribes how microdata should > be respresented as JSON, but it does provide a MIME type. I'm writing a > REST API that I would like to be able to return JSON in microdata > format, but I need the client to explicitly request this via the HTTP > Accept header. The main concern is to know when to return plain > properties as an array with one element. As a general rule I would recommend against using Accept headers to do anything. You're better off making the JSON data its own resource, IMHO. Having said that, as you noted in a later e-mail, the MIME type suggested by the HTML spec is "application/microdata+json". http://whatwg.org/html#application/microdata+json > 2. Section 5.2.4 does not provide a way to apply a property value to the > value attribute of an <option> element. Is this an oversight, or is > there simply not a convincing enough use case for the need? There's not any way currently to make for controls map to microdata. It's not clear exactly what it would mean. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jonas at sicking.cc Tue Apr 1 12:58:12 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Tue, 1 Apr 2014 12:58:12 -0700 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> Message-ID: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 3 Feb 2014, Jonas Sicking wrote: >> >> An even simpler solution would be to say "we choose the first >> <html:title> or <svg:title> in document order". That has the nice >> property that we align SVG and HTML more. > > This seems to not quite match the SVG semantics, unfortunately. Does it break existing content? If not, why not ask the SVG spec to be changed? The thread was started by one of the SVG spec editors after all. / Jonas From ian at hixie.ch Tue Apr 1 13:29:59 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 20:29:59 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404012027040.21310@ps20323.dreamhostps.com> On Tue, 1 Apr 2014, Jonas Sicking wrote: > On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Feb 2014, Jonas Sicking wrote: > >> > >> An even simpler solution would be to say "we choose the first > >> <html:title> or <svg:title> in document order". That has the nice > >> property that we align SVG and HTML more. > > > > This seems to not quite match the SVG semantics, unfortunately. > > Does it break existing content? If not, why not ask the SVG spec to be > changed? The thread was started by one of the SVG spec editors after > all. Dirk and heycam's replies to your original e-mail here suggest that this is not really viable. I mean, it'd be like changing document.title in HTML to point to the first title="" attribute in the document if it came before the first <title>. Anyway, what the spec ended up saying is in some ways even simpler, since it only looks one level deep for SVG rather than doing a deep tree search. (Is this the kind of change that you would have liked pre-flighted? I can revert the change and put out an announcement if you like. I'm not yet sure I exactly understand what kinds of changes fall into this category.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 17:02:51 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 00:02:51 +0000 (UTC) Subject: [whatwg] <keygen> and X509 client cert mime type In-Reply-To: <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> References: <2E519EB1-CB5D-48E1-8435-BEF2616E9F9C@bblfish.net> <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> Message-ID: <alpine.DEB.2.00.1404012343180.11249@ps20323.dreamhostps.com> On Tue, 25 Feb 2014, henry.story at bblfish.net wrote: > > The keygen form element does a great job of specifying how the browser > creates a public/private key pair, stores the private key in it's local > keystore. > > "When the control's form is submitted, the private key is stored in the > local keystore, and the public key is packaged and sent to the server." > > It is clear that the intention is for the server to send back a > certificate built from the public key. What I can't find is what the > mime type of the returned certificate should be. I have been using > `application/x-x509-user-cert` which seems to work for Safari, Firefox, > Opera . But I think that is not an officially supported certificate > type. application/pkix-cert seems to be that after looking it up on > iana. > > I ended up posting a bug report for Android on that. > http://code.google.com/p/android/issues/detail?id=66342 > > But now I have to check for each browser which is the type all browsers > support. To avoid people having to do this research again and again, > perhaps it would be worth specifying a mime type that all browsers > do/must support in the HTML5 spec? On Wed, 26 Feb 2014, henry.story at bblfish.net wrote: > > (1) most browsers currently understand the mime types > (a) application/x-x509-user-cert > (b) application/x-x509-ca-cert > (c) application/x-x509-email-cert > ( I have only verified (a) btw. I am assuming the others also support (b) and (c) ) > as specified here > https://wiki.mozilla.org/CA:Certificate_Download_Specification > > (2) the above mime types are not registered > http://www.iana.org/assignments/media-types/media-types.xhtml > > So really either the old mime types should be registered, or they should > be mentioned as being in use but deprecated and people should be guided > towards the application/pkix-cert I wouldn't worry too much about registered vs not registered. If the registry doesn't match the implementations, the registry is buggy. On the other hand, I also don't want to get into the business of specifying this stuff myself. I've added a link to the above MDN page to the keygen section. If there is ever something more canonical (and yet still useful and accurate), let me know and I'll update the spec. Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:43:08 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:43:08 +0000 (UTC) Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEEAS0O79Ko7QrxXKE8YxaVZha5Hzr_bqpAaJrb2PKHQggA@mail.gmail.com> References: <CA+dJEEAS0O79Ko7QrxXKE8YxaVZha5Hzr_bqpAaJrb2PKHQggA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021739430.11249@ps20323.dreamhostps.com> On Mon, 3 Mar 2014, Bob Owen wrote: > > The spec [...] seems to be fairly clear that if an existing window is > navigated using window.open, by a browsing context that is not the > original opener, then window.opener should remain unchanged. > > Currently, Trident (and incidentally Presto) seems to have the correct > behaviour, but Blink, WebKit and Gecko all change window.opener to the > window of the browsing context that has just caused it to navigate. I > believe this to be a very long standing difference (>10 years for Gecko > and Trident) > > I am proposing to change Gecko to match the spec, but I was advised to > raise the issue here before going ahead. > > Do people agree that window.opener should remain unchanged in this > circumstance? Did you receive any off-list feedback on this, or attempt to implement it and get any implementation experience? Having "opener" be the actual opener seems pretty intuitive to me; if there's no compat need to do otherwise, it seems like a reasonable choice. Is there a security reason to prefer the latest navigator? (At the time the spec was written, it was 2v2; the 1v3 situation we have now is the result of Presto going away and Blink forking from WebKit.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:52:14 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:52:14 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> On Mon, 3 Mar 2014, Ami Fischman wrote: > > Looks like we're back in business: > > Latest editor's draft: > http://dev.w3.org/2011/webrtc/editor/getusermedia.html Thanks. As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:57:11 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:57:11 +0000 (UTC) Subject: [whatwg] More effective model for handling resources In-Reply-To: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> References: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> On Thu, 13 Mar 2014, Tingan Ho wrote: > > Almost all web developer I know use externally linked CSS resource in > their web projects. That means that the browser needs to (1) request the > html page (2) parse the html (3) request for the CSS resource that is > linked from the html document. The problem with externally linked > resources is point three. It needs to make another request for the CSS > resource. There is a solution to this problem and that is to inline the > CSS. Though that would yield another problem: all subsequent page > request will become bigger. I believe this is being handled by the next-generation transport protocols (SPDY or whatever it's called now). I recommend approaching the relevant groups to check that your precise case has been handled. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 11:09:15 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 18:09:15 +0000 (UTC) Subject: [whatwg] inverse property mechanism for Microdata? In-Reply-To: <CAK-qy=6VGPOJshUqSg_BuVU44UUqV9WLxtJAdRUm-pnk=XDKnw@mail.gmail.com> References: <CAK-qy=7SuUq_4Ung06+1CLySJ3D7Aiv_1uyAZnJzc+jPuOcYHw@mail.gmail.com> <alpine.DEB.2.00.1401312334310.26647@ps20323.dreamhostps.com> <CAK-qy=6_ZQ5NCxVSqHraa-Lc1P88vY8BpuacLbj3_QyFpG5jnQ@mail.gmail.com> <alpine.DEB.2.00.1403172046390.31525@ps20323.dreamhostps.com> <CAK-qy=6VGPOJshUqSg_BuVU44UUqV9WLxtJAdRUm-pnk=XDKnw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021759091.11249@ps20323.dreamhostps.com> On Wed, 19 Mar 2014, Dan Brickley wrote: > > > > This is what the example would look like if I'm understanding this right: > > > > <div itemscope itemtype="http://schema.org/LocalBusiness"> > > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > > Giftware</span></h1> > > <span itemprop="description"> A superb collection of fine gifts and clothing > > to accent your stay in Mexico Beach.</span> > > Phone: <span itemprop="telephone">850-648-4200</span> > > > > <div itemscope itemtype="http://schema.org/LocalBusiness" > > itemprop-up="containedIn"> > > <h2><span itemprop="name">(Entity B) The tiny store within a > > store</span></h2> > > <span itemprop="description"> A superb collection of tiny clothes, > > from the store within the store.</span> > > Phone: <span itemprop="telephone">123-456-7890</span> > > </div> > > > > </div> > > > > It's not too bad, I guess. > > Yes. I notice that the words we were playing with at schema.org relate > to the underlying graph data model itemprop-inverse, -reverse etc., > whereas your draft name, itemprop-up is about the markup hierarchy. Yeah. I think most authors think in terms of what they see (their markup), not in terms of the data model. (I have had a _lot_ of conversations with authors where it was clear that they had no idea there was an underlying data model for the microdata that was separate from the markup.) > Yup, there are some cases where this can be addressed through the > rigorous use of entity IDs in itemid, as you sketch below. That would be > relatively new territory for schema.org and for publishers. Perhaps > there is an attribute name we can find that would leave the door open to > more use cases, e.g. "itemprop-backwards" rather than "itemprop-up". It > seems reasonable to try to address relationships between sibling > elements too. Well you'd been a new attribute to do that, unless I'm misunderstanding your proposal. Maybe you mean this attribute wouldn't point to a relative place in the markup, but would point to an identified element given by another attribute? I think that would be quite confusing. > Something like (trying out -backwards instead of -up, to allow for > non-hierarchical usage): > > <div itemid="bigshop" itemscope itemtype="http://schema.org/LocalBusiness"> > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > Giftware</span></h1> > </div> > <div itemscope itemtype="http://schema.org/Pharmacy"> > <meta itemprop-backwards="containedIn" itemid="bigshop" /> > <h2><span itemprop="name">Tiny pharmacy store within a store</span></h2> > </div> > > ? > > Can we use itemid in that way, to give a property value too? I don't > see itemid used much in the wild and the spec only mentions its use > for the item having the property, rather than using when supplying the > value of a property. itemid="" is a URL that gives the identifier of the item. We'd want to use a new attribute to do something like this; e.g.: itemrelation="containedIn bigshop" where "itemrelation" takes just two keywords, a property name and the ID (not itemid) of the target element. But that's pretty elaborate. Is there a need for this? Or is the relationship to the parent all that's needed? In your original e-mail you only suggested wanting to go up. > > Microdata actually already has a solution to this. The vocabulary can > > define an ID for each item using itemid="", and can define multiple items > > having the same ID as being the same conceptual item. Thus: > > > > <!-- first episode --> > > <div itemscope itemtype="http://schema.org/Episode"> > > ... > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"></div> > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"></div> > > </div> > > > > <!-- second episode --> > > <div itemscope itemtype="http://schema.org/Episode"> > > ... > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"></div> > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"></div> > > </div> > > > > <!-- actors --> > > <div itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"> > > ... > > </div> > > <div itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"> > > ... > > </div> > > > > This also enables the data to be spread across multiple pages without > > confusion. (This is similar to how RDF uses identifiers for everything > > -- essentially, in RDF terms, this turns the microdata item from a > > bnode into a node with a global identifier.) > > Yes, it succeeds or fails to the extent people agree on these global > identifiers. Do people not agree on them, typically? > > Your example would become: > > > > <div itemscope itemtype="http://schema.org/LocalBusiness" > > itemid="..."> > > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > > Giftware</span></h1> > > <span itemprop="description"> A superb collection of fine gifts and clothing > > to accent your stay in Mexico Beach.</span> > > Phone: <span itemprop="telephone">850-648-4200</span> > > > > <div itemscope itemtype="http://schema.org/LocalBusiness"> > > <div itemprop="containedIn" > > itemscope itemtype="http://schema.org/LocalBusiness" > > itemid="..."></div> > > <h2><span itemprop="name">(Entity B) The tiny store within a > > store</span></h2> > > <span itemprop="description"> A superb collection of tiny clothes, > > from the store within the store.</span> > > Phone: <span itemprop="telephone">123-456-7890</span> > > </div> > > > > </div> > > > > Is this not suitable for schema.org? Or is it just too much markup? > > It's in the clever-but-fragile category, I'd say. So yes, a bit too > much markup. In English this is saying something like > > "We're describing a LocalBusiness whose global ID is [xyz]; it has > certain name, description, telephone properties given here. > There is also a LocalBusiness that is containedIn a LocalBusiness > whose global ID is [xyz]; this [other] LocalBusiness has the following > name, description, telephone etc properties...." > > Just as in the English, it is rather easy to lose track of which > LocalBusiness we're talking about. I think you overstate the complexity, but ok. > >> > That is another option, similar to the parenthetical itemid="" note > >> > above -- you could just have the vocabulary define that for every > >> > property whose value is an item, the item type that that property > >> > can point to has another property with the same name plus a fixed > >> > suffix, like "-inv", that inverses the relationship. [...] > >> > >> This is easier to understand than itemref, but still involves > >> creating 100s of additional properties instead of just one new piece > >> of syntax. > > > > What do you mean by "creating additional properties" here? It's > > relatively trivial to define these with one sentence, you don't need > > to actually list them or anything. Implementing support is similarly > > easy, as far as I can tell -- you just check for the suffix or prefix > > and handle it accordingly. > > Re "you don't need to actually list them", this effectively creates two > classes of property. Real ones, and fake/pseudo properties which we're > pretending exist so that we can re-use a piece of syntax that expects a > property name. Once these pseudo properties are released into the wild, > they'll show up as if they were real. They would be real, I'm just saying that documenting them and implementing them is somewhat trivial. > What we want to avoid is saying things like: > > "You can use itemprop='containedIn-rev' to indicate a property that > means the inverse of containedIn. However this is not a first class > schema.org property, and should not be used other syntaxes (JSON etc), > data dumps, APIs etc. You should canonicalize x containedIn-rev y > into: y containedIn x., ..." Why wouldn't it be a first-class property? It could trivially be so. The implementation is easy, whatever the vocabulary it's used in. > > If you do want to go with a new property, just use the name you would > > want in the spec. I weakly recommend "itemprop-up", which is the most > > intuitive name I've seen so far for this, but if you find a better > > name just use that. I guarantee that I won't make the spec conflict > > with whatever you use, as long as you tell me what it is. :-) Assuming > > that it works well, then we would just update the spec to use that > > term directly, retroactively making the experimental content > > conforming. > > Thanks! I'll discuss this thread with the schema.org team. My guess is > that there's still a strong preference for a new property, and we'd be > happy to avoid using data-*. > > If I understand right, the outstanding area of discussion/confusion is > whether there are cases beyond simple DOM element containment where we > might want to use an inverse itemprop construction (even though we can > see how itemid everywhere might also be used). If we're only using > element hierarchy then itemprop-up could work. Did you reach any conclusions in these discussions? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bobowencode at gmail.com Wed Apr 2 13:16:58 2014 From: bobowencode at gmail.com (Bob Owen) Date: Wed, 2 Apr 2014 21:16:58 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> On 2 April 2014 18:43, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Mar 2014, Bob Owen wrote: > > > > The spec [...] seems to be fairly clear that if an existing window is > > navigated using window.open, by a browsing context that is not the > > original opener, then window.opener should remain unchanged. > > > > Currently, Trident (and incidentally Presto) seems to have the correct > > behaviour, but Blink, WebKit and Gecko all change window.opener to the > > window of the browsing context that has just caused it to navigate. I > > believe this to be a very long standing difference (>10 years for Gecko > > and Trident) > > > > I am proposing to change Gecko to match the spec, but I was advised to > > raise the issue here before going ahead. > > > > Do people agree that window.opener should remain unchanged in this > > circumstance? > > Did you receive any off-list feedback on this, or attempt to implement it > and get any implementation experience? Thanks for getting back to me Ian. No, no other feedback. I have a patch for it, but haven't pursued it any further. I could investigate putting the change in for Firefox Nightly, if you think that might help with finding any compat issues. > Having "opener" be the actual opener seems pretty intuitive to me; if > there's no compat need to do otherwise, it seems like a reasonable choice. > > Is there a security reason to prefer the latest navigator? Agreed, the specified behaviour makes sense to me, if only because of the name. The fact that you can also use window.open for subsequent navigation (which leads to the different behaviours), muddies the water a bit, but that's a genie that would definitely refuse to go back in the bottle. Over security reasons, although I don't have any concrete examples, I would have thought that either could possibly cause problems, if the opposite behaviour was expected. So, consistency is probably the most important thing. I can also see that both pieces of information (original opener and last navigator) might be useful. So, maybe the other could be added either way. From ian at hixie.ch Wed Apr 2 13:56:38 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 20:56:38 +0000 (UTC) Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> On Wed, 5 Mar 2014, Qebui Nehebkau wrote: > On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson <ian at hixie.ch> wrote: > > I think the arguments you've presented so far suggest "address-levelN" > > for N=1..4, with 4=region and 3=locality, is probably the simplest > > thing to do. I was hoping there might be other people with opinions, > > to give us different perspectives on this, but it seems nobody else > > cares. :-( > > Since you asked, I think the whole endeavour (of trying to tokenise an > address) is pointless and should be abandoned outright. :) In principle I agree, but in practice I think we have to work with the reality that that is what people are doing. > Short of my ideal of *only* offering the full address (as used on a > label) as an opaque string, I think it would be most reasonable to > consider the 'locality' field itself to be a fully-specified opaque > string, including whatever information is necessary to completely > identify the location from the region level (such as the prefecture and > district), rather than a single level. > > Failing all that, I would at least prefer for the fields to have names > instead of abstract numbering, because people are likely to be confused > about the order, no matter which end is the 'widest'. It also seems more > intuitive, to me, for the 'locality', as, after all, 'local', to be the > most specific level. Would people not be confused by names in the same way? On Wed, 5 Mar 2014, Qebui Nehebkau wrote: > > Right, "impose", certainly not. But, perhaps, (one hopes,) "encourage"? > Or at least "refuse to explicitly support anything else". Does > autocomplete *need* to support people who are already doing it wrong? > But I'm probably just being too utopian; it happens. Well if we don't support pretty much every form out there, the feature isn't particularly useful. On Tue, 4 Mar 2014, Kevin Marks wrote: > > > > > > > > > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "address-level4" > > > > > > > > "address-level3" > > > > > > > > "address-level2" / "locality" > > > > > > > > "address-level1" / "region" > > > > > > > > "country-name" > > > > > > > > > > > > This could work. It has the synonym issue (having multiple fields > > > > > > that mean the same thing is often the source of confusion). > > > > > > > > > > > > > > Or we could do: > > > > > > > > > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "subsublocality" > > > > > > > > "sublocality" > > > > > > > > "locality" > > > > > > > > "region" > > > > > > > > "country-name" > > > > > > > > > > > > This could work. It avoids the synonym problem. > > > > > > > > > > Yes, this alternative works, but in my opinion is not preferable. > > > Because these words don't really mean anything. Nor do numbers. I think we don't really have any chance of giving meaning to the names here either way. On Tue, 4 Mar 2014, Evan Stade wrote: > > "dependent-locality" and "locality" have a fairly precise meaning in the > UK. Also in a natural-language conversation, if you ask me what "region" > of the country I live in, I'd say "New England", "the Midwest", or some > such; certainly not the state where I reside. The descriptions for these > tokens are currently pretty specific, for example they say a city would > be a locality. But this is not true for Beijing or some other cities. To > fix the descriptions, we'd have to change them to something like > "region: the highest level administrative region below country in the > address" and "locality: the second-highest level administrative region > below country in the address", "sub-locality: the third-highest level > administrative region [...]". With you so far. > At this point, one wonders why the tokens aren't just [something]1, > [something]2, etc. I don't understand how you get there. Why would you wonder this? > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "locality" > > > > > > > > "subsubregion" > > > > > > > > "subregion" > > > > > > > > "region" > > > > > > > > "country-name" > > > > I don't understand why you think authors will think they need to > > include "subregion", but won't think they need to include > > "address-level3". > > I think they'll assume subregion returns something for the US if it's > sandwiched between "region" and "locality", because county is in between > state and city. But in reality, subregion will return nothing. But why does this not apply to the numeric version? > > Having synonyms is really bad. It leads to huge amounts of confusion. > > This is why I'm trying to avoid having synonyms for the address-level* > > stuff. We should definitely not add some just to introduce a slightly > > better name. > > My suggestion is to change the address-line1 to street-address-line1, > not to have synonyms. Chrome would then support address-line1 for a > limited period of time, but outside the spec. There's no "outside the spec". The spec tries to describe reality. If you implement something, then that's the reality, and that's what the spec would say, and therefore we'd have a synonym. > If you are avidly anti-synonym for the address-level* stuff, and don't > want to change "region" and "locality", then I guess the next best > naming scheme in my mind would be "region", "locality", "locality2", > "locality3". But we also need to update the descriptions as mentioned > above. I don't understand why "locality2" is better than "sublocality", nor why it's better to add things above locality than between locality and region. The numbering seems really prone to mistakes (I mean, I've been making mistakes with it this entire thread unintentionally, for example). > > > Why is that better than 1=region, 2=locality, except to a US-centric > > > viewpoint? This would lead to a weird situation where (a) you > > > couldn't expand past 4 levels without changing the meaning of > > > previous levels and (b) a country such as the US would have > > > address-level4 and address-level3 but no address-level2 or > > > address-level1. > > > > Well, at least as far as (a) goes, we have no way to know where > > governments are going to introduce new levels. Who's to say that the > > US won't introduce something between states and towns? This problem > > exists whatever we do. Maybe the US and the EU will merge and there'll > > be a new field between "country-name" and "region". Who knows. > > One can dream... > > You're right that changing political circumstances might put us in an > awkward situation no matter what we do. But it seems to me the most > likely scenario is that a government would add more administrative > levels at the most granular level. Why? It seems just as likely that we'll add levels between "country" and "region". For instance, the example above. Or, in a few years, when there are parts of countries in space, maybe there'll be a planetoid name between the country and the region. Or maybe that will go on the other side of the country. I think trying to guess how things will be extended is a fool's errand. If we use numbers, we paint ourselves into a corner with extensions anywhere but at the deepest level. Fundamentally, studying all the alternatives we've considered so far, they all suck. - some have weird names like "subsubregion". - some use numbers - some have synonyms - some leave gaps in addresses for some locales where it's not obvious where the gap should be - some are non-trivial to extend later I think I'm going to just go with more or less what you first proposed: "address-line1" | "address-line2" |- "street-address" "address-line3" | "address-level4" "address-level3" "address-level2" / "locality" "address-level1" / "region" "country-name" That is, make "locality" and "region" synonyms for two new fields, add two more, and say in the spec that different locales have different numbers of levels and that as many should be included as are appropriate, starting with level1 as the widest administrative division. I've filed a bug on this topic; if I can get agreement from other vendors, then I'll go ahead and spec this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235 On Wed, 5 Mar 2014, Edward O'Connor wrote: > > The techniques browsers use for autofilling auth information would > benefit enormously from some additional autocomplete="" values. The wiki > page Ilya mentioned captures the use cases pretty well. I think these > are the critical ones that capture the most common cases: > > # Passwords > > On "change your password" forms, which <input type=password> is your > current password? Which is the new password? Browsers want to avoid > filling the old password into the new or confirm password fields. > Additionally, distinguishing such fields would help tools that generate > passwords. These are useful on both sign-up and change password forms. > > <input type=password> - your current password > <input type=password autocomplete=new> - a new password > <input type=password autocomplete=confirm> - the new password, again > > Next to the other autocomplete values, "new" and "confirm" don't look > descriptive enough. "new-password" and "confirm-password", maybe? > "<input type=password autocomplete=new-password>" feels redundant and > verbose to me. Is there any reason to have two fields here, why not just "new" both times? Also, should we have an "old" field for the old password, or is the lack of an autofill field sufficient? I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236 It needs multiple vendors on board to make progress. > # Usernames > > Lots of websites use email addresses as usernames. Tools should be able > to distinguish email-used-as-username fields from other email fields. > This can also help on "forgot password"/"forgot username" forms. > > <inpyt type=text autocomplete=username> - your username on this site > <input type=email> - your preferred email address > <inpyt type=email autocomplete=username> - your username on this site, > not your preferred email > address > <input type=url autocomplete=username> - OpenID This seems reasonable. I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25237 It needs multiple vendors on board to make progress. > Also, consider the case of login forms without username fields. You see > this sort of thing a lot these days, when sites remember who was last > logged in: > > <form> > <label>Password for hober: <input type=password name=pw></label> > <p>Not hober? <a href=...>Click here to sign in</a>. > </form> > > It's difficult for tools to manage the user's auth info for such pages. > How can tools discover what the username is? The obvious solution, in a > world with autocomplete=username, would be to add <input type=hidden > autocomplete=username name=username value=hober> to the form. So far, autocomplete="" hasn't applied to <input type=hidden>. This would be a bit weird, giving it a different meaning than usual (providing information to the UA, rather than getting information from the UA). I'm a bit skeptical of this kind of overloading. Not sure what the right solution is, though. On Fri, 7 Mar 2014, Garrett Casto wrote: > > Another related issue that would be nice to address would be allowing > sites to positively assert that authentication succeeded. For sites that > authenticate client side via XHR, standardizing something like > window.external.AutoCompleteSaveForm() would be very helpful. For sites > that validate server side, I'm less sure what the correct avenue to > convey this information would be (response code, header, ...). I'm > assuming that this will be more contentious than adding username and > password attribution and I don't want to hold that up, but I would like > to see opinions on this. I actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. For the pure JS case, an API (probably on the <form> itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 For the real submission case, I guess what we want is a way to say "autocomplete=off" after the fact, basically. An HTTP header seems like the most obvious solution. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 Again, these need multiple vendors on board to make progress. On Mon, 10 Mar 2014, Evan Stade wrote: > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=?cc-number? the browser might provide an experience tailored > for a payment flow, or if there?s an element with autocomplete=?bday? the > browser might use an experience that?s tailored for sharing identiy. > > We?ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element.requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: ?transactionAmount? > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: ?transactionCurrency? > value: string > description: a valid ISO 4217 currency code that describes the currency > for transactionAmount. If not provided, the default is ?USD?. > > Justification? There are upper bounds on certain payment instruments, > for example different credit cards have different credit limits; a debit > card is linked to a bank account with a certain balance. It?s a much > preferable user experience to be able to catch these problems earlier > rather than waiting for the merchant to attempt the transaction and have > it fail (or have a user?s account overdrawn). Concretely, Chromium wants > to handle transactions over $2000 differently from transactions under > that amount. > > Does this seem reasonable? The requestAutocomplete() API is a Chrome proprietary feature right now so it's sort of acadmic, but: Why would this only apply to requestAutocomplete()? Surely it would be just as important for the case where the user agent is filling in a form without using that API. Also, I don't understand how these are supposed to work. How is the browser supposed to know the balance on my credit cards or bank accounts? How is the browser supposed to know which of my cards are good for USD and which are good for GBP? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 14:00:33 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 21:00:33 +0000 (UTC) Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> References: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404022057240.21310@ps20323.dreamhostps.com> On Wed, 2 Apr 2014, Bob Owen wrote: > > > > Did you receive any off-list feedback on this, or attempt to implement > > it and get any implementation experience? > > Thanks for getting back to me Ian. > No, no other feedback. > I have a patch for it, but haven't pursued it any further. > I could investigate putting the change in for Firefox Nightly, if you think > that might help with finding any compat issues. Well as far as I'm concerned, I would encourage you to try to converge on the spec behaviour. If it turns out there are compatibility issues, that would be good to know. If not, then at least we win more interoperability. > I can also see that both pieces of information (original opener and last > navigator) might be useful. So, maybe the other could be added either > way. I haven't heard any author demand for it, so I haven't added it, but indeed, if this is something authors have a use for, we could add it. It's worth noting that there are many many ways to navigate a browsing context beyond window.open(), e.g. <a target="">, window.location, drag-and-drop of a link, window.history.go(), etc. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bobowencode at gmail.com Wed Apr 2 15:09:00 2014 From: bobowencode at gmail.com (Bob Owen) Date: Wed, 2 Apr 2014 23:09:00 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> On 2 April 2014 22:00, Ian Hickson <ian at hixie.ch> wrote: > It's worth noting that there are many many ways to navigate a browsing > context beyond window.open(), e.g. <a target="">, window.location, > drag-and-drop of a link, window.history.go(), etc. Absolutely, if we were to converge on the spec for the current opener and people felt that last navigator would be useful, then it would need to be updated in all cases. Although, the history case might hold the original state. Anyway, getting way ahead of myself. I'll see if there are any more opinions, then look to move Gecko towards the spec and see if any compat issues arise. From tingan87 at gmail.com Wed Apr 2 21:37:33 2014 From: tingan87 at gmail.com (Tingan Ho) Date: Thu, 3 Apr 2014 12:37:33 +0800 Subject: [whatwg] More effective model for handling resources In-Reply-To: <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> References: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> Message-ID: <CAOr4atVY-mv1aCMwdY0ijz3vPcsYLdQzb_dgu5kx8kTkDSOXuQ@mail.gmail.com> Hi Ian, I believe this is being handled by the next-generation transport protocols > (SPDY or whatever it's called now). I recommend approaching the relevant > groups to check that your precise case has been handled. I just found out that SPDY Server Push and Cookies could accomplish the above mentioned caching. Cookies will take care of information providing. And the server just uses Server Push to push content. On Thu, Apr 3, 2014 at 1:57 AM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 13 Mar 2014, Tingan Ho wrote: > > > > Almost all web developer I know use externally linked CSS resource in > > their web projects. That means that the browser needs to (1) request the > > html page (2) parse the html (3) request for the CSS resource that is > > linked from the html document. The problem with externally linked > > resources is point three. It needs to make another request for the CSS > > resource. There is a solution to this problem and that is to inline the > > CSS. Though that would yield another problem: all subsequent page > > request will become bigger. > > I believe this is being handled by the next-generation transport protocols > (SPDY or whatever it's called now). I recommend approaching the relevant > groups to check that your precise case has been handled. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- Sincerely, Tingan Ho From lists at scratchdisk.com Wed Apr 2 23:21:38 2014 From: lists at scratchdisk.com (=?iso-8859-1?Q?J=FCrg_Lehni?=) Date: Thu, 3 Apr 2014 08:21:38 +0200 Subject: [whatwg] Grouping in canvas 2d In-Reply-To: <alpine.DEB.2.00.1403141808380.32463@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <CAGN7qDBHT_fitzzsrnGe6exCWr1Fc4mXSnY=_KW7fNjkoB6-KA@mail.gmail.com> <CABpaAqTdv4TaDpXj4jksL+jeDVqv9cKyVvxJO1nridR9Zwq66Q@mail.gmail.com> <CAGN7qDA9BfpOCqzAmbwooJ_aSw8cbLT-G_-can61K05Q7YsLMw@mail.gmail.com> <73A19694-2AB0-4948-8B4B-A5ED820B2444@scratchdisk.com> <alpine.DEB.2.00.1403141808380.32463@ps20323.dreamhostps.com> Message-ID: <6D69D840-D0F2-4547-AB63-8288C2E51A1D@scratchdisk.com> Here another simple example: When both filling and stroking a path and then drawing it with with an opacity of less than 100%, the path will be rendered differently than in an SVG (a large stroke width will make the issue more apparent): - In Canvas, both the fill and the stroke will be rendered with the given opacity, and the fill will shine through the inner half of the stroke. - In SVG, the stroke will cover the fill, and the fill will not shine through the inner half of the stroke, regardless of the opacity. If you'd like to emulate the SVG behavior in Canvas (which we happen to do in Paper.js), then the only way to do so currently is to draw the path's fill and stroke at 100% opacity into a separate canvas, and then blit the whole thing over with the given opacity. This is *much* slower than directly drawing into the Canvas, and happens to be one of the worst bottlenecks in Paper.js I would really appreciate a solution to this problem. J?rg On Mar 14, 2014, at 19:09 , Ian Hickson <ian at hixie.ch> wrote: > Can you elaborate on what precisely the performance bottleneck is? I was > looking through this thread but I can't find a description of the use > cases it addresses, so it's hard to evaluate the proposals. From mkwst at google.com Thu Apr 3 02:49:20 2014 From: mkwst at google.com (Mike West) Date: Thu, 3 Apr 2014 11:49:20 +0200 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <CAKXHy=cm3F1noHs1SM4XSOpno4aB1GPQ9mhjyva9v+6EU9v3HA@mail.gmail.com> On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson <ian at hixie.ch> wrote: > > Also, consider the case of login forms without username fields. You see > > this sort of thing a lot these days, when sites remember who was last > > logged in: > > > > <form> > > <label>Password for hober: <input type=password name=pw></label> > > <p>Not hober? <a href=...>Click here to sign in</a>. > > </form> > > > > It's difficult for tools to manage the user's auth info for such pages. > > How can tools discover what the username is? The obvious solution, in a > > world with autocomplete=username, would be to add <input type=hidden > > autocomplete=username name=username value=hober> to the form. > > So far, autocomplete="" hasn't applied to <input type=hidden>. This would > be a bit weird, giving it a different meaning than usual (providing > information to the UA, rather than getting information from the UA). I'm a > bit skeptical of this kind of overloading. > > Not sure what the right solution is, though. > As Garrett noted, this is already a solution Google is using, though not with explicit syntax, just taking advantage of existing heuristics. Paving this (potential) cowpath isn't really that weird. That said, an alternative might be to add a mechanism of associating autocompletion metadata with the field in order to give the UA enough context to fill it in. For example, if a password is being requested for a known username, that username could be added as an new "autocomplete-username" attribute (similar to the 'data-*' construct HTML already supports): <input type="password" autocomplete-username="hober"> -mike -- Mike West <mkwst at google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) From andy at pigsonthewing.org.uk Thu Apr 3 03:22:48 2014 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu, 3 Apr 2014 11:22:48 +0100 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <CABiXOEmndoUXWk1nWk00RyFsA6g2M8M0ZOofTctP+_oxC4odvQ@mail.gmail.com> [General point, so not quoting anyone in particular] [Resending to list, apologies to Ian] Why would you define any address components other than those in vCard, a standard with massive implementation and interoperable with most address book applications and services? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk From creis at chromium.org Thu Apr 3 11:28:15 2014 From: creis at chromium.org (Charlie Reis) Date: Thu, 3 Apr 2014 11:28:15 -0700 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> References: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> Message-ID: <CAH+8MBaU3NSq+WvZ2iG8n_-EAaSBZTA_fYOLoMw0NkFpRf4MiA@mail.gmail.com> On Wed, Apr 2, 2014 at 3:09 PM, Bob Owen <bobowencode at gmail.com> wrote: > On 2 April 2014 22:00, Ian Hickson <ian at hixie.ch> wrote: > > > It's worth noting that there are many many ways to navigate a browsing > > context beyond window.open(), e.g. <a target="">, window.location, > > drag-and-drop of a link, window.history.go(), etc. > > Absolutely, if we were to converge on the spec for the current opener and > people felt that last navigator would be useful, then it would need to be > updated in all cases. > Although, the history case might hold the original state. > > Anyway, getting way ahead of myself. > I'll see if there are any more opinions, then look to move Gecko towards > the spec and see if any compat issues arise. > For what it's worth, I think we'd be open to changing Blink to match the spec as well, if you don't find any compat issues. Charlie From bobowencode at gmail.com Fri Apr 4 01:40:50 2014 From: bobowencode at gmail.com (Bob Owen) Date: Fri, 4 Apr 2014 09:40:50 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEEDiH1N_9rex+Dq_8nzQrCVnpa8djiJGsc1xP3zHCLLY4g@mail.gmail.com> On 3 April 2014 19:28, Charlie Reis <creis at chromium.org> wrote: > For what it's worth, I think we'd be open to changing Blink to match the spec as well, if you don't find any compat issues. I'd say it's worth a lot, thanks Charlie. From faulkner.steve at gmail.com Sat Apr 5 00:59:03 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Sat, 5 Apr 2014 08:59:03 +0100 Subject: [whatwg] summary/details - proposal Message-ID: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> note: bringing this to the whatwg list to elicit feedback from implementers and other interested parties that are not involved in the discussion at the W3C Currently the implementation(s) of summary/details elements do not match the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element In the spec, the details element is interactive content, the summary is not, its a summary, caption, or legend. in webkit/blink the summary element is the interactive element (when pressed it opens/closes the details element) This is good because it provides a large default hit region to activate the control example to try in chrome/safari/opera http://codepen.io/stevef/pen/CyauJ/ So as the spec/implementations are at odds, the implementations need to change to match the spec or the spec needs to change to match implementations or the spec needs to change to accommodate the positive aspects of the current implementations while allowing for other use cases An issue with current implementations is that when the summary element includes other interactive elements (as it is allowed to), clicking on them results in the details element being opened/closed (although this can be overcome via scripting). example to try in chrome/safari/opera http://codepen.io/stevef/pen/xjJiy/ Issues with the current spec text: The interactive part of the details element is the disclosure triangle ? which is supposed to be an anonymous control in the shadow DOM The <summary> itself is not interactive, so only the triangle provides the actionable control. the summary text which is effectively the label for control does not activate the control. There is no method provided to associate a label with the anonymous control that can (a) provide an increased hit region and (b) provide an explicitly associated label for the anonymous control. Given that what we want to provide for the use case of having controls inside the summary, after discussion around the issue[1], I have proposed the following: <details> <summary id=x> <label for=x>Foo</label> </summary> ... </details> what this does is provide the author with the ability to add an explicit label (providing the acc name) to the details control which also increases the click region for improved accessibility/usability, while still allowing interactive content inside the summary element. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25140 feedback welcome! -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From dschulze at adobe.com Sat Apr 5 09:01:19 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sat, 5 Apr 2014 16:01:19 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() Message-ID: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> Hi, I looked at the behavior of negative width or height for the rect() and strokeRect() functions. All browsers normalize the passed parameters for strokeRect() to have positive width and height. strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) http://jsfiddle.net/za945/ Just WebKit seems to normalize for rect() as well: http://jsfiddle.net/VT4MG/ The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. Greetings, Dirk From cabanier at gmail.com Sat Apr 5 18:23:06 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 5 Apr 2014 18:23:06 -0700 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> Message-ID: <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > Hi, > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > strokeRect(90,10,-80,80) --> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ I'm unsure why such a rectangle is defined as a straight line. > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ > > The behavior of normalizing is not specified. Especially it seems odd that > the behavior for fillRect()/strokeRect() should differ from rect(). So we > should either normalize for all functions or don't do it for all IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for rect() > is important for filling with different winding rules as well. It is not > just stroking with dash arrays that is effected. > yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect From ian at hixie.ch Sat Apr 5 21:11:20 2014 From: ian at hixie.ch (Ian Hickson) Date: Sun, 6 Apr 2014 04:11:20 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> On Sat, 5 Apr 2014, Steve Faulkner wrote: > > The <summary> itself is not interactive, so only the triangle provides > the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). > Given that what we want to provide for the use case of having controls > inside the summary, after discussion around the issue, I have proposed > the following: > > <details> > <summary id=x> <label for=x>Foo</label> </summary> > ... > </details> That's way more complicated than necessary for authors, not to mention all the problems it would cause with the existing <label> definitions. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dschulze at adobe.com Sat Apr 5 23:00:50 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 06:00:50 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> Message-ID: <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > Hi, > > I looked at the behavior of negative width or height for the rect() and strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have positive width and height. > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ > >> It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ >> I'm unsure why such a rectangle is defined as a straight line. You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ > > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ > > The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. > >> yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw ?in that order? for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. Greetings, Dirk > > 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect From dschulze at adobe.com Sat Apr 5 23:23:36 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 06:23:36 +0000 Subject: [whatwg] Canvas Computing text metrics Message-ID: <69477B5B-A7A4-4674-B267-09EC2499C1F0@adobe.com> Hi, The spec says that the object TextMetrics[1] must return font and actual text metrics. All things require information from the font or the font system. In many cases either font or font system just do not provide these information. Instead of assuming that all information are accessible by the browser, it might be useful to define some heuristics that can be used. In WebKit and Blink we support the CSS dominant-baseline property in SVG that requires similar metrics as well[2]. Even SVG does not specify the heuristics yet and instead leaves that up to the browser. WebKit and Blink use the heuristics described in the documentation from Apache FOP[1]. Should these be used as fallback heuristics? Note: Many browsers might use heuristics by default since they can?t get all necessary font metrics at all. Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#textmetrics [2] http://www.w3.org/TR/SVG11/text.html#TextAlignmentProperties [3] http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling From cabanier at gmail.com Sat Apr 5 23:24:19 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 5 Apr 2014 23:24:19 -0700 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> Message-ID: <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > > > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > > Hi, > > > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > > > strokeRect(90,10,-80,80) --> strokeRect(10,10,80,80) > > > > http://jsfiddle.net/za945/ > > > >> It also seems that only firefox is following the spec [1] when width or > height are 0: http://jsfiddle.net/za945/2/ > >> I'm unsure why such a rectangle is defined as a straight line. > > You mean you would rather let it draw a one dimensional rectangle? So for > the dimension that is not zero, you would see two overlapping lines + the 0 > dimensional sides? > yes That seems indeed to be the case for IE, Safari and Blink: > http://jsfiddle.net/Gh9XK/ > > > > > Just WebKit seems to normalize for rect() as well: > > > > http://jsfiddle.net/VT4MG/ > > > > The behavior of normalizing is not specified. Especially it seems odd > that the behavior for fillRect()/strokeRect() should differ from rect(). So > we should either normalize for all functions or don't do it for all IMO. > > > > Note: fillRect() and clearRect() are not affected. The behavior for > rect() is important for filling with different winding rules as well. It is > not just stroking with dash arrays that is effected. > > > >> yes, the spec needs to say "in that order" as it does for fillRect and > strokeRect. > > Ok, that means you would be in favor not to normalize. Again, all current > browser normalize and do NOT draw "in that order" for fillRect() and > strokeRect(). That means you would require to give up the currently > interoperable behavior. > I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) I would be in favor to change the blink/webkit behavior as the specified one makes more sense. From dschulze at adobe.com Sun Apr 6 00:04:46 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 07:04:46 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> Message-ID: <872B4940-A589-46D1-B72B-B302E7FCC1E3@adobe.com> On Apr 6, 2014, at 8:24 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > > > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > > Hi, > > > > I looked at the behavior of negative width or height for the rect() and strokeRect() functions. > > > > All browsers normalize the passed parameters for strokeRect() to have positive width and height. > > > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > > > http://jsfiddle.net/za945/ > > > >> It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ > >> I'm unsure why such a rectangle is defined as a straight line. > > You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? > > yes > > That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ > > > > > Just WebKit seems to normalize for rect() as well: > > > > http://jsfiddle.net/VT4MG/ > > > > The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. > > > > Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. > > > >> yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. > > Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw ?in that order? for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. > > I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ > Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) Firefox has a strange different behavior if dash >= gap. If the gap is smaller it behaves like IE, Blink and WebKit. This also answers your question: Your example renders in IE the same as in WebKit and Blink. Greetings, Dirk > > I would be in favor to change the blink/webkit behavior as the specified one makes more sense. From harald at alvestrand.no Mon Apr 7 07:24:23 2014 From: harald at alvestrand.no (Harald Alvestrand) Date: Mon, 07 Apr 2014 16:24:23 +0200 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> Message-ID: <5342B517.1080401@alvestrand.no> On 04/02/2014 07:52 PM, Ian Hickson wrote: > On Mon, 3 Mar 2014, Ami Fischman wrote: >> Looks like we're back in business: >> >> Latest editor's draft: >> http://dev.w3.org/2011/webrtc/editor/getusermedia.html > Thanks. > > As a user, this scares me a lot. Why isn't it up to me to control this? I > don't understand the security model here at all. I don't want random Web > pages to know that they can pipe audio to the remote speakers in my > bedroom from my laptop, but if we just expose all the audio output > devices, that's exactly what will be possible. > > Without a much clearer security model, I don't think it's a good idea to > add any APIs. > Would it make sense to group the access to sinks in with access to sources - that is, "this page wants access to your cameras, microphones and audio output devices"? (either on a per-device basis or as an all-or-nothing prompting) From junov at google.com Mon Apr 7 08:07:34 2014 From: junov at google.com (Justin Novosad) Date: Mon, 7 Apr 2014 11:07:34 -0400 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDCijrx_3Rfk2mFThkBc7NignwXoFHhd3fnkL9_5QPE-rQ@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> <872B4940-A589-46D1-B72B-B302E7FCC1E3@adobe.com> <CABpaAqSm=9gAT6TfbJ7RHOcSDMcxy32Enj-txyV-yN=tF8H3JA@mail.gmail.com> <CAGN7qDCijrx_3Rfk2mFThkBc7NignwXoFHhd3fnkL9_5QPE-rQ@mail.gmail.com> Message-ID: <CABpaAqRVUa0-xeoRrBUik22GyYeY1Z0e3FBx=LLpEhryfnAJ5w@mail.gmail.com> On Mon, Apr 7, 2014 at 10:47 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Mon, Apr 7, 2014 at 7:29 AM, Justin Novosad <junov at google.com> wrote: > >> Putting myself the the web devs shoes... If I negate the height of a >> rect, what would I expect? My first though: a horizontally flipped mirror >> image of the rect. >> >> Now, what does the spec say? >> a) rect(): respect the flipped vertex order >> > > yes, except it doesn't explicitly say "in that order" so a UA could > implement it in a different one. > Okay. Nonetheless the spec already does define the order, it just does not insist that it must be respected. > > > >> b) strokeRect(): respect the flipped vertex order >> c) fillRect(): unaffected by vertex order. >> > > Where do you see that fillRect is not affected? > It does not say so explicitly, but it is implied. The coloring of pixels is governed by the fillStyle, which is not affected vertex order. > >> d) fillStyle and strokeStyle style application is independent of the >> primitive, mapping is controlled by CTM (and a pattern matrix) >> >> I find the spec is consistent with itself as it is currently worded. If >> you want to flip a rect (or any other geometry for that matter), you can >> either flip everything together using the CTM, or flip its parts (the >> vertices and the styles) individually. >> I think that having the styles automatically flip when the rect is >> inverted would have an undesirable consequence: It would break consistency >> with path rendering (how do you define the notion inverted geometry for a >> general, possibly self-intersecting, path?) >> > > I'm unsure why we would switch geometry. Are you referring to the dashing? > Dashing is one thing that would be affected. I think some implementations are currently in a non-compliant state probably because the line dashing feature was added recently. Back when strokeRect was originally implemented, we could get away with blindly normalizing rectangles because there was no impact on the rendering result. The other thing that is affected is fill rule application. For example, if you have a path that contains two intersecting rectangles and you are filling in with the nonzero rule. If one of the two rectangles is flipped, then the intersection region should be unfilled. If the rectangles are "normalized" internally by the implementation, then you will get the wrong (non spec compliant) result. > > >> On Sun, Apr 6, 2014 at 3:04 AM, Dirk Schulze <dschulze at adobe.com> wrote: >> >>> >>> On Apr 6, 2014, at 8:24 AM, Rik Cabanier <cabanier at gmail.com> wrote: >>> >>> > >>> > >>> > >>> > On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> >>> wrote: >>> > >>> > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: >>> > >>> > > >>> > > >>> > > >>> > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> >>> wrote: >>> > > Hi, >>> > > >>> > > I looked at the behavior of negative width or height for the rect() >>> and strokeRect() functions. >>> > > >>> > > All browsers normalize the passed parameters for strokeRect() to >>> have positive width and height. >>> > > >>> > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) >>> > > >>> > > http://jsfiddle.net/za945/ >>> > > >>> > >> It also seems that only firefox is following the spec [1] when >>> width or height are 0: http://jsfiddle.net/za945/2/ >>> > >> I'm unsure why such a rectangle is defined as a straight line. >>> > >>> > You mean you would rather let it draw a one dimensional rectangle? So >>> for the dimension that is not zero, you would see two overlapping lines + >>> the 0 dimensional sides? >>> > >>> > yes >>> > >>> > That seems indeed to be the case for IE, Safari and Blink: >>> http://jsfiddle.net/Gh9XK/ >>> > >>> > > >>> > > Just WebKit seems to normalize for rect() as well: >>> > > >>> > > http://jsfiddle.net/VT4MG/ >>> > > >>> > > The behavior of normalizing is not specified. Especially it seems >>> odd that the behavior for fillRect()/strokeRect() should differ from >>> rect(). So we should either normalize for all functions or don?t do it for >>> all IMO. >>> > > >>> > > Note: fillRect() and clearRect() are not affected. The behavior for >>> rect() is important for filling with different winding rules as well. It is >>> not just stroking with dash arrays that is effected. >>> > > >>> > >> yes, the spec needs to say "in that order" as it does for fillRect >>> and strokeRect. >>> > >>> > Ok, that means you would be in favor not to normalize. Again, all >>> current browser normalize and do NOT draw ?in that order? for fillRect() >>> and strokeRect(). That means you would require to give up the currently >>> interoperable behavior. >>> > >>> > I changed your test a bit so you can more easily see the >>> normalisation: http://jsfiddle.net/za945/3/ >>> > Safari and Chrome are doing as you say, but Firefox does not. (I don't >>> have IE to test) >>> >>> Firefox has a strange different behavior if dash >= gap. If the gap is >>> smaller it behaves like IE, Blink and WebKit. This also answers your >>> question: Your example renders in IE the same as in WebKit and Blink. >>> >>> Greetings, >>> Dirk >>> >>> > >>> > I would be in favor to change the blink/webkit behavior as the >>> specified one makes more sense. >>> >>> >> > From fischman at chromium.org Mon Apr 7 08:53:27 2014 From: fischman at chromium.org (Ami Fischman) Date: Mon, 7 Apr 2014 08:53:27 -0700 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> Message-ID: <CAHuR8a9Q6+FSmMVCXUoy79CLMhuHz=yLuNHA_xLjicvE4kAa7w@mail.gmail.com> Thanks Ian. I pinged public-media-capture about this and https://www.w3.org/Bugs/Public/show_bug.cgi?id=25245 is now tracking making that spec better specified. On Wed, Apr 2, 2014 at 10:52 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 3 Mar 2014, Ami Fischman wrote: > > > > Looks like we're back in business: > > > > Latest editor's draft: > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html > > Thanks. > > As a user, this scares me a lot. Why isn't it up to me to control this? I > don't understand the security model here at all. I don't want random Web > pages to know that they can pipe audio to the remote speakers in my > bedroom from my laptop, but if we just expose all the audio output > devices, that's exactly what will be possible. > > Without a much clearer security model, I don't think it's a good idea to > add any APIs. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 09:20:27 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 16:20:27 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342B517.1080401@alvestrand.no> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> Message-ID: <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Harald Alvestrand wrote: > On 04/02/2014 07:52 PM, Ian Hickson wrote: > > On Mon, 3 Mar 2014, Ami Fischman wrote: > > > Looks like we're back in business: > > > > > > Latest editor's draft: > > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html > > > > As a user, this scares me a lot. Why isn't it up to me to control > > this? I don't understand the security model here at all. I don't want > > random Web pages to know that they can pipe audio to the remote > > speakers in my bedroom from my laptop, but if we just expose all the > > audio output devices, that's exactly what will be possible. > > > > Without a much clearer security model, I don't think it's a good idea > > to add any APIs. > > Would it make sense to group the access to sinks in with access to > sources - that is, "this page wants access to your cameras, microphones > and audio output devices"? > > (either on a per-device basis or as an all-or-nothing prompting) Wouldn't that be an implementation detail? When I was first desigining the API for WebRTC (years ago, before it got rather unceremoniously forked by the W3C), the security design I had come up with was basically that the UA would show a panel of devices, and the user would drag-and-drop them into the page to give the page access to them. (Or equivalent UI, e.g. tapping on the relevant device icons to activate them for the page.) This would let me, as a user, specify that on my laptop YouTube can play video on my TV (assuming we extend this stuff to support video over Miracast/AirPlay/WiDi/DIAL/Chromecast/DLNA) while not allowing it to send audio to my bedroom, while simultaneously having Amazon's Cloud Player sending its music to my bedroom, but not allowing it to use my microphone. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From harald at alvestrand.no Mon Apr 7 10:28:45 2014 From: harald at alvestrand.no (Harald Alvestrand) Date: Mon, 07 Apr 2014 19:28:45 +0200 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> Message-ID: <5342E04D.3010301@alvestrand.no> On 04/07/2014 06:20 PM, Ian Hickson wrote: > On Mon, 7 Apr 2014, Harald Alvestrand wrote: >> On 04/02/2014 07:52 PM, Ian Hickson wrote: >>> On Mon, 3 Mar 2014, Ami Fischman wrote: >>>> Looks like we're back in business: >>>> >>>> Latest editor's draft: >>>> http://dev.w3.org/2011/webrtc/editor/getusermedia.html >>> As a user, this scares me a lot. Why isn't it up to me to control >>> this? I don't understand the security model here at all. I don't want >>> random Web pages to know that they can pipe audio to the remote >>> speakers in my bedroom from my laptop, but if we just expose all the >>> audio output devices, that's exactly what will be possible. >>> >>> Without a much clearer security model, I don't think it's a good idea >>> to add any APIs. >> Would it make sense to group the access to sinks in with access to >> sources - that is, "this page wants access to your cameras, microphones >> and audio output devices"? >> >> (either on a per-device basis or as an all-or-nothing prompting) > Wouldn't that be an implementation detail? The details are an implementation detail. Whether sinks should be treated at the same level as sources, higher level or lower level of protection is probably a somewhat higher level issue. > > When I was first desigining the API for WebRTC (years ago, before it got > rather unceremoniously forked by the W3C), the security design I had come > up with was basically that the UA would show a panel of devices, and the > user would drag-and-drop them into the page to give the page access to > them. (Or equivalent UI, e.g. tapping on the relevant device icons to > activate them for the page.) This was considered, but rejected. The consensus opinion at WebRTC and MediaCapture seemed to be that the ability to let an app say "which of these 5 microphones do you want?" is more amenable to creating good apps than leaving this UI to the browser chrome. > > This would let me, as a user, specify that on my laptop YouTube can play > video on my TV (assuming we extend this stuff to support video over > Miracast/AirPlay/WiDi/DIAL/Chromecast/DLNA) while not allowing it to send > audio to my bedroom, while simultaneously having Amazon's Cloud Player > sending its music to my bedroom, but not allowing it to use my microphone. > From faulkner.steve at gmail.com Sun Apr 6 12:50:49 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Sun, 6 Apr 2014 20:50:49 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > The <summary> itself is not interactive, so only the triangle provides > > the actionable control. > > The spec doesn't disallow making clicks on (non-interactive) parts of the > summary defer to the disclosure triangle. Browsers should just match > platform conventions, where applicable, and otherwise make whatever is > considered the best choice for users (such as making such content also > trigger the disclosure triangle). > > Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. It also provides the best choice for users, large click area and focus ring, Its also simple for authors in the majority of use cases. while on Mac OSX only the disclosure triangle (approx 13X13px) itself is clickable and has a focus rectangle. > <details> > <summary id=x> <label for=x>Foo</label> </summary> > ... > </details> That's way more complicated than necessary for authors, how so? with the current definition how do authors provide a label for the disclosure widget when summary also contains controls with labels? in the absence of browser making "clicks on (non-interactive) parts of the summary defer to the disclosure triangle." how is an author supposed to do this? > not to mention all > the problems it would cause with the existing <label> definitions. > may be making the details element a labelable control would be simpler, as its be definition an interactive control. would it cause problems for existing <label> definitions? <details id=x> <summary> <label for=x>Foo</label> </summary> ... </details> > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 10:37:29 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 17:37:29 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342E04D.3010301@alvestrand.no> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> Message-ID: <alpine.DEB.2.00.1404071735580.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Harald Alvestrand wrote: > > The consensus opinion at WebRTC and MediaCapture seemed to be that the > ability to let an app say "which of these 5 microphones do you want?" is > more amenable to creating good apps than leaving this UI to the browser > chrome. Seems to me that the privacy aspects (the fingerprinting vulnerabilities from exposing this data), and the abuse aspects (giving hostile sites the ability to access all the user's devices if any are made available) would trump this. Surely we can rely on user agents to provide nice UIs. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sun Apr 6 13:08:16 2014 From: ian at hixie.ch (Ian Hickson) Date: Sun, 6 Apr 2014 20:08:16 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> On Sun, 6 Apr 2014, Steve Faulkner wrote: > On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > > > The <summary> itself is not interactive, so only the triangle > > > provides the actionable control. > > > > The spec doesn't disallow making clicks on (non-interactive) parts of > > the summary defer to the disclosure triangle. Browsers should just > > match platform conventions, where applicable, and otherwise make > > whatever is considered the best choice for users (such as making such > > content also trigger the disclosure triangle). > > Platform conventions for disclosure type widgets vary, on windows for > example, the current implementations match the convention. The conventions on Windows are all over the place: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx ...but I doubt that this matches any of the Windows conventions: | when the summary element includes other interactive elements (as it is | allowed to), clicking on them results in the details element being | opened/closed > > > <details> > > > <summary id=x> <label for=x>Foo</label> </summary> > > > ... > > > </details> > > > > That's way more complicated than necessary for authors, > > how so? All that should be necessary is: <details> <summary> Foo </summary> ... </details> Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. > with the current definition how do authors provide a label for the > disclosure widget when summary also contains controls with labels? If doing so matches the platform conventions, any non-interactive text in the <summary> would open the widget. > in the absence of browser making "clicks on (non-interactive) parts of > the summary defer to the disclosure triangle." how is an author supposed > to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From faulkner.steve at gmail.com Mon Apr 7 11:50:51 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Mon, 7 Apr 2014 19:50:51 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 6 April 2014 21:08, Ian Hickson <ian at hixie.ch> wrote: > On Sun, 6 Apr 2014, Steve Faulkner wrote: > > On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > > > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > > > > > The <summary> itself is not interactive, so only the triangle > > > > provides the actionable control. > > > > > > The spec doesn't disallow making clicks on (non-interactive) parts of > > > the summary defer to the disclosure triangle. Browsers should just > > > match platform conventions, where applicable, and otherwise make > > > whatever is considered the best choice for users (such as making such > > > content also trigger the disclosure triangle). > > > > Platform conventions for disclosure type widgets vary, on windows for > > example, the current implementations match the convention. > > The conventions on Windows are all over the place: > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx > > ...but I doubt that this matches any of the Windows conventions: > > | when the summary element includes other interactive elements (as it is > | allowed to), clicking on them results in the details element being > | opened/closed > Not what I said, but the current implementations use of <summary> as the interactive element matches, the first example under usage patterns http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx#patterns > > > > > > <details> > > > > <summary id=x> <label for=x>Foo</label> </summary> > > > > ... > > > > </details> > > > > > > That's way more complicated than necessary for authors, > > > > how so? > > All that should be necessary is: > > <details> > <summary> Foo </summary> > ... > </details> > > Adding two attributes and an elements is thus more complicated than > necessary. This seems pretty unambiguous to me. > for the case <details> <summary> Foo <input> Bar </summary> ... </details> whats the disclosure label? what about? <details> <summary> <label><input> Bar </label></summary> ... </details> > > in the absence of browser making "clicks on (non-interactive) parts of > > the summary defer to the disclosure triangle." how is an author supposed > > to do this? > > The author isn't supposed to do this. The whole point of semantic controls > like this is that the user agent is the one that picks the user interface. > does this also extend to the author being able to provide an accessible name for the control? > > Once we start talking about custom widgets, we're in the space of Web > components, at which point the author can do whatever the author wants. > yeah, its a shame that the design of some html features don't provide the flexibility to allow authors to fix user agent specific design deficits without recourse to web components > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 12:06:15 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 19:06:15 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Steve Faulkner wrote: > > > > All that should be necessary is: > > > > <details> > > <summary> Foo </summary> > > ... > > </details> > > > > Adding two attributes and an elements is thus more complicated than > > necessary. This seems pretty unambiguous to me. > > for the case > > <details> > <summary> Foo <input> Bar </summary> > ... > </details> > > whats the disclosure label? The text "Foo", a text field, and the text "Bar". If by "disclosure label" you mean the parts which, on certain platforms, when clicked, would toggle the open state, then that depends on the platform, but I would expect the "Foo" and "Bar" text to be good candidates, since they're otherwise inert. > what about? > > <details> > <summary> <label><input> Bar </label></summary> > ... > </details> Here there's no non-interactive text, so there's no text to target. > > > in the absence of browser making "clicks on (non-interactive) parts > > > of the summary defer to the disclosure triangle." how is an author > > > supposed to do this? > > > > The author isn't supposed to do this. The whole point of semantic > > controls like this is that the user agent is the one that picks the > > user interface. > > does this also extend to the author being able to provide an accessible > name for the control? Should there be a particular need for an accessible name for the <details> control, ARIA can be used to set the name. But I must admit to not understanding why you would need that in practice, if the page is well written. (I find most pages that use accessible labels in situations such as this tend to be poorly written for non-AT users.) > > Once we start talking about custom widgets, we're in the space of Web > > components, at which point the author can do whatever the author > > wants. > > yeah, its a shame that the design of some html features don't provide > the flexibility to allow authors to fix user agent specific design > deficits without recourse to web components Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dyoung at pobox.com Mon Apr 7 12:30:16 2014 From: dyoung at pobox.com (David Young) Date: Mon, 7 Apr 2014 14:30:16 -0500 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342E04D.3010301@alvestrand.no> References: <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> Message-ID: <20140407193016.GE7959@pobox.com> On Mon, Apr 07, 2014 at 07:28:45PM +0200, Harald Alvestrand wrote: > On 04/07/2014 06:20 PM, Ian Hickson wrote: > >When I was first desigining the API for WebRTC (years ago, before it got > >rather unceremoniously forked by the W3C), the security design I had come > >up with was basically that the UA would show a panel of devices, and the > >user would drag-and-drop them into the page to give the page access to > >them. (Or equivalent UI, e.g. tapping on the relevant device icons to > >activate them for the page.) > > This was considered, but rejected. > The consensus opinion at WebRTC and MediaCapture seemed to be that > the ability to let an app say "which of these 5 microphones do you > want?" is more amenable to creating good apps than leaving this UI > to the browser chrome. If the app disregards or misunderstands the user's input, what keeps it from using the wrong microphone? How do I disconnect a microphone from an app? How do I know which microphones are connected to which apps? Ian's proposal seems to offer this visibility and control to the user. Dave -- David Young dyoung at pobox.com Urbana, IL (217) 721-9981 From cabanier at gmail.com Tue Apr 8 04:18:22 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 04:18:22 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDCitrYeR+zoh8B+FdGyF6mQL5Pvkd=UjbdKD_Urtw_vBg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 12 Mar 2014, Rik Cabanier wrote: > > On Wed, Mar 12, 2014 at 3:44 PM, Ian Hickson wrote: > > > On Thu, 28 Nov 2013, Rik Cabanier wrote: > > > > On Thu, Nov 28, 2013 at 8:30 AM, J?rg Lehni wrote: > > > > > > > > > > I meant to say that it I think it would make more sense if the > > > > > path was in the current transformation matrix, so it would > > > > > represent the same coordinate values in which it was drawn, and > > > > > could be used in the same 'context' of transformations applied to > > > > > the drawing context later on. > > > > > > > > No worries, it *is* confusing. For instance, if you emit coordinates > > > > and then scale the matrix by 2, those coordinates from > > > > getCurrentPath will have a scale of .5 applied. > > > > > > That's rather confusing, and a pretty good reason not to have a way to > > > go from the current default path to an explicit Path, IMHO. > > > > > > Transformations affect the building of the current default path at > > > each step of the way, which is really a very confusing API. The Path > > > API on the other hand doesn't have this problem -- it has no > > > transformation matrix. It's only when you use Path objects that they > > > get transformed. > > > > This happens transparently to the author so it's not confusing. > > I've been confused by it multiple times over the years, and I wrote the > spec. I am confident in calling it confusing. > Only when you think about it :-) > > For instance: > > > > ctx.rect(0,0,10,10); > > ctx.scale(2,2); <- should not affect geometry of the previous rect > > ctx.stroke(); <- linewidth is scaled by 2, but rect is still 10x10 > > It's confusing because it's not at all clear why this doesn't result in > two rectangles of different sizes: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > ctx.scale(2,2); > ctx.stroke(); > > ...while this does: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > ctx.beginPath(); > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > > It appears to be the same path in both cases, after all. > Maybe you can think about drawing paths like drawing in a graphics application. - moveTo, lineTo, etc = drawing line segments in the document - scale = hitting the magnifying glass/zooming - translate = panning the document (0,0) is the upper left of the screen - coordinates in path segments/rect = coordinates on the screen It would be very surprising that line art would change when zooming in or out or panning. From faulkner.steve at gmail.com Tue Apr 8 05:25:14 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Tue, 8 Apr 2014 13:25:14 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> On 7 April 2014 20:06, Ian Hickson <ian at hixie.ch> wrote: > Should there be a particular need for an accessible name for the <details> > control, ARIA can be used to set the name. But I must admit to not > understanding why you would need that in practice, if the page is well > written. (I find most pages that use accessible labels in situations such > as this tend to be poorly written for non-AT users.) > All controls are expected to have an accessible name and it is expected that the author is able to assign one. this is accessibility 101 across all platforms. Lack of an accessible name or a generic accessible name or an ambiguous accessible name causes issues for users. What's the mechanism by which the anonymous control for details can be assigned an accessible name? Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. avoiding unnecessary recourse to web component use is a reasonable and expected goal - built in vs bolt on accessibility is better. Having to use a web component to overcome the inability to make a html control usable without relying on CSS and Js and ARIA is unfortunate, and as you said yesterday "once you're using custom components you've pretty much sacrificed the ability for the web to work without css and js, especially if you don't have a fallback element..." http://krijnhoetmer.nl/irc-logs/whatwg/20140407#l-396 -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From cabanier at gmail.com Tue Apr 8 09:14:50 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 09:14:50 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDAaNR6_TgZMQq2tnE8NgAoWqBDrUB+_ELZqMCPxGWe6Mg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > So this is not how most implementations currently have it defined. > > > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > > definitely do store the path in user coordinates. The spec currently > > > > says otherwise [1] though. > > > > > > I'm not sure what you're referring to here. > > > > All graphics backends for canvas that I can inspect, don't apply the CTM > > to the current path when you call a painting operator. Instead, the path > > is passed as segments in the current CTM and the graphics library will > > apply the transform to the segments. > > Right. That's what the spec says too, for the current default path. No, the spec says this: For CanvasRenderingContext2D objects, the points passed to the methods, and the resulting lines added to current default path by these methods, must be transformed according to the current transformation matrix before being added to the path. > This is the confusing behaviour to which I was referring. The "Path" API > (or > Path2D or whatever we call it) doesn't have this problem. > That is correct. The Path2D object is in user space and can be passed directly to the graphics API (along with the CTM). > ... > > > > var s = new Shape(); > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > > Shape(ctx.currentPath)); > > > > ... > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke > calls? > > > > That does not work as the second addHitRegion will remove the control and > > id from the first one. > > The 'add' operation is needed to get a union of the region shapes. > > Just use two different IDs with two different addHitRegion() calls. That's > a lot less complicated than having a whole new API. > That doesn't work if you want to have the same control for the 2 areas, from the spec for addHitRegion: If there is a previous region with this control, remove it from the scratch bitmap's hit region list; then, if it had a parent region, decrement that hit region's child count by one. Even if you don't use the control, it would be strange to have 2 separate hit regions for something that represents 1 object. > > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > ... > > > > > copy, and would help memory consummation and performance. > > > > > > I don't really understand the use case here. > > > > Jurg was just talking about an optimization (so you don't have to make > > an internal copy) > > Sure, but that doesn't answer the question of what the use case is. > >From my recent experiments with porting canvg ( https://code.google.com/p/canvg/) to use Path2D, they have a routine that continually plays a path into the context which is called from a routine that does the fill, clip or stroke. Because that routine can't simply set the current path, a lot more changes were needed. Some pseudocode that shows the added complexity, without currentPath: function drawpath() { if(Path2DSupported) { return myPath; } else for(...) { ctx.moveTo/lineTo/... } } function fillpath() { var p = drawpath(); if(p) ctx.fill(p); else ctx.fill(); } with currentPath: function drawpath() { if(Path2DSupported) { // only 2 extra lines of code ctx.currentPath = myPath; } else for(...) { ctx.moveTo/lineTo/... } function fillpath() { drawpath(); ctx.fill(); } > On Wed, 12 Mar 2014, Rik Cabanier wrote: > ... > > > You say, here are some paths, here are some fill rules, here are some > > > operations you should perform, now give me back a path that describes > > > the result given a particular fill rule. > > > > I think you're collapsing a couple of different concepts here: > > > > path + fillrule -> shape > > union of shapes -> shape > > shape can be converted to a path > > I'm saying "shape" is an unnecessary primitive. You can do it all with > paths. > > union of (path + fillrule)s -> path > No, that makes no sense. What would you get when combining a path with a fillrule and no fillrule? > > > A shape is just a path with a fill rule, essentially. > > > > So, a path can now have a fillrule? Sorry, that makes no sense. > > I'm saying a shape is just the combination of a fill rule and a path. The > path is just a path, the fill rule is just a fill rule. > After applying a fillrule, there is no longer a path. You can *convert* it back to a path that describes the outline of the shape if you want, but that is something different. The way you've defined things now, you can apply another fill rule on a path with a fill rule. What would the result of that be? > > > Anything you can do > > > with one you can do with the other. > > > > You can't add segments from one shape to another as shapes represent > > regions. > > Likewise, you can't union, intersect or xor path segments. > > But you can union, intersect, or xor lists of pairs of paths and > fillrules. > would you start throwing when doing these operations on paths without fill rules? > ... > > > > > "Wrong" meaning: > > if the author has a bunch of geometry and wants to put it in 1 path > object > > so he can just execute 1 fill operation, he might be under the impression > > that "adding" the geometry will just work. > > Well, sure, an author might be under any number of false impressions. > > The API has a way for a bunch of paths to be merged with a single fillrule > to generate a new path with no crossing subpaths (which is also fillrule > agnostic), essentially giving you the union of the shapes represented by > those paths interpreted with that fillrule. > Is this the API you're referring to? path = new Path2D(paths [, fillRule ] ) The first argument could point to paths that need different winding rules so this won't work. What if one of the paths already had a fill rule? This doesn't seem implementable/stable. > There are very few use cases where you want to add partial path segments > > together but I agree that there are some cases that it's useful to have. > > I disagree that there few such cases. Pretty much any time you create a > path, you are adding partial path segments together. Whether you do so > using one Path object all at once or multiple Path objects that you later > add together is just a matter of programming style. > It's the multiple path objects use case that is unclear to me. Is there any tool/library that does this? Looking at Adobe's graphics applications, there isn't anything like it. Looking at graphics APIs, I don't see any calls that combine paths directly. hmm, it seems the spec has changed. It didn't used to start with "Create a new path that describes the edge of the areas" With the new wording, the last sentence should be updated: Subpaths in the newly created path must wind clockwise, regardless of the direction of paths in path. Since you now create 'holes', the separate paths need to be reoriented like you specify in other parts. > ... > > > > I want them removed because they will most likely not behave in the > > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > > expect that there is 'interference' between them. > > > > > > I don't see why not. It's exactly what happens today if you were to > > > just add the same path creation statements together into the current > > > default path and fill or stroke that. > > > > Sure but who does that? > > It's how all paths are built, as far as I can tell. I don't see how else > you could build a path that consists of more than one line. > > addPath() is useful for shifting a path according to a transform. > Why not just transform() then? addPathByStrokingPath() is for creating a stroked path. > addText() is for writing text. > > I don't see how removing any of them is a win. > Yes, they are useful. The issue is that they are not implementable as currently specified. > > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > ... > > > > > > > > > How would you get a point? the width is scaled to 0. > > > > > > That's how you get a point -- scale(0,0) essentially reverts > > > everything to a zero dimensional point. > > > > OK, but the width of the point is also transformed to 0 so you get > > nothing. > > Points are always zero-width, by definition. > You can still stroke it though and get a point of the strokewidth. > ... > > However the way you defined those APIs does not make sense and will not > > give the result that authors want. > > The way to make this point would be to start from the use case, describe > the desired effect, show the "obvious" way to achieve this using the API, > and then demonstrate how it doesn't match the desired effect. > The obvious way is to go with Shape2D. It's not because I invented it; many advanced graphics APIs came offer this (including D2D and skia) > ... > > > So, it's not realistic to add this to the Path2D object. > > I don't really see why it's unrealistic. In most cases, the user agent > doesn't actually have to do any work -- e.g. if all that you're doing is > merging two paths so that you can fill them simultaneously later, the UA > can just keep the two paths as is and, when necessary, fill them. > > For cases where you really want to have this effect -- e.g. when you want > to get the outline of the dashed outline of text -- then I don't really > see any way to work around it. > That is true. That is why I proposed to make the interface more limited for now until there is a time that this functionality is available. >From Ian Hickson: > I don't think the spec should be written with a particular > implementation in mind, nor should it dictate one. I agree it shouldn't (and doesn't) dictate one. But it's crazy to not consider implementations at all when writing a spec. That way lies madness like requiring O(N^2) algorithms and solving the halting problem and all kinds of other disasters (all of which I've seen in real proposals). > > The reason for that is that even though a UA could emulate the union by > > doing multiple fill operations, Path2D allows you to stroke another path > > object. At that point, you really have to do planarization. By defining > > a Shape2D object and not allowing it to be stroked, we can work around > > this. > > Sure, by limiting the feature set dramatically we can avoid the cases > where you have to do the hard work, but we also lose a bunch of features. > For now. They can be added later. Until then, this is confusing implementors. > ... > > > > Where is the union of fill regions specified? All I see is segments > > aggregation. > > One of the Path constructors takes an array of paths and a fill rule. > See above. > > > > No one has implemented them and they are confusing the browser > > > > vendors. > > > > > > I don't think they're confusing anyone. > > > > The blink people were looking at adding this until they thought it > > through and realized that it wouldn't work. > > Realised what wouldn't work? As far as I'm aware, there's nothing that > wouldn't work. > See this thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/168925.html I think you already addressed some of the concerns. Doing the planarization is now the problem so we can't implement this. > ... > > How can you make that statement? No one has implemented them yet. > > What do you mean by "stable"? > > I assumed you meant "hasn't been changing a lot". The spec hasn't been > changing a lot, so it seems pretty stable. > You've been making a lot of changes lately so this not quite true. Because you wrote it a long time ago and nobody looked at it until now, doesn't mean that it is stable. From ian at hixie.ch Mon Apr 7 15:35:50 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 22:35:50 +0000 (UTC) Subject: [whatwg] <canvas> feedback In-Reply-To: <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> (Note: I started responding to this feedback last week, so this is missing responses to feedback sent in the last few days. Sorry about that. I'll get to that feedback in due course as well!) On Mon, 3 Mar 2014, Justin Novosad wrote: > > Say you create a new document using > document.implementation.createHTMLDocument(), you get a document without > a browsing context. This means that style and layout will never be > calculated on the document. Some of those calculations are context > dependent, so they can't even be resolved. Now, what about canvas > elements? If JS code draws to a canvas that is in a document with no > browsing context, what should happen? It should draw. In theory, anywhere in the canvas API where it depends on computed styles, it has prose saying what should happen if the computed style cannot be used. This is needed for display:none canvases, for 2D contexts in workers, and for the case you describe. > For example, there is no locale for font family resolution I'm not clear on what you mean by "locale" here. What is the locale that a displayed <canvas> in a Document in a browsing context has, that a non-displayed <canvas> outside a Document and without a browsing context does not have? > and it is not possible to resolve font sizes in physical length units > unless the document is associated with a view. Why not? The canvas has a pixel density (currently always 1:1), no? > My 2 cents: specifying fallback behaviors for all use cases that are > context dependent could be tedious and I have yet to see a real-world > use case that requires being able to paint a canvas in a frame-less > document. Therefore, I think the spec should clearly state <canvas> > elements that are in a document without a browsing context are unusable. > Not sure what the exact behavior should be though. Should an exception > be thrown upon trying to use the rendering context? Perhaps canvas draws > should fail silently, and using the canvas as an image source should > give transparent black pixels? As far as I can tell, this is all already specified, and it just gets treated like a normal canvas. On Wed, 5 Mar 2014, Rik Cabanier wrote: > > Testing all browsers (except IE since > document.implementation.createHTMLDocument() doesn't work) they seem to > handle canvas contexts with no browsing context except when you use > text. Chrome crashes, firefox throws an exception and Safari draws the > text with a very small scale I don't really understand why this is problematic in practice. What does a browsing context provide that is needed for rendering text that a user agent couldn't fake for itself in other contexts? We're definitely going to need text in worker canvases. On Thu, 6 Mar 2014, Justin Novosad wrote: > > Thanks for checking. The reason I started this thread is that I just > recently solved the crash in Chrome, and I wasn't satisfied with my > resolution. I just added an early exit, so Chrome 35 will fail silently > on calls that depend on style resolution when the canvas has no browsing > context. So now we have three different behaviors. Yay! > > I don't think the Safari behavior is the right thing to do because it > will never match the developer's intent. I agree. The developer's intent is that text be drawn as specified in the API. Why would we do anything else? On Wed, 12 Mar 2014, Rik Cabanier wrote: > On Wed, Mar 12, 2014 at 3:44 PM, Ian Hickson wrote: > > On Thu, 28 Nov 2013, Rik Cabanier wrote: > > > On Thu, Nov 28, 2013 at 8:30 AM, J?rg Lehni wrote: > > > > > > > > I meant to say that it I think it would make more sense if the > > > > path was in the current transformation matrix, so it would > > > > represent the same coordinate values in which it was drawn, and > > > > could be used in the same 'context' of transformations applied to > > > > the drawing context later on. > > > > > > No worries, it *is* confusing. For instance, if you emit coordinates > > > and then scale the matrix by 2, those coordinates from > > > getCurrentPath will have a scale of .5 applied. > > > > That's rather confusing, and a pretty good reason not to have a way to > > go from the current default path to an explicit Path, IMHO. > > > > Transformations affect the building of the current default path at > > each step of the way, which is really a very confusing API. The Path > > API on the other hand doesn't have this problem -- it has no > > transformation matrix. It's only when you use Path objects that they > > get transformed. > > This happens transparently to the author so it's not confusing. I've been confused by it multiple times over the years, and I wrote the spec. I am confident in calling it confusing. > For instance: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); <- should not affect geometry of the previous rect > ctx.stroke(); <- linewidth is scaled by 2, but rect is still 10x10 It's confusing because it's not at all clear why this doesn't result in two rectangles of different sizes: ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); ctx.scale(2,2); ctx.stroke(); ...while this does: ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); ctx.beginPath(); ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); It appears to be the same path in both cases, after all. > > > > So this is not how most implementations currently have it defined. > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > definitely do store the path in user coordinates. The spec currently > > > says otherwise [1] though. > > > > I'm not sure what you're referring to here. > > All graphics backends for canvas that I can inspect, don't apply the CTM > to the current path when you call a painting operator. Instead, the path > is passed as segments in the current CTM and the graphics library will > apply the transform to the segments. Right. That's what the spec says too, for the current default path. This is the confusing behaviour to which I was referring. The "Path" API (or Path2D or whatever we call it) doesn't have this problem. > > > Another use case is to allow authors to quickly migrate to hit regions. > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); > > > ... // lots of complex drawing operation for a control > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); > > > > > > > > > To migrate that to a region (with my proposed shape interface [1]): > > > > > > var s = new Shape(); > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > Shape(ctx.currentPath)); > > > ... > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke calls? > > That does not work as the second addHitRegion will remove the control and > id from the first one. > The 'add' operation is needed to get a union of the region shapes. Just use two different IDs with two different addHitRegion() calls. That's a lot less complicated than having a whole new API. > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > > > > > > Instead of using getCurrentPath and setCurrentPath methods as a > > > solution, this could perhaps be solved by returning the internal > > > path instead of a copy, but with a flag that would prevent further > > > alterations on it. > > > > > > The setter of the currentPath accessor / data member could then make > > > the copy instead when a new path is to be set. > > > > > > This would also make sense from a a caching point of view, where > > > storing the currentPath for caching might not actually mean that it > > > will be used again in the future (e.g. because the path's geometry > > > changes completely on each frame of an animation), so copying only > > > when setting would postpone the actual work of having to make the > > > copy, and would help memory consummation and performance. > > > > I don't really understand the use case here. > > Jurg was just talking about an optimization (so you don't have to make > an internal copy) Sure, but that doesn't answer the question of what the use case is. On Wed, 12 Mar 2014, Rik Cabanier wrote: > > > > > > > > You can do unions and so forth with just paths, no need for > > > > regions. > > > > > > How would you do a union with paths? If you mean that you can just > > > aggregate the segments, sure but that doesn't seem very useful. > > > > You say, here are some paths, here are some fill rules, here are some > > operations you should perform, now give me back a path that describes > > the result given a particular fill rule. > > I think you're collapsing a couple of different concepts here: > > path + fillrule -> shape > union of shapes -> shape > shape can be converted to a path I'm saying "shape" is an unnecessary primitive. You can do it all with paths. union of (path + fillrule)s -> path > > A shape is just a path with a fill rule, essentially. > > So, a path can now have a fillrule? Sorry, that makes no sense. I'm saying a shape is just the combination of a fill rule and a path. The path is just a path, the fill rule is just a fill rule. > > Anything you can do > > with one you can do with the other. > > You can't add segments from one shape to another as shapes represent > regions. > Likewise, you can't union, intersect or xor path segments. But you can union, intersect, or xor lists of pairs of paths and fillrules. > > > > > The path object should represent the path in the graphics state. > > > > > You can't add a stroked path or text outline to the graphics > > > > > state and then fill/stroke it. > > > > > > > > Why not? > > > > > > As designed today, you could fill it, as long as you use non-zero > > > winding. If you use even-odd, the results will be very wrong. (ie > > > where joins and line segments meet, there will be white regions) > > > > I think "wrong" here implies a value judgement that's unwarranted. > > "Wrong" meaning: > if the author has a bunch of geometry and wants to put it in 1 path object > so he can just execute 1 fill operation, he might be under the impression > that "adding" the geometry will just work. Well, sure, an author might be under any number of false impressions. The API has a way for a bunch of paths to be merged with a single fillrule to generate a new path with no crossing subpaths (which is also fillrule agnostic), essentially giving you the union of the shapes represented by those paths interpreted with that fillrule. > There are very few use cases where you want to add partial path segments > together but I agree that there are some cases that it's useful to have. I disagree that there few such cases. Pretty much any time you create a path, you are adding partial path segments together. Whether you do so using one Path object all at once or multiple Path objects that you later add together is just a matter of programming style. > > > Stroking will be completely wrong too, because joins and end caps > > > are drawn separately, so they would be stroked as separate paths. > > > This will not give you the effect of a double-stroked path. > > > > I don't understand why you think joins and end caps are drawn > > separately. That is not what the spec requires. > > Sure it does, for instance from > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path > : > > The round value means that a filled arc connecting the two > aforementioned corners of the join, abutting (and not overlapping) the > aforementioned triangle, with the diameter equal to the line width and > the origin at the point of the join, must be added at joins. > > If you mean, "drawn with a separate fill call", yes that is true. > What I meant was that they are drawn as a separate closed path that will > interact with other paths as soon as there are different winding rules or > "holes". The word "filled" is a bit misleading here (I've removed it), but I don't see why that led you to the conclusion you reached. The step in question begins with "Create a new path that describes the edge of the areas that would be covered if a straight line of length equal to the styles lineWidth was swept along each path in path while being kept at an angle such that the line is orthogonal to the path being swept, replacing each point with the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, and replacing each join with the join necessary to satisfy the styles lineJoin type, as defined below", which seems pretty unambiguous. > > > > We seem to be going around in circles. We're in agreement that > > > > eventually we should add APIs for combining paths such that we get > > > > the equivalent of the union of their fill regions. I agree that > > > > converting text into paths is non-trivial (lots of stuff browsers > > > > do is non-trivial, that's kind of the point -- if it was trivial, > > > > we could leave it for authors). But I don't see how we get from > > > > there to you wanting the existing APIs removed. > > > > > > I want them removed because they will most likely not behave in the > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > expect that there is 'interference' between them. > > > > I don't see why not. It's exactly what happens today if you were to > > just add the same path creation statements together into the current > > default path and fill or stroke that. > > Sure but who does that? It's how all paths are built, as far as I can tell. I don't see how else you could build a path that consists of more than one line. addPath() is useful for shifting a path according to a transform. addPathByStrokingPath() is for creating a stroked path. addText() is for writing text. I don't see how removing any of them is a win. > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > > > > > > > > > > However, for your example, I'm unsure what the right solution > > > > > is. The canvas specification is silent on what the behavior is > > > > > for non-invertible matrices. > > > > > > > > What question do you think the spec doesn't answer? > > > > > > > > > I think setting scale(0,0) or another matrix operation that is > > > > > not reversible, should remove drawing operations from the state > > > > > because: - how would you stroke with such a matrix? > > > > > > > > You'd get a point. > > > > > > How would you get a point? the width is scaled to 0. > > > > That's how you get a point -- scale(0,0) essentially reverts > > everything to a zero dimensional point. > > OK, but the width of the point is also transformed to 0 so you get > nothing. Points are always zero-width, by definition. > We've gone over this several times now. > The APIs that you define, have use cases and I agree with them. > However the way you defined those APIs does not make sense and will not > give the result that authors want. The way to make this point would be to start from the use case, describe the desired effect, show the "obvious" way to achieve this using the API, and then demonstrate how it doesn't match the desired effect. > What you specified there is called "planarization". This is when you > calculate the intersections within and between closed shapes and remove the > line segments that are filled on both sides. > By specifying this: > > The subpaths in merged path must be oriented such that for any point, the > number of times a half-infinite straight line drawn from that point crosses > a subpath is even if and only if the number of times a half-infinite > straight line drawn from that same point crosses a subpath going in one > direction is equal to the number of times it crosses a subpath going in the > other direction. > > and relying on segment removal, you also get the same fill behavior for > even-odd. (Meaning that the end result can be used with either winding rule) > This is not something that is needed for just text but also when you do a > union of shapes. > > The bad news is that this algorithm is very expensive and there are few > libraries that do a decent job (I only know of 1). > So, it's not realistic to add this to the Path2D object. I don't really see why it's unrealistic. In most cases, the user agent doesn't actually have to do any work -- e.g. if all that you're doing is merging two paths so that you can fill them simultaneously later, the UA can just keep the two paths as is and, when necessary, fill them. For cases where you really want to have this effect -- e.g. when you want to get the outline of the dashed outline of text -- then I don't really see any way to work around it. > The reason for that is that even though a UA could emulate the union by > doing multiple fill operations, Path2D allows you to stroke another path > object. At that point, you really have to do planarization. By defining > a Shape2D object and not allowing it to be stroked, we can work around > this. Sure, by limiting the feature set dramatically we can avoid the cases where you have to do the hard work, but we also lose a bunch of features. > > I don't think the arguments for removing these are compelling. The > > problems with the APIs have been addressed (e.g. there's no ambiguity > > in the case of overlapping text), the use cases are clear (e.g. > > drawing text around an arc or drawing a label along a line graph's > > line), and the API now supports the constructs to do unions of fill > > regions. > > Where is the union of fill regions specified? All I see is segments > aggregation. One of the Path constructors takes an array of paths and a fill rule. > > > No one has implemented them and they are confusing the browser > > > vendors. > > > > I don't think they're confusing anyone. > > The blink people were looking at adding this until they thought it > through and realized that it wouldn't work. Realised what wouldn't work? As far as I'm aware, there's nothing that wouldn't work. > > > Until we have support for shapes, the output of these methods won't > > > be stable. > > > > These methods have been very stable. They have barely changed since > > they were added, except for some minor tweaks to fix bugs. > > How can you make that statement? No one has implemented them yet. What do you mean by "stable"? I assumed you meant "hasn't been changing a lot". The spec hasn't been changing a lot, so it seems pretty stable. On Fri, 14 Mar 2014, Justin Novosad wrote: > On Fri, Mar 14, 2014 at 2:29 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > If the bug is that Chrome resamples the image in an ugly way, then > > that's a bug with Chrome. As the bug says, browsers are allowed to > > pick whatever algorithm they want -- it's a quality-of-implementation > > issue. But if the result is ugly, that's a low quality implementation. > > Yes, and if we fixed it to make it prettier, people would complain about > a performance regression. It is impossible to make everyone happy right > now. Would be nice to have some kind of speed versus quality hint. The problem with a hint is that it will be set incorrectly, and so instead of having something that's mostly pretty but mostly fast for everyone, you'd end up with something that's slow on sites that need things to be fast, and things that are ugly on sites that need things to be pretty. In general I think it is very unwise for us to design APIs with hints that have subtle effects on developer machines but that can cripple performance on low-end devices. Instead, we should use adaptive algorithms, for example always using the prettiest algorithms unless we find that frame rate is suffering, and then stepping down to faster algorithms. On Wed, 26 Mar 2014, K. Gadd wrote: > > As I mentioned to Ryosuke off-list, I think the > interpolateEndpointsCleanly attribute is a (relatively) simple solution > to the problem I have with the current spec, and it doesn't > overcomplicate things or make it hard to improve filtering in the > future. It's also trivial to feature-detect, which means I can use it > when available and fallback to a temporary canvas otherwise. I think > providing this option would also make it easier to solve situations > where applications rely on the getImageData output after rendering a > scaled bitmap. > > I'd probably call it something (to me) clearer about semantics, though, > like 'sampleInsideRectangle' Here you are suggesting a feature that would override the requirement in the spec that reads "When the filtering algorithm requires a pixel value from outside the source rectangle but inside the original image data, then the value from the original image data must be used", right? What would you replace it with, exactly? Transparent black? The value from the nearest edge pixel inside the rectangle? Can you elaborate on the use case? On Fri, 14 Mar 2014, Rik Cabanier wrote: > On Fri, Mar 14, 2014 at 11:09 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 4 Dec 2013, J?rg Lehni wrote: > > > > > > Implementing [layering/grouping] would help us greatly to optimize > > > aspects of Paper.js, as double buffering into separate canvases is > > > very slow and costly. > > > > Can you elaborate on what precisely the performance bottleneck is? I > > was looking through this thread but I can't find a description of the > > use cases it addresses, so it's hard to evaluate the proposals. > > Let's say you're drawing a scene and there is a bunch of artwork that > you want to apply a multiply effect or opacity to. With today's code, it > would look something like this: > > var bigcanvas = document.getElementById("c"); > var ctx = bigcanvas.getContext("2d"); > ctx.moveto();.... // drawing underlying scene > > ctx.globalAlpha(.5); > var c = document.createElement("canvas"); > ctx2 = c.getContext("2d"); > ctx2.moveto();.... // drawing scene that needs the effect > ctx.drawImage(c, 0, 0); > > With layers, it would become: > > var bigcanvas = document.getElementById("c"); > var ctx = bigcanvas.getContext("2d"); > ctx.moveto();.... // drawing underlying scene > > ctx.globalAlpha(.5); > ctx.beginLayer(); > ctx.moveto();.... // drawing scene that needs the effect > ctx.endLayer(); > > So, with layers you > - avoid creating (expensive) DOM elements Not really though, right? I mean, the user agent still has to create the intermediate bitmap to apply the effects to. > - simplify the drawing (especially when there's a transformation) Why would it be simpler? There's a bug tracking this feature currently: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22704 On Fri, 14 Mar 2014, Rik Cabanier wrote: > > Path2D has now landed in Blink [1]. Blink also implemented the 'addPath' > method. > WebKit just landed a patch to rename Path to Path2D, remove currentPath and > add fill/stroke/clip with a path [2]. > A patch is under review for Firefox to add Path2D. > > Given this, can we change the spec to reflect the new name? > > 1: https://codereview.chromium.org/178673002/ > 2: https://webkit.org/b/130236 > 3: https://bugzilla.mozilla.org/show_bug.cgi?id=830734 Done. On Tue, 18 Mar 2014, J?rg Lehni wrote: > > So is currentPath going away then for sure? Will there still be a way to > to retrieve a Path2D representation of the path being drawn by the long > existing drawing commands on the context? > > I quite liked how I could use it for caching, in case the browser > supported that feature, and check wether I have a cached path the next > time I need to draw it, falling back on redrawing it using the same > drawing commands. Doing the same by feature-detecting the Path(2D) > constructor and building separate drawing approaches based on its > existence results in much more complicated code. Why is it so complicated? Here's an example of how you could do it, assuming you wanted to cache certain paths function myCircle(p) { p.moveTo(0,0); // etc... } function fillPath(c, callback) { if (window.Path2D) { var p; if (pathIsAlreadyCached(callback.name)) { p = getCachedPath(callback.name); } else { p = new Path2D(); callback(p); saveCachedPath(p, callback.name); } c.fill(p); } else { c.beginPath(); callback(c); c.fill(); } } fillPath(c, myCircle); On Tue, 18 Mar 2014, Dirk Schulze wrote: > > I am still in favor for a setter and getter as well. It had the benefit > that you were able to transform the context and it affected drawing > commands as well. It is more complicated to create a second Path2D > object and add it to a previous path with a transform. I'm not sure I understand what you mean. The interactions of transforms and path building on the 2D context was one of the biggest problems that the Path objects are intended to side-step. On Fri, 14 Mar 2014, Rik Cabanier wrote: > > > > Event retargetting now explicitly applies to "the control represented > > by the region", which is always null if the given control is now a > > text field. > > Does this change the eventTarget attribute on the event object [1]. It changes the "target" attribute, if that's what you mean. (See step 3 of the dispatch algorithm in DOM.) > > > More generally, is this event rerouting supposed to be able to > > > trigger browser default event handling behavior, or only DOM event > > > dispatch? > > > > As it was specified, I don't see how it could trigger default actions > > of anything other than the canvas and its ancestors. The canvas hook > > ran in the middle of the "When a pointing device is clicked, the user > > agent must run these steps" algorithm, which refers to the origin > > target, not the rerouted target. > > > > I've now changed this so that it does in fact trigger the default > > action if applicable. > > This will still just reroute events, right? Not sure what you mean by "just". > For instance, if the fallback element is a <a href="...">, will clicking > on the region cause the browser to follow the hyperlink? Yes. > > On Wed, 5 Mar 2014, Robert O'Callahan wrote: > > > > > > The problem is that if these retargeted events can trigger default > > > browser behavior, the browser has to be able to compute the position > > > of the event relative to the new target DOM node, and it's not clear > > > how to do that. > > > > I've made it explicit that the elements that can get clicks targetted > > to them only include elements that don't have subregions. In > > particular, image maps and image buttons are excluded. > > Thanks for updating the spec. It's getting quite complex though :-( > Maybe it's simpler to just add the id to the event and leave the canvas > element as the target? Since this is not a major feature, the complexity > might stop implementors. I don't understand what part you think is complicated here. Can you elaborate? > > > Currently, the specification states that if you create a region and > > > then create another region that completely covers region, the first > > > region is removed from the hit region list [1] > > > > > > This is a complex operation that involves either drawing the regions > > > to a bitmaps and counting pixels, or path intersection. > > > > There's two trivial ways to implement this, depending on whether the > > hit regions are backed by a bitmap (the simplest and fastest solution > > but uses a lot of memory) or a region list (slower, but much more > > memory efficient). In the case of a bitmap, you just draw on the new > > region, and the old region is no longer in the bitmap, so it's > > trivially gone. > > > > In the case of a list, you put the new region ahead of the old region > > so that you never actually get around to checking the old region. > > The following step still needs to run though: > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#garbage-collect-the-regions > > Let victim be the first hit region in list to have an empty set of > pixels and a zero child count, if any. > > If this was implemented with a bitmap, the only way to figure this out > is to walk the individual pixels (= expensive). This is garbage collection, it doesn't have to run often. When it _is_ run, it's actually pretty fast -- in the bitmap case, for example, you just need to walk the bitmap and for every pixel with a defined region mark the region as non-empty. This is O(N) with the size of the bitmap, but with a _very_ low constant factor (lower than recolourising a bitmap, say, which is something we expect authors to do in JS). > We should also not forget that a11y needs the bounding box of the hit > region which also means constantly walking of the pixels. Not "constantly". This kind of thing is trivially cacheable. It's also relatively simple to just check the pixels you're about to overwrite and note those regions as needing updating; when you _do_ update them, they can only have gotten smaller so you can just walk the edge of the bounding rectangle until you hit a pixel on each side. Plus, the bounding box doesn't have to be updated often -- the user isn't going to be jumping to the area every ten milliseconds or anything, and even if the user did, using a slightly out-of-date bounding box is fine (it'll just be bigger than strictly necessary). > > > It is also unintuitive because an author might expect that he could > > > remove the second region and still have the first region active. > > > > That would be inconsistent with how canvas works. Canvas is an > > immediate-mode API. If you draw on the canvas, and then clear it, you > > don't get back what was there before. > > What if an author doesn't clear it but just calls fillRect or is smart > and just invalidates/redraws portions of the canvas? Hit regions should > keep state, regardless of the canvas pixels. Those would just work, as far as I can tell. Do you have a concrete example? > > > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/thread.html#36556 > > > > > > It looks like that thread never came to a conclusion. > > > > Is there anything specifically that was raised in that thread that you > > think hasn't been responded to? > > Well, you had the last response but I don't think it came to a > conclusion :-) If people don't respond to my requests for clarification or if they don't disagree with the last thing I say, then that's a conclusion... > At the time, I was under the impression that we could mimic it with > paths but when I read the spec closer, the step that removes the region > pixels is too complex to implement and unintuitive for authors [2] As discussed earlier in this thread, it's easy to implement this using a list of paths, you just draw the cleared pixels as a new region on the top of your list. I don't see what's unintuitive here. > > > The arguments against using a bitmap presentation still stand: - it > > > will be too expensive to keep an actual copy of the canvas pixels in > > > memory to do hit testing > > > > It's actually pretty common to do exactly this. Note that you don't > > necessarily need a bitmap that has the same bit depth or pixel density > > as the visible bitmap. > > Where else does this happen? A Google search for "hit test bitmap" shows some examples, but unfortunately it's a hard topic to search for -- I kept running into examples of people trying to do collision detection with bitmaps instead! > Creating a canvas bitmap for constant reading will also be extremely > costly since so many implementations run canvas operations on the GPU. > I'm unsure if anyone supports a 8 bit backbuffer so at best, the hit > region bitmap is half the size. This is too expensive. Don't forget that this doesn't have to be a very high fidelity bitmap. It doesn't get any anti-aliasing, it has no alpha transparency, there's no bitmap drawing, it doesn't necessarily have to be full-density, either (it's unlikely that authors are going to have hit regions that are half a CSS pixel high, for instance). It's quite plausible to do all the work for this bitmap in software on the CPU, as far as I can tell. You can also use a hybrid approach, with the most recent regions added to a list, and the list regularly compressed down to a bitmap when the CPU load is low, or on a separate thread, such that the bitmap generation cost is a non-issue, while still not having to pay the cost of having all the regions in a long list, and while having the GC computations described earlier be reasonably straight-forward to compute (modulo inter-thread communication, which is always fun). > > > - if you have to mimic the behavior with paths, you need access to > > > expensive/difficult path manipulation algorithms > > > > The maths for determining if a region is contained in another region > > is pretty well understood at this point, as far as I can tell. > > It's still a hard problem. Looking at Firefox' and Apple's > implementation, I don't know how they could determine if a path is > contained within another path. Google has a library in development. We > looked at it 6 months ago and it had many issues. Our job is to implement these hard problems so that authors don't have to. > > > Hit regions should be redesigned so they work on the path geometry > > > as opposed to pixels. We already have the necessary code to do hit > > > testing on paths (see isPointInPath) > > > > isPointInPath() works on pixels just like hit regions works on pixels. > > No, this is not how it's implemented. > WebKit, Blink and Firefox use the geometry of the path. They don't use > pixels. That's an implementation detail. My point is that to an author, it's all pixels. The API takes in two coordinates, and gives you a boolean result. > > On Wed, 12 Mar 2014, Dirk Schulze wrote: > > > > > > In SVG we tried to avoid having hit testing based on pixel values > > > obviously for performance reasons. > > > > SVG is a retained-mode API, so naturally it has a different model. > > I don't see why. A browser draws the SVG DOM to a screen bitmap and then > does hit testing with fine paths. Canvas could do the exact same thing. If Canvas and SVG do "the exact same thing", then we should drop one. The whole point of <canvas> is to be an immediate-mode API that complements SVG. > People think of this API as populating a hit region OM. Why not go this > route? What people? > > > clearRect is currently defined as a subtraction mechanism for hit > > > regions [1]. > > > > > > It's unlikely that a UA will implement hit regions using pixels so > > > this would have to be done using path subtraction which is > > > expensive. > > > > I'm not sure why you think it's expensive. It's trivial to just add a > > rectangle to the front of the list of regions. > > That is true. This does mean that if there are a lot of small clearRect > calls, the list of regions could become very long. Sure. Same with if there are a lot of rectanglular hit regions added. The model above, where you start off with a list, but regularly flatten it to a bitmap, would lower the cost of maintaining such a list. > > > Why was this special behavior added to clearRect? > > > > Because it's the most obvious mechanism for authors. You clear a part > > of the canvas, naturally that part of the canvas no longer has > > regions. > > Why is that naturally? Because nothing is rendered there any more. > So, if an author clears an area there are no more regions in it, but if > he draws over it, they are still there? Right. Same as with regular drawing. If you clear it, it's gone. If you draw on top of it, it contributes (e.g. in the colour of anti-aliased lines, showing through where the content on top is transparent, etc). > Clipping also doesn't affect regions. Hm, good point. Fixed. > > On Tue, 4 Mar 2014, Rik Cabanier wrote: > > > > > > The spec implies-- > > > > The spec doesn't imply anything. It either requires something, or > > doesn't. If you ever find yourself reading between the lines, then > > there is either a spec bug, or you are reading something that the spec > > doesn't require. > > I know that. So, if I write "the spec implies", you can assume that I > believe that the spec is incomplete. I would rather you just said "the spec doesn't say whether..." rather than "the spec implies", since the latter has a very different meaning. On Sat, 15 Mar 2014, Dirk Schulze wrote: > > I would suggest a filter attribute that takes a list of filter > operations similar to the CSS Image filter function. Similar to > shadows[2], each drawing operation would be filtered. The API looks like > this: > > partial interface CanvasRenderingContext2D { > attribute DOMString filter; > } > > A filter DOMString could looks like: ?contrast(50%) blur(3px)? > > With the combination of grouping in canvas it would be possible to > group drawing operations and filter them together. > > Filter functions include a reference to a <filter> element and a > specification of SVG filters. I am unsure if a reference do an element > within a document can cause problems. If it does, we would just not > support SVG filter references. I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25243 On Mon, 17 Mar 2014, Justin Novosad wrote: > > Hmmm, I gave this a bit more thought... To apply the construction > algorithm in transformed space, the ellipse parameters (radiusX, > radiusY, rotation) would have to be transformed. Transforming the > parameters would be intractable under a projective transform (e.g. > perspective), but since we are limitted to affine transforms, it can be > done. Now, in the case of a non-invertible CTM, we would end up with > radiusX or radiusY or both equal to zero. And what happens when you > have that? Your arcTo just turned into lineTo(x1, y1). Tada! On Mon, 17 Mar 2014, Dirk Schulze wrote: > > Why does radiusX or radiusY need to be zero? Because you define it that > way for a non-invertible matrix? That makes sense for scale(0,0). What > about infinity or NaN? If Ian didn?t update the spec then this is still > undefined and therefore up to the UA to decide. How can it be infinity or NaN? (Recall that except where otherwise specified, for the 2D context interface, any method call with a numeric argument whose value is infinite or a NaN value must be ignored.) On Mon, 17 Mar 2014, Rik Cabanier wrote: > > I'm unsure if anyone has shipped that part of the spec. There's > certainly no interop... I am loathe to keep changing this kind of thing. We settled this part of the spec years ago. Let's not go back now. If we keep changing things like this, people will (rightly) complain that they can't trust the spec. > So, what we could say is: > - when drawing paths, ignore all calls if the matrix is non-invertible > (WebKit and Blink do this) > - when filling/stroking/clipping, ignore all calls if the matrix is > non-invertible (Firefox, WebKit and Blink do this) As far as I can tell, this is unnecessary. On Mon, 17 Mar 2014, Justin Novosad wrote: > > Yes, but there is still an issue that causes problems in Blink/WebKit: > because the canvas rendering context stores its path in local > (untransformed) space, whenever the CTM changes, the path needs to be > transformed to follow the new local spcae. This transform requires the CTM > to be invertible. So now webkit and blink have a bug that causes all > previously recorded parts of the current path to be discarded when the CTM > becomes non-invertible (even if it is only temporarily non-invertible, even > if the current path is not even touched while the matrix is > non-invertible). I have a fix in flight that fixes that problem in Blink by > storing the current path in transformed coordinates instead. I've had the > fix on the back burner pending the outcome of this thread. Indeed. It's possible to pick implementation strategies that just can't be compliant; we shouldn't change the spec every time any implementor happens to make that kind of mistake, IMHO. (Of course the better long-term solution here is the Path objects, which are transform-agnostic during building.) Just to be clear, we should support this because otherwise the results are just wrong. For example, here some browsers currently show a straight line in the default state, and this causes the animation to look ugly in the transition from the first frame to the secord frame (hover over the yellow to begin the transition): http://junkyard.damowmow.com/538 Contrast this to the equivalent code with the transforms explicitly multiplied into the coordinates: http://junkyard.damowmow.com/539 I don't see why we would want these to be different. From the author's perspective, they're identical. On Thu, 20 Mar 2014, Rik Cabanier wrote: > > It would be great if we could get clarification on this. I'm not sure what needs clarifying. The spec seems clear here. > Firefox and IE are conformant per the spec when it comes to drawing paths > but not fill/stroke/clip. Can you elaborate on how Firefox doesn't match the spec for stroke and clip? For fill, it does indeed seem to ignore the rule in the spec that says that fill solid colours are unaffected by the current transformation. It has a similar impact on renderings as the examples above: http://junkyard.damowmow.com/540 > Supporting this small edge case comes at a large cost in Firefox and > likely also IE. Can you elaborate on this cost? > Many APIs in canvas are running into this issue which results in lack of > interoperability. As far as I can tell, the spec is unambiguous. Certainly it does appear that browsers haven't yet converged on what the spec says, but that isn't unusual; it takes time for browsers to converge, especially for edge cases like this where there's not much pressure (since authors tend to just work around the bugs). On Wed, 19 Mar 2014, Dirk Schulze wrote: > > I just looked at the definition of Path.addPath[1]: > > void addPath(Path path, SVGMatrix? transformation); > > SVGMatrix is nullable but can not be omitted all together. Why isn?t it > optional as well? I think it should be optional [...] That seems reasonable. Done. On Wed, 19 Mar 2014, Rik Cabanier wrote: > > [context . currentTransform] > > As currently specified, this must return a live SVGMatrix object, > meaning that as you change the CTM on the 2d context, your reference to > the SVGMatrix should change as well. > > It's unlikely that you actually want this... Why? See Chris' original proposal here: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Mar/0269.html I would be reluctant to change this to a different design without their input. On Fri, 21 Mar 2014, Joe Gregorio wrote: > On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > > > I just looked at the definition of Path.addPath[1]: > > > > void addPath(Path path, SVGMatrix? transformation); > > > > SVGMatrix is nullable but can not be omitted all together. Why isn?t it > > optional as well? I think it should be optional, especially because > > creating an SVGMatrix at the moment means writing: > > > > var matrix = document.createElementNS('http://www.w3.org/2000/svg > > ','svg').createSVGMatrix(); > > Agreed, that's painful, +1 for making it optional. Just so we're clear, even when it wasn't optional, you didn't have to do any of that. You can just pass null. (It's still not optional for some of the other methods where it's in the middle of the arguments and making it optional doesn't make much sense.) On Sat, 22 Mar 2014, Dirk Schulze wrote: > > Does some one think it would be necessary to make SVGMatrix nullable > (optional SVGMatrix?)? I think it would be superfluous. It's needed for consistency with the other methods. On Thu, 20 Mar 2014, Rik Cabanier wrote: > > addPath is currently defined on the Path2D object. [1] > Is there a reason why it's not defined on CanvasPathMethods instead? > That way this method is available on the 2d contest so you can append a > path to the current graphics state. What's the use case? On Thu, 20 Mar 2014, Dirk Schulze wrote: > > I am supportive for this idea! I agree that this would solve one of the > reasons why I came up with currentPath for WebKit in the first place. Can you elaborate on the reason for this? On Thu, 20 Mar 2014, Justin Novosad wrote: > > This would apply the CTM to the incoming path, correct? I am a little > bit concerned that this API could end up being used in ways that would > cancel some of the performance benefits (internal caching opportunities) > of Path2D objects. Right, that's why it's not currently on CanvasPathMethods. The idea is to make a clean break from the world where the transforms affect the building of the path. On Thu, 20 Mar 2014, Dirk Schulze wrote: > > Where is the difference to fill(Path2D), stroke(Path2D) and > clip(Path2D)? The path will always need to be transformed to the CTM. > Graphic libraries usually do this already for you. The addPath() > proposal is not different to that. The difference is that there, you only have one path with one transform, not different parts of the path built with different transforms. On Thu, 20 Mar 2014, Justin Novosad wrote: > > The recently added currentTransform attribute on > CanvasRenderingContext2D gives shared access to the rendering context's > transform. By "shared", I mean: > > a) this code modifies the CTM: > var matrix = context.currentTransform; > matrix.a = 2; > > b) In this code, the second line modifies matrix: > var matrix = context.currentTransform; > context.scale(2, 2); > > This behavior is probably not what most developers would expect. It's the behaviour that was requested by the pdf.js developers. :-) On Thu, 20 Mar 2014, Simon Sarris wrote: > > FF (at least Aurora/Nightlies) has for some time had mozCurrentTransform > (and mozCurrentTransformInverse), which return an Array (so not > spec-compliant, since spec wants SVGMatrix). It is not shared, so it > does not do what your a) and b) examples do. > > I agree that changing it to a getter method would be better, it would be > more intuitive and clear for developers. On Mon, 24 Mar 2014, Hwang, Dongseong wrote: > > Looking over this thread, we make a consensus not to expose > currentTransform attribute. Consensus is not how we decide things in the WHATWG. It's based on the strength of arguments. So far, it seems the arguments either way are about equal. On the one hand you have a developer asking for the current API. On the other hand you have implementors saying that the current API is bad for developers. What we need to make more progress, I think, is more concrete arguments, for example sample code that uses both APIs so we can see how authors would experience the two APIs in the real world. On Mon, 24 Mar 2014, Simon Sarris wrote: > > I think using "Current" in the naming convention is silly. The transform > just as much a part of state as lineWidth/etc, but nobody would propose > naming lineWidth something like currentLineWidth! There's no way to get > a *non-current* transformation matrix (or lineWidth), so I think the > distinction is unnecessary. > > CTM only seems like a good idea if we're worried that the name is too > long, but since "Current" is redundant/extraneous, I don't think an > initialism is worth the added layer of confusion. These are solid arguments if we agree that we should change the spec. On Sun, 23 Mar 2014, Dirk Schulze wrote: > > 1) I noticed that createImageData() is explicit that it represent a > transparent black rectangle. The constructor for ImageData is not that > explicit. Fixed. > 2) The last step of the 2nd constructor that takes an Uint8ClampedArray > says: " ? Return a new ImageData object whose width is sw, whose height > is height, and whose data is source.? > > Is data a reference to the original source or a copy of source? For the > former, there might be two ImageData objects referencing the same > ByteArray. How would that be useful? The steps say that the data is the Uint8ClampedArray "source". I've added a note making the fact that it's not a copy more explicit. On Mon, 24 Mar 2014, J?rg Lehni wrote: > > Non-scaling Strokes in Canvas. > > The request has come up multiple times on the paper.js mailing list [1], > and we will emulate this in JavaScript. > > But since this will involve baking the CTM into the path to be drawn, > and setting the CTM to the identity matrix, I was wondering if this is > something worth supporting natively for the obvious reason of improved > performance? You can do this with the new Path2D API, right? On Tue, 25 Mar 2014, Dirk Schulze wrote: > > [...] currentTransform [...] > what should be returned for a CTM that is singular (not invertible)? Even when the transform is not invertible, it's precise value is still well-defined, no? > In WebKit we do not track all transformations of the CTM that caused a > singular matrix or are following a transformation that would have caused > a singular matrix. > > Example: > > ctx.scale(0,0); > ct.translate(10,10); The matrix should be 0,0,0,0,0,0 here. It starts as 1 0 0 0 1 0 0 0 1 Then you apply a scale transform to 0,0: 1 0 0 0 0 0 0 0 0 0 1 0 x 0 0 0 = 0 0 0 0 0 1 0 0 1 0 0 1 Then you post-multiply that by the translation by 10,10: 1 0 0 0 0 0 1 0 10 0 0 0 0 1 0 x 0 0 0 x 0 1 10 = 0 0 0 0 0 1 0 0 1 0 0 1 0 0 1 ...and that's the matrix you should return. > In webkit we would not apply the transformation scale(0,0) and mark the > CTM as not-invertible instead. I do not believe this is an implementation strategy that can lead to a conforming implementation. Note that this is the same as what you would get if you did: var a = new SVGMatrix(1,0,0,1,0,0); // assuming this interface gets a constructor, anyway a = a.scale(0,0); a = a.translate(10,10); ...so this is not unique to the canvas API. On Tue, 25 Mar 2014, Justin Novosad wrote: > > I prepared a code change to that effect, but then there was talk of > changing the spec to skip path primitives when the CTM is not > invertible, which I think is a good idea. It would avoid a lot of > needless hoop jumping on the implementation side for supporting weird > edge cases that have little practical usefulness. I'm not sure I agree that they have little practical usefulness. Zeros often occur at the edges of transitions, and if we changed the spec then these transitions would require all the special-case code to go in author code instead of implementor code. On Sun, 30 Mar 2014, Dirk Schulze wrote: > > Canvas let you set alignment baselines with the textBaseline attribute > [1]. > > One of the baseline values is ?middle?. The description of the ?middle? > baseline seems to be in conflict with the definition for the > alignment-baseline property in CSS[2]. > > Canvas: The middle of the em square > CSS: [..] it may be computed using 1/2 the "x-height? > > What Canvas uses as middle is described as ?center? in CSS. Is there a > way that we can change the naming and/or definition of ?middle? in > Canvas? This seems like something that's too late to change. (I think using "middle" for what is between "top" and "bottom" makes eminent sense, though, so it doesn't seem like that big a problem.) On Mon, 31 Mar 2014, Justin Novosad wrote: > > Wow, that is confusing. How can this be fixed without breaking existing > web content? Are browsers currently compliant with the canvas spec, or > do they implement the CSS definition of middle? Looks like everyone does it per the canvas spec: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2924 The CSS 'vertical-align' property works per the CSS spec on the browsers I tested, too, FWIW: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2925 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Tue Apr 8 09:07:21 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 09:07:21 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDRtCREBBG5koWfR-PDv_=dJejfA-WOniSwygSD4YhhWg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > So this is not how most implementations currently have it defined. > > > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > > definitely do store the path in user coordinates. The spec currently > > > > says otherwise [1] though. > > > > > > I'm not sure what you're referring to here. > > > > All graphics backends for canvas that I can inspect, don't apply the CTM > > to the current path when you call a painting operator. Instead, the path > > is passed as segments in the current CTM and the graphics library will > > apply the transform to the segments. > > Right. That's what the spec says too, for the current default path. No, the spec says this: For CanvasRenderingContext2D objects, the points passed to the methods, and the resulting lines added to current default path by these methods, must be transformed according to the current transformation matrix before being added to the path. > This is the confusing behaviour to which I was referring. The "Path" API > (or > Path2D or whatever we call it) doesn't have this problem. > That is correct. The Path2D object is in user space and can be passed directly to the graphics API (along with the CTM). > > > > Another use case is to allow authors to quickly migrate to hit > regions. > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); > > > > ... // lots of complex drawing operation for a control > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); > > > > > > > > > > > > To migrate that to a region (with my proposed shape interface [1]): > > > > > > > > var s = new Shape(); > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > > Shape(ctx.currentPath)); > > > > ... > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke > calls? > > > > That does not work as the second addHitRegion will remove the control and > > id from the first one. > > The 'add' operation is needed to get a union of the region shapes. > > Just use two different IDs with two different addHitRegion() calls. That's > a lot less complicated than having a whole new API. > That doesn't work if you want to have the same control for the 2 areas, from the spec for addHitRegion: If there is a previous region with this control, remove it from the scratch bitmap's hit region list; then, if it had a parent region, decrement that hit region's child count by one. Even if you don't use the control, it would be strange to have 2 separate hit regions for something that represents 1 object. > > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > ... > > > > copy, and would help memory consummation and performance. > > > > > > I don't really understand the use case here. > > > > Jurg was just talking about an optimization (so you don't have to make > > an internal copy) > > Sure, but that doesn't answer the question of what the use case is. > >From my recent experiments with porting canvg ( https://code.google.com/p/canvg/) to use Path2D, they have a routine that continually plays a path into the context which is called from a routine that does the fill, clip or stroke. Because that routine can't simply set the current path, a lot more changes were needed. Some pseudocode that shows the added complexity, without currentPath: function drawpath() { if(Path2DSupported) { return myPath; } else for(...) { ctx.moveTo/lineTo/... } } function fillpath() { var p = drawpath(); if(p) ctx.fill(p); else ctx.fill(); } with currentPath: function drawpath() { if(Path2DSupported) { // only 2 extra lines of code ctx.currentPath = myPath; } else for(...) { ctx.moveTo/lineTo/... } function fillpath() { drawpath(); ctx.fill(); } > On Wed, 12 Mar 2014, Rik Cabanier wrote: > > > > > > > > > > You can do unions and so forth with just paths, no need for > > > > > regions. > > > > > > > > How would you do a union with paths? If you mean that you can just > > > > aggregate the segments, sure but that doesn't seem very useful. > > > > > > You say, here are some paths, here are some fill rules, here are some > > > operations you should perform, now give me back a path that describes > > > the result given a particular fill rule. > > > > I think you're collapsing a couple of different concepts here: > > > > path + fillrule -> shape > > union of shapes -> shape > > shape can be converted to a path > > I'm saying "shape" is an unnecessary primitive. You can do it all with > paths. > > union of (path + fillrule)s -> path > No, that makes no sense. What would you get when combining a path with a fillrule and no fillrule? > > > A shape is just a path with a fill rule, essentially. > > > > So, a path can now have a fillrule? Sorry, that makes no sense. > > I'm saying a shape is just the combination of a fill rule and a path. The > path is just a path, the fill rule is just a fill rule. > After applying a fillrule, there is no longer a path. You can *convert* it back to a path that describes the outline of the shape if you want, but that is something different. The way you've defined things now, you can apply another fill rule on a path with a fill rule. What would the result of that be? > > > Anything you can do > > > with one you can do with the other. > > > > You can't add segments from one shape to another as shapes represent > > regions. > > Likewise, you can't union, intersect or xor path segments. > > But you can union, intersect, or xor lists of pairs of paths and > fillrules. > would you start throwing when doing these operations on paths without fill rules? > ... > > > > "Wrong" meaning: > > if the author has a bunch of geometry and wants to put it in 1 path > object > > so he can just execute 1 fill operation, he might be under the impression > > that "adding" the geometry will just work. > > Well, sure, an author might be under any number of false impressions. > > The API has a way for a bunch of paths to be merged with a single fillrule > to generate a new path with no crossing subpaths (which is also fillrule > agnostic), essentially giving you the union of the shapes represented by > those paths interpreted with that fillrule. > Is this the API you're referring to? path = new Path2D(paths [, fillRule ] ) The first argument could point to paths that need different winding rules so this won't work. What if one of the paths already had a fill rule? This doesn't seem implementable/stable. > There are very few use cases where you want to add partial path segments > > together but I agree that there are some cases that it's useful to have. > > I disagree that there few such cases. Pretty much any time you create a > path, you are adding partial path segments together. Whether you do so > using one Path object all at once or multiple Path objects that you later > add together is just a matter of programming style. > It's the multiple path objects use case that is unclear to me. Is there any tool/library that does this? Looking at Adobe's graphics applications, there isn't anything like it. Looking at graphics APIs, I don't see any calls that combine paths directly. hmm, it seems the spec has changed. It didn't used to start with "Create a new path that describes the edge of the areas" With the new wording, the last sentence should be updated: Subpaths in the newly created path must wind clockwise, regardless of the direction of paths in path. Since you now create 'holes', the separate paths need to be reoriented like you specify in other parts. > > > > > We seem to be going around in circles. We're in agreement that > > > > > eventually we should add APIs for combining paths such that we get > > > > > the equivalent of the union of their fill regions. I agree that > > > > > converting text into paths is non-trivial (lots of stuff browsers > > > > > do is non-trivial, that's kind of the point -- if it was trivial, > > > > > we could leave it for authors). But I don't see how we get from > > > > > there to you wanting the existing APIs removed. > > > > > > > > I want them removed because they will most likely not behave in the > > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > > expect that there is 'interference' between them. > > > > > > I don't see why not. It's exactly what happens today if you were to > > > just add the same path creation statements together into the current > > > default path and fill or stroke that. > > > > Sure but who does that? > > It's how all paths are built, as far as I can tell. I don't see how else > you could build a path that consists of more than one line. > > addPath() is useful for shifting a path according to a transform. > Why not just transform() then? addPathByStrokingPath() is for creating a stroked path. > addText() is for writing text. > > I don't see how removing any of them is a win. > Yes, they are useful. The issue is that they are not implementable as currently specified. > > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > ... > > > > > > > > How would you get a point? the width is scaled to 0. > > > > > > That's how you get a point -- scale(0,0) essentially reverts > > > everything to a zero dimensional point. > > > > OK, but the width of the point is also transformed to 0 so you get > > nothing. > > Points are always zero-width, by definition. > You can still stroke it though and get a point of the strokewidth. > > We've gone over this several times now. > > The APIs that you define, have use cases and I agree with them. > > However the way you defined those APIs does not make sense and will not > > give the result that authors want. > > The way to make this point would be to start from the use case, describe > the desired effect, show the "obvious" way to achieve this using the API, > and then demonstrate how it doesn't match the desired effect. > The obvious way is to go with Shape2D. It's not because I invented it; many advanced graphics APIs came offer this (including D2D and skia) > ... > > So, it's not realistic to add this to the Path2D object. > > I don't really see why it's unrealistic. In most cases, the user agent > doesn't actually have to do any work -- e.g. if all that you're doing is > merging two paths so that you can fill them simultaneously later, the UA > can just keep the two paths as is and, when necessary, fill them. > > For cases where you really want to have this effect -- e.g. when you want > to get the outline of the dashed outline of text -- then I don't really > see any way to work around it. > That is true. That is why I proposed to make the interface more limited for now until there is a time that this functionality is available. >From Ian Hickson: > I don't think the spec should be written with a particular > implementation in mind, nor should it dictate one. I agree it shouldn't (and doesn't) dictate one. But it's crazy to not consider implementations at all when writing a spec. That way lies madness like requiring O(N^2) algorithms and solving the halting problem and all kinds of other disasters (all of which I've seen in real proposals). > > The reason for that is that even though a UA could emulate the union by > > doing multiple fill operations, Path2D allows you to stroke another path > > object. At that point, you really have to do planarization. By defining > > a Shape2D object and not allowing it to be stroked, we can work around > > this. > > Sure, by limiting the feature set dramatically we can avoid the cases > where you have to do the hard work, but we also lose a bunch of features. > For now. They can be added later. Until then, this is confusing implementors. > > > I don't think the arguments for removing these are compelling. The > > > problems with the APIs have been addressed (e.g. there's no ambiguity > > > in the case of overlapping text), the use cases are clear (e.g. > > > drawing text around an arc or drawing a label along a line graph's > > > line), and the API now supports the constructs to do unions of fill > > > regions. > > > > Where is the union of fill regions specified? All I see is segments > > aggregation. > > One of the Path constructors takes an array of paths and a fill rule. > See above. > > > > No one has implemented them and they are confusing the browser > > > > vendors. > > > > > > I don't think they're confusing anyone. > > > > The blink people were looking at adding this until they thought it > > through and realized that it wouldn't work. > > Realised what wouldn't work? As far as I'm aware, there's nothing that > wouldn't work. > See this thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/168925.html I think you already addressed some of the concerns. Doing the planarization is now the problem so we can't implement this. > > > > Until we have support for shapes, the output of these methods won't > > > > be stable. > > > > > > These methods have been very stable. They have barely changed since > > > they were added, except for some minor tweaks to fix bugs. > > > > How can you make that statement? No one has implemented them yet. > > What do you mean by "stable"? > > I assumed you meant "hasn't been changing a lot". The spec hasn't been > changing a lot, so it seems pretty stable. > You've been making a lot of changes lately so this not quite true. Because you wrote it a long time ago and nobody looked at it until now, doesn't mean that it is stable. From junov at google.com Tue Apr 8 12:25:04 2014 From: junov at google.com (Justin Novosad) Date: Tue, 8 Apr 2014 15:25:04 -0400 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> On Mon, Apr 7, 2014 at 6:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > For example, there is no locale for font family resolution > > I'm not clear on what you mean by "locale" here. What is the locale that a > displayed <canvas> in a Document in a browsing context has, that a > non-displayed <canvas> outside a Document and without a browsing context > does not have? > I am not sure exactly how this relates to the specification, but when reading the code in Blink, I saw that font family resolution goes through different paths if the view has a Korean, Chinese or Japanese locale. Some OSes allow you to have different locales on a per window basis, so you need to have a view (i.e. a browsing context) associated with the Document in order to resolve this. > > and it is not possible to resolve font sizes in physical length units > > unless the document is associated with a view. > > Why not? The canvas has a pixel density (currently always 1:1), no? > 1:1 is not a physical pixel density. To resolve a font size that is specified in physical units (e.g. millimeters or inches) you need something like a DPI value, which requires information about the output device. > > > My 2 cents: specifying fallback behaviors for all use cases that are > > context dependent could be tedious and I have yet to see a real-world > > use case that requires being able to paint a canvas in a frame-less > > document. Therefore, I think the spec should clearly state <canvas> > > elements that are in a document without a browsing context are unusable. > > Not sure what the exact behavior should be though. Should an exception > > be thrown upon trying to use the rendering context? Perhaps canvas draws > > should fail silently, and using the canvas as an image source should > > give transparent black pixels? > > As far as I can tell, this is all already specified, and it just gets > treated like a normal canvas. > Agreed. The fallback behavior is specified. But is it good enough? There will be discrepancies, sometimes large ones, between text rendered with and without a browsing context. On Wed, 5 Mar 2014, Rik Cabanier wrote: > > > > Testing all browsers (except IE since > > document.implementation.createHTMLDocument() doesn't work) they seem to > > handle canvas contexts with no browsing context except when you use > > text. Chrome crashes, firefox throws an exception and Safari draws the > > text with a very small scale > > I don't really understand why this is problematic in practice. What does a > browsing context provide that is needed for rendering text that a user > agent couldn't fake for itself in other contexts? We're definitely going > to need text in worker canvases. > It is because the browsing context serves as a bridge between the document and the OS/window manager/display device. Therefore some of the system configuration info that comes into play in font style resolution and text rendering is not accessible when the document is not associated with a browsing context. For example to know which locale to use, the document needs to be linked to a window; to know the display density (dpi) we need to know which display device will be used for displaying the document; to use subpixel text anti-aliasing, we need to know the display device's LCD configuration; etc. If we fake this information by using fallbacks and defaults, we may end up with text that looks different when rendering in a Worker or into a Document without a browsing context. If we want everything to look the same, perhaps the spec should specify how to get to a browsing context that can be used for retrieving display settings. For example, if the current document has no browsing context, use the settings from the browsing context of the global 'document' object. That would probably match the developer's intent almost all the time. > > On Fri, 14 Mar 2014, Justin Novosad wrote: > > On Fri, Mar 14, 2014 at 2:29 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > If the bug is that Chrome resamples the image in an ugly way, then > > > that's a bug with Chrome. As the bug says, browsers are allowed to > > > pick whatever algorithm they want -- it's a quality-of-implementation > > > issue. But if the result is ugly, that's a low quality implementation. > > > > Yes, and if we fixed it to make it prettier, people would complain about > > a performance regression. It is impossible to make everyone happy right > > now. Would be nice to have some kind of speed versus quality hint. > > The problem with a hint is that it will be set incorrectly, and so instead > of having something that's mostly pretty but mostly fast for everyone, > you'd end up with something that's slow on sites that need things to be > fast, and things that are ugly on sites that need things to be pretty. > > In general I think it is very unwise for us to design APIs with hints that > have subtle effects on developer machines but that can cripple performance > on low-end devices. > The point of it being a hint is that the UA is free to disregarded it precisely in that kind of situation (e.g. fallback to fastest filtering on a low-end device) > Instead, we should use adaptive algorithms, for example always using the > prettiest algorithms unless we find that frame rate is suffering, and then > stepping down to faster algorithms. > Such an adaptive algorithm implies making some kind of weighted decision to chose a reasonable compromise between quality and performance. Sounds like the perfect place to use a hint. > > > On Mon, 17 Mar 2014, Justin Novosad wrote: > > > > Yes, but there is still an issue that causes problems in Blink/WebKit: > > because the canvas rendering context stores its path in local > > (untransformed) space, whenever the CTM changes, the path needs to be > > transformed to follow the new local spcae. This transform requires the > CTM > > to be invertible. So now webkit and blink have a bug that causes all > > previously recorded parts of the current path to be discarded when the > CTM > > becomes non-invertible (even if it is only temporarily non-invertible, > even > > if the current path is not even touched while the matrix is > > non-invertible). I have a fix in flight that fixes that problem in Blink > by > > storing the current path in transformed coordinates instead. I've had the > > fix on the back burner pending the outcome of this thread. > > Indeed. It's possible to pick implementation strategies that just can't be > compliant; we shouldn't change the spec every time any implementor happens > to make that kind of mistake, IMHO. > > (Of course the better long-term solution here is the Path objects, which > are transform-agnostic during building.) > > > Just to be clear, we should support this because otherwise the results are > just wrong. For example, here some browsers currently show a straight line > in the default state, and this causes the animation to look ugly in the > transition from the first frame to the secord frame (hover over the yellow > to begin the transition): > > http://junkyard.damowmow.com/538 > > Contrast this to the equivalent code with the transforms explicitly > multiplied into the coordinates: > > http://junkyard.damowmow.com/539 > > I don't see why we would want these to be different. From the author's > perspective, they're identical. If we stick to that, there are still some behaviors that need to resolved. One issue that comes to mind is what happens if stroke or fill are called while the CTM is non-invertible? To be more precise, how would the styles be mapped? If the fillStyle is collapsed to a point, does that mean the path gets filled in transparent black? If we go down this road, we will likely uncover more questions of this nature. > On Tue, 25 Mar 2014, Justin Novosad wrote: > > > > I prepared a code change to that effect, but then there was talk of > > changing the spec to skip path primitives when the CTM is not > > invertible, which I think is a good idea. It would avoid a lot of > > needless hoop jumping on the implementation side for supporting weird > > edge cases that have little practical usefulness. > > I'm not sure I agree that they have little practical usefulness. Zeros > often occur at the edges of transitions, and if we changed the spec then > these transitions would require all the special-case code to go in author > code instead of implementor code. > Yes, I think that may be the strongest argument so far in this discussion. The examples you provided earlier illustrate it well. I would like to hear what Rik and Dirk think about this now. From jackalmage at gmail.com Tue Apr 8 13:54:39 2014 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Tue, 8 Apr 2014 13:54:39 -0700 Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> Message-ID: <CAAWBYDCAr4C-fSYx9a_y=D3aZe0_9e_UOLo5yUJrk9TXs46Meg@mail.gmail.com> On Tue, Apr 8, 2014 at 5:25 AM, Steve Faulkner <faulkner.steve at gmail.com> wrote: > avoiding unnecessary recourse to web component use is a reasonable and > expected goal - built in vs bolt on accessibility is better. Having to use > a web component to overcome the inability to make a html control usable > without relying on CSS and Js and ARIA is unfortunate, and as you said > yesterday I still don't understand. Do you think that what Hixie is saying (about clicking on non-interactive text in <summary> toggling the <details>) is wrong? The behavior that Hixie describes is roughly what implementations do today. In Blink, clicking on any bare text in the <summary> toggles the <details>, while clicking on an <input> does not. However, Blink current behavior with <label> is different - it basically ignores the presence of the <label>, as far as I can tell, and still toggles the <details> even if the <label> is redirecting the click to an <input>. I would strongly object to any suggestion that <summary> should only toggle <details> when you click on the disclosure triangle, unless you add some additional markup like <label>. That would be terrible UI. ~TJ From cabanier at gmail.com Tue Apr 8 15:10:09 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 15:10:09 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> Message-ID: <CAGN7qDDJKmx1T9_8cu--T7mAUy2uucTde+S6atnJTBe7baBQRg@mail.gmail.com> On Tue, Apr 8, 2014 at 12:25 PM, Justin Novosad <junov at google.com> wrote: > > > > > On Mon, 17 Mar 2014, Justin Novosad wrote: > > > > > > Yes, but there is still an issue that causes problems in Blink/WebKit: > > > because the canvas rendering context stores its path in local > > > (untransformed) space, whenever the CTM changes, the path needs to be > > > transformed to follow the new local spcae. This transform requires the > > CTM > > > to be invertible. So now webkit and blink have a bug that causes all > > > previously recorded parts of the current path to be discarded when the > > CTM > > > becomes non-invertible (even if it is only temporarily non-invertible, > > even > > > if the current path is not even touched while the matrix is > > > non-invertible). I have a fix in flight that fixes that problem in > Blink > > by > > > storing the current path in transformed coordinates instead. I've had > the > > > fix on the back burner pending the outcome of this thread. > > > > Indeed. It's possible to pick implementation strategies that just can't > be > > compliant; we shouldn't change the spec every time any implementor > happens > > to make that kind of mistake, IMHO. > > > > (Of course the better long-term solution here is the Path objects, which > > are transform-agnostic during building.) > > > > > > Just to be clear, we should support this because otherwise the results > are > > just wrong. For example, here some browsers currently show a straight > line > > in the default state, and this causes the animation to look ugly in the > > transition from the first frame to the secord frame (hover over the > yellow > > to begin the transition): > > > > http://junkyard.damowmow.com/538 > > > > Contrast this to the equivalent code with the transforms explicitly > > multiplied into the coordinates: > > > > http://junkyard.damowmow.com/539 > > > > I don't see why we would want these to be different. From the author's > > perspective, they're identical. > These examples are pretty far fetched. How many time do people change the CTM in the middle of a drawing operation and not change the geometry? If we stick to that, there are still some behaviors that need to resolved. > One issue that comes to mind is what happens if stroke or fill are called > while the CTM is non-invertible? To be more precise, how would the styles > be mapped? If the fillStyle is collapsed to a point, does that mean the > path gets filled in transparent black? If we go down this road, we will > likely uncover more questions of this nature. Indeed > > On Tue, 25 Mar 2014, Justin Novosad wrote: > > > > > > I prepared a code change to that effect, but then there was talk of > > > changing the spec to skip path primitives when the CTM is not > > > invertible, which I think is a good idea. It would avoid a lot of > > > needless hoop jumping on the implementation side for supporting weird > > > edge cases that have little practical usefulness. > > > > I'm not sure I agree that they have little practical usefulness. Zeros > > often occur at the edges of transitions, and if we changed the spec then > > these transitions would require all the special-case code to go in author > > code instead of implementor code. > > > > Yes, I think that may be the strongest argument so far in this discussion. > The examples you provided earlier illustrate it well. > I would like to hear what Rik and Dirk think about this now. > I looked at the webkit and chrome bug databases and I haven't found anyone who complained about their current behavior. Implementing this consistently will either add a bunch of special case code to deal with non-singular matrices or double (triple?) conversion of all segment points like firefox does. After that, fill, stroke and clip will still not work when there's a non-invertible matrix. I do not think it's worth the effort... From cabanier at gmail.com Tue Apr 8 16:50:48 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 16:50:48 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > ... > > > > > Stroking will be completely wrong too, because joins and end caps > > > > are drawn separately, so they would be stroked as separate paths. > > > > This will not give you the effect of a double-stroked path. > > > > > > I don't understand why you think joins and end caps are drawn > > > separately. That is not what the spec requires. > > > > Sure it does, for instance from > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path > > : > > > > The round value means that a filled arc connecting the two > > aforementioned corners of the join, abutting (and not overlapping) the > > aforementioned triangle, with the diameter equal to the line width and > > the origin at the point of the join, must be added at joins. > > > > If you mean, "drawn with a separate fill call", yes that is true. > > What I meant was that they are drawn as a separate closed path that will > > interact with other paths as soon as there are different winding rules or > > "holes". > > The word "filled" is a bit misleading here (I've removed it), but I don't > see why that led you to the conclusion you reached. The step in question > begins with "Create a new path that describes the edge of the areas that > would be covered if a straight line of length equal to the styles > lineWidth was swept along each path in path while being kept at an angle > such that the line is orthogonal to the path being swept, replacing each > point with the end cap necessary to satisfy the styles lineCap attribute > as described previously and elaborated below, and replacing each join with > the join necessary to satisfy the styles lineJoin type, as defined below", > which seems pretty unambiguous. > Thinking about this some more, it looks like you came around and specified stroking like I requested from the beginning. For instance, http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0354.html or http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0213.html Now that you made that change, 'addPathByStrokingPath' is specified correctly. I still don't know how it could be implemented though... (It *could* as a shape but not as a path) From cabanier at gmail.com Tue Apr 8 17:17:39 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 17:17:39 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> Message-ID: <CAGN7qDBfO_7katfwHTX+CT_HgRcEuq3AL7544y+YTJU54HbahQ@mail.gmail.com> On Tue, Apr 8, 2014 at 4:50 PM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > >> ... >> >> >> > > > Stroking will be completely wrong too, because joins and end caps >> > > > are drawn separately, so they would be stroked as separate paths. >> > > > This will not give you the effect of a double-stroked path. >> > > >> > > I don't understand why you think joins and end caps are drawn >> > > separately. That is not what the spec requires. >> > >> > Sure it does, for instance from >> > >> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path >> > : >> > >> > The round value means that a filled arc connecting the two >> > aforementioned corners of the join, abutting (and not overlapping) the >> > aforementioned triangle, with the diameter equal to the line width and >> > the origin at the point of the join, must be added at joins. >> > >> > If you mean, "drawn with a separate fill call", yes that is true. >> > What I meant was that they are drawn as a separate closed path that will >> > interact with other paths as soon as there are different winding rules >> or >> > "holes". >> >> The word "filled" is a bit misleading here (I've removed it), but I don't >> see why that led you to the conclusion you reached. The step in question >> begins with "Create a new path that describes the edge of the areas that >> would be covered if a straight line of length equal to the styles >> lineWidth was swept along each path in path while being kept at an angle >> such that the line is orthogonal to the path being swept, replacing each >> point with the end cap necessary to satisfy the styles lineCap attribute >> as described previously and elaborated below, and replacing each join with >> the join necessary to satisfy the styles lineJoin type, as defined below", >> which seems pretty unambiguous. >> > > Thinking about this some more, it looks like you came around and specified > stroking like I requested from the beginning. > For instance, > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0354.html > or > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0213.html > Now that you made that change, 'addPathByStrokingPath' is specified > correctly. I still don't know how it could be implemented though... (It > *could* as a shape but not as a path) > The spec is still confusingly written and could be misinterpreted: Create a new path that describes the edge of the areas that would be covered if a straight line of length equal to the styles lineWidth was swept along each subpath in path while being kept at an angle such that the line is orthogonal to the path being swept, replacing each point with the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, and replacing each join with the join necessary to satisfy the styles lineJoin type, as defined below. Maybe could become: Create a new path that describes the edge of the coverage of the following areas: - a straight line of length equal to the styles lineWidth that was swept along each subpath in path while being kept at an angle such that the line is orthogonal to the path being swept, - the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, - the join with the join necessary to satisfy the styles lineJoin type, as defined below. From junov at google.com Wed Apr 9 07:14:42 2014 From: junov at google.com (Justin Novosad) Date: Wed, 9 Apr 2014 10:14:42 -0400 Subject: [whatwg] <canvas> feedback In-Reply-To: <CAGN7qDDJKmx1T9_8cu--T7mAUy2uucTde+S6atnJTBe7baBQRg@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> <CAGN7qDDJKmx1T9_8cu--T7mAUy2uucTde+S6atnJTBe7baBQRg@mail.gmail.com> Message-ID: <CABpaAqSfmKu2mkeZg39Nn_OeOaSWdW0ZwvGuhq0+jiYWq_v0PQ@mail.gmail.com> On Tue, Apr 8, 2014 at 6:10 PM, Rik Cabanier <cabanier at gmail.com> wrote: > > > On Tue, 25 Mar 2014, Justin Novosad wrote: >> > > >> > > I prepared a code change to that effect, but then there was talk of >> > > changing the spec to skip path primitives when the CTM is not >> > > invertible, which I think is a good idea. It would avoid a lot of >> > > needless hoop jumping on the implementation side for supporting weird >> > > edge cases that have little practical usefulness. >> > >> > I'm not sure I agree that they have little practical usefulness. Zeros >> > often occur at the edges of transitions, and if we changed the spec then >> > these transitions would require all the special-case code to go in >> author >> > code instead of implementor code. >> > >> >> Yes, I think that may be the strongest argument so far in this discussion. >> The examples you provided earlier illustrate it well. >> I would like to hear what Rik and Dirk think about this now. >> > > I looked at the webkit and chrome bug databases and I haven't found anyone > who complained about their current behavior. > Implementing this consistently will either add a bunch of special case > code to deal with non-singular matrices or double (triple?) conversion of > all segment points like firefox does. After that, fill, stroke and clip > will still not work when there's a non-invertible matrix. > > I do not think it's worth the effort... > If I did not feel bad about using laziness as an argument, I might agree. :-) From fantasai.lists at inkedblade.net Wed Apr 9 13:48:52 2014 From: fantasai.lists at inkedblade.net (fantasai) Date: Wed, 09 Apr 2014 13:48:52 -0700 Subject: [whatwg] [CSSWG][css-scoping] CSS Scoping FPWD Published Message-ID: <5345B234.2020603@inkedblade.net> The CSS WG has published a First Public Working Draft of the CSS Scoping Module Level 1: http://www.w3.org/TR/css-scoping-1/ This specification defines various scoping/encapsulation mechanisms for CSS, including scoped styles and the @scope rule, Shadow DOM selectors, and page/region-based styling. It is an early-stage working draft, and the features described therein are not well-baked and may change dramatically or be removed. The CSSWG encourages comments on both design and details of these features. Please send any comments to this mailing list, <www-style at w3.org>, and please, prefix the subject line with [css-scoping] (as I did on this message). For the CSS WG, ~fantasai From faulkner.steve at gmail.com Thu Apr 10 08:49:55 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Thu, 10 Apr 2014 16:49:55 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <CAAWBYDCAr4C-fSYx9a_y=D3aZe0_9e_UOLo5yUJrk9TXs46Meg@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> <CAAWBYDCAr4C-fSYx9a_y=D3aZe0_9e_UOLo5yUJrk9TXs46Meg@mail.gmail.com> Message-ID: <CA+ri+V=3xcOHhnxO=q9UVaNhg4UU4w3QmhjZXjkCHjOAHVN5WA@mail.gmail.com> On 8 April 2014 21:54, Tab Atkins Jr. <jackalmage at gmail.com> wrote: > I still don't understand. Do you think that what Hixie is saying > (about clicking on non-interactive text in <summary> toggling the > <details>) is wrong? > nope. > > The behavior that Hixie describes is roughly what implementations do > today. In Blink, clicking on any bare text in the <summary> toggles > the <details>, while clicking on an <input> does not. However, Blink > current behavior with <label> is different - it basically ignores the > presence of the <label>, as far as I can tell, and still toggles the > <details> even if the <label> is redirecting the click to an <input>. > Implementations today have the summary element as the focusable/interactive element. this has several pros/cons what I am trying to achieve is to have the pros defined as part of the feature. I would strongly object to any suggestion that <summary> should only > toggle <details> when you click on the disclosure triangle, > I cannot agree more, which is why I have brought up the issue here and elsewhere. Hixie talks about platform conventions and UAs deciding, and as I have pointed out several times the OSX platform convention is just what you describe. and as you say "would be terrible UI." unless you > add some additional markup like <label>. That would be terrible UI. > I would prefer that the summary element acted as the label the disclosure triangle of the details element, thus providing a reasonable default click area and focus are and source for the accessible name of the control. I see a few issues, which is why I have suggested allowing the use of <label> (to provide both a clickable area that can be assigned by the author and provide an explicit method to assign an accessible name) 1. When the summary element also includes links or other controls each with their own accessible name, providing an unambiguous accessible name for the disclosure triangle becomes problematic. 2. I have observed that assigning an accessible name for a control in the shadow DOM from the DOM is not possible. Thus my question to the list/hixie: "What's the mechanism by which the anonymous control for details can be assigned an accessible name?" -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From ian at hixie.ch Thu Apr 10 13:49:49 2014 From: ian at hixie.ch (Ian Hickson) Date: Thu, 10 Apr 2014 20:49:49 +0000 (UTC) Subject: [whatwg] <input type=number> for year input In-Reply-To: <87zjl0cy02.fsf@dieweltistgarnichtso.net> References: <5303E843.4010403@jwatt.org> <8761nptdfp.fsf@dieweltistgarnichtso.net> <001b01cf3afd$94f980b0$beec8210$@net> <87zjl0cy02.fsf@dieweltistgarnichtso.net> Message-ID: <alpine.DEB.2.00.1404101715001.6826@ps20323.dreamhostps.com> On Wed, 19 Feb 2014, Michael[tm] Smith wrote: > Ian Hickson <ian at hixie.ch>, 2014-02-18 23:59 +0000: > > On Tue, 18 Feb 2014, Jonathan Watt wrote: > > > > > > I wonder if it would be that bad to have a 'year' type to compliment > > > the 'month' and 'day' types... > > > > This has come up a few times, but so far the use cases have not been > > compelling enough. This is probably the most compelling use case, but > > even here, I don't know that it's that compelling. > > > > I would be interested in hearing more about the locales where not > > using separators even for four digits is bad/suboptimal. If it wasn't > > for those, I would say that just not using separators for four-digit > > numbers would be an easy and effective solution. > > The following info seems relevant - > > http://www.thepunctuationguide.com/comma.html#numbers > "Most authorities, including The Associated Press Stylebook and The Chicago > Manual of Style, recommend a comma after the first digit of a four-digit > number. The exceptions include years, page numbers, and street addresses." > > To me that appears to be a strong argument that formatting of years is > in fact clearly an exception, and that's compelling enough to warrant > having a type for them separate from the normal number type (in which > four-digit numbers would instead have a separator, to follow existing > longstanding conventions). Interesting. For street addresses, we are moving in the direction of larger fields not smaller fields, so I'm not too worried about that use case. (I do know one form that looks just for a street address number, but presumably it has to handle non-numeric data anyway, as in "23A".) If that left just page numbers, I'd probably ignore it, since the use cases are pretty limited there. But years are clearly a major use case. Doing further research along these lines, it seems that it's specifically page numbers and years _that are four digits long_ that are at issue, when it comes to English: | MLA style is to use a comma in four-digit numbers except in page | numbers, line numbers, addresses, and years, unless the year has more | than four digits, such as 10,000 BCE. -- http://www.esc.edu/online-writing-center/resources/punctuation/commas/ Though some people say that applies to more than just years and page numbers: | Use commas to separate groups of 3 numbers in numbers of 5 digits or | more unless decimals are used. The comma in a 4-digit number may be | omitted. -- http://mtdesk.com/Numbers However, in other languages, as Karl showed, the pattern is different. As I see it, we have two possible paths: 1. We consider this a stylistic issue, and we add something to CSS to make it possible to control the formatting of numbers in <input type=number>. Then, someone doing a page-number control in English can use CSS to make it not include commas in four-digit numbers but include numbers otherwise, and so forth. 2. We consider this a semantic issue, and we add one or more new input types to handle the new smenatics. For example, we add type=year and type=page-number. We can also follow a combinations of both, providing a new control for the cases that need more than just style, and providing style for the cases that are just presentational. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: > > The point is that year numbers aren't really "numbers" in a normal > sense, any more than car plate numbers, credit card numbers, product > numbers, or social security numbers are. Surely they can be regarded as > numbers, but so can car plate numbers and the others. On Wed, 19 Feb 2014, Smylers wrote: > > Except that years do actually form a sequence, and it's possible to > perform maths on them; for instances, subtracting one year from another > yields a duration, which is a meaningful quantity, whereas subtracting a > couple of credit card numbers is completely useless. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: > > Mathematically, you are right, but input types aren't based on general > properties of quantities but on practical classification of input data. > All the examples I gave, including year numbers, are normally input by > typing the digits - in contrast with, say, using a color picker, a data > picker, or a slider. Your annual income, when enterested into an electronic tax form, is usually "input by typing the digits", but it's definitely a number. I think the only way, in western locales, that years differ from other numbers is with respect to formatting, and that's not unique to years, as Mike pointed out (c.f. page numbers). On Wed, 19 Feb 2014, Smylers wrote: > > There are situations where up/down arrows makes sense on years. For > instance, a chart of various baby names could have a box for the year > currently being displayed, and it's handy to be able to nudge that along > by a year at a time to see it change, without having to manually retype > the year. Or when displaying one year's tax return, with the ability to > display other years' returns ? with adjacent years being likely options. Indeed. This is why so far we haven't included a type=year control: type=number, semantically, is the right control. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: > > And year numbers differ, as mentioned, from normal numbers as regards to > conventional formats (e.g., 2014 vs. 2,014 or 2'014 or 2 014 or...). But as noted above, this is not unique to years. Indeed in some locales, it's all numbers with four digits; in others it's also page numbers and street addresses. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: > > What else could <input type=year> be other than reading some digits? This is an interesting question. If the answer is "nothing", then type=number with styling hints is the right answer for addressing the "no commas in years" problem. But if the answer is "in some locales, years are completely different", then we have a semantic on our hands. On Fri, 7 Mar 2014, Ryosuke Niwa wrote: > > Let me point out that not every calendar uses simple 2-4 digit numbers > to denote years. > > The Japanese era name calendar system, for example, requires an era name > such as Showa and Heisei associated with each year. > > For example, I was born in Gregorian year 1986 but any Japanese > government document would say I was born in Showa 61. My brother was > born in 1989 but, again, he must write "Heisei 1" instead on any > government form. > > There are also even quite few banks and other organizations in Japan > that use the era name system for various forms and documents. This is a pretty strong argument for a type=date feature, in principle. However: Some eras start mid-way through a year. For example, Meiji 45 lasts until July 30th 1912, and Taish? 1 starts then. Without date context, how would such values get round-tripped? If we assume a hypothetical type=year displays Japanese era years in the UI, but transmits Gregorian years over the wire, how do we ensure that the same year comes back? If round-tripping is important, then this is actually a _different_ input type than Gregorian years. Presumably, round-tripping is important here. For example, I would presume that the sentence "Emperor Meiji said 'Hello' in Meiji 45" has rather different connotations than "Emperor Meiji said 'Hello' in Taish? 1". On Tue, 11 Mar 2014, Smylers wrote: > > [..] But if <input?type=year> isn't otherwise useful, there may be a > more generic way of addressing the ?no commas in 4-digit years? issue > which also addresses 4-digit page numbers (and the like). Indeed. On Tue, 11 Mar 2014, Ryosuke Niwa wrote: > > This is why iOS allows users to pick either representation instead of > always using either based on locale. How does iOS handle the round-tripping issue? On Tue, 11 Mar 2014, Smylers wrote: > > It follows that any site which wants a year for any purpose and has a > Japanese audience would therefore benefit from a year widget which also > offers both Gregorian and Japanese ways of specifying a year. > > I could find such sites in English, and hypothesize that equivalent > Japanese sites would also exist. But in terms of providing requirements > to the HTML spec, it'd be better to have examples of actual sites, not > mere hypothetical ones. Indeed. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: > > And what about page numbers and street addresses (and other exceptions)? > If we have <input type=year>, then it would be rather odd to use it for > reading a page number. > > Most importantly, though, this would introduce yet another value for the > type attribute for something that can well be handled with existing > tools: <input pattern=\d{4}>. It is improbable that any year selection > widget would be useful. Years are normally best entered by typing them. The pattern="" attribute is about the wire format constraints, not about the display format. They are orthogonal issues. I think trying to reuse pattern="" in the context of numeric formatting is not a winning strategy. > On the other hand, as this is about input, not output, a simple > additional rule (which has other usability benefits, too) would solve > the issue, too: User agents may allow locale-specific group separators > in a number (e.g., ?1,500? when the locale is English), but they shall > accept a number without group separators, too (e.g., ?1500?, in any > locale). The problem is what the display should be, not what input should be accepted. One would not want this: <label> Year: <input type=number value="2014"> </label> ...to render, in an English context, as: Year: [ 2,014 ] On Wed, 19 Feb 2014, Nils Dagsson Moskopp wrote: > > Some calendars do have an integer offset to the gregorian calendar, > allowing localization. If I understand the Wikipedia pages correctly, to > get the year in the Thai solar calendar one has to add 543 to the ISO > year and for both the Republic of China calendar and North Korean > calendar one has to substract 1911. > > <http://en.wikipedia.org/wiki/Thai_solar_calendar> > <http://en.wikipedia.org/wiki/North_Korean_calendar> > <http://en.wikipedia.org/wiki/Minguo_calendar> These appear to all map cleanly to Gregorian years, which increases the argument for a type=year control. > Interface-wise, a dialog for <input type=year> without a value might > focus the current year initially ? I would consider that a usability > boon. Year selection dialogs do already exist: > <http://www.yuiblog.com/blog/2009/04/03/multi-layer-calendar/> > <http://msdn.microsoft.com/en-us/library/windows/desktop/bb760913(v=vs.85).aspx#SELECT_DIFF_YEAR> It's a pity those are Western only, it would have been interesting to see how they handled the overlap issues with Japanese eras. > Consider the following grouping of <input type=number>: > > [ 210 000 ] [+|-] > [ 19 250 ] [+|-] > [ 1 500 ] [+|-] This is a strong argument for not special-casing four-digit numbers. It looks like there's some demand for type=year; I've filed a bug to track implementor interest: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25315 It also looks like it would be good to have a way to style input controls, in particular <input type=number>, to use specific kinds of formatting. This is somewhat out of scope for HTML; I recommend developing a CSS feature for this purpose in conjunction with browser vendors, if anyone is interested in pursuing this. I've abandoned the idea of making the spec suggest that four-digit numbers should not have separators. On Wed, 19 Feb 2014, Nils Dagsson Moskopp wrote: > > I hereby ? only half-jokingly ? propose a @unit-type attribute for both > <input type=number> and <input type=range>, which conveys what the given > number represents. Thee @unit-type attribute can have the values ?K", > "s", "m", "kg", "cd", "A" and "mol" to enable hints for the seven SI > base units. A microsyntax using the tokens ?(?, ?)?, "+", "-", "*", "/" > and "^" could be used to specify derived units. User agents would be > encouraged to localized the displayed data. What problem is this solving? > Example for <input> element on a cooking form: > > <label>temperature <input type=number unit-type="K" value=453.15></label> > <label>cooking time <input type=number unit-type="s" value=900></label> > <label>beep frequency <input type=range unit-type="1/s" value=1></label> > > A user agent could display this ? localized ? as follows: > > temperature [ 180 ?C ][+|-] > cooking time [ 15 min ][+|-] > beep frequency [ each second ][+|-] > > The @unit-type attribute could also provide useful when allowed on the > <data>, <var>, <output> and <meter> elements. Mark my words. Is this something that has real author demand? What pages are working around the lack of this feature today? On Thu, 20 Feb 2014, Qebui Nehebkau wrote: > > When I first read this, I considered it unnecessary complexity. On > reflection, though, I find that I kind of like it. Perhaps it should be > allowed for <data> as well? Of course, I'm not sure that anyone would > really use it in practice. If no-one would use it... On Sat, 8 Mar 2014, David Dailey wrote: > > I think there are two interesting questions here: 1. What is a number? > A magnitude, an ordinal value (obeying the transitive property), a > rotational value (like day of year, degrees, day of week), an interval > value, a nominal labeling (take the SS Stevens taxonomy and add > rotational [1])? In the context of <input type=number>, a number is something for which it makes sense to have a up/down buttons. > 2. What sort of interface is best used to elicit a numerical response > from a person? We often assume that the human will type such a thing, > though for small n, radios and even selects work okay. Can a widget be > developed called a "throttle" which allows the user to use a joystick to > accelerate through an ordinal collection of n ordinal values (for large > n>10000) and to pick a number more quickly using the throttle than by > using the keyboard? Since the words of an alphabetic language have a > natural ordering (imposed by alphabetization) are not words numeric, and > cannot a throttle be used more effectively than a keyboard? That's up to the browser. On Tue, 18 Feb 2014, David Dailey wrote: > > <input > [magnitude|quantity|quality|time|thing|person|place|action|epistemic|quantif > ier|URI|anaphora|mediatype|direction|influence|...]=attribute-value-expressi > on-with-micro-syntax> > > with all appropriate cross-cultural studies underlying each > attribute-value. > > I am reminded of the Navajo verb system, in which epistemic values > (certainty), influence (transitive/intransitive), deixis > (this/that/yonder), and quantifiers (unique, none, all, some) are not > strictly orthogonal. Nle`i dzilh bits'i`i d'shighan : the unique and > well-known hill over yonder, beyond it there is my house. Were the hill > or the direction not well known, then it might be expressed differently > (as I seem to recall). It's maybe a bad example since bits'i`i could be > viewed as a preposition, but heck, it's been decades since I had a > Navajo-speaking hitchhiker in my car (and we seemed never to agree on > etymology)! > > What sorts of things might people want to say to us as web-folk? Are not > those all the possible types of input? I'm not sure I follow what you are asking here. On Tue, 18 Feb 2014, David Dailey wrote: > > Thanks to jwatt for raising the issue and to Karl for casting it in the > context that I presume jwatt was intending it to be cast. > > It reminds me of the early discussions, circa 2007 on > whatwg/public-html, of what exactly was meant by 'semantics'. Is it > merely HTML or is it meaning? > > In a cross-cultural sense, do we really expect that <p> and <aside> and > <quote> and <grid> and <section> and all the other things (that > HTML5.5555555... might ultimately asymptote with itself to include) are > inclusive of the ways that cultures, the world wide, might choose to > partition their discourse, into tags, elements, and taxonomies, replete > with meaning, context, style and behavior? > > Perhaps at the core of human expression is the <idea> and until we > respect one another for that core expression, distinctions between > semantics, behavior, presentation and context are askew, or at least > un-worldwidish. HTML7 should be radically different than HTML5: a new > prime number requires new thinking and new participation and perhaps, > even, reinvention at the expense of a broken wheel or two. I don't understand what you are proposing here, but it's worth noting that (a) "5" is also prime, and (b) we've dropped the number entirely. For further discussion on the issue of reinvention, I recommend this post: https://plus.google.com/+IanHickson/posts/SiLdNL9MsFw -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From estade at chromium.org Fri Apr 11 11:19:27 2014 From: estade at chromium.org (Evan Stade) Date: Fri, 11 Apr 2014 11:19:27 -0700 Subject: [whatwg] Additional details for invoking requestAutocomplete In-Reply-To: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> Message-ID: <CAO4XGS-iAaBRtV-3QW7xY4u4gh2bYgMURtg8gv_EmtoxwYKyhA@mail.gmail.com> Perhaps now is a more appropriate time for this discussion, given that requestAutocomplete is now published in the spec (!). -- Evan Stade On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade <estade at chromium.org> wrote: > Hi WhatWG. > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=?cc-number? the browser might provide an experience tailored > for a payment flow, or if there?s an element with autocomplete=?bday? the > browser might use an experience that?s tailored for sharing identiy. > > We?ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element.requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: ?transactionAmount? > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: ?transactionCurrency? > value: string > description: a valid ISO 4217 currency code that describes the > currency for transactionAmount. If not provided, the default is ?USD?. > > Justification? There are upper bounds on certain payment instruments, for > example different credit cards have different credit limits; a debit card > is linked to a bank account with a certain balance. It?s a much preferable > user experience to be able to catch these problems earlier rather than > waiting for the merchant to attempt the transaction and have it fail (or > have a user?s account overdrawn). Concretely, Chromium wants to handle > transactions over $2000 differently from transactions under that amount. > > Does this seem reasonable? > > > -- Evan Stade > From eoconnor at apple.com Fri Apr 11 15:36:41 2014 From: eoconnor at apple.com (Edward O'Connor) Date: Fri, 11 Apr 2014 15:36:41 -0700 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <m2k3av5w92.fsf@apple.com> Hi, Ian wrote: > Is there any reason to have two fields here, why not just "new" both > times? That works for me. Browsers can supply the same value for multiple autocomplete=new-password fields in the same form. > Also, should we have an "old" field for the old password, or is the > lack of an autofill field sufficient? I think it makes sense to have an old/current password token, for change password forms. It also helps to distinguish sign up forms from sign in forms, as Mike mentioned in the bug. > I've filed a bug to track this: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236 > > It needs multiple vendors on board to make progress. [?] > I've filed a bug to track this: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25237 > > It needs multiple vendors on board to make progress. Chrome has also expressed interest on both of these bugs. >> Also, consider the case of login forms without username fields. You >> see this sort of thing a lot these days, when sites remember who was >> last logged in: >> >> <form> >> <label>Password for hober: <input type=password name=pw></label> >> <p>Not hober? <a href=...>Click here to sign in</a>. >> </form> >> >> It's difficult for tools to manage the user's auth info for such >> pages. How can tools discover what the username is? The obvious >> solution, in a world with autocomplete=username, would be to add >> <input type=hidden autocomplete=username name=username value=hober> >> to the form. > > So far, autocomplete="" hasn't applied to <input type=hidden>. This > would be a bit weird, giving it a different meaning than usual > (providing information to the UA, rather than getting information from > the UA). I'm a bit skeptical of this kind of overloading. It is kind of weird. Given that, maybe this case should have new syntax. I'm OK with overloading autocomplete=username or with new syntax. I don't have a particular color to suggest for the bikeshed. > For the real submission case, I guess what we want is a way to say > "autocomplete=off" after the fact, basically. An HTTP header seems > like the most obvious solution. > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 > > Again, these need multiple vendors on board to make progress. Browsers are moving away from respecting autocomplete=off. I don't think we should be adding a new but basically equivalent mechanism. > I actually have a similar problem with purely JS-handled forms even > unrelated to credentials. Because the form is never really submitted > (even if we reuse the submit infrastructure, we cancel the 'submit' > event and handle the work on the JS side), there's never an indication > to the UA that it should save the fields, and so autofill never works > right on these forms, even for things like postal addresses or e-mail > addresses. > > For the pure JS case, an API (probably on the <form> itself) would > make sense and seems relatively easy. I've filed a bug on this: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 This case is pretty weird. Authors are going out of their way to avoid using the built in platform features that would get them autofill saving for free. In some cases, they might be doing this precisely because they want to prevent autofill but can't count on autocomplete=off anymore. > The requestAutocomplete() API is a Chrome proprietary feature right > now so it's sort of acadmic, but: > > Why would this only apply to requestAutocomplete()? Surely it would be > just as important for the case where the user agent is filling in a > form without using that API. Agreed. I don't see the benefit of requestAutocomplete() here. Ted From ian at hixie.ch Fri Apr 11 16:10:07 2014 From: ian at hixie.ch (Ian Hickson) Date: Fri, 11 Apr 2014 23:10:07 +0000 (UTC) Subject: [whatwg] Proposal: requestBackgroundProcessing() In-Reply-To: <20140220214338.GW770@pobox.com> References: <CAABs73iJcgcPFC5cKn=h1qHRCMfcaNNKm=jvVoKitWs8wOJKTQ@mail.gmail.com> <20140220214338.GW770@pobox.com> Message-ID: <alpine.DEB.2.00.1404102328350.6826@ps20323.dreamhostps.com> On Thu, 20 Feb 2014, Ashley Gullen wrote: > > We're building a browser-based P2P multiplayer engine on top of WebRTC > DataChannels. You can try out our work-in-progress here: > http://www.scirra.com/labs/multiplayer/test1/ > > The first player in to a room is assigned the host, and all other > subsequently joining peers connect to the host with WebRTC DataChannels > and start exchanging game data. Like all responsible HTML5 games, it > runs based on a requestAnimationFrame loop. requestAnimationFrame() is for animations, not for logic. For logic, your better bet is to use a worker or, at worst, setInterval(). > To prevent multiplayer games commonly hanging, perhaps there could be a > new API to request that a page can keep running at full capacity even in > the background, such as window.requestBackgroundProcessing(). Workers are the mechanism for running code in the background. I would strongly recommend not using a peer server architecture, though. Doing this requires trusting the client, which is highly dubious. A hostile player could just inject arbitrary code into your logic, and subtly cheat without being detected. It also means that handling the host crashing or closing their laptop or going into a tunnel is different than the same for another player, which is a sucky experience for everyone. On Thu, 20 Feb 2014, Glenn Maynard wrote: > On Thu, Feb 20, 2014 at 12:35 PM, Rik Cabanier wrote: > > > > Is WebRTC available in a worker? > > I don't know, but if not, fixing that is probably closer to the right > direction than letting people run fast timers in minimized UI threads. Yeah. If WebRTC isn't being exposed to workers, I recommend bringing that up with the editor of the WebRTC spec. On Thu, 20 Feb 2014, Ashley Gullen wrote: > > There's a lot of worker features that aren't widely supported yet, like > rendering to canvas with WebGL and 2D, Web Audio support, inputs, > various APIs like speech and fullscreen, so I don't think that's > practical right now. Presumably your server logic doesn't need to be fullscreen... On Thu, 20 Feb 2014, Ashley Gullen wrote: > > Since it's a peer-to-peer engine, the user acting as the server is also > a participant in the game. This means the server is also running the > full game experience with rendering and audio. That part of the logic should be in the tab. Then the tab just acts as a client to the server in the worker, in the same way that the other clients for the other players do. > The game logic is tied to rAF, since we intend to step the world once > per screen draw, including for the player acting as a server. Different players are going to have different frame rates, so it doesn't make sense to make one player's frame rate more important than another's. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From eoconnor at apple.com Fri Apr 11 16:23:16 2014 From: eoconnor at apple.com (Edward O'Connor) Date: Fri, 11 Apr 2014 16:23:16 -0700 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404071735580.21310@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> <alpine.DEB.2.00.1404071735580.21310@ps20323.dreamhostps.com> Message-ID: <m2d2gn5u3f.fsf@apple.com> Hi, >> The consensus opinion at WebRTC and MediaCapture seemed to be that >> the ability to let an app say "which of these 5 microphones do you >> want?" is more amenable to creating good apps than leaving this UI to >> the browser chrome. > > Seems to me that the privacy aspects (the fingerprinting > vulnerabilities from exposing this data), and the abuse aspects > (giving hostile sites the ability to access all the user's devices if > any are made available) would trump this. Surely we can rely on user > agents to provide nice UIs. I agree with Ian. For instance, on iOS we provide features that allow Web developers to take AirPlay into account when building custom video controls, but we do not expose the list of AirPlay targets to Web content. Ted From glenn at zewt.org Fri Apr 11 16:48:22 2014 From: glenn at zewt.org (Glenn Maynard) Date: Fri, 11 Apr 2014 18:48:22 -0500 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <m2d2gn5u3f.fsf@apple.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> <alpine.DEB.2.00.1404071735580.21310@ps20323.dreamhostps.com> <m2d2gn5u3f.fsf@apple.com> Message-ID: <CABirCh9S=7o7+DYq4zB2a+FtVL3Zv7wuUdOnn-JkwO3euUpFaw@mail.gmail.com> On Fri, Apr 11, 2014 at 6:23 PM, Edward O'Connor <eoconnor at apple.com> wrote: > >> The consensus opinion at WebRTC and MediaCapture seemed to be that > >> the ability to let an app say "which of these 5 microphones do you > >> want?" is more amenable to creating good apps than leaving this UI to > >> the browser chrome. > > > > Seems to me that the privacy aspects (the fingerprinting > > vulnerabilities from exposing this data), and the abuse aspects > > (giving hostile sites the ability to access all the user's devices if > > any are made available) would trump this. Surely we can rely on user > > agents to provide nice UIs. > The fingerprinting could be pretty specific, too. For example, my apple TV advertises itself with a custom AirPlay name. I agree with Ian. For instance, on iOS we provide features that allow > Web developers to take AirPlay into account when building custom video > controls, but we do not expose the list of AirPlay targets to Web > content. > Some other issues: - The browser will give a consistent UI. I don't get a different "Save As" dialog for each site, and I shouldn't get a different "which mic do you want to use?" dialog for each site either. - The browser will give a UI. My guess is that the vast majority of web apps wouldn't provide a selection UI *at all* for mics or speakers, and just use the default. - Web apps shouldn't need to implement basic UI for things like this, just like they shouldn't have to implement their own Save As dialogs. That's the platform's job. -- Glenn Maynard From brettz9 at yahoo.com Sat Apr 12 20:13:15 2014 From: brettz9 at yahoo.com (Brett Zamir) Date: Sun, 13 Apr 2014 11:13:15 +0800 Subject: [whatwg] Self-imposed script or networking restrictions (toward privacy and XSS-protection, and stimulating offline tool creation and increased but safer privilege escalation) Message-ID: <534A00CB.6060007@yahoo.com> *Problem:* I believe that if Ajax or other forms of dynamic scripting had been absent but were proposed today, people would probably say things like: 1. "What, you want to allow sites to have the ability out of the box to track my mouse movements?" 2. "You want sites to be able to know what I'm typing in a text box before I choose to explicitly submit?" 3. "You want to allow executable code, including third party code, to update itself without a means for a developer to review the source?" 4. "You want my generic offline build tool to cause users concern about whether the data I've added locally will be sent back to the server?" While browsers will hopefully allow user-directed control of this regardless of standards, ala NoScript or the like, there is no means (to my knowledge), besides perhaps packaging the file as an add-on with limited privileges or a sandboxed site-specific_browser ( https://en.wikipedia.org/wiki/Site-specific_browser ), by which a website author can cause its own particular web app loaded over the web to be issued in such as manner as to allay privacy or cross-site scripting concerns by having the browser inform the user that a given type of (safe) app has been loaded, one which is either not able to: 1. execute any scripts at all 2. phone home at all 3. phone home at all after the initial static HTML payload 4. phone home at all after the initial static HTML payload except to a list of origins indicated to the user The above ought to also allay security concerns in the case that a script uses eval capabilities on a post-load network-delivered string. *Proposed Solution:* I would like to propose that HTTP headers, an internal HTML tag attribute (like the offline apps manifest attribute), and/or changes to the AppCache manifest structure be created which will cause desired security principal restrictions to be enforced, in particular either: 1. preventing all scripting 2. allowing scripting but prohibiting all Ajax or other networking requests (dynamic insertion of iframes, image or link tags with remote URLs, dynamic form submissions, etc.) 3. allowing scripting but prohibiting all Ajax or other networking requests except to URL origins or pages indicated within a whitelist (where the browser UI would display any such whitelist to users and/or prevent requests to the whitelist until the user approved, ideally providing them first a view of the proposed payload, and if approved, with a preview of the response payload and a choice as to whether to accept, and with the option to remember any such outgoing or incoming approvals in the future). Perhaps the AppCache manifest could be extended to provide this directive of prohibited or conditional updating. 4. optionally excluding loading of other resources within even the initial declarative HTML payload. Data: URIs and blobs could, however, be allowed dynamically where scripting was allowed (e.g., whether through window.open(), a dynamic execution of an <a download=""> tag or the like) as well as statically without the need for a whitelist. *Benefits:* 1. The designation by authors of this status could give assurance to users that privacy between page loads will not be violated on sites of general interest. This would be especially useful in apps utilizing IndexedDB where the user might make a lot of local modifications but not wish to share these back with the origin server. 2. It could also be a boon to web developers who wish to share generic build tools (whether ones that are online, offlinable via AppCache, and/or which run from file://) in a manner which does not raise privacy concerns. Currently, many web apps are distributed along with OS-dependent build scripts or scripts using non-client-side languages such as Node.js, Python, or Java, and whose interpretation requires the downloading of additional tools. If the developer could create a tool which would not raise privacy concerns but would instead inform users that the code they have loaded locally will not be able to update itself without their permission (at least without giving consent to a proposed payload back to the server), developers may prefer to write in client-side JavaScript for their own convenience (given the ubiquity of client-side JavaScript), and with the benefit of facilitating modifications on their tools whether by paid developers or open source contributors who may be most likely to know at least some JavaScript. Their code could provide build functionality by compiling locally designated files or other content into a file download, texarea, etc. 3. If implemented, the sandboxing capability could be leveraged to blur the line between add-ons, web apps, and mobile apps and be used by site-specific browser implementations. Web app users would gain the same peace of mind and more granular privilege control of mobile apps. As a result of users knowing there would be this sandboxing, the door could, moreover, be opened for websites to request any privilege allowed to add-ons without needing the step of special packaging and encouraging the development of standardized privileged APIs which would work across the web, mobile, and packaged add-ons*. A website may already currently ask users from the web whether they wish to install a privileged add-on, so there should be no net increase in security risk by allowing sandboxed websites from doing the same; on the contrary, the requirement of granting privileges granularly (unlike in some add-on systems), will ensure that users are well-informed as to the exact security or privacy implications of granting approval, as well as let websites be designed for progressive enhancement (e.g., an app might only ask for privileges as needed, a user might allow the app one high-level privilege but not another (e.g., granting arbitrary local file access on an app deemed by the user to be safe in its current snapshot, but disallow networking-related privileges), etc.). My Firefox add-on, AsYouWish (at https://github.com/brettz9/asyouwish/ ), is meant as a current workaround in this regard for Firefox, https://github.com/brettz9/asyouwish/ , but while it offers granular privileges, it suffers from not being currently sandboxable and not being standard across browser. Best wishes, Brett * Proposed to Mozilla at https://bugzilla.mozilla.org/show_bug.cgi?id=848647 From dbeam at chromium.org Mon Apr 14 21:41:51 2014 From: dbeam at chromium.org (Dan Beam) Date: Mon, 14 Apr 2014 21:41:51 -0700 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise Message-ID: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> Hey whatwg@, I propose requestAutocomplete()[1] should return a Promise. This has been requested since the creation of this API[2][3] and seems like a natural fit. Web authors can then call requestAutocomplete() like this: form.requestAutocomplete().then(function() { // form.submit() or some other success action }, function(errorDetails) { // handle error based on errorDetails.reason (e.g. "cancel") }); The returned promise would be resolved after the corresponding "autocomplete" or "autocompleteerror" event is dispatched on the form. Null would be passed on fulfillment* and {"reason": <matching AutocompleteErrorEvent#reason>} would be passed on rejection. There should be little compatibility risk as requestAutocomplete() currently returns undefined. Thoughts? Concerns? Questions? -- Dan Beam dbeam at chromium.org * until I think of something useful for the success case... [1] http://www.whatwg.org/specs/web-apps/current-work/#dom-form-requestautocomplete [2] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/0TnqLOvC2ZY [3] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/aqKcZkCMsUI From domenic at domenicdenicola.com Mon Apr 14 21:44:59 2014 From: domenic at domenicdenicola.com (Domenic Denicola) Date: Tue, 15 Apr 2014 04:44:59 +0000 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise In-Reply-To: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> References: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> Message-ID: <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Dan Beam > I propose requestAutocomplete()[1] should return a Promise. This has been requested since the creation of this API[2][3] and seems like a natural fit. Web authors can then call requestAutocomplete() like this: I strongly support this. > Null would be passed on fulfillment* and `undefined` would be better, as that is what normal JavaScript functions return when they have nothing to return. > {"reason": <matching AutocompleteErrorEvent#reason>} would be passed on rejection. Rejection reasons should always be instanceof Error: https://github.com/w3ctag/promises-guide#rejection-reasons-should-be-errors From vnicolas at mozilla.com Tue Apr 15 09:08:23 2014 From: vnicolas at mozilla.com (Vivien Nicolas) Date: Tue, 15 Apr 2014 18:08:23 +0200 Subject: [whatwg] Add a |transient| mechanism to the notifications API Message-ID: <534D5977.4040307@mozilla.com> Hello, Would it be possible to add a |transient| mechanism to the notifications spec ? In the context of FirefosOS, one of the use case is for example an email application. For instance the user can write a message, click the send button, and then leave the application to do something else. It would be useful if the application is able to give the user a transient notification that the email has been correctly sent. This kind of notifications are not particularly useful after a while and should dismiss automatically after a small delay. Looking at what others are doing, it seems related to 'Toasts'. Here is what I found on google: Gnome is using a |transient| hint (https://bugzilla.gnome.org/show_bug.cgi?id=633412) Windows 8 call those type of notifications Toast and display them for 7 seconds (http://msdn.microsoft.com/en-us/library/windows/apps/hh779727.aspx) Android also call that Toasts and let the user specify a duration (http://developer.android.com/guide/topics/ui/notifiers/toasts.html) iOS: It seems like this is not part of the default UI toolkit. Looking at Growl for mac (http://growl.info/) it seems like there is no possibility for the notifications to be transient or not. Instead everything is customizable by the user, and all notifications ends up into the 'Rollup' database (even when you mount/unmount a hard drive). Regards, Vivien. From domenic at domenicdenicola.com Tue Apr 15 09:12:12 2014 From: domenic at domenicdenicola.com (Domenic Denicola) Date: Tue, 15 Apr 2014 16:12:12 +0000 Subject: [whatwg] Add a |transient| mechanism to the notifications API In-Reply-To: <534D5977.4040307@mozilla.com> References: <534D5977.4040307@mozilla.com> Message-ID: <67441e562cde478ca71bab7e0ce09d0e@BN1PR05MB325.namprd05.prod.outlook.com> This seems like a valuable feature. I am hopeful something like it can be added. >From my reading of Windows Phone 8.1 reviews, the way they handle this is by allowing applications to remove notifications themselves. This seems like the most flexible approach: applications could automatically remove the notification after 7 seconds, or e.g. remove them after the email has been read on another computer. From annevk at annevk.nl Tue Apr 15 10:46:55 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Tue, 15 Apr 2014 18:46:55 +0100 Subject: [whatwg] Add a |transient| mechanism to the notifications API In-Reply-To: <67441e562cde478ca71bab7e0ce09d0e@BN1PR05MB325.namprd05.prod.outlook.com> References: <534D5977.4040307@mozilla.com> <67441e562cde478ca71bab7e0ce09d0e@BN1PR05MB325.namprd05.prod.outlook.com> Message-ID: <CADnb78jw3NvPmdJm2zbEcBe=_CZu1U5v1Ke8BV_3L=g22A2Pfg@mail.gmail.com> On Tue, Apr 15, 2014 at 5:12 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote: > From my reading of Windows Phone 8.1 reviews, the way they handle this is by allowing applications to remove notifications themselves. We already have this actually: var = n = new Notification(...) n.onshow = () => setTimeout(() => n.close(), 7000) I guess this would be for the case where you close the window before that timer is able to run. Normally that would leave the notification in the notification center, but with say a duration member set to non-zero it would be removed. -- http://annevankesteren.nl/ From dbeam at chromium.org Tue Apr 15 16:29:05 2014 From: dbeam at chromium.org (Dan Beam) Date: Tue, 15 Apr 2014 16:29:05 -0700 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise In-Reply-To: <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> References: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> Message-ID: <CANpe7K25BCCFJuS89YQ9Od81ZhPDVdxUoyzP0uz=BTUpnzJqTw@mail.gmail.com> On Mon, Apr 14, 2014 at 9:44 PM, Domenic Denicola < domenic at domenicdenicola.com> wrote: > > From: whatwg-bounces at lists.whatwg.org [mailto: whatwg-bounces at lists.whatwg.org] On Behalf Of Dan Beam > > > I propose requestAutocomplete()[1] should return a Promise. This has been requested since the creation of this API[2][3] and seems like a natural fit. Web authors can then call requestAutocomplete() like this: > > I strongly support this. > > > Null would be passed on fulfillment* and > > `undefined` would be better, as that is what normal JavaScript functions return when they have nothing to return. So just pass no argument at all (i.e. arguments.length == 0)? I was under the impression some type of value should always be returned (but I'm biased by blink/v8's current implementation). > > > {"reason": <matching AutocompleteErrorEvent#reason>} would be passed on rejection. > > Rejection reasons should always be instanceof Error: https://github.com/w3ctag/promises-guide#rejection-reasons-should-be-errors > Great, will figure out a way to subclass Error to provide some type of "reason" property on the rejection argument. -- Dan Beam dbeam at chromium.org From bzbarsky at MIT.EDU Tue Apr 15 22:08:16 2014 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Wed, 16 Apr 2014 01:08:16 -0400 Subject: [whatwg] canvas drawImage and EXIF orientation metadata Message-ID: <534E1040.3040103@mit.edu> Right now canvas drawImage ignores EXIF orientation metadata. Could we add a version that doesn't do that? Especially with CSS growing things like the image-orientation property, it would be good to support drawing the image in its correct orientation. -Boris From vnicolas at mozilla.com Wed Apr 16 03:37:04 2014 From: vnicolas at mozilla.com (Vivien Nicolas) Date: Wed, 16 Apr 2014 12:37:04 +0200 Subject: [whatwg] Add a |transient| mechanism to the notifications API In-Reply-To: <CADnb78jw3NvPmdJm2zbEcBe=_CZu1U5v1Ke8BV_3L=g22A2Pfg@mail.gmail.com> References: <534D5977.4040307@mozilla.com> <67441e562cde478ca71bab7e0ce09d0e@BN1PR05MB325.namprd05.prod.outlook.com> <CADnb78jw3NvPmdJm2zbEcBe=_CZu1U5v1Ke8BV_3L=g22A2Pfg@mail.gmail.com> Message-ID: <534E5D50.5010507@mozilla.com> On 15/04/2014 19:46, Anne van Kesteren wrote: > On Tue, Apr 15, 2014 at 5:12 PM, Domenic Denicola > <domenic at domenicdenicola.com> wrote: >> From my reading of Windows Phone 8.1 reviews, the way they handle this is by allowing applications to remove notifications themselves. > > We already have this actually: > > var = n = new Notification(...) > n.onshow = () => setTimeout(() => n.close(), 7000) > > > I guess this would be for the case where you close the window before > that timer is able to run. Normally that would leave the notification > in the notification center, but with say a duration member set to > non-zero it would be removed. > It could be done this way as mentioned. What I'm looking for is a hint for the user agent, so such notifications can be displayed differently by the user-agent if it is the one rendering notifications, or forwarded to the underlying platform notifications API. From junov at google.com Wed Apr 16 07:22:28 2014 From: junov at google.com (Justin Novosad) Date: Wed, 16 Apr 2014 07:22:28 -0700 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <534E1040.3040103@mit.edu> References: <534E1040.3040103@mit.edu> Message-ID: <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> +1 But why a new version of drawImage? Couldn't we just modify the existing drawImage definition to state that it takes into account the image-orientation property on the source image? The default value for image-orientation is 0deg, which corresponds to the current drawImage behavior. So I think we can make that change to the drawImage spec without breaking stuff, as long as we make the change while image-orientation is still an experimental feature. On Tue, Apr 15, 2014 at 10:08 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > Right now canvas drawImage ignores EXIF orientation metadata. > > Could we add a version that doesn't do that? Especially with CSS growing > things like the image-orientation property, it would be good to support > drawing the image in its correct orientation. > > -Boris > From annevk at annevk.nl Wed Apr 16 07:26:55 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 16 Apr 2014 15:26:55 +0100 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> Message-ID: <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> On Wed, Apr 16, 2014 at 3:22 PM, Justin Novosad <junov at google.com> wrote: > But why a new version of drawImage? Couldn't we just modify the existing > drawImage definition to state that it takes into account the > image-orientation property on the source image? The default value for > image-orientation is 0deg, which corresponds to the current drawImage > behavior. So I think we can make that change to the drawImage spec without > breaking stuff, as long as we make the change while image-orientation is > still an experimental feature. Why is image-orientation in CSS for <img>? For background-image that makes sense, but if you are actually affecting the semantics of the image that is displayed, it seems like it should be in HTML or a hint in the image format. (My reply to Boris was going to be that drawImage() should follow whatever flag we introduce for <img> to have this behavior, seems weird for that flag to be in CSS though.) -- http://annevankesteren.nl/ From junov at google.com Wed Apr 16 07:45:46 2014 From: junov at google.com (Justin Novosad) Date: Wed, 16 Apr 2014 07:45:46 -0700 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> Message-ID: <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> On Wed, Apr 16, 2014 at 7:26 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > On Wed, Apr 16, 2014 at 3:22 PM, Justin Novosad <junov at google.com> wrote: > > But why a new version of drawImage? Couldn't we just modify the existing > > drawImage definition to state that it takes into account the > > image-orientation property on the source image? The default value for > > image-orientation is 0deg, which corresponds to the current drawImage > > behavior. So I think we can make that change to the drawImage spec > without > > breaking stuff, as long as we make the change while image-orientation is > > still an experimental feature. > > Why is image-orientation in CSS for <img>? For background-image that > makes sense, but if you are actually affecting the semantics of the > image that is displayed, it seems like it should be in HTML or a hint > in the image format. I was wondering the same thing. From the image-orientation spec: "It applies only to content images (e.g. replaced elements and generated content), not decorative images (such as background-image)." So this property apparently has a considerably larger scope than just correcting the orientation of images from files, which I guess explains why it is in CSS. > (My reply to Boris was going to be that drawImage() should follow > whatever flag we introduce for <img> to have this behavior, seems > weird for that flag to be in CSS though.) > > > -- > http://annevankesteren.nl/ > From bzbarsky at MIT.EDU Wed Apr 16 07:53:46 2014 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Wed, 16 Apr 2014 10:53:46 -0400 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> Message-ID: <534E997A.5090504@mit.edu> On 4/16/14 10:22 AM, Justin Novosad wrote: > But why a new version of drawImage? Couldn't we just modify the existing > drawImage definition to state that it takes into account the > image-orientation property on the source image? We could do that, though it introduces a dependency of drawImage on style computation that isn't there right now. > So I think we can make that change to the drawImage spec > without breaking stuff, as long as we make the change > while image-orientation is still an experimental feature. Note that image-orientation has been shipping in Firefox for several releases now. -Boris From annevk at annevk.nl Wed Apr 16 08:09:04 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 16 Apr 2014 16:09:04 +0100 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> Message-ID: <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> On Wed, Apr 16, 2014 at 3:45 PM, Justin Novosad <junov at google.com> wrote: > I was wondering the same thing. From the image-orientation spec: "It applies > only to content images (e.g. replaced elements and generated content), not > decorative images (such as background-image)." > So this property apparently has a considerably larger scope than just > correcting the orientation of images from files, which I guess explains why > it is in CSS. I don't really follow the reasoning. But I guess if this has been shipping in Firefox for a while we might be out of luck changing this. -- http://annevankesteren.nl/ From bzbarsky at MIT.EDU Wed Apr 16 08:15:46 2014 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Wed, 16 Apr 2014 11:15:46 -0400 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> Message-ID: <534E9EA2.1000602@mit.edu> On 4/16/14 11:09 AM, Anne van Kesteren wrote: > I don't really follow the reasoning. But I guess if this has been > shipping in Firefox for a while we might be out of luck changing this. I doubt image-orientation is widely used, esp. in combination with drawImage. But if we want to use it here, we should coordinate with the CSS WG at least. -Boris From junov at google.com Wed Apr 16 09:54:24 2014 From: junov at google.com (Justin Novosad) Date: Wed, 16 Apr 2014 09:54:24 -0700 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <534E9EA2.1000602@mit.edu> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> <534E9EA2.1000602@mit.edu> Message-ID: <CABpaAqSWOZ+HyEAPc1mJgj=s5-SFTYPbZe=rFZrQv-h+yHdc6g@mail.gmail.com> Another use case to think about is: XHR->Blob->ImageBitmap->Canvas(2D or WebGL) With that data flow, there is no opportunity to use a CSS property to tweak image orientation. There is this idea though: http://wiki.whatwg.org/wiki/ImageBitmap_Options Boris' point about adding a dependency on style computation is concerning. This could potentially seriously regress performance of existing apps that (inadvertently?) invalidate style of image elements at each animation frame. >From an implementation standpoint though, it would make sense for image elements to to store decoded images with the corrected orientation baked-in, and to be able to use that cached decoded image buffer directly in drawImage, without having to re-apply (or even verify) orientation correction at that time. But of course, that implies resolving style at image decode time. What to do? On Wed, Apr 16, 2014 at 8:15 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 4/16/14 11:09 AM, Anne van Kesteren wrote: > >> I don't really follow the reasoning. But I guess if this has been >> shipping in Firefox for a while we might be out of luck changing this. >> > > I doubt image-orientation is widely used, esp. in combination with > drawImage. > > But if we want to use it here, we should coordinate with the CSS WG at > least. > > -Boris > > > From annevk at annevk.nl Wed Apr 16 10:57:41 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 16 Apr 2014 18:57:41 +0100 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CABpaAqSWOZ+HyEAPc1mJgj=s5-SFTYPbZe=rFZrQv-h+yHdc6g@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> <534E9EA2.1000602@mit.edu> <CABpaAqSWOZ+HyEAPc1mJgj=s5-SFTYPbZe=rFZrQv-h+yHdc6g@mail.gmail.com> Message-ID: <CADnb78jnvd1He-pDHnOO==8L9wWZQ6mKi7ikb8ScZdDkoudeQA@mail.gmail.com> On Wed, Apr 16, 2014 at 5:54 PM, Justin Novosad <junov at google.com> wrote: > From an implementation standpoint though, it would make sense for image > elements to to store decoded images with the corrected orientation baked-in, > and to be able to use that cached decoded image buffer directly in > drawImage, without having to re-apply (or even verify) orientation > correction at that time. But of course, that implies resolving style at > image decode time. What to do? We could consider moving this property into markup. It seems somewhat more semantic than stylistic too. Image orientation affects the content. -- http://annevankesteren.nl/ From junov at google.com Wed Apr 16 12:23:39 2014 From: junov at google.com (Justin Novosad) Date: Wed, 16 Apr 2014 12:23:39 -0700 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CADnb78jnvd1He-pDHnOO==8L9wWZQ6mKi7ikb8ScZdDkoudeQA@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> <534E9EA2.1000602@mit.edu> <CABpaAqSWOZ+HyEAPc1mJgj=s5-SFTYPbZe=rFZrQv-h+yHdc6g@mail.gmail.com> <CADnb78jnvd1He-pDHnOO==8L9wWZQ6mKi7ikb8ScZdDkoudeQA@mail.gmail.com> Message-ID: <CABpaAqRm5NOD+=6HAn-fvRDeroiAHwTqT--SF=A3yNJkvrBuig@mail.gmail.com> On Wed, Apr 16, 2014 at 10:57 AM, Anne van Kesteren <annevk at annevk.nl>wrote: > On Wed, Apr 16, 2014 at 5:54 PM, Justin Novosad <junov at google.com> wrote: > > From an implementation standpoint though, it would make sense for image > > elements to to store decoded images with the corrected orientation > baked-in, > > and to be able to use that cached decoded image buffer directly in > > drawImage, without having to re-apply (or even verify) orientation > > correction at that time. But of course, that implies resolving style at > > image decode time. What to do? > > We could consider moving this property into markup. It seems somewhat > more semantic than stylistic too. Image orientation affects the > content. > Yes, that makes a lot of sense IMHO. I just posted feedback to www-style > > -- > http://annevankesteren.nl/ > From eoconnor at apple.com Wed Apr 16 16:10:36 2014 From: eoconnor at apple.com (Edward O'Connor) Date: Wed, 16 Apr 2014 16:10:36 -0700 Subject: [whatwg] [notifications][editorial] tweaking the "Activating a notification" window.focus() note Message-ID: <m261m898gj.fsf@eoconnor.apple.com> Hi, In ?4.6 Activating a notification, there's a note that currently reads "User agents are strongly encouraged to make window.focus() work from within the event listener for the event named click as a means of focusing the browsing context related to the notification." This note assumes that the UA doesn't automatically focus the browsing context when a notification is activated. (Safari on OS X is one example of a UA which does this.) The note should be adjusted so that readers understand that calling window.focus() may not be necessary on some combinations of UA and system notification service. Ted From annevk at annevk.nl Wed Apr 16 16:14:41 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 17 Apr 2014 00:14:41 +0100 Subject: [whatwg] [notifications][editorial] tweaking the "Activating a notification" window.focus() note In-Reply-To: <m261m898gj.fsf@eoconnor.apple.com> References: <m261m898gj.fsf@eoconnor.apple.com> Message-ID: <CADnb78iMXJPFGS9OUq_=HsA1XOszA7hsKigvyhEkCcFkBB9_tg@mail.gmail.com> On Thu, Apr 17, 2014 at 12:10 AM, Edward O'Connor <eoconnor at apple.com> wrote: > In ?4.6 Activating a notification, there's a note that currently reads > > "User agents are strongly encouraged to make window.focus() work > from within the event listener for the event named click as a means > of focusing the browsing context related to the notification." > > This note assumes that the UA doesn't automatically focus the browsing > context when a notification is activated. (Safari on OS X is one example > of a UA which does this.) The note should be adjusted so that readers > understand that calling window.focus() may not be necessary on some > combinations of UA and system notification service. Cool, do you have a plan for shared workers? (E.g. down the road with service workers you can imagine creating Notification objects from there at which point things become a bit hazy.) -- http://annevankesteren.nl/ From glenn at zewt.org Wed Apr 16 16:45:04 2014 From: glenn at zewt.org (Glenn Maynard) Date: Wed, 16 Apr 2014 18:45:04 -0500 Subject: [whatwg] [notifications][editorial] tweaking the "Activating a notification" window.focus() note In-Reply-To: <m261m898gj.fsf@eoconnor.apple.com> References: <m261m898gj.fsf@eoconnor.apple.com> Message-ID: <CABirCh_pbd4oLxz_cS6d5GqNFq8qV58bsP01HS9nHcorihk=5g@mail.gmail.com> On Wed, Apr 16, 2014 at 6:10 PM, Edward O'Connor <eoconnor at apple.com> wrote: > Hi, > > In ?4.6 Activating a notification, there's a note that currently reads > > "User agents are strongly encouraged to make window.focus() work > from within the event listener for the event named click as a means > of focusing the browsing context related to the notification." > > This note assumes that the UA doesn't automatically focus the browsing > context when a notification is activated. (Safari on OS X is one example > of a UA which does this.) The note should be adjusted so that readers > understand that calling window.focus() may not be necessary on some > combinations of UA and system notification service. > Rather, pages should never be allowed to window.focus() when a notification is activated. If the platform's notification design wants that to happen, it's the platform's job to do that, and pages shouldn't all be required to call window.focus() to make this happen consistently. (If for some reason the platform doesn't want that to happen, the page shouldn't be able to override that, either.) If there are notifications that don't want to focus a page when activated, that should be a setting on the notification. -- Glenn Maynard From domenic at domenicdenicola.com Wed Apr 16 18:59:21 2014 From: domenic at domenicdenicola.com (Domenic Denicola) Date: Thu, 17 Apr 2014 01:59:21 +0000 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise In-Reply-To: <CANpe7K25BCCFJuS89YQ9Od81ZhPDVdxUoyzP0uz=BTUpnzJqTw@mail.gmail.com> References: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> <CANpe7K25BCCFJuS89YQ9Od81ZhPDVdxUoyzP0uz=BTUpnzJqTw@mail.gmail.com> Message-ID: <1fb95b4500944205baf2857a6525bc51@BN1PR05MB325.namprd05.prod.outlook.com> From: dbeam at google.com [mailto:dbeam at google.com] On Behalf Of Dan Beam > So just pass no argument at all (i.e. arguments.length == 0)? ?I was under the impression some type of value should always be returned (but I'm biased by blink/v8's current implementation). It's equivalent, both for promises and for return values of functions. Both `new Promise(resolve => resolve())` and `new Promise(resolve => resolve(undefined))` give a promise whose fulfillment value is `undefined`. In this sense `resolve` behaves like all non-evil JavaScript functions, where evil is defined as "checking `arguments.length`" ;) From jonas at sicking.cc Thu Apr 17 00:46:55 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 17 Apr 2014 00:46:55 -0700 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> Message-ID: <CA+c2ei9Ww7NxN-oO1eKhg5gunkidJja1NAGZpPJvjsQ3fSD0yQ@mail.gmail.com> On Wed, Apr 16, 2014 at 8:09 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > On Wed, Apr 16, 2014 at 3:45 PM, Justin Novosad <junov at google.com> wrote: >> I was wondering the same thing. From the image-orientation spec: "It applies >> only to content images (e.g. replaced elements and generated content), not >> decorative images (such as background-image)." >> So this property apparently has a considerably larger scope than just >> correcting the orientation of images from files, which I guess explains why >> it is in CSS. > > I don't really follow the reasoning. But I guess if this has been > shipping in Firefox for a while we might be out of luck changing this. The problem here stemms from that orientation data lives as "metadata" in the EXIF data of image formats. This means that many tools has simply ignored that metadata. The result seems to have been that people open their images in tools that ignore the EXIF metadata. Then rotates the pixel data using that tool. Then saves the image again while keeping the EXIF metadata unchanged. This now means the pixels have been rotated (say) 90 degrees, but the EXIF metadata still says "rotate image 90 degrees". So any tool that now honors the EXIF renders the picture *wrong*. So effectively the EXIF metadata has to be ignored in order to keep webcompat. That was the case even before image-orientation was implemented. FWIW I believe that WebP is remaking this same mistake. Would be cool if someone tried to prevent this from happening. / Jonas From glenn at zewt.org Thu Apr 17 07:30:21 2014 From: glenn at zewt.org (Glenn Maynard) Date: Thu, 17 Apr 2014 09:30:21 -0500 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CA+c2ei9Ww7NxN-oO1eKhg5gunkidJja1NAGZpPJvjsQ3fSD0yQ@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> <CA+c2ei9Ww7NxN-oO1eKhg5gunkidJja1NAGZpPJvjsQ3fSD0yQ@mail.gmail.com> Message-ID: <CABirCh8AipxyJnt0PiPj=qAY58T+8Msm8a09JUPV7cUTvL4cBA@mail.gmail.com> On Thu, Apr 17, 2014 at 2:46 AM, Jonas Sicking <jonas at sicking.cc> wrote: > The problem here stemms from that orientation data lives as "metadata" > in the EXIF data of image formats. This means that many tools has > simply ignored that metadata. > > The result seems to have been that people open their images in tools > that ignore the EXIF metadata. Then rotates the pixel data using that > tool. Then saves the image again while keeping the EXIF metadata > unchanged. > > This now means the pixels have been rotated (say) 90 degrees, but the > EXIF metadata still says "rotate image 90 degrees". So any tool that > now honors the EXIF renders the picture *wrong*. > > So effectively the EXIF metadata has to be ignored in order to keep > webcompat. That was the case even before image-orientation was > implemented. > > FWIW I believe that WebP is remaking this same mistake. Would be cool > if someone tried to prevent this from happening. > The question was "why is this a CSS style instead of a property on <img>", not "why isn't this just the default". -- Glenn Maynard From jonas at sicking.cc Thu Apr 17 14:32:41 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 17 Apr 2014 14:32:41 -0700 Subject: [whatwg] BroadcastChannel should support structured clones Message-ID: <CA+c2ei-4u-iMSts6z0owHi2V8Z6bEXhgj1_WyJmak+mACWR1VA@mail.gmail.com> It would be very useful to be able to send structured data, including Blobs, through the BroadcastChannel API. This is something we've seen any time we've done storage or message passing, that one of the first thing authors ask for is to not have to do JSON serialization/parsing manually. The ability to pass ArrayBuffers and Blobs is somewhat less commonly asked for, likely because binary data is less often used, but seems important nonetheless. We can't allow transferring of objects, since you can't transfer something to all listeners of a broadcasting API. But plain structured clones should be no problem to support conceptually (though more work to implement of course). We've started looking at doing structured clone support for Firefox and likely won't ship until we have that implemented. / Jonas From jonas at sicking.cc Thu Apr 17 15:09:43 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 17 Apr 2014 15:09:43 -0700 Subject: [whatwg] BroadcastChannel should support structured clones In-Reply-To: <CA+c2ei-4u-iMSts6z0owHi2V8Z6bEXhgj1_WyJmak+mACWR1VA@mail.gmail.com> References: <CA+c2ei-4u-iMSts6z0owHi2V8Z6bEXhgj1_WyJmak+mACWR1VA@mail.gmail.com> Message-ID: <CA+c2ei_4hFxmegCK13LyiZV4pjwou_TyCUO44HrqizccR5VZvA@mail.gmail.com> Another thing that seems like an oversight in the spec is that the spec currently says that BroadcastChannel should be exposed in Window context. We should also expose it in Worker contexts. / Jonas On Thu, Apr 17, 2014 at 2:32 PM, Jonas Sicking <jonas at sicking.cc> wrote: > It would be very useful to be able to send structured data, including > Blobs, through the BroadcastChannel API. > > This is something we've seen any time we've done storage or message > passing, that one of the first thing authors ask for is to not have to > do JSON serialization/parsing manually. The ability to pass > ArrayBuffers and Blobs is somewhat less commonly asked for, likely > because binary data is less often used, but seems important > nonetheless. > > We can't allow transferring of objects, since you can't transfer > something to all listeners of a broadcasting API. But plain structured > clones should be no problem to support conceptually (though more work > to implement of course). > > We've started looking at doing structured clone support for Firefox > and likely won't ship until we have that implemented. > > / Jonas From gcasto at chromium.org Mon Apr 21 14:44:22 2014 From: gcasto at chromium.org (Garrett Casto) Date: Mon, 21 Apr 2014 14:44:22 -0700 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <m2k3av5w92.fsf@apple.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> <m2k3av5w92.fsf@apple.com> Message-ID: <CAGQFVJgkQknT+VTV9ob6VO5tv9SPaRzpfJBY4juxd62V5NeVYQ@mail.gmail.com> > > > > For the real submission case, I guess what we want is a way to say > > "autocomplete=off" after the fact, basically. An HTTP header seems > > like the most obvious solution. > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 > > > > Again, these need multiple vendors on board to make progress. > > Browsers are moving away from respecting autocomplete=off. I don't think > we should be adding a new but basically equivalent mechanism. > > While I agree that it's a concern, I'm not overly worried that this is going to be abused for a few reasons. 1) We talked to some major US banks when disabling autocomplete=off for passwords, and though they historically have been a big proponent of the feature they didn't seem bothered that it was no longer going to be respected. It seems like sites are more accepting of password managers now. I wouldn't be surprised if a reasonable percentage of autocomplete=off usage is just inertia at this point. 2) A well-intentioned site might use autocomplete=off thinking that it's a security benefit to their site. Doing this with this new API would be obvious abuse and it doesn't seem likely that a site would do it unless they were looking for some way to block password managers. 3) If a site really wants to go out of their way to make sure that password managers don't work on their site, there are already ways of doing it. This would be an easier mechanism, but I'm not sure how much that matters. If we still think that this is too likely to be abused, another possibility might be to only allow the site to assert login succeeded not that it failed. Not sure how useful that is though, since it's generally easier to prompt on incorrect login than miss a correct login. > > I actually have a similar problem with purely JS-handled forms even > > unrelated to credentials. Because the form is never really submitted > > (even if we reuse the submit infrastructure, we cancel the 'submit' > > event and handle the work on the JS side), there's never an indication > > to the UA that it should save the fields, and so autofill never works > > right on these forms, even for things like postal addresses or e-mail > > addresses. > > > > For the pure JS case, an API (probably on the <form> itself) would > > make sense and seems relatively easy. I've filed a bug on this: > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 > > This case is pretty weird. Authors are going out of their way to avoid > using the built in platform features that would get them autofill saving > for free. In some cases, they might be doing this precisely because they > want to prevent autofill but can't count on autocomplete=off anymore. > > In most of the cases that I've seen where this comes up (e.g. Pandora) it seems like the entire site does navigation via AJAX + history.pushState(). It doesn't seem like the site is trying to avoid password managers so much as they are trying to keep the aesthetic of their site consistent. > > The requestAutocomplete() API is a Chrome proprietary feature right > > now so it's sort of acadmic, but: > > > > Why would this only apply to requestAutocomplete()? Surely it would be > > just as important for the case where the user agent is filling in a > > form without using that API. > > Agreed. I don't see the benefit of requestAutocomplete() here. > > > Ted > From atwilson at google.com Wed Apr 23 07:09:45 2014 From: atwilson at google.com (Andrew Wilson) Date: Wed, 23 Apr 2014 16:09:45 +0200 Subject: [whatwg] [notifications][editorial] tweaking the "Activating a notification" window.focus() note In-Reply-To: <CABirCh_pbd4oLxz_cS6d5GqNFq8qV58bsP01HS9nHcorihk=5g@mail.gmail.com> References: <m261m898gj.fsf@eoconnor.apple.com> <CABirCh_pbd4oLxz_cS6d5GqNFq8qV58bsP01HS9nHcorihk=5g@mail.gmail.com> Message-ID: <CAArhhit+4rDCowR4rnxwYt7u4grHCwGKXC3W7p7U0HYW1AQ=YQ@mail.gmail.com> The problem here is that the platform's notification design has no way to understand what the application wants to happen when the user clicks on a notification. As a great example - Gmail uses desktop notifications to notify the user about chat events and new emails. When the user clicks on a chat notification, gmail uses window.focus() to focus itself so the user can view the chat (which is displayed in the main gmail window via a <div> overlay). When the user clicks on an email notification, we don't want to bring up that email in the main gmail window because the user may be in the middle of some other operation (like composing an email) - in fact, we don't want to focus the gmail tab at all. Instead we pop up that email in a separate popup window. In that case, having the UA auto-focus the tab is a mistake. I'm OK if you somehow want to make auto-focus a default property of the notification and have the app determine a-priori whether a given notification should trigger auto-focus at the time the notification is created, but it seems less flexible than the current behavior that Chrome has, which is that notifications don't auto-focus, and that applications have full control over what they want to happen when a click occurs. I suppose you can make the argument that auto-focus is so overwhelmingly common that we should just make it the default as a developer convenience - do you have any data to back up this assertion? In any case, I'm OK with the status quo, which is that UAs either auto-focus (if they want to force consistent click-on-notification functionality regardless of app intent) or they should support window.focus(). Actively prohibiting window.focus() seems like a bad step. -atw On Thu, Apr 17, 2014 at 1:45 AM, Glenn Maynard <glenn at zewt.org> wrote: > On Wed, Apr 16, 2014 at 6:10 PM, Edward O'Connor <eoconnor at apple.com> > wrote: > > > Hi, > > > > In ?4.6 Activating a notification, there's a note that currently reads > > > > "User agents are strongly encouraged to make window.focus() work > > from within the event listener for the event named click as a means > > of focusing the browsing context related to the notification." > > > > This note assumes that the UA doesn't automatically focus the browsing > > context when a notification is activated. (Safari on OS X is one example > > of a UA which does this.) The note should be adjusted so that readers > > understand that calling window.focus() may not be necessary on some > > combinations of UA and system notification service. > > > > Rather, pages should never be allowed to window.focus() when a notification > is activated. If the platform's notification design wants that to happen, > it's the platform's job to do that, and pages shouldn't all be required to > call window.focus() to make this happen consistently. (If for some reason > the platform doesn't want that to happen, the page shouldn't be able to > override that, either.) > > If there are notifications that don't want to focus a page when activated, > that should be a setting on the notification. > > -- > Glenn Maynard > From bnicholson at mozilla.com Wed Apr 23 17:02:43 2014 From: bnicholson at mozilla.com (Brian Nicholson) Date: Wed, 23 Apr 2014 17:02:43 -0700 Subject: [whatwg] Additional details for invoking requestAutocomplete Message-ID: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> This optional argument sounds reasonable to me (FWIW, I'm working on the requestAutocomplete implementation for Firefox). The transaction fields also seem sensible, but I have no experience with payment APIs, so I can't give feedback on how well this will work with payment providers in general (and whether any additional fields might be useful). Those working on Mozilla's payment APIs are aware of this thread, so hopefully they'll be giving feedback if they have anything to add. When I first read this proposal, I was under the impression that the browser would somehow detect whether transactions would put users over their card limits, but maybe you're going for something simpler than that. Could you elaborate on how Chromium will handle these transactions differently? - Brian On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade <est... at chromium.org> wrote: > Hi WhatWG. > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=?cc-number? the browser might provide an experience tailored > for a payment flow, or if there?s an element with autocomplete=?bday? the > browser might use an experience that?s tailored for sharing identiy. > > We?ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element. requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: ?transactionAmount? > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: ?transactionCurrency? > value: string > description: a valid ISO 4217 currency code that describes the > currency for transactionAmount. If not provided, the default is ?USD?. > > Justification? There are upper bounds on certain payment instruments, for > example different credit cards have different credit limits; a debit card > is linked to a bank account with a certain balance. It?s a much preferable > user experience to be able to catch these problems earlier rather than > waiting for the merchant to attempt the transaction and have it fail (or > have a user?s account overdrawn). Concretely, Chromium wants to handle > transactions over $2000 differently from transactions under that amount. > > Does this seem reasonable? > > > -- Evan Stade > From estade at chromium.org Wed Apr 23 21:13:28 2014 From: estade at chromium.org (Evan Stade) Date: Wed, 23 Apr 2014 21:13:28 -0700 Subject: [whatwg] Additional details for invoking requestAutocomplete In-Reply-To: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> References: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> Message-ID: <CAO4XGS_rXaHxtU1oKypMixwU+iDKocPgvbBuFiV15OYWv6bTnQ@mail.gmail.com> Specifically, Chromium would disable Wallet for transactions over a certain limit (at the moment, that's $2k, but this business logic is subject to change). When Wallet is disabled, users can still store/access their data in Chrome/Chrome Sync. -- Evan Stade On Wed, Apr 23, 2014 at 5:02 PM, Brian Nicholson <bnicholson at mozilla.com>wrote: > This optional argument sounds reasonable to me (FWIW, I'm working on > the requestAutocomplete implementation for Firefox). The transaction > fields also seem sensible, but I have no experience with payment APIs, > so I can't give feedback on how well this will work with payment > providers in general (and whether any additional fields might be > useful). Those working on Mozilla's payment APIs are aware of this > thread, so hopefully they'll be giving feedback if they have anything > to add. > > When I first read this proposal, I was under the impression that the > browser would somehow detect whether transactions would put users over > their card limits, but maybe you're going for something simpler than > that. Could you elaborate on how Chromium will handle these > transactions differently? > > - Brian > > > On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade <est... at chromium.org> wrote: > > > Hi WhatWG. > > > > Currently, requestAutocomplete lets a user agent provide the same user > > experience across multiple sites for common data input flows. A site > > describes the data it desires (via a form and autocomplete attributes), > and > > the user agent uses this information and what it knows about the user to > > expedite data input. For example, if one of the form elements has > > autocomplete=?cc-number? the browser might provide an experience tailored > > for a payment flow, or if there?s an element with autocomplete=?bday? the > > browser might use an experience that?s tailored for sharing identiy. > > > > We?ve found that there are some details of the interaction which might > > affect the UX which cannot be inferred from the data inputs. We propose > to > > add an optional argument to the requestAutocomplete method. Thus > invocation > > would look like: > > > > form_element. > requestAutocomplete(details); > > > > This |details| argument would be an object where key-value pairs provide > > additional details regarding the request. The spec should define a set of > > keys and associated data types which are recognized. There are currently > > two key-value pairs we would like to add: > > > > key: ?transactionAmount? > > value: number > > description: For data that is going to be applied towards a > > transaction, the /maximum/ value of the transaction. The browser does not > > guarantee that the returned payment instrument will work, but keeping the > > transaction under this amount will increase the likelihood of receiving a > > valid card number. > > > > key: ?transactionCurrency? > > value: string > > description: a valid ISO 4217 currency code that describes the > > currency for transactionAmount. If not provided, the default is ?USD?. > > > > Justification? There are upper bounds on certain payment instruments, for > > example different credit cards have different credit limits; a debit card > > is linked to a bank account with a certain balance. It?s a much > preferable > > user experience to be able to catch these problems earlier rather than > > waiting for the merchant to attempt the transaction and have it fail (or > > have a user?s account overdrawn). Concretely, Chromium wants to handle > > transactions over $2000 differently from transactions under that amount. > > > > Does this seem reasonable? > > > > > > -- Evan Stade > > > From estade at chromium.org Thu Apr 24 09:37:45 2014 From: estade at chromium.org (Evan Stade) Date: Thu, 24 Apr 2014 09:37:45 -0700 Subject: [whatwg] Additional details for invoking requestAutocomplete In-Reply-To: <CAO4XGS_rXaHxtU1oKypMixwU+iDKocPgvbBuFiV15OYWv6bTnQ@mail.gmail.com> References: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> <CAO4XGS_rXaHxtU1oKypMixwU+iDKocPgvbBuFiV15OYWv6bTnQ@mail.gmail.com> Message-ID: <CAO4XGS9rBiX-Bz8SLa=cfbMbf7UFC1Qyv-VV9=WgiyiS8SgEyA@mail.gmail.com> Also, in response to something Ian wrote on another thread: > Why would this only apply to requestAutocomplete()? Surely it would be > just as important for the case where the user agent is filling in a form > without using that API. That is true, but I don't know of a better way to convey this information from the page to browser. Additional attributes on the cc-number field? > Also, I don't understand how these are supposed to work. How is the > browser supposed to know the balance on my credit cards or bank accounts? > How is the browser supposed to know which of my cards are good for USD and > which are good for GBP? If the browser is just a dumb number memorizer, it probably won't, in which case it may return a card that denies the transaction. The new API doesn't /guarantee/ the returned card will work, it just increases the likelihood of a successful transaction. Conceptually, how the browser /could/ know the balance on the credit cards is if it pings some remote server to obtain this information, or if it remembers each card's credit limit (ignoring how much of the limit may have already been used), etc. -- Evan Stade On Wed, Apr 23, 2014 at 9:13 PM, Evan Stade <estade at chromium.org> wrote: > Specifically, Chromium would disable Wallet for transactions over a > certain limit (at the moment, that's $2k, but this business logic is > subject to change). When Wallet is disabled, users can still store/access > their data in Chrome/Chrome Sync. > > > -- Evan Stade > > > On Wed, Apr 23, 2014 at 5:02 PM, Brian Nicholson <bnicholson at mozilla.com>wrote: > >> This optional argument sounds reasonable to me (FWIW, I'm working on >> the requestAutocomplete implementation for Firefox). The transaction >> fields also seem sensible, but I have no experience with payment APIs, >> so I can't give feedback on how well this will work with payment >> providers in general (and whether any additional fields might be >> useful). Those working on Mozilla's payment APIs are aware of this >> thread, so hopefully they'll be giving feedback if they have anything >> to add. >> >> When I first read this proposal, I was under the impression that the >> browser would somehow detect whether transactions would put users over >> their card limits, but maybe you're going for something simpler than >> that. Could you elaborate on how Chromium will handle these >> transactions differently? >> >> - Brian >> >> >> On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade <est... at chromium.org> wrote: >> >> > Hi WhatWG. >> > >> > Currently, requestAutocomplete lets a user agent provide the same user >> > experience across multiple sites for common data input flows. A site >> > describes the data it desires (via a form and autocomplete attributes), >> and >> > the user agent uses this information and what it knows about the user to >> > expedite data input. For example, if one of the form elements has >> > autocomplete=?cc-number? the browser might provide an experience >> tailored >> > for a payment flow, or if there?s an element with autocomplete=?bday? >> the >> > browser might use an experience that?s tailored for sharing identiy. >> > >> > We?ve found that there are some details of the interaction which might >> > affect the UX which cannot be inferred from the data inputs. We propose >> to >> > add an optional argument to the requestAutocomplete method. Thus >> invocation >> > would look like: >> > >> > form_element. >> requestAutocomplete(details); >> > >> > This |details| argument would be an object where key-value pairs provide >> > additional details regarding the request. The spec should define a set >> of >> > keys and associated data types which are recognized. There are currently >> > two key-value pairs we would like to add: >> > >> > key: ?transactionAmount? >> > value: number >> > description: For data that is going to be applied towards a >> > transaction, the /maximum/ value of the transaction. The browser does >> not >> > guarantee that the returned payment instrument will work, but keeping >> the >> > transaction under this amount will increase the likelihood of receiving >> a >> > valid card number. >> > >> > key: ?transactionCurrency? >> > value: string >> > description: a valid ISO 4217 currency code that describes the >> > currency for transactionAmount. If not provided, the default is ?USD?. >> > >> > Justification? There are upper bounds on certain payment instruments, >> for >> > example different credit cards have different credit limits; a debit >> card >> > is linked to a bank account with a certain balance. It?s a much >> preferable >> > user experience to be able to catch these problems earlier rather than >> > waiting for the merchant to attempt the transaction and have it fail (or >> > have a user?s account overdrawn). Concretely, Chromium wants to handle >> > transactions over $2000 differently from transactions under that amount. >> > >> > Does this seem reasonable? >> > >> > >> > -- Evan Stade >> > >> > > From dbeam at chromium.org Thu Apr 24 21:06:15 2014 From: dbeam at chromium.org (Dan Beam) Date: Thu, 24 Apr 2014 21:06:15 -0700 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise In-Reply-To: <1fb95b4500944205baf2857a6525bc51@BN1PR05MB325.namprd05.prod.outlook.com> References: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> <CANpe7K25BCCFJuS89YQ9Od81ZhPDVdxUoyzP0uz=BTUpnzJqTw@mail.gmail.com> <1fb95b4500944205baf2857a6525bc51@BN1PR05MB325.namprd05.prod.outlook.com> Message-ID: <CANpe7K0bcyBs-yb3mg+C01f=8E+q_r6yNYkiyV=sXzqWYk6ehw@mail.gmail.com> On Wed, Apr 16, 2014 at 6:59 PM, Domenic Denicola < domenic at domenicdenicola.com> wrote: > > From: dbeam at google.com [mailto:dbeam at google.com] On Behalf Of Dan Beam > > > So just pass no argument at all (i.e. arguments.length == 0)? I was under the impression some type of value should always be returned (but I'm biased by blink/v8's current implementation). > > It's equivalent, both for promises and for return values of functions. Both `new Promise(resolve => resolve())` and `new Promise(resolve => resolve(undefined))` give a promise whose fulfillment value is `undefined`. In this sense `resolve` behaves like all non-evil JavaScript functions, where evil is defined as "checking `arguments.length`" ;) > I've seen only positive feedback on this thread, so I've started implementing in Blink. Regarding the rejection argument: requestAutocomplete() can fail in a way that doesn't map intuitively to the current DOMException names (e.g. the invoking <form> has autocomplete="off" or isn't in a frame). Adding new names for these specific failure categories doesn't seem useful to the platform. Additionally, many potential failure causes may have the same reason property[1] ("disabled" => SecurityError, WrongDocumentError?, InvalidAccessError?)** and the terminology differs slightly ("cancel" => AbortError). This seems confusing to web authors, so I propose a new type instead (in IDL): interface AutocompleteError : DOMException { readonly attribute DOMString reason; // matches AutocompleteErrorEvent's reason[1] }; This new type would have a code of 0 (as other new exceptions have; code is deprecated). I've filed a bug to add this to the DOMException name table[2]. -- Dan Beam dbeam at chomium.org [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#the-autocompleteerrorevent-interface [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25457 ** names with "?" are the closest existing error names I could find (but aren?t great) From bzbarsky at MIT.EDU Thu Apr 24 21:17:10 2014 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Fri, 25 Apr 2014 00:17:10 -0400 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise In-Reply-To: <CANpe7K0bcyBs-yb3mg+C01f=8E+q_r6yNYkiyV=sXzqWYk6ehw@mail.gmail.com> References: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> <CANpe7K25BCCFJuS89YQ9Od81ZhPDVdxUoyzP0uz=BTUpnzJqTw@mail.gmail.com> <1fb95b4500944205baf2857a6525bc51@BN1PR05MB325.namprd05.prod.outlook.com> <CANpe7K0bcyBs-yb3mg+C01f=8E+q_r6yNYkiyV=sXzqWYk6ehw@mail.gmail.com> Message-ID: <5359E1C6.1020103@mit.edu> On 4/25/14, 12:06 AM, Dan Beam wrote: > interface AutocompleteError : DOMException { DOMException isn't an interface as currently proposed. In general, please check with public-script-coord before minting new exception types; there's been a lot of discussion on that issue recently. -Boris From ian at hixie.ch Fri Apr 25 16:54:53 2014 From: ian at hixie.ch (Ian Hickson) Date: Fri, 25 Apr 2014 23:54:53 +0000 (UTC) Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <CAO4XGS9rBiX-Bz8SLa=cfbMbf7UFC1Qyv-VV9=WgiyiS8SgEyA@mail.gmail.com> References: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> <CAO4XGS_rXaHxtU1oKypMixwU+iDKocPgvbBuFiV15OYWv6bTnQ@mail.gmail.com> <CAO4XGS9rBiX-Bz8SLa=cfbMbf7UFC1Qyv-VV9=WgiyiS8SgEyA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404251934580.7589@ps20323.dreamhostps.com> On Thu, 3 Apr 2014, Mike West wrote: > On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > Also, consider the case of login forms without username fields. You > > > see this sort of thing a lot these days, when sites remember who was > > > last logged in: > > > > > > <form> > > > <label>Password for hober: <input type=password name=pw></label> > > > <p>Not hober? <a href=...>Click here to sign in</a>. > > > </form> > > > > > > It's difficult for tools to manage the user's auth info for such > > > pages. How can tools discover what the username is? The obvious > > > solution, in a world with autocomplete=username, would be to add > > > <input type=hidden autocomplete=username name=username value=hober> > > > to the form. > > > > So far, autocomplete="" hasn't applied to <input type=hidden>. This > > would be a bit weird, giving it a different meaning than usual > > (providing information to the UA, rather than getting information from > > the UA). I'm a bit skeptical of this kind of overloading. > > > > Not sure what the right solution is, though. > > As Garrett noted, this is already a solution Google is using, though not > with explicit syntax, just taking advantage of existing heuristics. > Paving this (potential) cowpath isn't really that weird. > > That said, an alternative might be to add a mechanism of associating > autocompletion metadata with the field in order to give the UA enough > context to fill it in. For example, if a password is being requested for > a known username, that username could be added as an new > "autocomplete-username" attribute (similar to the 'data-*' construct > HTML already supports): > > <input type="password" autocomplete-username="hober"> On Fri, 11 Apr 2014, Edward O'Connor wrote: > > It is kind of weird. Given that, maybe this case should have new syntax. > I'm OK with overloading autocomplete=username or with new syntax. I'm not sure I really understand how autocomplete-* would work (e.g. would you have to specify it for all three fields of a change-password form?). Having autocomplete="" mean something slightly different on type=hidden does make some sense, even if it is overloading. It has the advantage of fitting into the current syntax machinery, too. I've made a proposal in this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25471 I would be particularly interested in feedback from vendors who haven't commented on this yet. Will this overloading work for you? On Fri, 11 Apr 2014, Edward O'Connor wrote: > > > > I actually have a similar problem with purely JS-handled forms even > > unrelated to credentials. Because the form is never really submitted > > (even if we reuse the submit infrastructure, we cancel the 'submit' > > event and handle the work on the JS side), there's never an indication > > to the UA that it should save the fields, and so autofill never works > > right on these forms, even for things like postal addresses or e-mail > > addresses. > > > > For the pure JS case, an API (probably on the <form> itself) would > > make sense and seems relatively easy. I've filed a bug on this: > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 > > This case is pretty weird. Authors are going out of their way to avoid > using the built in platform features that would get them autofill saving > for free. In some cases, they might be doing this precisely because they > want to prevent autofill but can't count on autocomplete=off anymore. I'm not sure what you mean here. The context is a form that is used in a purely scripted fashion. It's not at all obvious how to tell the user agent to save the data in this situation. I don't think authors are going out of their way to avoid using built-in platform features; what feature should they use here? On Fri, 11 Apr 2014, Edward O'Connor wrote: > > > > For the real submission case, I guess what we want is a way to say > > "autocomplete=off" after the fact, basically. An HTTP header seems > > like the most obvious solution. > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 > > > > Again, these need multiple vendors on board to make progress. > > Browsers are moving away from respecting autocomplete=off. I don't think > we should be adding a new but basically equivalent mechanism. On Mon, 21 Apr 2014, Garrett Casto wrote: > > While I agree that it's a concern, I'm not overly worried that this is > going to be abused for a few reasons. > > 1) We talked to some major US banks when disabling autocomplete=off for > passwords, and though they historically have been a big proponent of the > feature they didn't seem bothered that it was no longer going to be > respected. It seems like sites are more accepting of password managers > now. I wouldn't be surprised if a reasonable percentage of > autocomplete=off usage is just inertia at this point. > > 2) A well-intentioned site might use autocomplete=off thinking that it's > a security benefit to their site. Doing this with this new API would be > obvious abuse and it doesn't seem likely that a site would do it unless > they were looking for some way to block password managers. 3) If a site > really wants to go out of their way to make sure that password managers > don't work on their site, there are already ways of doing it. This would > be an easier mechanism, but I'm not sure how much that matters. > > If we still think that this is too likely to be abused, another > possibility might be to only allow the site to assert login succeeded > not that it failed. Not sure how useful that is though, since it's > generally easier to prompt on incorrect login than miss a correct login. I think the way to make progress on this issue would be for the vendors interested in deploying a solution to do so experimentally, and to see how authors use it. On Mon, 14 Apr 2014, Dan Beam wrote: > > I propose requestAutocomplete()[1] should return a Promise. This has > been requested since the creation of this API[2][3] and seems like a > natural fit. Web authors can then call requestAutocomplete() like this: > > form.requestAutocomplete().then(function() { > // form.submit() or some other success action > }, function(errorDetails) { > // handle error based on errorDetails.reason (e.g. "cancel") > }); > > The returned promise would be resolved after the corresponding > "autocomplete" or "autocompleteerror" event is dispatched on the form. > [...] Fine by me. How stable is the whole promise world so far? Are any APIs using it yet? I tried using it in HTML before, but the API changed radically shortly afterwards, so I'm a bit reluctant to start specifying stuff again on this topic before other specs have done so. On Thu, 24 Apr 2014, Dan Beam wrote: > > Regarding the rejection argument: requestAutocomplete() can fail in a > way that doesn't map intuitively to the current DOMException names (e.g. > the invoking <form> has autocomplete="off" or isn't in a frame). > Adding new names for these specific failure categories doesn't seem > useful to the platform. Additionally, many potential failure causes may > have the same reason property[1] ("disabled" => SecurityError, > WrongDocumentError?, InvalidAccessError?)** and the terminology differs > slightly ("cancel" => AbortError). > > This seems confusing to web authors, so I propose a new type instead (in > IDL): > > interface AutocompleteError : DOMException { > readonly attribute DOMString reason; // matches AutocompleteErrorEvent's reason > }; On Fri, 25 Apr 2014, Boris Zbarsky wrote: > > In general, please check with public-script-coord before minting new > exception types; there's been a lot of discussion on that issue > recently. Please report back on the conclusion of this discussion on this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25472 Thanks! On Wed, 23 Apr 2014, Brian Nicholson wrote: > On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: > > > > Currently, requestAutocomplete lets a user agent provide the same user > > experience across multiple sites for common data input flows. A site > > describes the data it desires (via a form and autocomplete > > attributes), and the user agent uses this information and what it > > knows about the user to expedite data input. For example, if one of > > the form elements has autocomplete=?cc-number? the browser might > > provide an experience tailored for a payment flow, or if there?s an > > element with autocomplete=?bday? the browser might use an experience > > that?s tailored for sharing identiy. > > > > We?ve found that there are some details of the interaction which might > > affect the UX which cannot be inferred from the data inputs. We > > propose to add an optional argument to the requestAutocomplete method. > > Thus invocation would look like: > > > > form_element.requestAutocomplete(details); > > > > This |details| argument would be an object where key-value pairs > > provide additional details regarding the request. The spec should > > define a set of keys and associated data types which are recognized. > > There are currently two key-value pairs we would like to add: > > > > key: ?transactionAmount? > > value: number > > description: For data that is going to be applied towards a > > transaction, the /maximum/ value of the transaction. The browser does > > not guarantee that the returned payment instrument will work, but > > keeping the transaction under this amount will increase the likelihood > > of receiving a valid card number. > > > > key: ?transactionCurrency? > > value: string > > description: a valid ISO 4217 currency code that describes the > > currency for transactionAmount. If not provided, the default is ?USD?. > > > > Justification? There are upper bounds on certain payment instruments, > > for example different credit cards have different credit limits; a > > debit card is linked to a bank account with a certain balance. It?s a > > much preferable user experience to be able to catch these problems > > earlier rather than waiting for the merchant to attempt the > > transaction and have it fail (or have a user?s account overdrawn). > > Concretely, Chromium wants to handle transactions over $2000 > > differently from transactions under that amount. > > This optional argument sounds reasonable to me (FWIW, I'm working on the > requestAutocomplete implementation for Firefox). The transaction fields > also seem sensible, but I have no experience with payment APIs, so I > can't give feedback on how well this will work with payment providers in > general (and whether any additional fields might be useful). Those > working on Mozilla's payment APIs are aware of this thread, so hopefully > they'll be giving feedback if they have anything to add. On Thu, 24 Apr 2014, Evan Stade wrote: > Ian wrote: > > Why would this only apply to requestAutocomplete()? Surely it would be > > just as important for the case where the user agent is filling in a > > form without using that API. > > That is true, but I don't know of a better way to convey this > information from the page to browser. Additional attributes on the > cc-number field? Well, if we're going to use type=hidden fields to expose the username, we could also use it to expose the amount and currency. Would that work? On Thu, 3 Apr 2014, Andy Mabbett wrote: > > Why would you define any address components other than those in vCard, a > standard with massive implementation and interoperable with most address > book applications and services? Because vCard doesn't work in China. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From estade at chromium.org Mon Apr 28 11:42:53 2014 From: estade at chromium.org (Evan Stade) Date: Mon, 28 Apr 2014 11:42:53 -0700 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404251934580.7589@ps20323.dreamhostps.com> References: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> <CAO4XGS_rXaHxtU1oKypMixwU+iDKocPgvbBuFiV15OYWv6bTnQ@mail.gmail.com> <CAO4XGS9rBiX-Bz8SLa=cfbMbf7UFC1Qyv-VV9=WgiyiS8SgEyA@mail.gmail.com> <alpine.DEB.2.00.1404251934580.7589@ps20323.dreamhostps.com> Message-ID: <CAO4XGS_RNkMpkobGsXLvTd=AjxTWL5F=gJnxgXQPnZ_z8WbkMw@mail.gmail.com> On Fri, Apr 25, 2014 at 4:54 PM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 3 Apr 2014, Mike West wrote: > > On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > > > Also, consider the case of login forms without username fields. You > > > > see this sort of thing a lot these days, when sites remember who was > > > > last logged in: > > > > > > > > <form> > > > > <label>Password for hober: <input type=password name=pw></label> > > > > <p>Not hober? <a href=...>Click here to sign in</a>. > > > > </form> > > > > > > > > It's difficult for tools to manage the user's auth info for such > > > > pages. How can tools discover what the username is? The obvious > > > > solution, in a world with autocomplete=username, would be to add > > > > <input type=hidden autocomplete=username name=username value=hober> > > > > to the form. > > > > > > So far, autocomplete="" hasn't applied to <input type=hidden>. This > > > would be a bit weird, giving it a different meaning than usual > > > (providing information to the UA, rather than getting information from > > > the UA). I'm a bit skeptical of this kind of overloading. > > > > > > Not sure what the right solution is, though. > > > > As Garrett noted, this is already a solution Google is using, though not > > with explicit syntax, just taking advantage of existing heuristics. > > Paving this (potential) cowpath isn't really that weird. > > > > That said, an alternative might be to add a mechanism of associating > > autocompletion metadata with the field in order to give the UA enough > > context to fill it in. For example, if a password is being requested for > > a known username, that username could be added as an new > > "autocomplete-username" attribute (similar to the 'data-*' construct > > HTML already supports): > > > > <input type="password" autocomplete-username="hober"> > > On Fri, 11 Apr 2014, Edward O'Connor wrote: > > > > It is kind of weird. Given that, maybe this case should have new syntax. > > I'm OK with overloading autocomplete=username or with new syntax. > > I'm not sure I really understand how autocomplete-* would work (e.g. would > you have to specify it for all three fields of a change-password form?). > > Having autocomplete="" mean something slightly different on type=hidden > does make some sense, even if it is overloading. It has the advantage of > fitting into the current syntax machinery, too. > > I've made a proposal in this bug: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25471 > > I would be particularly interested in feedback from vendors who haven't > commented on this yet. Will this overloading work for you? > > > On Fri, 11 Apr 2014, Edward O'Connor wrote: > > > > > > I actually have a similar problem with purely JS-handled forms even > > > unrelated to credentials. Because the form is never really submitted > > > (even if we reuse the submit infrastructure, we cancel the 'submit' > > > event and handle the work on the JS side), there's never an indication > > > to the UA that it should save the fields, and so autofill never works > > > right on these forms, even for things like postal addresses or e-mail > > > addresses. > > > > > > For the pure JS case, an API (probably on the <form> itself) would > > > make sense and seems relatively easy. I've filed a bug on this: > > > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 > > > > This case is pretty weird. Authors are going out of their way to avoid > > using the built in platform features that would get them autofill saving > > for free. In some cases, they might be doing this precisely because they > > want to prevent autofill but can't count on autocomplete=off anymore. > > I'm not sure what you mean here. The context is a form that is used in a > purely scripted fashion. It's not at all obvious how to tell the user > agent to save the data in this situation. I don't think authors are going > out of their way to avoid using built-in platform features; what feature > should they use here? > > > > On Fri, 11 Apr 2014, Edward O'Connor wrote: > > > > > > For the real submission case, I guess what we want is a way to say > > > "autocomplete=off" after the fact, basically. An HTTP header seems > > > like the most obvious solution. > > > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 > > > > > > Again, these need multiple vendors on board to make progress. > > > > Browsers are moving away from respecting autocomplete=off. I don't think > > we should be adding a new but basically equivalent mechanism. > > On Mon, 21 Apr 2014, Garrett Casto wrote: > > > > While I agree that it's a concern, I'm not overly worried that this is > > going to be abused for a few reasons. > > > > 1) We talked to some major US banks when disabling autocomplete=off for > > passwords, and though they historically have been a big proponent of the > > feature they didn't seem bothered that it was no longer going to be > > respected. It seems like sites are more accepting of password managers > > now. I wouldn't be surprised if a reasonable percentage of > > autocomplete=off usage is just inertia at this point. > > > > 2) A well-intentioned site might use autocomplete=off thinking that it's > > a security benefit to their site. Doing this with this new API would be > > obvious abuse and it doesn't seem likely that a site would do it unless > > they were looking for some way to block password managers. 3) If a site > > really wants to go out of their way to make sure that password managers > > don't work on their site, there are already ways of doing it. This would > > be an easier mechanism, but I'm not sure how much that matters. > > > > If we still think that this is too likely to be abused, another > > possibility might be to only allow the site to assert login succeeded > > not that it failed. Not sure how useful that is though, since it's > > generally easier to prompt on incorrect login than miss a correct login. > > I think the way to make progress on this issue would be for the vendors > interested in deploying a solution to do so experimentally, and to see how > authors use it. > > > On Mon, 14 Apr 2014, Dan Beam wrote: > > > > I propose requestAutocomplete()[1] should return a Promise. This has > > been requested since the creation of this API[2][3] and seems like a > > natural fit. Web authors can then call requestAutocomplete() like this: > > > > form.requestAutocomplete().then(function() { > > // form.submit() or some other success action > > }, function(errorDetails) { > > // handle error based on errorDetails.reason (e.g. "cancel") > > }); > > > > The returned promise would be resolved after the corresponding > > "autocomplete" or "autocompleteerror" event is dispatched on the form. > > [...] > > Fine by me. > > How stable is the whole promise world so far? Are any APIs using it yet? > > I tried using it in HTML before, but the API changed radically shortly > afterwards, so I'm a bit reluctant to start specifying stuff again on this > topic before other specs have done so. > > > On Thu, 24 Apr 2014, Dan Beam wrote: > > > > Regarding the rejection argument: requestAutocomplete() can fail in a > > way that doesn't map intuitively to the current DOMException names (e.g. > > the invoking <form> has autocomplete="off" or isn't in a frame). > > Adding new names for these specific failure categories doesn't seem > > useful to the platform. Additionally, many potential failure causes may > > have the same reason property[1] ("disabled" => SecurityError, > > WrongDocumentError?, InvalidAccessError?)** and the terminology differs > > slightly ("cancel" => AbortError). > > > > This seems confusing to web authors, so I propose a new type instead (in > > IDL): > > > > interface AutocompleteError : DOMException { > > readonly attribute DOMString reason; // matches > AutocompleteErrorEvent's reason > > }; > > On Fri, 25 Apr 2014, Boris Zbarsky wrote: > > > > In general, please check with public-script-coord before minting new > > exception types; there's been a lot of discussion on that issue > > recently. > > Please report back on the conclusion of this discussion on this bug: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25472 > > Thanks! > > > On Wed, 23 Apr 2014, Brian Nicholson wrote: > > On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: > > > > > > Currently, requestAutocomplete lets a user agent provide the same user > > > experience across multiple sites for common data input flows. A site > > > describes the data it desires (via a form and autocomplete > > > attributes), and the user agent uses this information and what it > > > knows about the user to expedite data input. For example, if one of > > > the form elements has autocomplete=?cc-number? the browser might > > > provide an experience tailored for a payment flow, or if there?s an > > > element with autocomplete=?bday? the browser might use an experience > > > that?s tailored for sharing identiy. > > > > > > We?ve found that there are some details of the interaction which might > > > affect the UX which cannot be inferred from the data inputs. We > > > propose to add an optional argument to the requestAutocomplete method. > > > Thus invocation would look like: > > > > > > form_element.requestAutocomplete(details); > > > > > > This |details| argument would be an object where key-value pairs > > > provide additional details regarding the request. The spec should > > > define a set of keys and associated data types which are recognized. > > > There are currently two key-value pairs we would like to add: > > > > > > key: ?transactionAmount? > > > value: number > > > description: For data that is going to be applied towards a > > > transaction, the /maximum/ value of the transaction. The browser does > > > not guarantee that the returned payment instrument will work, but > > > keeping the transaction under this amount will increase the likelihood > > > of receiving a valid card number. > > > > > > key: ?transactionCurrency? > > > value: string > > > description: a valid ISO 4217 currency code that describes the > > > currency for transactionAmount. If not provided, the default is ?USD?. > > > > > > Justification? There are upper bounds on certain payment instruments, > > > for example different credit cards have different credit limits; a > > > debit card is linked to a bank account with a certain balance. It?s a > > > much preferable user experience to be able to catch these problems > > > earlier rather than waiting for the merchant to attempt the > > > transaction and have it fail (or have a user?s account overdrawn). > > > Concretely, Chromium wants to handle transactions over $2000 > > > differently from transactions under that amount. > > > > This optional argument sounds reasonable to me (FWIW, I'm working on the > > requestAutocomplete implementation for Firefox). The transaction fields > > also seem sensible, but I have no experience with payment APIs, so I > > can't give feedback on how well this will work with payment providers in > > general (and whether any additional fields might be useful). Those > > working on Mozilla's payment APIs are aware of this thread, so hopefully > > they'll be giving feedback if they have anything to add. > > On Thu, 24 Apr 2014, Evan Stade wrote: > > Ian wrote: > > > Why would this only apply to requestAutocomplete()? Surely it would be > > > just as important for the case where the user agent is filling in a > > > form without using that API. > > > > That is true, but I don't know of a better way to convey this > > information from the page to browser. Additional attributes on the > > cc-number field? > > Well, if we're going to use type=hidden fields to expose the username, we > could also use it to expose the amount and currency. Would that work? > I agree with those upthread who said that overloading autocomplete= to provide information to the user agent is confusing. If we introduce something like autocomplete="transaction-currency" then it's easy to misinterpret that as the site asking the browser what the currency is for the payment method, then having a site author use transaction-currency in a non type=hidden input. So I would prefer a separate attribute called autocomplete-hint="" or something, which has its own set of tags. (also added this comment to the bug) > > > On Thu, 3 Apr 2014, Andy Mabbett wrote: > > > > Why would you define any address components other than those in vCard, a > > standard with massive implementation and interoperable with most address > > book applications and services? > > Because vCard doesn't work in China. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From beverloo at google.com Tue Apr 29 10:24:42 2014 From: beverloo at google.com (Peter Beverloo) Date: Tue, 29 Apr 2014 18:24:42 +0100 Subject: [whatwg] [Notifications] Notification.hasPermission() instead of Notification.permission Message-ID: <CALt3x6=kNZwZPT7a6aGHnRXHkOQT4mCi_Z=NCkXCGUJHj1_F3A@mail.gmail.com> The Notification specification defines a static Notification.permission accessor, which returns one of {granted, denied, default}. This requires the browser to synchronously determine whether the page has permission to show notifications, whereas checking this may be an asynchronous operation. This is the case in Chrome. Before this becomes a paradigm, could we consider having a static hasPermission() instead, returning a Promise? I'll add a UseCounter to Blink for tracking Notification.permission usage, but it will take some time before conclusive usage data comes in. Thanks, Peter From ian at hixie.ch Tue Apr 29 10:55:13 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 29 Apr 2014 17:55:13 +0000 (UTC) Subject: [whatwg] HTML spec incorrectly suggests that <br> can have its rendering changed with CSS In-Reply-To: <CAAWBYDBxpkUYRiaa-z9YVHUTtbkdpYLuT3zoS4nMHRH+P0forA@mail.gmail.com> References: <52E03D6C.6090406@mozilla.com> <CAAWBYDBxpkUYRiaa-z9YVHUTtbkdpYLuT3zoS4nMHRH+P0forA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404291649590.7589@ps20323.dreamhostps.com> This discussion focused around the various behaviours that browsers have around the rendering of <br>. On Thu, 23 Jan 2014, Boris Zbarsky wrote: > > What Gecko does with <br> is basically to treat it like a special box > type that has special sizing/painting/linebreak behavior. But we do > still allow that box to be positioned/floated, just like an <img>... On Tue, 28 Jan 2014, Elliott Sprehn wrote: > > Blink treats <br> (conceptually) like a subclass of Text, there's > nothing to style because it's just a run of text with a forced break. On Wed, 29 Jan 2014, Tab Atkins Jr. wrote: > > We talked this over in the CSSWG meeting, and came up with a proposal > for non-magical styling that is still very close to current behavior in > all browsers: > > br { > display-box: contents; > content: "\A"; > white-space: pre; > } I've filed a bug to track this. It would be useful if browser vendors could indicate whether they think Tab's proposal is satisfactory (in particular, is 'display-box' something that browsers will implement? Apparently Gecko is doing it, anyone else?). https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bruant.d at gmail.com Tue Apr 29 14:32:39 2014 From: bruant.d at gmail.com (David Bruant) Date: Tue, 29 Apr 2014 23:32:39 +0200 Subject: [whatwg] hidden attribute useless with display: flex? Message-ID: <53601A77.9050102@gmail.com> Hi, // CSS: div{ display: flex; } // HTML: <div hidden></div> Per spec, the div should be shown right? I imagine there is no way back on that? Does it mean hidden only works when the default (UA stylesheet) display value is kept? Does it mean hidden is completely useless when trying to combine it with display:flex? What I'm trying to do is just that an element have display:flex and to hide it with the hidden attribute when I don't need the element to be shown. I guess my only option is changing style.display? Thanks, David From ian at hixie.ch Tue Apr 29 15:27:59 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 29 Apr 2014 22:27:59 +0000 (UTC) Subject: [whatwg] <canvas> feedback In-Reply-To: <69477B5B-A7A4-4674-B267-09EC2499C1F0@adobe.com> References: <69477B5B-A7A4-4674-B267-09EC2499C1F0@adobe.com> Message-ID: <alpine.DEB.2.00.1404291905070.7589@ps20323.dreamhostps.com> On Tue, 8 Apr 2014, Rik Cabanier wrote: > On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > > > > > > > So this is not how most implementations currently have it > > > > > > defined. > > > > > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > > > definitely do store the path in user coordinates. The spec > > > > > currently says otherwise [1] though. > > > > > > > > I'm not sure what you're referring to here. > > > > > > All graphics backends for canvas that I can inspect, don't apply the > > > CTM to the current path when you call a painting operator. Instead, > > > the path is passed as segments in the current CTM and the graphics > > > library will apply the transform to the segments. > > > > Right. That's what the spec says too, for the current default path. > > No, the spec says this: > > For CanvasRenderingContext2D objects, the points passed to the methods, > and the resulting lines added to current default path by these methods, > must be transformed according to the current transformation matrix > before being added to the path. As far as I can tell, these are block-box indistinguishable statements. Can you show a test case that demonstrates how the spec doesn't match browsers? > > > [use case: two paths mapping to the same region] > > > > Just use two different IDs with two different addHitRegion() calls. > > That's a lot less complicated than having a whole new API. > > That doesn't work if you want to have the same control for the 2 areas, > from the spec for addHitRegion: > ># If there is a previous region with this control, remove it from the ># scratch bitmap's hit region list; then, if it had a parent region, ># decrement that hit region's child count by one. Interesting. You mean like a case where you had a button that got split into multiple segments animated separately that then joined together, but where you want to be able to click on any part of that split-up button? Hmm. There's several ways we could support that. The simple way would be to allow multiple regions to refer to a control. The more subtle way would be to allow the control logic to defer to the parent region, but that's probably a bad idea (where would you put the parent region?). So I guess the question is: is it more useful to be able to refer to the same control from multiple regions, or is it more useful for the previous region to be automatically discarded when you add a new one? It's probably more useful to have multiple regions. You can always do the discarding using IDs. > Even if you don't use the control, it would be strange to have 2 > separate hit regions for something that represents 1 object. Why? I think that makes a lot of sense. There are multiple regions, why not have multiple hit regions? This becomes especially true when the multiple regions might be differently overlapped by other regions, or where different parts of the canvas are renderings from different angles of the same underlying scene. It would be silly for things to be easier to do with two canvases than one, in that kind of case, no? I've changed the spec to not discard regions based on the control. > > > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > > > > > > > > > > Instead of using getCurrentPath and setCurrentPath methods as a > > > > > solution, this could perhaps be solved by returning the internal > > > > > path instead of a copy, but with a flag that would prevent > > > > > further alterations on it. > > > > > > > > > > The setter of the currentPath accessor / data member could then > > > > > make the copy instead when a new path is to be set. > > > > > > > > > > This would also make sense from a a caching point of view, where > > > > > storing the currentPath for caching might not actually mean that > > > > > it will be used again in the future (e.g. because the path's > > > > > geometry changes completely on each frame of an animation), so > > > > > copying only when setting would postpone the actual work of > > > > > having to make the copy, and would help memory consummation and > > > > > performance. > > > > > > > > I don't really understand the use case here. > > > > > > Jurg was just talking about an optimization (so you don't have to > > > make an internal copy) > > > > Sure, but that doesn't answer the question of what the use case is. > > From my recent experiments with porting canvg ( > https://code.google.com/p/canvg/) to use Path2D, they have a routine > that continually plays a path into the context which is called from a > routine that does the fill, clip or stroke. Because that routine can't > simply set the current path, a lot more changes were needed. Sure, but the brief transitional cost of moving from canvas current default paths to Path2D objects is minor on the long run, and not worth the added complexity cost paid over the lifetime of the Web for the feature. So for something like this, we need a stronger use case than "it makes transitioning to Path2D slightly easier". > > On Wed, 12 Mar 2014, Rik Cabanier wrote: > > > > > > > > > > > > You can do unions and so forth with just paths, no need for > > > > > > regions. > > > > > > > > > > How would you do a union with paths? If you mean that you can > > > > > just aggregate the segments, sure but that doesn't seem very > > > > > useful. > > > > > > > > You say, here are some paths, here are some fill rules, here are > > > > some operations you should perform, now give me back a path that > > > > describes the result given a particular fill rule. > > > > > > I think you're collapsing a couple of different concepts here: > > > > > > path + fillrule -> shape > > > union of shapes -> shape > > > shape can be converted to a path > > > > I'm saying "shape" is an unnecessary primitive. You can do it all with > > paths. > > > > union of (path + fillrule)s -> path > > No, that makes no sense. What would you get when combining a path with a > fillrule and no fillrule? Why would you combine a path with a fillrule and no fillrule? I'm saying that you can replace "shape" with "path+fillrule", that's all. > > > > A shape is just a path with a fill rule, essentially. > > > > > > So, a path can now have a fillrule? Sorry, that makes no sense. > > > > I'm saying a shape is just the combination of a fill rule and a path. > > The path is just a path, the fill rule is just a fill rule. > > After applying a fillrule, there is no longer a path. You can *convert* > it back to a path that describes the outline of the shape if you want, > but that is something different. The way you've defined things now, you > can apply another fill rule on a path with a fill rule. What would the > result of that be? Exactly what you say -- you'd take the path, and apply the other fill rule to it. Applying fill rules to paths seems like a known operation. > > > > Anything you can do with one you can do with the other. > > > > > > You can't add segments from one shape to another as shapes represent > > > regions. Likewise, you can't union, intersect or xor path segments. > > > > But you can union, intersect, or xor lists of pairs of paths and > > fillrules. > > would you start throwing when doing these operations on paths without > fill rules? I'm not saying Path2D objects would get a built-in fill rule. I'm saying that you would pass Path2D objects and fill rules together. An analogy: You could have a "Length" object that represented a particular length, e.g. "4cm" or "12 lightyears". You could add these "Length" objects together, so "1 inch" plus "2cm" is "0.0454m" or some such. You could, instead, have numbers and units, e.g. "4" "cm" and "12" "lightyears". Then you could add pairs of numbers and units, as in "1" "inch" plus "2" "cm" is "0.0454" "m". Numbers are like paths, units are like fill rules. > > > > > > > The path object should represent the path in the graphics > > > > > > > state. You can't add a stroked path or text outline to the > > > > > > > graphics state and then fill/stroke it. > > > > > > > > > > > > Why not? > > > > > > > > > > As designed today, you could fill it, as long as you use > > > > > non-zero winding. If you use even-odd, the results will be very > > > > > wrong. (ie where joins and line segments meet, there will be > > > > > white regions) > > > > > > > > I think "wrong" here implies a value judgement that's unwarranted. > > > > > > "Wrong" meaning: if the author has a bunch of geometry and wants to > > > put it in 1 path object so he can just execute 1 fill operation, he > > > might be under the impression that "adding" the geometry will just > > > work. > > > > Well, sure, an author might be under any number of false impressions. > > > > The API has a way for a bunch of paths to be merged with a single > > fillrule to generate a new path with no crossing subpaths (which is > > also fillrule agnostic), essentially giving you the union of the > > shapes represented by those paths interpreted with that fillrule. > > Is this the API you're referring to? > > path = new Path2D(paths [, fillRule ] ) > > The first argument could point to paths that need different winding > rules. Sure, if you happen to make your paths with different winding rules, you might have that. In that case, merge all your paths that need one winding rule together, then merge all your paths that need the other winding rule together, then merge the two resulting paths together. If this is something that people do a lot (why would it be?) then we can provide a dedicated API for that. > > > There are very few use cases where you want to add partial path > > > segments together but I agree that there are some cases that it's > > > useful to have. > > > > I disagree that there few such cases. Pretty much any time you create > > a path, you are adding partial path segments together. Whether you do > > so using one Path object all at once or multiple Path objects that you > > later add together is just a matter of programming style. > > It's the multiple path objects use case that is unclear to me. Is there > any tool/library that does this? Right now, with canvas, any time you create a path with a transform in the middle of creating the path, you are doing the equivalent of using multiple Path2D objects then merging them. > With the new wording, the last sentence should be updated: > > Subpaths in the newly created path must wind clockwise, regardless of > the direction of paths in path. > > Since you now create 'holes', the separate paths need to be reoriented > like you specify in other parts. Good point, fixed. Thanks. > > addPath() is useful for shifting a path according to a transform. > > Why not just transform() then? I'm not sure what you're proposing here. Can you elaborate? > > addPathByStrokingPath() is for creating a stroked path. > > addText() is for writing text. > > > > I don't see how removing any of them is a win. > > Yes, they are useful. The issue is that they shouldn't be implemented as > currently specified. Instead of arguing for their removal, then, describe the use case that they do not handle. > > > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > > > > > > > > > > > > > > However, for your example, I'm unsure what the right > > > > > > > solution is. The canvas specification is silent on what the > > > > > > > behavior is for non-invertible matrices. > > > > > > > > > > > > What question do you think the spec doesn't answer? > > > > > > > > > > > > > I think setting scale(0,0) or another matrix operation that > > > > > > > is not reversible, should remove drawing operations from the > > > > > > > state because: - how would you stroke with such a matrix? > > > > > > > > > > > > You'd get a point. > > > > > > > > > > How would you get a point? the width is scaled to 0. > > > > > > > > That's how you get a point -- scale(0,0) essentially reverts > > > > everything to a zero dimensional point. > > > > > > OK, but the width of the point is also transformed to 0 so you get > > > nothing. > > > > Points are always zero-width, by definition. > > You can still stroke it though and get a point of the strokewidth. If you are scaling by 0, the strokeWidth essentially gets scaled to 0 also. > > > The APIs that you define, have use cases and I agree with them. > > > However the way you defined those APIs does not make sense and will > > > not give the result that authors want. > > > > The way to make this point would be to start from the use case, > > describe the desired effect, show the "obvious" way to achieve this > > using the API, and then demonstrate how it doesn't match the desired > > effect. > > The obvious way is to go with Shape2D. At no point in the steps I just described does giving a solution enter into the equation. > It's not because I invented it; many advanced graphics APIs came offer > this (including D2D and skia) I'm not arguing that Shape2D is a bad idea, nor that it is a good idea. I'm arguing that you haven't explained the use cases or shown why the current spec doesn't address the use cases. > > > The bad news is that this algorithm is very expensive and there are > > > few libraries that do a decent job (I only know of 1). So, it's not > > > realistic to add this to the Path2D object. > > > > I don't really see why it's unrealistic. In most cases, the user agent > > doesn't actually have to do any work -- e.g. if all that you're doing > > is merging two paths so that you can fill them simultaneously later, > > the UA can just keep the two paths as is and, when necessary, fill > > them. > > > > For cases where you really want to have this effect -- e.g. when you > > want to get the outline of the dashed outline of text -- then I don't > > really see any way to work around it. > > That is true. That is why I proposed to make the interface more limited > for now until there is a time that this functionality is available. Making the interface more limited fails to address the use cases that are currently addressed. > > > The reason for that is that even though a UA could emulate the union > > > by doing multiple fill operations, Path2D allows you to stroke > > > another path object. At that point, you really have to do > > > planarization. By defining a Shape2D object and not allowing it to > > > be stroked, we can work around this. > > > > Sure, by limiting the feature set dramatically we can avoid the cases > > where you have to do the hard work, but we also lose a bunch of > > features. > > For now. They can be added later. > Until then, this is confusing implementors. The only thing I see that is confusing implementors here is the forking of the canvas spec that you and W3C staff are doing at the W3C. If you are concerned about confusion, then stop doing that. Then, maybe, arguments about the WHATWG spec being confusing could have credibility. > > > > > No one has implemented them and they are confusing the browser > > > > > vendors. > > > > > > > > I don't think they're confusing anyone. > > > > > > The blink people were looking at adding this until they thought it > > > through and realized that it wouldn't work. > > > > Realised what wouldn't work? As far as I'm aware, there's nothing that > > wouldn't work. > > See this thread: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/168925.html I see nothing in that e-mail that shows anyone confused. Could you be more specific? On Tue, 8 Apr 2014, Justin Novosad wrote: > > > > > > For example, there is no locale for font family resolution > > > > I'm not clear on what you mean by "locale" here. What is the locale > > that a displayed <canvas> in a Document in a browsing context has, > > that a non-displayed <canvas> outside a Document and without a > > browsing context does not have? > > I am not sure exactly how this relates to the specification, but when > reading the code in Blink, I saw that font family resolution goes > through different paths if the view has a Korean, Chinese or Japanese > locale. Some OSes allow you to have different locales on a per window > basis, so you need to have a view (i.e. a browsing context) associated > with the Document in order to resolve this. Ah, I see. I don't think the HTML spec mentions this (I don't know what it would say exactly), but I would recommend using the script's script settings object's responsible browsing context or script's script setting object's responsible document or something similar. That way it's defined regardless of what the <canvas> element is. > > > and it is not possible to resolve font sizes in physical length > > > units unless the document is associated with a view. > > > > Why not? The canvas has a pixel density (currently always 1:1), no? > > 1:1 is not a physical pixel density. To resolve a font size that is > specified in physical units (e.g. millimeters or inches) you need > something like a DPI value, which requires information about the output > device. No, not any more. CSS "physical" units are defined as mapping to CSS pixels at 96 CSS pixels per CSS inch, and canvas is defined as mapping CSS pixels to canvas coordinate space units at one CSS pixel per coordinate space unit. As far as I know, all browsers do this now. > > > My 2 cents: specifying fallback behaviors for all use cases that are > > > context dependent could be tedious and I have yet to see a > > > real-world use case that requires being able to paint a canvas in a > > > frame-less document. Therefore, I think the spec should clearly > > > state <canvas> elements that are in a document without a browsing > > > context are unusable. Not sure what the exact behavior should be > > > though. Should an exception be thrown upon trying to use the > > > rendering context? Perhaps canvas draws should fail silently, and > > > using the canvas as an image source should give transparent black > > > pixels? > > > > As far as I can tell, this is all already specified, and it just gets > > treated like a normal canvas. > > Agreed. The fallback behavior is specified. But is it good enough? There > will be discrepancies, sometimes large ones, between text rendered with > and without a browsing context. I don't think there should be any discrepancies. > > Instead, we should use adaptive algorithms, for example always using > > the prettiest algorithms unless we find that frame rate is suffering, > > and then stepping down to faster algorithms. > > Such an adaptive algorithm implies making some kind of weighted decision > to chose a reasonable compromise between quality and performance. > Sounds like the perfect place to use a hint. If we really need a hint. But do we? Do we have data showing that adaptive algorithms can't do a good job without a hint? > One issue that comes to mind is what happens if stroke or fill are > called while the CTM is non-invertible? To be more precise, how would > the styles be mapped? If the fillStyle is collapsed to a point, does > that mean the path gets filled in transparent black? If we go down this > road, we will likely uncover more questions of this nature. The spec handles fills already as far as I can tell (e.g. "When the value is a color, it must not be affected by the transformation matrix when used to draw on bitmaps", "If a radial gradient or repeated pattern is used when the transformation matrix is singular, the resulting style must be transparent black", and so on). For strokes, you get nothing if the stroke is transformed to 0. On Tue, 8 Apr 2014, Rik Cabanier wrote: > > > > > > Just to be clear, we should support this because otherwise the > > > results are just wrong. For example, here some browsers currently > > > show a straight line in the default state, and this causes the > > > animation to look ugly in the transition from the first frame to the > > > secord frame (hover over the yellow to begin the transition): > > > > > > http://junkyard.damowmow.com/538 > > > > > > Contrast this to the equivalent code with the transforms explicitly > > > multiplied into the coordinates: > > > > > > http://junkyard.damowmow.com/539 > > > > > > I don't see why we would want these to be different. From the > > > author's perspective, they're identical. > > These examples are pretty far fetched. > > How many time do people change the CTM in the middle of a drawing > operation and not change the geometry? That kind of reasoning is not how we design a good platform. A good platform is consistent and predictable. It doesn't have surprises. Intuitively, a transform (as in 538) is equivalent to the same logic with the transform explicitly applied (as in 539). It is surprising if this is not the case. We should make sure our platform is a good platform when we can. It has enough crazy surprises that we can't prevent as it is. On Tue, 8 Apr 2014, Rik Cabanier wrote: > > The spec is still confusingly written and could be misinterpreted: > > Create a new path that describes the edge of the areas that would be > covered if a straight line of length equal to the styles lineWidth was > swept along each subpath in path while being kept at an angle such that > the line is orthogonal to the path being swept, replacing each point > with the end cap necessary to satisfy the styles lineCap attribute as > described previously and elaborated below, and replacing each join with > the join necessary to satisfy the styles lineJoin type, as defined > below. > > Maybe could become: > > Create a new path that describes the edge of the coverage of the following > areas: > - a straight line of length equal to the styles lineWidth that was swept > along each subpath in path while being kept at an angle such that the line > is orthogonal to the path being swept, > - the end cap necessary to satisfy the styles lineCap attribute as > described previously and elaborated below, > - the join with the join necessary to satisfy the styles lineJoin type, as > defined below. Can you elaborate on what the possible misinterpretation of the current paragraph is that is resolved by this change? On Thu, 3 Apr 2014, J?rg Lehni wrote: > > When both filling and stroking a path and then drawing it with with an > opacity of less than 100%, the path will be rendered differently than in > an SVG (a large stroke width will make the issue more apparent): > > - In Canvas, both the fill and the stroke will be rendered with the > given opacity, and the fill will shine through the inner half of the > stroke. > > - In SVG, the stroke will cover the fill, and the fill will not shine > through the inner half of the stroke, regardless of the opacity. > > If you'd like to emulate the SVG behavior in Canvas (which we happen to > do in Paper.js), then the only way to do so currently is to draw the > path's fill and stroke at 100% opacity into a separate canvas, and then > blit the whole thing over with the given opacity. > > This is *much* slower than directly drawing into the Canvas, and happens > to be one of the worst bottlenecks in Paper.js > > I would really appreciate a solution to this problem. Interesting. Would you still want the overlapping in the case of the stroke itself being semi-transparent, though? On Mon, 7 Apr 2014, Rik Cabanier wrote: > > Maybe this would better be solved by a function that does fill and > stroke at the same time, for instance: > > void fillAndStroke(optional CanvasFillRule fillRule = "nonzero"); > void fillAndStroke(Path2D path, optional CanvasFillRule fillRule = > "nonzero"); > > globalAlpha would then apply to the operation as a whole. This would also allow us to shift the fill so that it doesn't overlap with the stroke, so that in the case of a semi-transparent stroke, it doesn't overlap the fill. On Mon, 7 Apr 2014, J?rg Lehni wrote: > > Well this particular case, yes. But in the same way we allow a group of > items to have an opacity applied to in Paper.js, and expect it to behave > the same ways as in SVG: The group should appear as if its children were > first rendered at 100% alpha and then blitted over with the desired > transparency. > > Layers would offer exactly this flexibility, and having them around > would make a whole lot of sense, because currently the above can only be > achieved by drawing into a separate canvas and blitting the result over. > The performance of this is real low on all browsers, a true bottleneck > in our library currently. It's not clear to me why it would be faster if implemented as layers. Wouldn't the solution here be for browsers to make canvas-on-canvas drawing faster? I mean, fundamentally, they're the same feature. On Sat, 5 Apr 2014, Dirk Schulze wrote: > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2978 > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2979 > The behavior of normalizing is not specified. Especially it seems odd > that the behavior for fillRect()/strokeRect() should differ from rect(). > So we should either normalize for all functions or don?t do it for all > IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for > rect() is important for filling with different winding rules as well. It > is not just stroking with dash arrays that is effected. On Sat, 5 Apr 2014, Rik Cabanier wrote: > > yes, the spec needs to say "in that order" as it does for fillRect and > strokeRect. On Sat, 5 Apr 2014, Rik Cabanier wrote: > > It also seems that only firefox is following the spec [1] when width or > height are 0: http://jsfiddle.net/za945/2/ http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2981 > I'm unsure why such a rectangle is defined as a straight line. On Sun, 6 Apr 2014, Dirk Schulze wrote: > > You mean you would rather let it draw a one dimensional rectangle? So > for the dimension that is not zero, you would see two overlapping lines > + the 0 dimensional sides? > > That seems indeed to be the case for IE, Safari and Blink: > http://jsfiddle.net/Gh9XK/ On Mon, 7 Apr 2014, Justin Novosad wrote: > > Dashing is one thing that would be affected. I think some > implementations are currently in a non-compliant state probably because > the line dashing feature was added recently. Back when strokeRect was > originally implemented, we could get away with blindly normalizing > rectangles because there was no impact on the rendering result. The > other thing that is affected is fill rule application. For example, if > you have a path that contains two intersecting rectangles and you are > filling in with the nonzero rule. If one of the two rectangles is > flipped, then the intersection region should be unfilled. If the > rectangles are "normalized" internally by the implementation, then you > will get the wrong (non spec compliant) result. I've added "in that order" to rect(). I couldn't find the original reason for strokeRect() only drawing one line in the one-dimensional case, though it dates back to 2007 at least. I haven't changed rect() to do that too. On Sun, 6 Apr 2014, Dirk Schulze wrote: > > The spec says that the object TextMetrics[1] must return font and actual > text metrics. All things require information from the font or the font > system. In many cases either font or font system just do not provide > these information. Which cases? The information is needed for text layout purposes; if the browser can't get the information, how is it conforming to CSS? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 29 16:26:13 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 29 Apr 2014 23:26:13 +0000 (UTC) Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <534E997A.5090504@mit.edu> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <534E997A.5090504@mit.edu> Message-ID: <alpine.DEB.2.00.1404292247220.7589@ps20323.dreamhostps.com> On Wed, 16 Apr 2014, Boris Zbarsky wrote: > > Right now canvas drawImage ignores EXIF orientation metadata. > > Could we add a version that doesn't do that? Especially with CSS > growing things like the image-orientation property, it would be good to > support drawing the image in its correct orientation. On Wed, 16 Apr 2014, Justin Novosad wrote: > > But why a new version of drawImage? Couldn't we just modify the existing > drawImage definition to state that it takes into account the > image-orientation property on the source image? The default value for > image-orientation is 0deg, which corresponds to the current drawImage > behavior. So I think we can make that change to the drawImage spec > without breaking stuff, as long as we make the change while > image-orientation is still an experimental feature. On Wed, 16 Apr 2014, Anne van Kesteren wrote: > > Why is image-orientation in CSS for <img>? For background-image that > makes sense, but if you are actually affecting the semantics of the > image that is displayed, it seems like it should be in HTML or a hint in > the image format. On Wed, 16 Apr 2014, Justin Novosad wrote: > > Yes, that makes a lot of sense IMHO. I just posted feedback to www-style The feedback seemed positive: http://lists.w3.org/Archives/Public/www-style/2014Apr/thread.html#msg179 This proposal seems pretty reasonable. I'm tracking this in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 On Wed, 16 Apr 2014, Justin Novosad wrote: > > Another use case to think about is: XHR->Blob->ImageBitmap->Canvas(2D or > WebGL) With that data flow, there is no opportunity to use a CSS > property to tweak image orientation. > There is this idea though: http://wiki.whatwg.org/wiki/ImageBitmap_Options Tracking this in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25507 If other vendors want to do this, please comment on the bug (or here). Here is a summary of related bugs: Regarding EXIF: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23510 Allow EXIF data to be passed to toBlob() This is pending implementation interest from browsers outside Mozilla, and someone coming up with a way to map EXIF to JSON in a well-defined way. https://www.w3.org/Bugs/Public/show_bug.cgi?id=23511 Expose EXIF data of images in <img> elements This is pending implementation interest and would also benefit from a way to map EXIF to an API in a well-defined way. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25507 Have createImageBitmap() take options, e.g. to honour EXIF orientation This is pending implementation interest outside Chrome. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 Have an attribute that honours EXIF orientation This seems to have implementation interest from everyone, and I'll hopefully be adding it soon. Need a good name; if you have a suggestion, add it to the bug. Regarding drawImage(): https://www.w3.org/Bugs/Public/show_bug.cgi?id=17427 drawImage() should accept SVGImageElement (<svg:image>) This is blocked on the SVG spec being updated to define image loading in a suitable level of detail. It could also do with interest from browser vendors other than Mozilla. Regarding ImageBitmap: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21346 Have ImageBitmap expose height and width attributes This is pending implementation interest outside Chrome. Regarding <img>: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842 Feature to make <img> elements not load their images until needed This is something I plan to deal with at the same time as <script> preloading, <object> preloading, et al. Right now I'm waiting to see if public-web-perf (the W3C WG) is going to move on this topic. No ETA. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24711 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24958 Refactor the image loading model; When exactly should "update the image data" run? The current <img> loading model doesn't match browsers well enough and I need to work on that. If you have thoughts on how image loading should work, please comment on bug 24711 soon. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From junov at google.com Tue Apr 29 16:35:52 2014 From: junov at google.com (Justin Novosad) Date: Tue, 29 Apr 2014 16:35:52 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404291905070.7589@ps20323.dreamhostps.com> References: <69477B5B-A7A4-4674-B267-09EC2499C1F0@adobe.com> <alpine.DEB.2.00.1404291905070.7589@ps20323.dreamhostps.com> Message-ID: <CABpaAqQGbexMVgO6Nq6JrXg4c7_1bpG_0QF=Vg2K+e=B=OBScA@mail.gmail.com> > > > > > > and it is not possible to resolve font sizes in physical length > > > > units unless the document is associated with a view. > > > > > > Why not? The canvas has a pixel density (currently always 1:1), no? > > > > 1:1 is not a physical pixel density. To resolve a font size that is > > specified in physical units (e.g. millimeters or inches) you need > > something like a DPI value, which requires information about the output > > device. > > No, not any more. CSS "physical" units are defined as mapping to CSS > pixels at 96 CSS pixels per CSS inch, and canvas is defined as mapping CSS > pixels to canvas coordinate space units at one CSS pixel per coordinate > space unit. As far as I know, all browsers do this now. > Right... So I think there is a bug in Blink then. Thanks. > > > > > My 2 cents: specifying fallback behaviors for all use cases that are > > > > context dependent could be tedious and I have yet to see a > > > > real-world use case that requires being able to paint a canvas in a > > > > frame-less document. Therefore, I think the spec should clearly > > > > state <canvas> elements that are in a document without a browsing > > > > context are unusable. Not sure what the exact behavior should be > > > > though. Should an exception be thrown upon trying to use the > > > > rendering context? Perhaps canvas draws should fail silently, and > > > > using the canvas as an image source should give transparent black > > > > pixels? > > > > > > As far as I can tell, this is all already specified, and it just gets > > > treated like a normal canvas. > > > > Agreed. The fallback behavior is specified. But is it good enough? There > > will be discrepancies, sometimes large ones, between text rendered with > > and without a browsing context. > > I don't think there should be any discrepancies. > One major discrepancy I noticed is that web font resolution fails but I don't think that is due to lack of a browsing context per se. It is more precisely due to the fact that we don't compute style on documents that are not displayed (web fonts are defined in CSS). > > > Instead, we should use adaptive algorithms, for example always using > > > the prettiest algorithms unless we find that frame rate is suffering, > > > and then stepping down to faster algorithms. > > > > Such an adaptive algorithm implies making some kind of weighted decision > > to chose a reasonable compromise between quality and performance. > > Sounds like the perfect place to use a hint. > > If we really need a hint. But do we? Do we have data showing that adaptive > algorithms can't do a good job without a hint? > Fair enough. Will give it a try. > On Mon, 7 Apr 2014, Justin Novosad wrote: > > > > Dashing is one thing that would be affected. I think some > > implementations are currently in a non-compliant state probably because > > the line dashing feature was added recently. Back when strokeRect was > > originally implemented, we could get away with blindly normalizing > > rectangles because there was no impact on the rendering result. The > > other thing that is affected is fill rule application. For example, if > > you have a path that contains two intersecting rectangles and you are > > filling in with the nonzero rule. If one of the two rectangles is > > flipped, then the intersection region should be unfilled. If the > > rectangles are "normalized" internally by the implementation, then you > > will get the wrong (non spec compliant) result. > > I've added "in that order" to rect(). > Thanks. > I couldn't find the original reason for strokeRect() only drawing one line > in the one-dimensional case, though it dates back to 2007 at least. That speaks for itself: If no one has complained about that since 2007... > I haven't changed rect() to do that too. > Good. I think it is best for rect to not optimize to a line because that would affect filling in an undesirable way and it would affect the start point of the next sub-path. That being said, it is probably safe to optimize it to two lines, but that does not have to be detailed in the spec since it is an implementation optimization that has no effect on the rendered result. > > On Sun, 6 Apr 2014, Dirk Schulze wrote: > > > > The spec says that the object TextMetrics[1] must return font and actual > > text metrics. All things require information from the font or the font > > system. In many cases either font or font system just do not provide > > these information. > > Which cases? The information is needed for text layout purposes; if the > browser can't get the information, how is it conforming to CSS? > It conforms by applying approximation rules (or guesses?) that derive the missing metrics from the ones that are available. It's ugly, but it kinda works. From ian at hixie.ch Tue Apr 29 16:48:41 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 29 Apr 2014 23:48:41 +0000 (UTC) Subject: [whatwg] BroadcastChannel should support structured clones In-Reply-To: <CA+c2ei_4hFxmegCK13LyiZV4pjwou_TyCUO44HrqizccR5VZvA@mail.gmail.com> References: <CA+c2ei-4u-iMSts6z0owHi2V8Z6bEXhgj1_WyJmak+mACWR1VA@mail.gmail.com> <CA+c2ei_4hFxmegCK13LyiZV4pjwou_TyCUO44HrqizccR5VZvA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404292331410.7589@ps20323.dreamhostps.com> On Thu, 17 Apr 2014, Jonas Sicking wrote: > > It would be very useful to be able to send structured data, including > Blobs, through the BroadcastChannel API. > > This is something we've seen any time we've done storage or message > passing, that one of the first thing authors ask for is to not have to > do JSON serialization/parsing manually. The ability to pass ArrayBuffers > and Blobs is somewhat less commonly asked for, likely because binary > data is less often used, but seems important nonetheless. > > We can't allow transferring of objects, since you can't transfer > something to all listeners of a broadcasting API. But plain structured > clones should be no problem to support conceptually (though more work to > implement of course). > > We've started looking at doing structured clone support for Firefox and > likely won't ship until we have that implemented. This would make a lot of sense. I think when I was first speccing this I wanted to avoid transferring and forgot that you could clone without transferring! I see that you filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25415 ...so I'll track it there. For implementation purposes you can assume that I'm going to make this change. On Thu, 17 Apr 2014, Jonas Sicking wrote: > > Another thing that seems like an oversight in the spec is that the spec > currently says that BroadcastChannel should be exposed in Window > context. We should also expose it in Worker contexts. I had filed a bug to track this earlier: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24414 If you want to implement this in workers please do go ahead. I was just waiting for people to implement it at all before doing the minor work of updating the spec for workers (mostly, as noted in the bug, changing the "responsible document" stuff to check for worker event loops instead when in a worker, and excluding suspended workers). I've moved the bug back onto my radar. For people following on at home, there's also this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25414 ...relating to the order of events in a broadcast channel, and this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25413 ...wherein I'm about to change how channel names are exposed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bruant.d at gmail.com Wed Apr 30 02:36:19 2014 From: bruant.d at gmail.com (David Bruant) Date: Wed, 30 Apr 2014 11:36:19 +0200 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <53601A77.9050102@gmail.com> References: <53601A77.9050102@gmail.com> Message-ID: <5360C413.5070003@gmail.com> Ok, sorry, I was pissed off... The web platform triggers this sort of reactions sometimes :-) Constructive proposal: * a special value for the hidden attribute that forces the element to be hidden regardless of what the CSS or style attribute says for the display value. Maybe `hidden="force"`? This might break existing website which would use the "force" value, but since it had no special meaning currently and there is no good reason to use this value, I'd say the odds are very low. Any implementor interested? David Le 29/04/2014 23:32, David Bruant a ?crit : > Hi, > > // CSS: > div{ > display: flex; > } > > // HTML: > <div hidden></div> > > Per spec, the div should be shown right? I imagine there is no way > back on that? > Does it mean hidden only works when the default (UA stylesheet) > display value is kept? Does it mean hidden is completely useless when > trying to combine it with display:flex? > > What I'm trying to do is just that an element have display:flex and to > hide it with the hidden attribute when I don't need the element to be > shown. I guess my only option is changing style.display? > > Thanks, > > David From annevk at annevk.nl Wed Apr 30 04:01:44 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 30 Apr 2014 12:01:44 +0100 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <5360C413.5070003@gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> Message-ID: <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> > Le 29/04/2014 23:32, David Bruant a ?crit : >> >> Hi, >> >> // CSS: >> div{ >> display: flex; >> } >> >> // HTML: >> <div hidden></div> >> >> Per spec, the div should be shown right? I imagine there is no way back on >> that? We could change the specification to use display-box instead. That might work. -- http://annevankesteren.nl/ From bruant.d at gmail.com Wed Apr 30 04:51:11 2014 From: bruant.d at gmail.com (David Bruant) Date: Wed, 30 Apr 2014 13:51:11 +0200 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> Message-ID: <5360E3AF.8000506@gmail.com> Le 30/04/2014 13:01, Anne van Kesteren a ?crit : >> Le 29/04/2014 23:32, David Bruant a ?crit : >>> Hi, >>> >>> // CSS: >>> div{ >>> display: flex; >>> } >>> >>> // HTML: >>> <div hidden></div> >>> >>> Per spec, the div should be shown right? I imagine there is no way back on >>> that? > We could change the specification to use display-box instead. That might work. Just read about display-box [1]. (Sorry, I'm lagging behind on CSS innovations) Just to be sure I understand, are you suggesting to change the default UA stylesheet from *[hidden]{ display: none; } to *[hidden]{ display-box: none; } Also, what's the intention/implementation status of display-box across various browsers? Thanks, David [1] http://dev.w3.org/csswg/css-display-3/#the-display-box From robin at w3.org Wed Apr 30 05:24:12 2014 From: robin at w3.org (Robin Berjon) Date: Wed, 30 Apr 2014 14:24:12 +0200 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> Message-ID: <5360EB6C.1020700@w3.org> On 30/04/2014 13:01 , Anne van Kesteren wrote: >> Le 29/04/2014 23:32, David Bruant a ?crit : >>> // CSS: >>> div{ >>> display: flex; >>> } >>> >>> // HTML: >>> <div hidden></div> >>> >>> Per spec, the div should be shown right? I imagine there is no way back on >>> that? > > We could change the specification to use display-box instead. That might work. Isn't that just moving the problem though? If the CSS uses display-box: contents (or whatever else might get added next) for some reason then hidden won't work either. Less likely, but still. Maybe having the default style use both display and display-box might fly? -- Robin Berjon - http://berjon.com/ - @robinberjon From glenn at zewt.org Wed Apr 30 07:32:37 2014 From: glenn at zewt.org (Glenn Maynard) Date: Wed, 30 Apr 2014 09:32:37 -0500 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> Message-ID: <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> Previous discussion: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037905.html On Wed, Apr 30, 2014 at 6:01 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > >> <div hidden></div> > >> > >> Per spec, the div should be shown right? I imagine there is no way back > on > >> that? > > We could change the specification to use display-box instead. That might > work. > It's too bad that display-box also has multiple uses--it doesn't only display or hide the content, it has a third "contents" mode. That means the same problem would happen as soon as you set "display-box: contents" on something--it would override [hidden]. What we really need is a CSS property that only sets whether the element is visible or not and nothing else, like "visible: false". That way, the only way [hidden] gets overridden is if you're actually setting the visibility style. I assume it's too late to change the style [hidden] uses, though. Lots of pages do things like "d = elem.style.display; elem.style.display = "block"; width = elem.style.offsetWidth; elem.style.display = d;" to work around offset* being 0 while hidden, and if [hidden] changes to some other style (or to !important) that code will break. I always just put [hidden] { display: none !important; } in my stylesheets to work around this. That sucks, since it makes [hidden] in pages and scripts I write incompatible with everyone else, who may be writing scripts that don't understand this (such as the above pattern), or may work around it in some other way. -- Glenn Maynard From ian at hixie.ch Wed Apr 30 13:22:49 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 30 Apr 2014 20:22:49 +0000 (UTC) Subject: [whatwg] Feedback on seamless iframe attribute In-Reply-To: <CAA-7dEo9ZyhJABdE1O4H5E2d=xpxwWs=mm=uNn_H3oijOPZpCQ@mail.gmail.com> References: <CAA-7dEo9ZyhJABdE1O4H5E2d=xpxwWs=mm=uNn_H3oijOPZpCQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404302011570.30416@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Ben Vinegar wrote: > > But while we?re not interested in the style component of the seamless > attribute, we ? and probably all developers that hack on iframes ? are > interested in the resizing behaviour it introduces. Right now we deploy > fairly complex code, both inside the iframed document, and on the parent > document, to resize the iframe element when the iframed content changes > size. Every iframed application with dynamically-sized content does the > same. Thanks for descrbing this use case. It has come up before, as it happens. Combined with the desire for other aspects of seamless="" to apply to cross-origin iframes, the current proposal is to have headers that enable these features on the embedee site, with CSP being used to decide which origins are allowed to use the feature at all. You can see more about this at these links: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0207.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html https://www.w3.org/Bugs/Public/show_bug.cgi?id=23513 The current blocker is getting implementor interest; right now, most implementors haven't finished (or in some cases even started) supporting seamless="" even for same-origin iframes, so we don't want to start adding more features yet lest we get too far ahead of the browsers. > To me, it?s crazy that it?s 2013 and there?s still no native way to have > the browser automatically resize an iframe. And yet we have seamless. > But it not only resizes: it adds all this other bundled behaviour, and > strictly serves a fringe use case where somebody is distributing iframes > on the same origin. The main use case is same-origin-served blog comments, which isn't that fringe, to be fair. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ben at benv.ca Wed Apr 30 13:31:46 2014 From: ben at benv.ca (Ben Vinegar) Date: Wed, 30 Apr 2014 13:31:46 -0700 Subject: [whatwg] Feedback on seamless iframe attribute In-Reply-To: <alpine.DEB.2.00.1404302011570.30416@ps20323.dreamhostps.com> References: <CAA-7dEo9ZyhJABdE1O4H5E2d=xpxwWs=mm=uNn_H3oijOPZpCQ@mail.gmail.com> <alpine.DEB.2.00.1404302011570.30416@ps20323.dreamhostps.com> Message-ID: <CAA-7dEqo8ekcN+EvaLfXR=rzXQCSP3n2OoDbT0_48Hf9ozPoxA@mail.gmail.com> > The main use case is same-origin-served blog comments, which isn't that fringe, to be fair. Are you aware of any other products/companies using same-origin-served blog comments, that aren't Google Plus/Blogger? Genuinely curious. - Ben On Wed, Apr 30, 2014 at 1:22 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Feb 2014, Ben Vinegar wrote: > > > > But while we?re not interested in the style component of the seamless > > attribute, we ? and probably all developers that hack on iframes ? are > > interested in the resizing behaviour it introduces. Right now we deploy > > fairly complex code, both inside the iframed document, and on the parent > > document, to resize the iframe element when the iframed content changes > > size. Every iframed application with dynamically-sized content does the > > same. > > Thanks for descrbing this use case. > > It has come up before, as it happens. Combined with the desire for other > aspects of seamless="" to apply to cross-origin iframes, the current > proposal is to have headers that enable these features on the embedee > site, with CSP being used to decide which origins are allowed to use the > feature at all. You can see more about this at these links: > > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0207.html > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html > https://www.w3.org/Bugs/Public/show_bug.cgi?id=23513 > > The current blocker is getting implementor interest; right now, most > implementors haven't finished (or in some cases even started) supporting > seamless="" even for same-origin iframes, so we don't want to start adding > more features yet lest we get too far ahead of the browsers. > > > > To me, it?s crazy that it?s 2013 and there?s still no native way to have > > the browser automatically resize an iframe. And yet we have seamless. > > But it not only resizes: it adds all this other bundled behaviour, and > > strictly serves a fringe use case where somebody is distributing iframes > > on the same origin. > > The main use case is same-origin-served blog comments, which isn't that > fringe, to be fair. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Wed Apr 30 14:12:19 2014 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 30 Apr 2014 14:12:19 -0700 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> Message-ID: <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> On Wed, Apr 30, 2014 at 7:32 AM, Glenn Maynard <glenn at zewt.org> wrote: > It's too bad that display-box also has multiple uses--it doesn't only > display or hide the content, it has a third "contents" mode. That means > the same problem would happen as soon as you set "display-box: contents" on > something--it would override [hidden]. What we really need is a CSS > property that only sets whether the element is visible or not and nothing > else, like "visible: false". That way, the only way [hidden] gets > overridden is if you're actually setting the visibility style. Mind bringing this up in www-style? My thinking in that design is that display-box controls whether an element generates boxes at all, which seems consistent with including the 'contents' value. But if it seems useful to have a property dedicated to literally just hiding the element, we can see about rejiggering things. ~TJ From ian at hixie.ch Wed Apr 30 14:32:32 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 30 Apr 2014 21:32:32 +0000 (UTC) Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404302119290.30416@ps20323.dreamhostps.com> On Wed, 30 Apr 2014, David Bruant wrote: > Le 29/04/2014 23:32, David Bruant a ?crit : > > > > // CSS: > > div { > > display: flex; > > } > > > > // HTML: > > <div hidden></div> > > > > Per spec, the div should be shown right? I imagine there is no way > > back on that? Right. You want: div[hidden] { display: block } ...in your style sheet. It's the equivalent of: strong { font: 1em sans-serif; } ...removing the bold, or: td.foo { display: none; } ...making all the cells after <td class=foo> end up in the wrong column. > > Does it mean hidden only works when the default (UA stylesheet) > > display value is kept? Does it mean hidden is completely useless when > > trying to combine it with display:flex? No, it just means you have to be careful with your CSS. Personally I often use this rule: [hidden] { display: block; opacity: 0; } ...combined with CSS transitions to animate elements that are being hidden or shown. This is one example of why it's important that author CSS be able to override the default CSS. > > What I'm trying to do is just that an element have display:flex and to > > hide it with the hidden attribute when I don't need the element to be > > shown. I guess my only option is changing style.display? Just add "[hidden] { display: none }" to your style sheet. > Constructive proposal: > * a special value for the hidden attribute that forces the element to be > hidden regardless of what the CSS or style attribute says for the display > value. > Maybe `hidden="force"`? Hidden how? 'visibility'? 'display'? 'opacity'? Why? What if you later want to style it differently? On Wed, 30 Apr 2014, Anne van Kesteren wrote: > > We could change the specification to use display-box instead. That might > work. Would that break sites that are intentionally replacing the styling for hidden="" from 'display:none' to 'opacity:0' ? On Wed, 30 Apr 2014, Glenn Maynard wrote: > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037905.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0143.html -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Wed Apr 30 14:39:15 2014 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 30 Apr 2014 14:39:15 -0700 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <alpine.DEB.2.00.1404302119290.30416@ps20323.dreamhostps.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> <alpine.DEB.2.00.1404302119290.30416@ps20323.dreamhostps.com> Message-ID: <CAAWBYDAWjkE3hywtgBXG52H=DiogZpUfYH19QjkbLVYVv+T-YA@mail.gmail.com> On Wed, Apr 30, 2014 at 2:32 PM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 30 Apr 2014, Anne van Kesteren wrote: >> We could change the specification to use display-box instead. That might >> work. > > Would that break sites that are intentionally replacing the styling for > hidden="" from 'display:none' to 'opacity:0' ? Yes. ~TJ From domenic at domenicdenicola.com Wed Apr 30 14:56:53 2014 From: domenic at domenicdenicola.com (Domenic Denicola) Date: Wed, 30 Apr 2014 21:56:53 +0000 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CAAWBYDAWjkE3hywtgBXG52H=DiogZpUfYH19QjkbLVYVv+T-YA@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> <alpine.DEB.2.00.1404302119290.30416@ps20323.dreamhostps.com>, <CAAWBYDAWjkE3hywtgBXG52H=DiogZpUfYH19QjkbLVYVv+T-YA@mail.gmail.com> Message-ID: <C57F3B27-2A57-4646-97B2-8A1F1E3CFEF6@domenicdenicola.com> > On Apr 30, 2014, at 17:44, "Tab Atkins Jr." <jackalmage at gmail.com> wrote: > >> On Wed, Apr 30, 2014 at 2:32 PM, Ian Hickson <ian at hixie.ch> wrote: >>> On Wed, 30 Apr 2014, Anne van Kesteren wrote: >>> We could change the specification to use display-box instead. That might >>> work. >> >> Would that break sites that are intentionally replacing the styling for >> hidden="" from 'display:none' to 'opacity:0' ? > > Yes. I have done this (overwritten hidden to be opacity zero) on multiple client sites. Please don't break them :) From ian at hixie.ch Wed Apr 30 15:35:07 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 30 Apr 2014 22:35:07 +0000 (UTC) Subject: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online In-Reply-To: <CAHpoE=ighx=+X8LLoVhdUDEGJ+6K_W-wGSrSG_y2opuQPLZhRA@mail.gmail.com> References: <CAM2RUGM93QEdJpac7=WqYZ6VV5tU0vx8VJNmgYVf2TLOG_dBLQ@mail.gmail.com> <CAM2RUGNv=rqh85jO9nB=h0UTuduuM5hYzCxqzmB+kXuQTQ1oEA@mail.gmail.com> <Pine.LNX.4.64.1212101917340.9975@ps20323.dreamhostps.com> <CA+iXHYOchgdHLtoLvnZopig3Or1eSU0ZrnLvi9UX8XQNC0=OGQ@mail.gmail.com> <Pine.LNX.4.64.1212172128400.20758@ps20323.dreamhostps.com> <50D2E754.5010007@peda.net> <CAHpoE=ighx=+X8LLoVhdUDEGJ+6K_W-wGSrSG_y2opuQPLZhRA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404302224270.30416@ps20323.dreamhostps.com> On Mon, 17 Dec 2012, David Barrett-Kahn wrote: > On Mon, Dec 17, 2012 at 3:30 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Tue, 11 Dec 2012, David Barrett-Kahn wrote: > > > > > > We ran into this same problem on Google Docs offline. Our solution > > > was to add a proprietary response header to Chrome which instructs > > > the browser that the response is not to trigger the fallback entry, > > > despite its response code. Something like it could be considered > > > for standardization. I know there are some people on the Chrome team > > > looking to advance some new appcache features, and that this use > > > case is on their list. > > > > Can you elaborate on the need for this feature? Why would you ever > > send the user to a 404 page intentionally (i.e. when the server isn't > > broken)? Similarly, why would you not consider the server returning > > 500 a good indication that the cache should be used? > > Generally speaking, this feature is useful where the error page is > somewhat routine and contains information comprehensible and actionable > by the user, which would otherwise be lost in the fallback. > > This was mainly about 404s, which docs will serve when a requested > document id doesn't exist, which includes cases where it was deleted. > All our offline application could say (once triggered) was that the > document was not present in our local storage. It couldn't say the > document didn't actually exist. We therefore wanted the server's > version of the error page to be displayed. 401/403 were also of > interest, mainly for cases where the user had previously had access to a > document, but that access had been rescinded. Whether it's a good idea > to divert 500s kind of depends on what they are, especially whether the > served error page contains user-actionable information. > > The current generation of docs offline attempts to only engage the > browser's offline machinery when truly offline. For example, the > regular docs pages one interacts with when online do not bind appcaches. > We have a fallback entry covering the entire origin which engages this > machinery, loading a 'controller' style application which decides how to > handle whatever URL was provided. We have this strict separation for > two reasons. First, we were very keen to ensure that instability in the > new offline technologies we were using never lead to disruption of the > online solution, especially during early development. Second, the > online start-up procedures used by our applications are complex and > highly optimized, and fundamentally incompatible with appcache due to a > 'blending' of the document and the application. We wanted to preserve > those optimizations online and have a different startup procedure when > offline. Interesting. The AppCache API was really designed more around a model where the editor and the data were completely separate, and the data was obtained by the script using XHR or WebSocket and cached locally manually using IndexDB or Web Storage or some such. So yeah, the above use case isn't handled. I've filed a bug to track this, but in pracrice I expect that Service Workers will subsume most of the appcache feature requests. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25525 On Thu, 20 Dec 2012, Mikko Rantalainen wrote: > > I'm not sure about 404 but if the UA is able to connect the server and > gets HTTP 410 Gone, I'd be pretty upset if cached offline copy would be > used automatically. The server has clearly responded that the requested > document is intentionally removed. End user seeing cached (stale) copy > instead is very far from intented result in this case. > > In my opinion the UA should *always* use server returned response if > server responded at all. The original thinking here was that the server here might not be the original server, but might instead be a captive portal. It's far worse to start clearing appcaches because you happened to be connected to a captive portal than it is to display the old offline file instead of saying the file is now gone. After all, if the file is gone, why is it listed in the manifest? On Thu, 20 Dec 2012, Michael Nordman wrote: > > It'd be loads better if application logic were directly responsible for > making these sort of policy decisions regarding what cached resource to > use under what circumstance. I believe that's the approach that Service Workers will provide. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 30 15:36:14 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 30 Apr 2014 22:36:14 +0000 (UTC) Subject: [whatwg] Any plan for a TIMEOUT section on appcache manifests ? In-Reply-To: <50D06D66.1040105@yahoo.fr> References: <50D06D66.1040105@yahoo.fr> Message-ID: <alpine.DEB.2.00.1404302235410.30416@ps20323.dreamhostps.com> On Tue, 18 Dec 2012, Nicolas Froidure wrote: > > I'm using the appcache since it's adoption on major browsers and i think > it lacks of a section to specify fallbacks with a specific timeout in > order to avoid slow networks to damage user experience. To me this is > the main issue still remaining in order to have the same experience than > installed apps. > > It could take the form of a section like this (with a 2 seconds timeout): > TIMEOUT 2: > onlineres.html fallbackres.html > > Or maybe be done with the connection types : > BANDWIDTH EDGE: > onlineres.html fallbackres.html > ... > > Is it planned to have some similar mechanism ? Isn't this something browsers should just implement themselves? It's not clear to me how an author is supposed to know what timeout to give. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From glenn at zewt.org Wed Apr 30 16:08:11 2014 From: glenn at zewt.org (Glenn Maynard) Date: Wed, 30 Apr 2014 18:08:11 -0500 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> Message-ID: <CABirCh_guMWOn4WeAhJ0y3HQ8rquT+RsDfW0R+jhd=SUfpq5jg@mail.gmail.com> On Wed, Apr 30, 2014 at 4:12 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > On Wed, Apr 30, 2014 at 7:32 AM, Glenn Maynard <glenn at zewt.org> wrote: > > It's too bad that display-box also has multiple uses--it doesn't only > > display or hide the content, it has a third "contents" mode. That means > > the same problem would happen as soon as you set "display-box: contents" > on > > something--it would override [hidden]. What we really need is a CSS > > property that only sets whether the element is visible or not and nothing > > else, like "visible: false". That way, the only way [hidden] gets > > overridden is if you're actually setting the visibility style. > > Mind bringing this up in www-style? My thinking in that design is > (It's confusing to move conversations to lists some people aren't subscribed to, since they'll inevitably miss part of the discussion. It'd help a lot if the lists wouldn't bounce mails if you're subscribed to *any* w3 mailing list, so cross-posting would work better. But, I think that starting a new thread on another list without copying it to this one is even more confusing, so I've CC'd both.) that display-box controls whether an element generates boxes at all, > which seems consistent with including the 'contents' value. But if it > seems useful to have a property dedicated to literally just hiding the > element, we can see about rejiggering things. > If an element is @hidden, I don't want style rules for other behaviors to override that. Just as today I don't want a display: block; style to break hidden ("I just wanted this inline element to be block when it's not hidden, not override hidden entirely!"), I don't want display-box: contents; to break hidden either ("I just wanted to cause the element itself to not be rendered when it's not hidden, not override hidden entirely!").. That said, we may be past the point where it will really help. It's too late to actually use this with the default [hidden] rule, which means authors will have to put a [hidden] { rendered: false; } (or something) rule in their stylesheet. If authors all need to add a boilerplate rule to fix @hidden anyway, [hidden] { display: none !important; } works. -- Glenn Maynard From ian at hixie.ch Tue Apr 1 11:55:24 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 18:55:24 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <20140205183607.GA56968@sideshowbarker> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> Message-ID: <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> On Tue, 4 Feb 2014, Cameron McCormack wrote: > Ian Hickson wrote: > > I'm all for handling it in one place. What precisely do you want the > > behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- "the first > > <svg:title> element" may come after "the first<html:title> element", and > > vice versa. Also consider when one or the other is "primary" but the > > relevant element is absent.) > > OK, how about: if the document element is an <html:html>, we choose the > first <html:title> in document order; if the document element is an > <svg:svg>, we choose the first child <svg:title> of the document > element; otherwise, null. > > This still is going to produce "incorrect" results for things like: > > <!DOCTYPE html> > <svg> > <foreignObject> > <title>blah > > > > but arguably you shouldn't be using in there anyway. It doesn't seem useful to hit that element. It's not the (SVG) document title, after all. I ended up going with: - if it's an SVG document, use the first <title> child of the root element - if it's an HTML document, use the first <title> element in tree order (that's what it used to be) For setting it uses the same element, unless there isn't one, in which case: - if it's an SVG document, append an SVG <title> to the root element - if it's an HTML document, append a <title> to the <head> Hopefully that's compatible enough. Let me know if you need something different. On Mon, 3 Feb 2014, Jonas Sicking wrote: > > An even simpler solution would be to say "we choose the first > <html:title> or <svg:title> in document order". That has the nice > property that we align SVG and HTML more. This seems to not quite match the SVG semantics, unfortunately. On Wed, 5 Feb 2014, Simon Pieters wrote: > > Is there a situation in which it is conforming to use html:title outside > the <head> in a document where the root is html:html? In > math:annotation-xml? You can certainly imagine a compound document format containing entire HTML subdocuments, <html>, <head>, <title>, and all. I'm not sure that's possible with just SVG and HTML currently though. (Maybe MathML, indeed.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 12:01:46 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 19:01:46 +0000 (UTC) Subject: [whatwg] microdata questions In-Reply-To: <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> References: <CAGYLO0+N_3BTmKM6+2XLcghm2d0GSy36xubRJKTR5KWEnGhvNg@mail.gmail.com> <CAGYLO0JGVLpYLA+g4EtvN70Rg7_SvGON2adFBfuSpiLtJH-RFg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404011857230.11249@ps20323.dreamhostps.com> On Mon, 10 Feb 2014, Eric Devine wrote: > > 1. Section 5.5.1 of the Microdata spec prescribes how microdata should > be respresented as JSON, but it does provide a MIME type. I'm writing a > REST API that I would like to be able to return JSON in microdata > format, but I need the client to explicitly request this via the HTTP > Accept header. The main concern is to know when to return plain > properties as an array with one element. As a general rule I would recommend against using Accept headers to do anything. You're better off making the JSON data its own resource, IMHO. Having said that, as you noted in a later e-mail, the MIME type suggested by the HTML spec is "application/microdata+json". http://whatwg.org/html#application/microdata+json > 2. Section 5.2.4 does not provide a way to apply a property value to the > value attribute of an <option> element. Is this an oversight, or is > there simply not a convincing enough use case for the need? There's not any way currently to make for controls map to microdata. It's not clear exactly what it would mean. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jonas at sicking.cc Tue Apr 1 12:58:12 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Tue, 1 Apr 2014 12:58:12 -0700 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> Message-ID: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 3 Feb 2014, Jonas Sicking wrote: >> >> An even simpler solution would be to say "we choose the first >> <html:title> or <svg:title> in document order". That has the nice >> property that we align SVG and HTML more. > > This seems to not quite match the SVG semantics, unfortunately. Does it break existing content? If not, why not ask the SVG spec to be changed? The thread was started by one of the SVG spec editors after all. / Jonas From ian at hixie.ch Tue Apr 1 13:29:59 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 1 Apr 2014 20:29:59 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> <alpine.DEB.2.00.1402041713470.30855@ps20323.dreamhostps.com> <op.xas8u0znidj3kv@simon-pieterss-macbook.local> <52F24694.5020903@nag.co.uk> <op.xatdhcm3idj3kv@simon-pieterss-macbook.local> <20140205183607.GA56968@sideshowbarker> <alpine.DEB.2.00.1404011847110.11249@ps20323.dreamhostps.com> <CA+c2ei_yqpa4gVTw5DFi_qSEEAU1KdvwyHotfYqgwbpApupZXg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404012027040.21310@ps20323.dreamhostps.com> On Tue, 1 Apr 2014, Jonas Sicking wrote: > On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Feb 2014, Jonas Sicking wrote: > >> > >> An even simpler solution would be to say "we choose the first > >> <html:title> or <svg:title> in document order". That has the nice > >> property that we align SVG and HTML more. > > > > This seems to not quite match the SVG semantics, unfortunately. > > Does it break existing content? If not, why not ask the SVG spec to be > changed? The thread was started by one of the SVG spec editors after > all. Dirk and heycam's replies to your original e-mail here suggest that this is not really viable. I mean, it'd be like changing document.title in HTML to point to the first title="" attribute in the document if it came before the first <title>. Anyway, what the spec ended up saying is in some ways even simpler, since it only looks one level deep for SVG rather than doing a deep tree search. (Is this the kind of change that you would have liked pre-flighted? I can revert the change and put out an announcement if you like. I'm not yet sure I exactly understand what kinds of changes fall into this category.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 1 17:02:51 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 00:02:51 +0000 (UTC) Subject: [whatwg] <keygen> and X509 client cert mime type In-Reply-To: <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> References: <2E519EB1-CB5D-48E1-8435-BEF2616E9F9C@bblfish.net> <6ED6097D-6F25-4C59-8159-AAB17181D956@bblfish.net> Message-ID: <alpine.DEB.2.00.1404012343180.11249@ps20323.dreamhostps.com> On Tue, 25 Feb 2014, henry.story at bblfish.net wrote: > > The keygen form element does a great job of specifying how the browser > creates a public/private key pair, stores the private key in it's local > keystore. > > "When the control's form is submitted, the private key is stored in the > local keystore, and the public key is packaged and sent to the server." > > It is clear that the intention is for the server to send back a > certificate built from the public key. What I can't find is what the > mime type of the returned certificate should be. I have been using > `application/x-x509-user-cert` which seems to work for Safari, Firefox, > Opera . But I think that is not an officially supported certificate > type. application/pkix-cert seems to be that after looking it up on > iana. > > I ended up posting a bug report for Android on that. > http://code.google.com/p/android/issues/detail?id=66342 > > But now I have to check for each browser which is the type all browsers > support. To avoid people having to do this research again and again, > perhaps it would be worth specifying a mime type that all browsers > do/must support in the HTML5 spec? On Wed, 26 Feb 2014, henry.story at bblfish.net wrote: > > (1) most browsers currently understand the mime types > (a) application/x-x509-user-cert > (b) application/x-x509-ca-cert > (c) application/x-x509-email-cert > ( I have only verified (a) btw. I am assuming the others also support (b) and (c) ) > as specified here > https://wiki.mozilla.org/CA:Certificate_Download_Specification > > (2) the above mime types are not registered > http://www.iana.org/assignments/media-types/media-types.xhtml > > So really either the old mime types should be registered, or they should > be mentioned as being in use but deprecated and people should be guided > towards the application/pkix-cert I wouldn't worry too much about registered vs not registered. If the registry doesn't match the implementations, the registry is buggy. On the other hand, I also don't want to get into the business of specifying this stuff myself. I've added a link to the above MDN page to the keygen section. If there is ever something more canonical (and yet still useful and accurate), let me know and I'll update the spec. Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:43:08 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:43:08 +0000 (UTC) Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEEAS0O79Ko7QrxXKE8YxaVZha5Hzr_bqpAaJrb2PKHQggA@mail.gmail.com> References: <CA+dJEEAS0O79Ko7QrxXKE8YxaVZha5Hzr_bqpAaJrb2PKHQggA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021739430.11249@ps20323.dreamhostps.com> On Mon, 3 Mar 2014, Bob Owen wrote: > > The spec [...] seems to be fairly clear that if an existing window is > navigated using window.open, by a browsing context that is not the > original opener, then window.opener should remain unchanged. > > Currently, Trident (and incidentally Presto) seems to have the correct > behaviour, but Blink, WebKit and Gecko all change window.opener to the > window of the browsing context that has just caused it to navigate. I > believe this to be a very long standing difference (>10 years for Gecko > and Trident) > > I am proposing to change Gecko to match the spec, but I was advised to > raise the issue here before going ahead. > > Do people agree that window.opener should remain unchanged in this > circumstance? Did you receive any off-list feedback on this, or attempt to implement it and get any implementation experience? Having "opener" be the actual opener seems pretty intuitive to me; if there's no compat need to do otherwise, it seems like a reasonable choice. Is there a security reason to prefer the latest navigator? (At the time the spec was written, it was 2v2; the 1v3 situation we have now is the result of Presto going away and Blink forking from WebKit.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:52:14 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:52:14 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> On Mon, 3 Mar 2014, Ami Fischman wrote: > > Looks like we're back in business: > > Latest editor's draft: > http://dev.w3.org/2011/webrtc/editor/getusermedia.html Thanks. As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 10:57:11 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 17:57:11 +0000 (UTC) Subject: [whatwg] More effective model for handling resources In-Reply-To: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> References: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> On Thu, 13 Mar 2014, Tingan Ho wrote: > > Almost all web developer I know use externally linked CSS resource in > their web projects. That means that the browser needs to (1) request the > html page (2) parse the html (3) request for the CSS resource that is > linked from the html document. The problem with externally linked > resources is point three. It needs to make another request for the CSS > resource. There is a solution to this problem and that is to inline the > CSS. Though that would yield another problem: all subsequent page > request will become bigger. I believe this is being handled by the next-generation transport protocols (SPDY or whatever it's called now). I recommend approaching the relevant groups to check that your precise case has been handled. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 11:09:15 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 18:09:15 +0000 (UTC) Subject: [whatwg] inverse property mechanism for Microdata? In-Reply-To: <CAK-qy=6VGPOJshUqSg_BuVU44UUqV9WLxtJAdRUm-pnk=XDKnw@mail.gmail.com> References: <CAK-qy=7SuUq_4Ung06+1CLySJ3D7Aiv_1uyAZnJzc+jPuOcYHw@mail.gmail.com> <alpine.DEB.2.00.1401312334310.26647@ps20323.dreamhostps.com> <CAK-qy=6_ZQ5NCxVSqHraa-Lc1P88vY8BpuacLbj3_QyFpG5jnQ@mail.gmail.com> <alpine.DEB.2.00.1403172046390.31525@ps20323.dreamhostps.com> <CAK-qy=6VGPOJshUqSg_BuVU44UUqV9WLxtJAdRUm-pnk=XDKnw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021759091.11249@ps20323.dreamhostps.com> On Wed, 19 Mar 2014, Dan Brickley wrote: > > > > This is what the example would look like if I'm understanding this right: > > > > <div itemscope itemtype="http://schema.org/LocalBusiness"> > > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > > Giftware</span></h1> > > <span itemprop="description"> A superb collection of fine gifts and clothing > > to accent your stay in Mexico Beach.</span> > > Phone: <span itemprop="telephone">850-648-4200</span> > > > > <div itemscope itemtype="http://schema.org/LocalBusiness" > > itemprop-up="containedIn"> > > <h2><span itemprop="name">(Entity B) The tiny store within a > > store</span></h2> > > <span itemprop="description"> A superb collection of tiny clothes, > > from the store within the store.</span> > > Phone: <span itemprop="telephone">123-456-7890</span> > > </div> > > > > </div> > > > > It's not too bad, I guess. > > Yes. I notice that the words we were playing with at schema.org relate > to the underlying graph data model itemprop-inverse, -reverse etc., > whereas your draft name, itemprop-up is about the markup hierarchy. Yeah. I think most authors think in terms of what they see (their markup), not in terms of the data model. (I have had a _lot_ of conversations with authors where it was clear that they had no idea there was an underlying data model for the microdata that was separate from the markup.) > Yup, there are some cases where this can be addressed through the > rigorous use of entity IDs in itemid, as you sketch below. That would be > relatively new territory for schema.org and for publishers. Perhaps > there is an attribute name we can find that would leave the door open to > more use cases, e.g. "itemprop-backwards" rather than "itemprop-up". It > seems reasonable to try to address relationships between sibling > elements too. Well you'd been a new attribute to do that, unless I'm misunderstanding your proposal. Maybe you mean this attribute wouldn't point to a relative place in the markup, but would point to an identified element given by another attribute? I think that would be quite confusing. > Something like (trying out -backwards instead of -up, to allow for > non-hierarchical usage): > > <div itemid="bigshop" itemscope itemtype="http://schema.org/LocalBusiness"> > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > Giftware</span></h1> > </div> > <div itemscope itemtype="http://schema.org/Pharmacy"> > <meta itemprop-backwards="containedIn" itemid="bigshop" /> > <h2><span itemprop="name">Tiny pharmacy store within a store</span></h2> > </div> > > ? > > Can we use itemid in that way, to give a property value too? I don't > see itemid used much in the wild and the spec only mentions its use > for the item having the property, rather than using when supplying the > value of a property. itemid="" is a URL that gives the identifier of the item. We'd want to use a new attribute to do something like this; e.g.: itemrelation="containedIn bigshop" where "itemrelation" takes just two keywords, a property name and the ID (not itemid) of the target element. But that's pretty elaborate. Is there a need for this? Or is the relationship to the parent all that's needed? In your original e-mail you only suggested wanting to go up. > > Microdata actually already has a solution to this. The vocabulary can > > define an ID for each item using itemid="", and can define multiple items > > having the same ID as being the same conceptual item. Thus: > > > > <!-- first episode --> > > <div itemscope itemtype="http://schema.org/Episode"> > > ... > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"></div> > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"></div> > > </div> > > > > <!-- second episode --> > > <div itemscope itemtype="http://schema.org/Episode"> > > ... > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"></div> > > <div itemprop="actor" > > itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"></div> > > </div> > > > > <!-- actors --> > > <div itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/123"> > > ... > > </div> > > <div itemscope itemtype="http://schema.org/Person" > > itemid="http://.../person/456"> > > ... > > </div> > > > > This also enables the data to be spread across multiple pages without > > confusion. (This is similar to how RDF uses identifiers for everything > > -- essentially, in RDF terms, this turns the microdata item from a > > bnode into a node with a global identifier.) > > Yes, it succeeds or fails to the extent people agree on these global > identifiers. Do people not agree on them, typically? > > Your example would become: > > > > <div itemscope itemtype="http://schema.org/LocalBusiness" > > itemid="..."> > > <h1><span itemprop="name">(Entity A) Beachwalk Beachwear & > > Giftware</span></h1> > > <span itemprop="description"> A superb collection of fine gifts and clothing > > to accent your stay in Mexico Beach.</span> > > Phone: <span itemprop="telephone">850-648-4200</span> > > > > <div itemscope itemtype="http://schema.org/LocalBusiness"> > > <div itemprop="containedIn" > > itemscope itemtype="http://schema.org/LocalBusiness" > > itemid="..."></div> > > <h2><span itemprop="name">(Entity B) The tiny store within a > > store</span></h2> > > <span itemprop="description"> A superb collection of tiny clothes, > > from the store within the store.</span> > > Phone: <span itemprop="telephone">123-456-7890</span> > > </div> > > > > </div> > > > > Is this not suitable for schema.org? Or is it just too much markup? > > It's in the clever-but-fragile category, I'd say. So yes, a bit too > much markup. In English this is saying something like > > "We're describing a LocalBusiness whose global ID is [xyz]; it has > certain name, description, telephone properties given here. > There is also a LocalBusiness that is containedIn a LocalBusiness > whose global ID is [xyz]; this [other] LocalBusiness has the following > name, description, telephone etc properties...." > > Just as in the English, it is rather easy to lose track of which > LocalBusiness we're talking about. I think you overstate the complexity, but ok. > >> > That is another option, similar to the parenthetical itemid="" note > >> > above -- you could just have the vocabulary define that for every > >> > property whose value is an item, the item type that that property > >> > can point to has another property with the same name plus a fixed > >> > suffix, like "-inv", that inverses the relationship. [...] > >> > >> This is easier to understand than itemref, but still involves > >> creating 100s of additional properties instead of just one new piece > >> of syntax. > > > > What do you mean by "creating additional properties" here? It's > > relatively trivial to define these with one sentence, you don't need > > to actually list them or anything. Implementing support is similarly > > easy, as far as I can tell -- you just check for the suffix or prefix > > and handle it accordingly. > > Re "you don't need to actually list them", this effectively creates two > classes of property. Real ones, and fake/pseudo properties which we're > pretending exist so that we can re-use a piece of syntax that expects a > property name. Once these pseudo properties are released into the wild, > they'll show up as if they were real. They would be real, I'm just saying that documenting them and implementing them is somewhat trivial. > What we want to avoid is saying things like: > > "You can use itemprop='containedIn-rev' to indicate a property that > means the inverse of containedIn. However this is not a first class > schema.org property, and should not be used other syntaxes (JSON etc), > data dumps, APIs etc. You should canonicalize x containedIn-rev y > into: y containedIn x., ..." Why wouldn't it be a first-class property? It could trivially be so. The implementation is easy, whatever the vocabulary it's used in. > > If you do want to go with a new property, just use the name you would > > want in the spec. I weakly recommend "itemprop-up", which is the most > > intuitive name I've seen so far for this, but if you find a better > > name just use that. I guarantee that I won't make the spec conflict > > with whatever you use, as long as you tell me what it is. :-) Assuming > > that it works well, then we would just update the spec to use that > > term directly, retroactively making the experimental content > > conforming. > > Thanks! I'll discuss this thread with the schema.org team. My guess is > that there's still a strong preference for a new property, and we'd be > happy to avoid using data-*. > > If I understand right, the outstanding area of discussion/confusion is > whether there are cases beyond simple DOM element containment where we > might want to use an inverse itemprop construction (even though we can > see how itemid everywhere might also be used). If we're only using > element hierarchy then itemprop-up could work. Did you reach any conclusions in these discussions? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bobowencode at gmail.com Wed Apr 2 13:16:58 2014 From: bobowencode at gmail.com (Bob Owen) Date: Wed, 2 Apr 2014 21:16:58 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> On 2 April 2014 18:43, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Mar 2014, Bob Owen wrote: > > > > The spec [...] seems to be fairly clear that if an existing window is > > navigated using window.open, by a browsing context that is not the > > original opener, then window.opener should remain unchanged. > > > > Currently, Trident (and incidentally Presto) seems to have the correct > > behaviour, but Blink, WebKit and Gecko all change window.opener to the > > window of the browsing context that has just caused it to navigate. I > > believe this to be a very long standing difference (>10 years for Gecko > > and Trident) > > > > I am proposing to change Gecko to match the spec, but I was advised to > > raise the issue here before going ahead. > > > > Do people agree that window.opener should remain unchanged in this > > circumstance? > > Did you receive any off-list feedback on this, or attempt to implement it > and get any implementation experience? Thanks for getting back to me Ian. No, no other feedback. I have a patch for it, but haven't pursued it any further. I could investigate putting the change in for Firefox Nightly, if you think that might help with finding any compat issues. > Having "opener" be the actual opener seems pretty intuitive to me; if > there's no compat need to do otherwise, it seems like a reasonable choice. > > Is there a security reason to prefer the latest navigator? Agreed, the specified behaviour makes sense to me, if only because of the name. The fact that you can also use window.open for subsequent navigation (which leads to the different behaviours), muddies the water a bit, but that's a genie that would definitely refuse to go back in the bottle. Over security reasons, although I don't have any concrete examples, I would have thought that either could possibly cause problems, if the opposite behaviour was expected. So, consistency is probably the most important thing. I can also see that both pieces of information (original opener and last navigator) might be useful. So, maybe the other could be added either way. From ian at hixie.ch Wed Apr 2 13:56:38 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 20:56:38 +0000 (UTC) Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> On Wed, 5 Mar 2014, Qebui Nehebkau wrote: > On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson <ian at hixie.ch> wrote: > > I think the arguments you've presented so far suggest "address-levelN" > > for N=1..4, with 4=region and 3=locality, is probably the simplest > > thing to do. I was hoping there might be other people with opinions, > > to give us different perspectives on this, but it seems nobody else > > cares. :-( > > Since you asked, I think the whole endeavour (of trying to tokenise an > address) is pointless and should be abandoned outright. :) In principle I agree, but in practice I think we have to work with the reality that that is what people are doing. > Short of my ideal of *only* offering the full address (as used on a > label) as an opaque string, I think it would be most reasonable to > consider the 'locality' field itself to be a fully-specified opaque > string, including whatever information is necessary to completely > identify the location from the region level (such as the prefecture and > district), rather than a single level. > > Failing all that, I would at least prefer for the fields to have names > instead of abstract numbering, because people are likely to be confused > about the order, no matter which end is the 'widest'. It also seems more > intuitive, to me, for the 'locality', as, after all, 'local', to be the > most specific level. Would people not be confused by names in the same way? On Wed, 5 Mar 2014, Qebui Nehebkau wrote: > > Right, "impose", certainly not. But, perhaps, (one hopes,) "encourage"? > Or at least "refuse to explicitly support anything else". Does > autocomplete *need* to support people who are already doing it wrong? > But I'm probably just being too utopian; it happens. Well if we don't support pretty much every form out there, the feature isn't particularly useful. On Tue, 4 Mar 2014, Kevin Marks wrote: > > > > > > > > > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "address-level4" > > > > > > > > "address-level3" > > > > > > > > "address-level2" / "locality" > > > > > > > > "address-level1" / "region" > > > > > > > > "country-name" > > > > > > > > > > > > This could work. It has the synonym issue (having multiple fields > > > > > > that mean the same thing is often the source of confusion). > > > > > > > > > > > > > > Or we could do: > > > > > > > > > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "subsublocality" > > > > > > > > "sublocality" > > > > > > > > "locality" > > > > > > > > "region" > > > > > > > > "country-name" > > > > > > > > > > > > This could work. It avoids the synonym problem. > > > > > > > > > > Yes, this alternative works, but in my opinion is not preferable. > > > Because these words don't really mean anything. Nor do numbers. I think we don't really have any chance of giving meaning to the names here either way. On Tue, 4 Mar 2014, Evan Stade wrote: > > "dependent-locality" and "locality" have a fairly precise meaning in the > UK. Also in a natural-language conversation, if you ask me what "region" > of the country I live in, I'd say "New England", "the Midwest", or some > such; certainly not the state where I reside. The descriptions for these > tokens are currently pretty specific, for example they say a city would > be a locality. But this is not true for Beijing or some other cities. To > fix the descriptions, we'd have to change them to something like > "region: the highest level administrative region below country in the > address" and "locality: the second-highest level administrative region > below country in the address", "sub-locality: the third-highest level > administrative region [...]". With you so far. > At this point, one wonders why the tokens aren't just [something]1, > [something]2, etc. I don't understand how you get there. Why would you wonder this? > > > > > > > > "address-line1" | > > > > > > > > "address-line2" |- "street-address" > > > > > > > > "address-line3" | > > > > > > > > "locality" > > > > > > > > "subsubregion" > > > > > > > > "subregion" > > > > > > > > "region" > > > > > > > > "country-name" > > > > I don't understand why you think authors will think they need to > > include "subregion", but won't think they need to include > > "address-level3". > > I think they'll assume subregion returns something for the US if it's > sandwiched between "region" and "locality", because county is in between > state and city. But in reality, subregion will return nothing. But why does this not apply to the numeric version? > > Having synonyms is really bad. It leads to huge amounts of confusion. > > This is why I'm trying to avoid having synonyms for the address-level* > > stuff. We should definitely not add some just to introduce a slightly > > better name. > > My suggestion is to change the address-line1 to street-address-line1, > not to have synonyms. Chrome would then support address-line1 for a > limited period of time, but outside the spec. There's no "outside the spec". The spec tries to describe reality. If you implement something, then that's the reality, and that's what the spec would say, and therefore we'd have a synonym. > If you are avidly anti-synonym for the address-level* stuff, and don't > want to change "region" and "locality", then I guess the next best > naming scheme in my mind would be "region", "locality", "locality2", > "locality3". But we also need to update the descriptions as mentioned > above. I don't understand why "locality2" is better than "sublocality", nor why it's better to add things above locality than between locality and region. The numbering seems really prone to mistakes (I mean, I've been making mistakes with it this entire thread unintentionally, for example). > > > Why is that better than 1=region, 2=locality, except to a US-centric > > > viewpoint? This would lead to a weird situation where (a) you > > > couldn't expand past 4 levels without changing the meaning of > > > previous levels and (b) a country such as the US would have > > > address-level4 and address-level3 but no address-level2 or > > > address-level1. > > > > Well, at least as far as (a) goes, we have no way to know where > > governments are going to introduce new levels. Who's to say that the > > US won't introduce something between states and towns? This problem > > exists whatever we do. Maybe the US and the EU will merge and there'll > > be a new field between "country-name" and "region". Who knows. > > One can dream... > > You're right that changing political circumstances might put us in an > awkward situation no matter what we do. But it seems to me the most > likely scenario is that a government would add more administrative > levels at the most granular level. Why? It seems just as likely that we'll add levels between "country" and "region". For instance, the example above. Or, in a few years, when there are parts of countries in space, maybe there'll be a planetoid name between the country and the region. Or maybe that will go on the other side of the country. I think trying to guess how things will be extended is a fool's errand. If we use numbers, we paint ourselves into a corner with extensions anywhere but at the deepest level. Fundamentally, studying all the alternatives we've considered so far, they all suck. - some have weird names like "subsubregion". - some use numbers - some have synonyms - some leave gaps in addresses for some locales where it's not obvious where the gap should be - some are non-trivial to extend later I think I'm going to just go with more or less what you first proposed: "address-line1" | "address-line2" |- "street-address" "address-line3" | "address-level4" "address-level3" "address-level2" / "locality" "address-level1" / "region" "country-name" That is, make "locality" and "region" synonyms for two new fields, add two more, and say in the spec that different locales have different numbers of levels and that as many should be included as are appropriate, starting with level1 as the widest administrative division. I've filed a bug on this topic; if I can get agreement from other vendors, then I'll go ahead and spec this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235 On Wed, 5 Mar 2014, Edward O'Connor wrote: > > The techniques browsers use for autofilling auth information would > benefit enormously from some additional autocomplete="" values. The wiki > page Ilya mentioned captures the use cases pretty well. I think these > are the critical ones that capture the most common cases: > > # Passwords > > On "change your password" forms, which <input type=password> is your > current password? Which is the new password? Browsers want to avoid > filling the old password into the new or confirm password fields. > Additionally, distinguishing such fields would help tools that generate > passwords. These are useful on both sign-up and change password forms. > > <input type=password> - your current password > <input type=password autocomplete=new> - a new password > <input type=password autocomplete=confirm> - the new password, again > > Next to the other autocomplete values, "new" and "confirm" don't look > descriptive enough. "new-password" and "confirm-password", maybe? > "<input type=password autocomplete=new-password>" feels redundant and > verbose to me. Is there any reason to have two fields here, why not just "new" both times? Also, should we have an "old" field for the old password, or is the lack of an autofill field sufficient? I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236 It needs multiple vendors on board to make progress. > # Usernames > > Lots of websites use email addresses as usernames. Tools should be able > to distinguish email-used-as-username fields from other email fields. > This can also help on "forgot password"/"forgot username" forms. > > <inpyt type=text autocomplete=username> - your username on this site > <input type=email> - your preferred email address > <inpyt type=email autocomplete=username> - your username on this site, > not your preferred email > address > <input type=url autocomplete=username> - OpenID This seems reasonable. I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25237 It needs multiple vendors on board to make progress. > Also, consider the case of login forms without username fields. You see > this sort of thing a lot these days, when sites remember who was last > logged in: > > <form> > <label>Password for hober: <input type=password name=pw></label> > <p>Not hober? <a href=...>Click here to sign in</a>. > </form> > > It's difficult for tools to manage the user's auth info for such pages. > How can tools discover what the username is? The obvious solution, in a > world with autocomplete=username, would be to add <input type=hidden > autocomplete=username name=username value=hober> to the form. So far, autocomplete="" hasn't applied to <input type=hidden>. This would be a bit weird, giving it a different meaning than usual (providing information to the UA, rather than getting information from the UA). I'm a bit skeptical of this kind of overloading. Not sure what the right solution is, though. On Fri, 7 Mar 2014, Garrett Casto wrote: > > Another related issue that would be nice to address would be allowing > sites to positively assert that authentication succeeded. For sites that > authenticate client side via XHR, standardizing something like > window.external.AutoCompleteSaveForm() would be very helpful. For sites > that validate server side, I'm less sure what the correct avenue to > convey this information would be (response code, header, ...). I'm > assuming that this will be more contentious than adding username and > password attribution and I don't want to hold that up, but I would like > to see opinions on this. I actually have a similar problem with purely JS-handled forms even unrelated to credentials. Because the form is never really submitted (even if we reuse the submit infrastructure, we cancel the 'submit' event and handle the work on the JS side), there's never an indication to the UA that it should save the fields, and so autofill never works right on these forms, even for things like postal addresses or e-mail addresses. For the pure JS case, an API (probably on the <form> itself) would make sense and seems relatively easy. I've filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 For the real submission case, I guess what we want is a way to say "autocomplete=off" after the fact, basically. An HTTP header seems like the most obvious solution. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 Again, these need multiple vendors on board to make progress. On Mon, 10 Mar 2014, Evan Stade wrote: > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=?cc-number? the browser might provide an experience tailored > for a payment flow, or if there?s an element with autocomplete=?bday? the > browser might use an experience that?s tailored for sharing identiy. > > We?ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element.requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: ?transactionAmount? > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: ?transactionCurrency? > value: string > description: a valid ISO 4217 currency code that describes the currency > for transactionAmount. If not provided, the default is ?USD?. > > Justification? There are upper bounds on certain payment instruments, > for example different credit cards have different credit limits; a debit > card is linked to a bank account with a certain balance. It?s a much > preferable user experience to be able to catch these problems earlier > rather than waiting for the merchant to attempt the transaction and have > it fail (or have a user?s account overdrawn). Concretely, Chromium wants > to handle transactions over $2000 differently from transactions under > that amount. > > Does this seem reasonable? The requestAutocomplete() API is a Chrome proprietary feature right now so it's sort of acadmic, but: Why would this only apply to requestAutocomplete()? Surely it would be just as important for the case where the user agent is filling in a form without using that API. Also, I don't understand how these are supposed to work. How is the browser supposed to know the balance on my credit cards or bank accounts? How is the browser supposed to know which of my cards are good for USD and which are good for GBP? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 2 14:00:33 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 2 Apr 2014 21:00:33 +0000 (UTC) Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> References: <CA+dJEECpW1gudugaEEpXxjiKPckSkNOGeZv_kizf4njk-Tkcdw@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404022057240.21310@ps20323.dreamhostps.com> On Wed, 2 Apr 2014, Bob Owen wrote: > > > > Did you receive any off-list feedback on this, or attempt to implement > > it and get any implementation experience? > > Thanks for getting back to me Ian. > No, no other feedback. > I have a patch for it, but haven't pursued it any further. > I could investigate putting the change in for Firefox Nightly, if you think > that might help with finding any compat issues. Well as far as I'm concerned, I would encourage you to try to converge on the spec behaviour. If it turns out there are compatibility issues, that would be good to know. If not, then at least we win more interoperability. > I can also see that both pieces of information (original opener and last > navigator) might be useful. So, maybe the other could be added either > way. I haven't heard any author demand for it, so I haven't added it, but indeed, if this is something authors have a use for, we could add it. It's worth noting that there are many many ways to navigate a browsing context beyond window.open(), e.g. <a target="">, window.location, drag-and-drop of a link, window.history.go(), etc. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bobowencode at gmail.com Wed Apr 2 15:09:00 2014 From: bobowencode at gmail.com (Bob Owen) Date: Wed, 2 Apr 2014 23:09:00 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> On 2 April 2014 22:00, Ian Hickson <ian at hixie.ch> wrote: > It's worth noting that there are many many ways to navigate a browsing > context beyond window.open(), e.g. <a target="">, window.location, > drag-and-drop of a link, window.history.go(), etc. Absolutely, if we were to converge on the spec for the current opener and people felt that last navigator would be useful, then it would need to be updated in all cases. Although, the history case might hold the original state. Anyway, getting way ahead of myself. I'll see if there are any more opinions, then look to move Gecko towards the spec and see if any compat issues arise. From tingan87 at gmail.com Wed Apr 2 21:37:33 2014 From: tingan87 at gmail.com (Tingan Ho) Date: Thu, 3 Apr 2014 12:37:33 +0800 Subject: [whatwg] More effective model for handling resources In-Reply-To: <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> References: <CAOr4atUxXE7U3vxJEGuRU+Ns2mgFBZ+sS7j9zB0det4ZLPsrWw@mail.gmail.com> <alpine.DEB.2.00.1404021756090.11249@ps20323.dreamhostps.com> Message-ID: <CAOr4atVY-mv1aCMwdY0ijz3vPcsYLdQzb_dgu5kx8kTkDSOXuQ@mail.gmail.com> Hi Ian, I believe this is being handled by the next-generation transport protocols > (SPDY or whatever it's called now). I recommend approaching the relevant > groups to check that your precise case has been handled. I just found out that SPDY Server Push and Cookies could accomplish the above mentioned caching. Cookies will take care of information providing. And the server just uses Server Push to push content. On Thu, Apr 3, 2014 at 1:57 AM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 13 Mar 2014, Tingan Ho wrote: > > > > Almost all web developer I know use externally linked CSS resource in > > their web projects. That means that the browser needs to (1) request the > > html page (2) parse the html (3) request for the CSS resource that is > > linked from the html document. The problem with externally linked > > resources is point three. It needs to make another request for the CSS > > resource. There is a solution to this problem and that is to inline the > > CSS. Though that would yield another problem: all subsequent page > > request will become bigger. > > I believe this is being handled by the next-generation transport protocols > (SPDY or whatever it's called now). I recommend approaching the relevant > groups to check that your precise case has been handled. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- Sincerely, Tingan Ho From lists at scratchdisk.com Wed Apr 2 23:21:38 2014 From: lists at scratchdisk.com (=?iso-8859-1?Q?J=FCrg_Lehni?=) Date: Thu, 3 Apr 2014 08:21:38 +0200 Subject: [whatwg] Grouping in canvas 2d In-Reply-To: <alpine.DEB.2.00.1403141808380.32463@ps20323.dreamhostps.com> References: <CAGN7qDAZbmCh-WqPKxQbk2NvUG1uBWJeeKrwfW--tjWKqtTkEQ@mail.gmail.com> <CAHOuermMNORCZjEBopD5iefJ+RAvhotoyChZDj0EXu6Qcirtxg@mail.gmail.com> <CAGN7qDBHT_fitzzsrnGe6exCWr1Fc4mXSnY=_KW7fNjkoB6-KA@mail.gmail.com> <CABpaAqTdv4TaDpXj4jksL+jeDVqv9cKyVvxJO1nridR9Zwq66Q@mail.gmail.com> <CAGN7qDA9BfpOCqzAmbwooJ_aSw8cbLT-G_-can61K05Q7YsLMw@mail.gmail.com> <73A19694-2AB0-4948-8B4B-A5ED820B2444@scratchdisk.com> <alpine.DEB.2.00.1403141808380.32463@ps20323.dreamhostps.com> Message-ID: <6D69D840-D0F2-4547-AB63-8288C2E51A1D@scratchdisk.com> Here another simple example: When both filling and stroking a path and then drawing it with with an opacity of less than 100%, the path will be rendered differently than in an SVG (a large stroke width will make the issue more apparent): - In Canvas, both the fill and the stroke will be rendered with the given opacity, and the fill will shine through the inner half of the stroke. - In SVG, the stroke will cover the fill, and the fill will not shine through the inner half of the stroke, regardless of the opacity. If you'd like to emulate the SVG behavior in Canvas (which we happen to do in Paper.js), then the only way to do so currently is to draw the path's fill and stroke at 100% opacity into a separate canvas, and then blit the whole thing over with the given opacity. This is *much* slower than directly drawing into the Canvas, and happens to be one of the worst bottlenecks in Paper.js I would really appreciate a solution to this problem. J?rg On Mar 14, 2014, at 19:09 , Ian Hickson <ian at hixie.ch> wrote: > Can you elaborate on what precisely the performance bottleneck is? I was > looking through this thread but I can't find a description of the use > cases it addresses, so it's hard to evaluate the proposals. From mkwst at google.com Thu Apr 3 02:49:20 2014 From: mkwst at google.com (Mike West) Date: Thu, 3 Apr 2014 11:49:20 +0200 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <CAKXHy=cm3F1noHs1SM4XSOpno4aB1GPQ9mhjyva9v+6EU9v3HA@mail.gmail.com> On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson <ian at hixie.ch> wrote: > > Also, consider the case of login forms without username fields. You see > > this sort of thing a lot these days, when sites remember who was last > > logged in: > > > > <form> > > <label>Password for hober: <input type=password name=pw></label> > > <p>Not hober? <a href=...>Click here to sign in</a>. > > </form> > > > > It's difficult for tools to manage the user's auth info for such pages. > > How can tools discover what the username is? The obvious solution, in a > > world with autocomplete=username, would be to add <input type=hidden > > autocomplete=username name=username value=hober> to the form. > > So far, autocomplete="" hasn't applied to <input type=hidden>. This would > be a bit weird, giving it a different meaning than usual (providing > information to the UA, rather than getting information from the UA). I'm a > bit skeptical of this kind of overloading. > > Not sure what the right solution is, though. > As Garrett noted, this is already a solution Google is using, though not with explicit syntax, just taking advantage of existing heuristics. Paving this (potential) cowpath isn't really that weird. That said, an alternative might be to add a mechanism of associating autocompletion metadata with the field in order to give the UA enough context to fill it in. For example, if a password is being requested for a known username, that username could be added as an new "autocomplete-username" attribute (similar to the 'data-*' construct HTML already supports): <input type="password" autocomplete-username="hober"> -mike -- Mike West <mkwst at google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 M?nchen, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) From andy at pigsonthewing.org.uk Thu Apr 3 03:22:48 2014 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu, 3 Apr 2014 11:22:48 +0100 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <CABiXOEmndoUXWk1nWk00RyFsA6g2M8M0ZOofTctP+_oxC4odvQ@mail.gmail.com> [General point, so not quoting anyone in particular] [Resending to list, apologies to Ian] Why would you define any address components other than those in vCard, a standard with massive implementation and interoperable with most address book applications and services? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk From creis at chromium.org Thu Apr 3 11:28:15 2014 From: creis at chromium.org (Charlie Reis) Date: Thu, 3 Apr 2014 11:28:15 -0700 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open In-Reply-To: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> References: <CA+dJEEDt++6erD2DnRtnx3vHwbR0gVibGx-Tj+q8uTDEeqYm5w@mail.gmail.com> Message-ID: <CAH+8MBaU3NSq+WvZ2iG8n_-EAaSBZTA_fYOLoMw0NkFpRf4MiA@mail.gmail.com> On Wed, Apr 2, 2014 at 3:09 PM, Bob Owen <bobowencode at gmail.com> wrote: > On 2 April 2014 22:00, Ian Hickson <ian at hixie.ch> wrote: > > > It's worth noting that there are many many ways to navigate a browsing > > context beyond window.open(), e.g. <a target="">, window.location, > > drag-and-drop of a link, window.history.go(), etc. > > Absolutely, if we were to converge on the spec for the current opener and > people felt that last navigator would be useful, then it would need to be > updated in all cases. > Although, the history case might hold the original state. > > Anyway, getting way ahead of myself. > I'll see if there are any more opinions, then look to move Gecko towards > the spec and see if any compat issues arise. > For what it's worth, I think we'd be open to changing Blink to match the spec as well, if you don't find any compat issues. Charlie From bobowencode at gmail.com Fri Apr 4 01:40:50 2014 From: bobowencode at gmail.com (Bob Owen) Date: Fri, 4 Apr 2014 09:40:50 +0100 Subject: [whatwg] Effect on window.opener when navigating an existing window using window.open Message-ID: <CA+dJEEDiH1N_9rex+Dq_8nzQrCVnpa8djiJGsc1xP3zHCLLY4g@mail.gmail.com> On 3 April 2014 19:28, Charlie Reis <creis at chromium.org> wrote: > For what it's worth, I think we'd be open to changing Blink to match the spec as well, if you don't find any compat issues. I'd say it's worth a lot, thanks Charlie. From faulkner.steve at gmail.com Sat Apr 5 00:59:03 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Sat, 5 Apr 2014 08:59:03 +0100 Subject: [whatwg] summary/details - proposal Message-ID: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> note: bringing this to the whatwg list to elicit feedback from implementers and other interested parties that are not involved in the discussion at the W3C Currently the implementation(s) of summary/details elements do not match the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element In the spec, the details element is interactive content, the summary is not, its a summary, caption, or legend. in webkit/blink the summary element is the interactive element (when pressed it opens/closes the details element) This is good because it provides a large default hit region to activate the control example to try in chrome/safari/opera http://codepen.io/stevef/pen/CyauJ/ So as the spec/implementations are at odds, the implementations need to change to match the spec or the spec needs to change to match implementations or the spec needs to change to accommodate the positive aspects of the current implementations while allowing for other use cases An issue with current implementations is that when the summary element includes other interactive elements (as it is allowed to), clicking on them results in the details element being opened/closed (although this can be overcome via scripting). example to try in chrome/safari/opera http://codepen.io/stevef/pen/xjJiy/ Issues with the current spec text: The interactive part of the details element is the disclosure triangle ? which is supposed to be an anonymous control in the shadow DOM The <summary> itself is not interactive, so only the triangle provides the actionable control. the summary text which is effectively the label for control does not activate the control. There is no method provided to associate a label with the anonymous control that can (a) provide an increased hit region and (b) provide an explicitly associated label for the anonymous control. Given that what we want to provide for the use case of having controls inside the summary, after discussion around the issue[1], I have proposed the following: <details> <summary id=x> <label for=x>Foo</label> </summary> ... </details> what this does is provide the author with the ability to add an explicit label (providing the acc name) to the details control which also increases the click region for improved accessibility/usability, while still allowing interactive content inside the summary element. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25140 feedback welcome! -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From dschulze at adobe.com Sat Apr 5 09:01:19 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sat, 5 Apr 2014 16:01:19 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() Message-ID: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> Hi, I looked at the behavior of negative width or height for the rect() and strokeRect() functions. All browsers normalize the passed parameters for strokeRect() to have positive width and height. strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) http://jsfiddle.net/za945/ Just WebKit seems to normalize for rect() as well: http://jsfiddle.net/VT4MG/ The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. Greetings, Dirk From cabanier at gmail.com Sat Apr 5 18:23:06 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 5 Apr 2014 18:23:06 -0700 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> Message-ID: <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > Hi, > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > strokeRect(90,10,-80,80) --> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ I'm unsure why such a rectangle is defined as a straight line. > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ > > The behavior of normalizing is not specified. Especially it seems odd that > the behavior for fillRect()/strokeRect() should differ from rect(). So we > should either normalize for all functions or don't do it for all IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for rect() > is important for filling with different winding rules as well. It is not > just stroking with dash arrays that is effected. > yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect From ian at hixie.ch Sat Apr 5 21:11:20 2014 From: ian at hixie.ch (Ian Hickson) Date: Sun, 6 Apr 2014 04:11:20 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> On Sat, 5 Apr 2014, Steve Faulkner wrote: > > The <summary> itself is not interactive, so only the triangle provides > the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). > Given that what we want to provide for the use case of having controls > inside the summary, after discussion around the issue, I have proposed > the following: > > <details> > <summary id=x> <label for=x>Foo</label> </summary> > ... > </details> That's way more complicated than necessary for authors, not to mention all the problems it would cause with the existing <label> definitions. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dschulze at adobe.com Sat Apr 5 23:00:50 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 06:00:50 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> Message-ID: <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > Hi, > > I looked at the behavior of negative width or height for the rect() and strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have positive width and height. > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ > >> It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ >> I'm unsure why such a rectangle is defined as a straight line. You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ > > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ > > The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. > >> yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw ?in that order? for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. Greetings, Dirk > > 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect From dschulze at adobe.com Sat Apr 5 23:23:36 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 06:23:36 +0000 Subject: [whatwg] Canvas Computing text metrics Message-ID: <69477B5B-A7A4-4674-B267-09EC2499C1F0@adobe.com> Hi, The spec says that the object TextMetrics[1] must return font and actual text metrics. All things require information from the font or the font system. In many cases either font or font system just do not provide these information. Instead of assuming that all information are accessible by the browser, it might be useful to define some heuristics that can be used. In WebKit and Blink we support the CSS dominant-baseline property in SVG that requires similar metrics as well[2]. Even SVG does not specify the heuristics yet and instead leaves that up to the browser. WebKit and Blink use the heuristics described in the documentation from Apache FOP[1]. Should these be used as fallback heuristics? Note: Many browsers might use heuristics by default since they can?t get all necessary font metrics at all. Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#textmetrics [2] http://www.w3.org/TR/SVG11/text.html#TextAlignmentProperties [3] http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling From cabanier at gmail.com Sat Apr 5 23:24:19 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Sat, 5 Apr 2014 23:24:19 -0700 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> Message-ID: <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > > > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > > Hi, > > > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > > > strokeRect(90,10,-80,80) --> strokeRect(10,10,80,80) > > > > http://jsfiddle.net/za945/ > > > >> It also seems that only firefox is following the spec [1] when width or > height are 0: http://jsfiddle.net/za945/2/ > >> I'm unsure why such a rectangle is defined as a straight line. > > You mean you would rather let it draw a one dimensional rectangle? So for > the dimension that is not zero, you would see two overlapping lines + the 0 > dimensional sides? > yes That seems indeed to be the case for IE, Safari and Blink: > http://jsfiddle.net/Gh9XK/ > > > > > Just WebKit seems to normalize for rect() as well: > > > > http://jsfiddle.net/VT4MG/ > > > > The behavior of normalizing is not specified. Especially it seems odd > that the behavior for fillRect()/strokeRect() should differ from rect(). So > we should either normalize for all functions or don't do it for all IMO. > > > > Note: fillRect() and clearRect() are not affected. The behavior for > rect() is important for filling with different winding rules as well. It is > not just stroking with dash arrays that is effected. > > > >> yes, the spec needs to say "in that order" as it does for fillRect and > strokeRect. > > Ok, that means you would be in favor not to normalize. Again, all current > browser normalize and do NOT draw "in that order" for fillRect() and > strokeRect(). That means you would require to give up the currently > interoperable behavior. > I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) I would be in favor to change the blink/webkit behavior as the specified one makes more sense. From dschulze at adobe.com Sun Apr 6 00:04:46 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 6 Apr 2014 07:04:46 +0000 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> Message-ID: <872B4940-A589-46D1-B72B-B302E7FCC1E3@adobe.com> On Apr 6, 2014, at 8:24 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > > > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> wrote: > > Hi, > > > > I looked at the behavior of negative width or height for the rect() and strokeRect() functions. > > > > All browsers normalize the passed parameters for strokeRect() to have positive width and height. > > > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > > > http://jsfiddle.net/za945/ > > > >> It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/ > >> I'm unsure why such a rectangle is defined as a straight line. > > You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides? > > yes > > That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/ > > > > > Just WebKit seems to normalize for rect() as well: > > > > http://jsfiddle.net/VT4MG/ > > > > The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don?t do it for all IMO. > > > > Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected. > > > >> yes, the spec needs to say "in that order" as it does for fillRect and strokeRect. > > Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw ?in that order? for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior. > > I changed your test a bit so you can more easily see the normalisation: http://jsfiddle.net/za945/3/ > Safari and Chrome are doing as you say, but Firefox does not. (I don't have IE to test) Firefox has a strange different behavior if dash >= gap. If the gap is smaller it behaves like IE, Blink and WebKit. This also answers your question: Your example renders in IE the same as in WebKit and Blink. Greetings, Dirk > > I would be in favor to change the blink/webkit behavior as the specified one makes more sense. From harald at alvestrand.no Mon Apr 7 07:24:23 2014 From: harald at alvestrand.no (Harald Alvestrand) Date: Mon, 07 Apr 2014 16:24:23 +0200 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> Message-ID: <5342B517.1080401@alvestrand.no> On 04/02/2014 07:52 PM, Ian Hickson wrote: > On Mon, 3 Mar 2014, Ami Fischman wrote: >> Looks like we're back in business: >> >> Latest editor's draft: >> http://dev.w3.org/2011/webrtc/editor/getusermedia.html > Thanks. > > As a user, this scares me a lot. Why isn't it up to me to control this? I > don't understand the security model here at all. I don't want random Web > pages to know that they can pipe audio to the remote speakers in my > bedroom from my laptop, but if we just expose all the audio output > devices, that's exactly what will be possible. > > Without a much clearer security model, I don't think it's a good idea to > add any APIs. > Would it make sense to group the access to sinks in with access to sources - that is, "this page wants access to your cameras, microphones and audio output devices"? (either on a per-device basis or as an all-or-nothing prompting) From junov at google.com Mon Apr 7 08:07:34 2014 From: junov at google.com (Justin Novosad) Date: Mon, 7 Apr 2014 11:07:34 -0400 Subject: [whatwg] Canvas normalize rect() and strokeRect() In-Reply-To: <CAGN7qDCijrx_3Rfk2mFThkBc7NignwXoFHhd3fnkL9_5QPE-rQ@mail.gmail.com> References: <3709B668-C951-4013-9907-A07A04C4DA9A@adobe.com> <CAGN7qDDqFcZVX2hk1gc_AOGb7cCTRxqwVS2-mu1QuZ0pqAopPQ@mail.gmail.com> <9270921E-A856-4130-B923-66411D7A47F7@adobe.com> <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com> <872B4940-A589-46D1-B72B-B302E7FCC1E3@adobe.com> <CABpaAqSm=9gAT6TfbJ7RHOcSDMcxy32Enj-txyV-yN=tF8H3JA@mail.gmail.com> <CAGN7qDCijrx_3Rfk2mFThkBc7NignwXoFHhd3fnkL9_5QPE-rQ@mail.gmail.com> Message-ID: <CABpaAqRVUa0-xeoRrBUik22GyYeY1Z0e3FBx=LLpEhryfnAJ5w@mail.gmail.com> On Mon, Apr 7, 2014 at 10:47 AM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Mon, Apr 7, 2014 at 7:29 AM, Justin Novosad <junov at google.com> wrote: > >> Putting myself the the web devs shoes... If I negate the height of a >> rect, what would I expect? My first though: a horizontally flipped mirror >> image of the rect. >> >> Now, what does the spec say? >> a) rect(): respect the flipped vertex order >> > > yes, except it doesn't explicitly say "in that order" so a UA could > implement it in a different one. > Okay. Nonetheless the spec already does define the order, it just does not insist that it must be respected. > > > >> b) strokeRect(): respect the flipped vertex order >> c) fillRect(): unaffected by vertex order. >> > > Where do you see that fillRect is not affected? > It does not say so explicitly, but it is implied. The coloring of pixels is governed by the fillStyle, which is not affected vertex order. > >> d) fillStyle and strokeStyle style application is independent of the >> primitive, mapping is controlled by CTM (and a pattern matrix) >> >> I find the spec is consistent with itself as it is currently worded. If >> you want to flip a rect (or any other geometry for that matter), you can >> either flip everything together using the CTM, or flip its parts (the >> vertices and the styles) individually. >> I think that having the styles automatically flip when the rect is >> inverted would have an undesirable consequence: It would break consistency >> with path rendering (how do you define the notion inverted geometry for a >> general, possibly self-intersecting, path?) >> > > I'm unsure why we would switch geometry. Are you referring to the dashing? > Dashing is one thing that would be affected. I think some implementations are currently in a non-compliant state probably because the line dashing feature was added recently. Back when strokeRect was originally implemented, we could get away with blindly normalizing rectangles because there was no impact on the rendering result. The other thing that is affected is fill rule application. For example, if you have a path that contains two intersecting rectangles and you are filling in with the nonzero rule. If one of the two rectangles is flipped, then the intersection region should be unfilled. If the rectangles are "normalized" internally by the implementation, then you will get the wrong (non spec compliant) result. > > >> On Sun, Apr 6, 2014 at 3:04 AM, Dirk Schulze <dschulze at adobe.com> wrote: >> >>> >>> On Apr 6, 2014, at 8:24 AM, Rik Cabanier <cabanier at gmail.com> wrote: >>> >>> > >>> > >>> > >>> > On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze at adobe.com> >>> wrote: >>> > >>> > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier at gmail.com> wrote: >>> > >>> > > >>> > > >>> > > >>> > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze at adobe.com> >>> wrote: >>> > > Hi, >>> > > >>> > > I looked at the behavior of negative width or height for the rect() >>> and strokeRect() functions. >>> > > >>> > > All browsers normalize the passed parameters for strokeRect() to >>> have positive width and height. >>> > > >>> > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) >>> > > >>> > > http://jsfiddle.net/za945/ >>> > > >>> > >> It also seems that only firefox is following the spec [1] when >>> width or height are 0: http://jsfiddle.net/za945/2/ >>> > >> I'm unsure why such a rectangle is defined as a straight line. >>> > >>> > You mean you would rather let it draw a one dimensional rectangle? So >>> for the dimension that is not zero, you would see two overlapping lines + >>> the 0 dimensional sides? >>> > >>> > yes >>> > >>> > That seems indeed to be the case for IE, Safari and Blink: >>> http://jsfiddle.net/Gh9XK/ >>> > >>> > > >>> > > Just WebKit seems to normalize for rect() as well: >>> > > >>> > > http://jsfiddle.net/VT4MG/ >>> > > >>> > > The behavior of normalizing is not specified. Especially it seems >>> odd that the behavior for fillRect()/strokeRect() should differ from >>> rect(). So we should either normalize for all functions or don?t do it for >>> all IMO. >>> > > >>> > > Note: fillRect() and clearRect() are not affected. The behavior for >>> rect() is important for filling with different winding rules as well. It is >>> not just stroking with dash arrays that is effected. >>> > > >>> > >> yes, the spec needs to say "in that order" as it does for fillRect >>> and strokeRect. >>> > >>> > Ok, that means you would be in favor not to normalize. Again, all >>> current browser normalize and do NOT draw ?in that order? for fillRect() >>> and strokeRect(). That means you would require to give up the currently >>> interoperable behavior. >>> > >>> > I changed your test a bit so you can more easily see the >>> normalisation: http://jsfiddle.net/za945/3/ >>> > Safari and Chrome are doing as you say, but Firefox does not. (I don't >>> have IE to test) >>> >>> Firefox has a strange different behavior if dash >= gap. If the gap is >>> smaller it behaves like IE, Blink and WebKit. This also answers your >>> question: Your example renders in IE the same as in WebKit and Blink. >>> >>> Greetings, >>> Dirk >>> >>> > >>> > I would be in favor to change the blink/webkit behavior as the >>> specified one makes more sense. >>> >>> >> > From fischman at chromium.org Mon Apr 7 08:53:27 2014 From: fischman at chromium.org (Ami Fischman) Date: Mon, 7 Apr 2014 08:53:27 -0700 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> Message-ID: <CAHuR8a9Q6+FSmMVCXUoy79CLMhuHz=yLuNHA_xLjicvE4kAa7w@mail.gmail.com> Thanks Ian. I pinged public-media-capture about this and https://www.w3.org/Bugs/Public/show_bug.cgi?id=25245 is now tracking making that spec better specified. On Wed, Apr 2, 2014 at 10:52 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 3 Mar 2014, Ami Fischman wrote: > > > > Looks like we're back in business: > > > > Latest editor's draft: > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html > > Thanks. > > As a user, this scares me a lot. Why isn't it up to me to control this? I > don't understand the security model here at all. I don't want random Web > pages to know that they can pipe audio to the remote speakers in my > bedroom from my laptop, but if we just expose all the audio output > devices, that's exactly what will be possible. > > Without a much clearer security model, I don't think it's a good idea to > add any APIs. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 09:20:27 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 16:20:27 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342B517.1080401@alvestrand.no> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> Message-ID: <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Harald Alvestrand wrote: > On 04/02/2014 07:52 PM, Ian Hickson wrote: > > On Mon, 3 Mar 2014, Ami Fischman wrote: > > > Looks like we're back in business: > > > > > > Latest editor's draft: > > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html > > > > As a user, this scares me a lot. Why isn't it up to me to control > > this? I don't understand the security model here at all. I don't want > > random Web pages to know that they can pipe audio to the remote > > speakers in my bedroom from my laptop, but if we just expose all the > > audio output devices, that's exactly what will be possible. > > > > Without a much clearer security model, I don't think it's a good idea > > to add any APIs. > > Would it make sense to group the access to sinks in with access to > sources - that is, "this page wants access to your cameras, microphones > and audio output devices"? > > (either on a per-device basis or as an all-or-nothing prompting) Wouldn't that be an implementation detail? When I was first desigining the API for WebRTC (years ago, before it got rather unceremoniously forked by the W3C), the security design I had come up with was basically that the UA would show a panel of devices, and the user would drag-and-drop them into the page to give the page access to them. (Or equivalent UI, e.g. tapping on the relevant device icons to activate them for the page.) This would let me, as a user, specify that on my laptop YouTube can play video on my TV (assuming we extend this stuff to support video over Miracast/AirPlay/WiDi/DIAL/Chromecast/DLNA) while not allowing it to send audio to my bedroom, while simultaneously having Amazon's Cloud Player sending its music to my bedroom, but not allowing it to use my microphone. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From harald at alvestrand.no Mon Apr 7 10:28:45 2014 From: harald at alvestrand.no (Harald Alvestrand) Date: Mon, 07 Apr 2014 19:28:45 +0200 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> Message-ID: <5342E04D.3010301@alvestrand.no> On 04/07/2014 06:20 PM, Ian Hickson wrote: > On Mon, 7 Apr 2014, Harald Alvestrand wrote: >> On 04/02/2014 07:52 PM, Ian Hickson wrote: >>> On Mon, 3 Mar 2014, Ami Fischman wrote: >>>> Looks like we're back in business: >>>> >>>> Latest editor's draft: >>>> http://dev.w3.org/2011/webrtc/editor/getusermedia.html >>> As a user, this scares me a lot. Why isn't it up to me to control >>> this? I don't understand the security model here at all. I don't want >>> random Web pages to know that they can pipe audio to the remote >>> speakers in my bedroom from my laptop, but if we just expose all the >>> audio output devices, that's exactly what will be possible. >>> >>> Without a much clearer security model, I don't think it's a good idea >>> to add any APIs. >> Would it make sense to group the access to sinks in with access to >> sources - that is, "this page wants access to your cameras, microphones >> and audio output devices"? >> >> (either on a per-device basis or as an all-or-nothing prompting) > Wouldn't that be an implementation detail? The details are an implementation detail. Whether sinks should be treated at the same level as sources, higher level or lower level of protection is probably a somewhat higher level issue. > > When I was first desigining the API for WebRTC (years ago, before it got > rather unceremoniously forked by the W3C), the security design I had come > up with was basically that the UA would show a panel of devices, and the > user would drag-and-drop them into the page to give the page access to > them. (Or equivalent UI, e.g. tapping on the relevant device icons to > activate them for the page.) This was considered, but rejected. The consensus opinion at WebRTC and MediaCapture seemed to be that the ability to let an app say "which of these 5 microphones do you want?" is more amenable to creating good apps than leaving this UI to the browser chrome. > > This would let me, as a user, specify that on my laptop YouTube can play > video on my TV (assuming we extend this stuff to support video over > Miracast/AirPlay/WiDi/DIAL/Chromecast/DLNA) while not allowing it to send > audio to my bedroom, while simultaneously having Amazon's Cloud Player > sending its music to my bedroom, but not allowing it to use my microphone. > From faulkner.steve at gmail.com Sun Apr 6 12:50:49 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Sun, 6 Apr 2014 20:50:49 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > The <summary> itself is not interactive, so only the triangle provides > > the actionable control. > > The spec doesn't disallow making clicks on (non-interactive) parts of the > summary defer to the disclosure triangle. Browsers should just match > platform conventions, where applicable, and otherwise make whatever is > considered the best choice for users (such as making such content also > trigger the disclosure triangle). > > Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. It also provides the best choice for users, large click area and focus ring, Its also simple for authors in the majority of use cases. while on Mac OSX only the disclosure triangle (approx 13X13px) itself is clickable and has a focus rectangle. > <details> > <summary id=x> <label for=x>Foo</label> </summary> > ... > </details> That's way more complicated than necessary for authors, how so? with the current definition how do authors provide a label for the disclosure widget when summary also contains controls with labels? in the absence of browser making "clicks on (non-interactive) parts of the summary defer to the disclosure triangle." how is an author supposed to do this? > not to mention all > the problems it would cause with the existing <label> definitions. > may be making the details element a labelable control would be simpler, as its be definition an interactive control. would it cause problems for existing <label> definitions? <details id=x> <summary> <label for=x>Foo</label> </summary> ... </details> > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 10:37:29 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 17:37:29 +0000 (UTC) Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342E04D.3010301@alvestrand.no> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> Message-ID: <alpine.DEB.2.00.1404071735580.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Harald Alvestrand wrote: > > The consensus opinion at WebRTC and MediaCapture seemed to be that the > ability to let an app say "which of these 5 microphones do you want?" is > more amenable to creating good apps than leaving this UI to the browser > chrome. Seems to me that the privacy aspects (the fingerprinting vulnerabilities from exposing this data), and the abuse aspects (giving hostile sites the ability to access all the user's devices if any are made available) would trump this. Surely we can rely on user agents to provide nice UIs. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sun Apr 6 13:08:16 2014 From: ian at hixie.ch (Ian Hickson) Date: Sun, 6 Apr 2014 20:08:16 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> On Sun, 6 Apr 2014, Steve Faulkner wrote: > On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > > > The <summary> itself is not interactive, so only the triangle > > > provides the actionable control. > > > > The spec doesn't disallow making clicks on (non-interactive) parts of > > the summary defer to the disclosure triangle. Browsers should just > > match platform conventions, where applicable, and otherwise make > > whatever is considered the best choice for users (such as making such > > content also trigger the disclosure triangle). > > Platform conventions for disclosure type widgets vary, on windows for > example, the current implementations match the convention. The conventions on Windows are all over the place: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx ...but I doubt that this matches any of the Windows conventions: | when the summary element includes other interactive elements (as it is | allowed to), clicking on them results in the details element being | opened/closed > > > <details> > > > <summary id=x> <label for=x>Foo</label> </summary> > > > ... > > > </details> > > > > That's way more complicated than necessary for authors, > > how so? All that should be necessary is: <details> <summary> Foo </summary> ... </details> Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. > with the current definition how do authors provide a label for the > disclosure widget when summary also contains controls with labels? If doing so matches the platform conventions, any non-interactive text in the <summary> would open the widget. > in the absence of browser making "clicks on (non-interactive) parts of > the summary defer to the disclosure triangle." how is an author supposed > to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From faulkner.steve at gmail.com Mon Apr 7 11:50:51 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Mon, 7 Apr 2014 19:50:51 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 6 April 2014 21:08, Ian Hickson <ian at hixie.ch> wrote: > On Sun, 6 Apr 2014, Steve Faulkner wrote: > > On 6 April 2014 05:11, Ian Hickson <ian at hixie.ch> wrote: > > > On Sat, 5 Apr 2014, Steve Faulkner wrote: > > > > > > > > The <summary> itself is not interactive, so only the triangle > > > > provides the actionable control. > > > > > > The spec doesn't disallow making clicks on (non-interactive) parts of > > > the summary defer to the disclosure triangle. Browsers should just > > > match platform conventions, where applicable, and otherwise make > > > whatever is considered the best choice for users (such as making such > > > content also trigger the disclosure triangle). > > > > Platform conventions for disclosure type widgets vary, on windows for > > example, the current implementations match the convention. > > The conventions on Windows are all over the place: > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx > > ...but I doubt that this matches any of the Windows conventions: > > | when the summary element includes other interactive elements (as it is > | allowed to), clicking on them results in the details element being > | opened/closed > Not what I said, but the current implementations use of <summary> as the interactive element matches, the first example under usage patterns http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx#patterns > > > > > > <details> > > > > <summary id=x> <label for=x>Foo</label> </summary> > > > > ... > > > > </details> > > > > > > That's way more complicated than necessary for authors, > > > > how so? > > All that should be necessary is: > > <details> > <summary> Foo </summary> > ... > </details> > > Adding two attributes and an elements is thus more complicated than > necessary. This seems pretty unambiguous to me. > for the case <details> <summary> Foo <input> Bar </summary> ... </details> whats the disclosure label? what about? <details> <summary> <label><input> Bar </label></summary> ... </details> > > in the absence of browser making "clicks on (non-interactive) parts of > > the summary defer to the disclosure triangle." how is an author supposed > > to do this? > > The author isn't supposed to do this. The whole point of semantic controls > like this is that the user agent is the one that picks the user interface. > does this also extend to the author being able to provide an accessible name for the control? > > Once we start talking about custom widgets, we're in the space of Web > components, at which point the author can do whatever the author wants. > yeah, its a shame that the design of some html features don't provide the flexibility to allow authors to fix user agent specific design deficits without recourse to web components > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From ian at hixie.ch Mon Apr 7 12:06:15 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 19:06:15 +0000 (UTC) Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> On Mon, 7 Apr 2014, Steve Faulkner wrote: > > > > All that should be necessary is: > > > > <details> > > <summary> Foo </summary> > > ... > > </details> > > > > Adding two attributes and an elements is thus more complicated than > > necessary. This seems pretty unambiguous to me. > > for the case > > <details> > <summary> Foo <input> Bar </summary> > ... > </details> > > whats the disclosure label? The text "Foo", a text field, and the text "Bar". If by "disclosure label" you mean the parts which, on certain platforms, when clicked, would toggle the open state, then that depends on the platform, but I would expect the "Foo" and "Bar" text to be good candidates, since they're otherwise inert. > what about? > > <details> > <summary> <label><input> Bar </label></summary> > ... > </details> Here there's no non-interactive text, so there's no text to target. > > > in the absence of browser making "clicks on (non-interactive) parts > > > of the summary defer to the disclosure triangle." how is an author > > > supposed to do this? > > > > The author isn't supposed to do this. The whole point of semantic > > controls like this is that the user agent is the one that picks the > > user interface. > > does this also extend to the author being able to provide an accessible > name for the control? Should there be a particular need for an accessible name for the <details> control, ARIA can be used to set the name. But I must admit to not understanding why you would need that in practice, if the page is well written. (I find most pages that use accessible labels in situations such as this tend to be poorly written for non-AT users.) > > Once we start talking about custom widgets, we're in the space of Web > > components, at which point the author can do whatever the author > > wants. > > yeah, its a shame that the design of some html features don't provide > the flexibility to allow authors to fix user agent specific design > deficits without recourse to web components Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dyoung at pobox.com Mon Apr 7 12:30:16 2014 From: dyoung at pobox.com (David Young) Date: Mon, 7 Apr 2014 14:30:16 -0500 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <5342E04D.3010301@alvestrand.no> References: <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> Message-ID: <20140407193016.GE7959@pobox.com> On Mon, Apr 07, 2014 at 07:28:45PM +0200, Harald Alvestrand wrote: > On 04/07/2014 06:20 PM, Ian Hickson wrote: > >When I was first desigining the API for WebRTC (years ago, before it got > >rather unceremoniously forked by the W3C), the security design I had come > >up with was basically that the UA would show a panel of devices, and the > >user would drag-and-drop them into the page to give the page access to > >them. (Or equivalent UI, e.g. tapping on the relevant device icons to > >activate them for the page.) > > This was considered, but rejected. > The consensus opinion at WebRTC and MediaCapture seemed to be that > the ability to let an app say "which of these 5 microphones do you > want?" is more amenable to creating good apps than leaving this UI > to the browser chrome. If the app disregards or misunderstands the user's input, what keeps it from using the wrong microphone? How do I disconnect a microphone from an app? How do I know which microphones are connected to which apps? Ian's proposal seems to offer this visibility and control to the user. Dave -- David Young dyoung at pobox.com Urbana, IL (217) 721-9981 From cabanier at gmail.com Tue Apr 8 04:18:22 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 04:18:22 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDCitrYeR+zoh8B+FdGyF6mQL5Pvkd=UjbdKD_Urtw_vBg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 12 Mar 2014, Rik Cabanier wrote: > > On Wed, Mar 12, 2014 at 3:44 PM, Ian Hickson wrote: > > > On Thu, 28 Nov 2013, Rik Cabanier wrote: > > > > On Thu, Nov 28, 2013 at 8:30 AM, J?rg Lehni wrote: > > > > > > > > > > I meant to say that it I think it would make more sense if the > > > > > path was in the current transformation matrix, so it would > > > > > represent the same coordinate values in which it was drawn, and > > > > > could be used in the same 'context' of transformations applied to > > > > > the drawing context later on. > > > > > > > > No worries, it *is* confusing. For instance, if you emit coordinates > > > > and then scale the matrix by 2, those coordinates from > > > > getCurrentPath will have a scale of .5 applied. > > > > > > That's rather confusing, and a pretty good reason not to have a way to > > > go from the current default path to an explicit Path, IMHO. > > > > > > Transformations affect the building of the current default path at > > > each step of the way, which is really a very confusing API. The Path > > > API on the other hand doesn't have this problem -- it has no > > > transformation matrix. It's only when you use Path objects that they > > > get transformed. > > > > This happens transparently to the author so it's not confusing. > > I've been confused by it multiple times over the years, and I wrote the > spec. I am confident in calling it confusing. > Only when you think about it :-) > > For instance: > > > > ctx.rect(0,0,10,10); > > ctx.scale(2,2); <- should not affect geometry of the previous rect > > ctx.stroke(); <- linewidth is scaled by 2, but rect is still 10x10 > > It's confusing because it's not at all clear why this doesn't result in > two rectangles of different sizes: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > ctx.scale(2,2); > ctx.stroke(); > > ...while this does: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > ctx.beginPath(); > ctx.rect(0,0,10,10); > ctx.scale(2,2); > ctx.stroke(); > > It appears to be the same path in both cases, after all. > Maybe you can think about drawing paths like drawing in a graphics application. - moveTo, lineTo, etc = drawing line segments in the document - scale = hitting the magnifying glass/zooming - translate = panning the document (0,0) is the upper left of the screen - coordinates in path segments/rect = coordinates on the screen It would be very surprising that line art would change when zooming in or out or panning. From faulkner.steve at gmail.com Tue Apr 8 05:25:14 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Tue, 8 Apr 2014 13:25:14 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> Message-ID: <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> On 7 April 2014 20:06, Ian Hickson <ian at hixie.ch> wrote: > Should there be a particular need for an accessible name for the <details> > control, ARIA can be used to set the name. But I must admit to not > understanding why you would need that in practice, if the page is well > written. (I find most pages that use accessible labels in situations such > as this tend to be poorly written for non-AT users.) > All controls are expected to have an accessible name and it is expected that the author is able to assign one. this is accessibility 101 across all platforms. Lack of an accessible name or a generic accessible name or an ambiguous accessible name causes issues for users. What's the mechanism by which the anonymous control for details can be assigned an accessible name? Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. avoiding unnecessary recourse to web component use is a reasonable and expected goal - built in vs bolt on accessibility is better. Having to use a web component to overcome the inability to make a html control usable without relying on CSS and Js and ARIA is unfortunate, and as you said yesterday "once you're using custom components you've pretty much sacrificed the ability for the web to work without css and js, especially if you don't have a fallback element..." http://krijnhoetmer.nl/irc-logs/whatwg/20140407#l-396 -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From cabanier at gmail.com Tue Apr 8 09:14:50 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 09:14:50 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDAaNR6_TgZMQq2tnE8NgAoWqBDrUB+_ELZqMCPxGWe6Mg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > So this is not how most implementations currently have it defined. > > > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > > definitely do store the path in user coordinates. The spec currently > > > > says otherwise [1] though. > > > > > > I'm not sure what you're referring to here. > > > > All graphics backends for canvas that I can inspect, don't apply the CTM > > to the current path when you call a painting operator. Instead, the path > > is passed as segments in the current CTM and the graphics library will > > apply the transform to the segments. > > Right. That's what the spec says too, for the current default path. No, the spec says this: For CanvasRenderingContext2D objects, the points passed to the methods, and the resulting lines added to current default path by these methods, must be transformed according to the current transformation matrix before being added to the path. > This is the confusing behaviour to which I was referring. The "Path" API > (or > Path2D or whatever we call it) doesn't have this problem. > That is correct. The Path2D object is in user space and can be passed directly to the graphics API (along with the CTM). > ... > > > > var s = new Shape(); > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > > Shape(ctx.currentPath)); > > > > ... > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke > calls? > > > > That does not work as the second addHitRegion will remove the control and > > id from the first one. > > The 'add' operation is needed to get a union of the region shapes. > > Just use two different IDs with two different addHitRegion() calls. That's > a lot less complicated than having a whole new API. > That doesn't work if you want to have the same control for the 2 areas, from the spec for addHitRegion: If there is a previous region with this control, remove it from the scratch bitmap's hit region list; then, if it had a parent region, decrement that hit region's child count by one. Even if you don't use the control, it would be strange to have 2 separate hit regions for something that represents 1 object. > > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > ... > > > > > copy, and would help memory consummation and performance. > > > > > > I don't really understand the use case here. > > > > Jurg was just talking about an optimization (so you don't have to make > > an internal copy) > > Sure, but that doesn't answer the question of what the use case is. > >From my recent experiments with porting canvg ( https://code.google.com/p/canvg/) to use Path2D, they have a routine that continually plays a path into the context which is called from a routine that does the fill, clip or stroke. Because that routine can't simply set the current path, a lot more changes were needed. Some pseudocode that shows the added complexity, without currentPath: function drawpath() { if(Path2DSupported) { return myPath; } else for(...) { ctx.moveTo/lineTo/... } } function fillpath() { var p = drawpath(); if(p) ctx.fill(p); else ctx.fill(); } with currentPath: function drawpath() { if(Path2DSupported) { // only 2 extra lines of code ctx.currentPath = myPath; } else for(...) { ctx.moveTo/lineTo/... } function fillpath() { drawpath(); ctx.fill(); } > On Wed, 12 Mar 2014, Rik Cabanier wrote: > ... > > > You say, here are some paths, here are some fill rules, here are some > > > operations you should perform, now give me back a path that describes > > > the result given a particular fill rule. > > > > I think you're collapsing a couple of different concepts here: > > > > path + fillrule -> shape > > union of shapes -> shape > > shape can be converted to a path > > I'm saying "shape" is an unnecessary primitive. You can do it all with > paths. > > union of (path + fillrule)s -> path > No, that makes no sense. What would you get when combining a path with a fillrule and no fillrule? > > > A shape is just a path with a fill rule, essentially. > > > > So, a path can now have a fillrule? Sorry, that makes no sense. > > I'm saying a shape is just the combination of a fill rule and a path. The > path is just a path, the fill rule is just a fill rule. > After applying a fillrule, there is no longer a path. You can *convert* it back to a path that describes the outline of the shape if you want, but that is something different. The way you've defined things now, you can apply another fill rule on a path with a fill rule. What would the result of that be? > > > Anything you can do > > > with one you can do with the other. > > > > You can't add segments from one shape to another as shapes represent > > regions. > > Likewise, you can't union, intersect or xor path segments. > > But you can union, intersect, or xor lists of pairs of paths and > fillrules. > would you start throwing when doing these operations on paths without fill rules? > ... > > > > > "Wrong" meaning: > > if the author has a bunch of geometry and wants to put it in 1 path > object > > so he can just execute 1 fill operation, he might be under the impression > > that "adding" the geometry will just work. > > Well, sure, an author might be under any number of false impressions. > > The API has a way for a bunch of paths to be merged with a single fillrule > to generate a new path with no crossing subpaths (which is also fillrule > agnostic), essentially giving you the union of the shapes represented by > those paths interpreted with that fillrule. > Is this the API you're referring to? path = new Path2D(paths [, fillRule ] ) The first argument could point to paths that need different winding rules so this won't work. What if one of the paths already had a fill rule? This doesn't seem implementable/stable. > There are very few use cases where you want to add partial path segments > > together but I agree that there are some cases that it's useful to have. > > I disagree that there few such cases. Pretty much any time you create a > path, you are adding partial path segments together. Whether you do so > using one Path object all at once or multiple Path objects that you later > add together is just a matter of programming style. > It's the multiple path objects use case that is unclear to me. Is there any tool/library that does this? Looking at Adobe's graphics applications, there isn't anything like it. Looking at graphics APIs, I don't see any calls that combine paths directly. hmm, it seems the spec has changed. It didn't used to start with "Create a new path that describes the edge of the areas" With the new wording, the last sentence should be updated: Subpaths in the newly created path must wind clockwise, regardless of the direction of paths in path. Since you now create 'holes', the separate paths need to be reoriented like you specify in other parts. > ... > > > > I want them removed because they will most likely not behave in the > > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > > expect that there is 'interference' between them. > > > > > > I don't see why not. It's exactly what happens today if you were to > > > just add the same path creation statements together into the current > > > default path and fill or stroke that. > > > > Sure but who does that? > > It's how all paths are built, as far as I can tell. I don't see how else > you could build a path that consists of more than one line. > > addPath() is useful for shifting a path according to a transform. > Why not just transform() then? addPathByStrokingPath() is for creating a stroked path. > addText() is for writing text. > > I don't see how removing any of them is a win. > Yes, they are useful. The issue is that they are not implementable as currently specified. > > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > ... > > > > > > > > > How would you get a point? the width is scaled to 0. > > > > > > That's how you get a point -- scale(0,0) essentially reverts > > > everything to a zero dimensional point. > > > > OK, but the width of the point is also transformed to 0 so you get > > nothing. > > Points are always zero-width, by definition. > You can still stroke it though and get a point of the strokewidth. > ... > > However the way you defined those APIs does not make sense and will not > > give the result that authors want. > > The way to make this point would be to start from the use case, describe > the desired effect, show the "obvious" way to achieve this using the API, > and then demonstrate how it doesn't match the desired effect. > The obvious way is to go with Shape2D. It's not because I invented it; many advanced graphics APIs came offer this (including D2D and skia) > ... > > > So, it's not realistic to add this to the Path2D object. > > I don't really see why it's unrealistic. In most cases, the user agent > doesn't actually have to do any work -- e.g. if all that you're doing is > merging two paths so that you can fill them simultaneously later, the UA > can just keep the two paths as is and, when necessary, fill them. > > For cases where you really want to have this effect -- e.g. when you want > to get the outline of the dashed outline of text -- then I don't really > see any way to work around it. > That is true. That is why I proposed to make the interface more limited for now until there is a time that this functionality is available. >From Ian Hickson: > I don't think the spec should be written with a particular > implementation in mind, nor should it dictate one. I agree it shouldn't (and doesn't) dictate one. But it's crazy to not consider implementations at all when writing a spec. That way lies madness like requiring O(N^2) algorithms and solving the halting problem and all kinds of other disasters (all of which I've seen in real proposals). > > The reason for that is that even though a UA could emulate the union by > > doing multiple fill operations, Path2D allows you to stroke another path > > object. At that point, you really have to do planarization. By defining > > a Shape2D object and not allowing it to be stroked, we can work around > > this. > > Sure, by limiting the feature set dramatically we can avoid the cases > where you have to do the hard work, but we also lose a bunch of features. > For now. They can be added later. Until then, this is confusing implementors. > ... > > > > Where is the union of fill regions specified? All I see is segments > > aggregation. > > One of the Path constructors takes an array of paths and a fill rule. > See above. > > > > No one has implemented them and they are confusing the browser > > > > vendors. > > > > > > I don't think they're confusing anyone. > > > > The blink people were looking at adding this until they thought it > > through and realized that it wouldn't work. > > Realised what wouldn't work? As far as I'm aware, there's nothing that > wouldn't work. > See this thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/168925.html I think you already addressed some of the concerns. Doing the planarization is now the problem so we can't implement this. > ... > > How can you make that statement? No one has implemented them yet. > > What do you mean by "stable"? > > I assumed you meant "hasn't been changing a lot". The spec hasn't been > changing a lot, so it seems pretty stable. > You've been making a lot of changes lately so this not quite true. Because you wrote it a long time ago and nobody looked at it until now, doesn't mean that it is stable. From ian at hixie.ch Mon Apr 7 15:35:50 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Apr 2014 22:35:50 +0000 (UTC) Subject: [whatwg] <canvas> feedback In-Reply-To: <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> (Note: I started responding to this feedback last week, so this is missing responses to feedback sent in the last few days. Sorry about that. I'll get to that feedback in due course as well!) On Mon, 3 Mar 2014, Justin Novosad wrote: > > Say you create a new document using > document.implementation.createHTMLDocument(), you get a document without > a browsing context. This means that style and layout will never be > calculated on the document. Some of those calculations are context > dependent, so they can't even be resolved. Now, what about canvas > elements? If JS code draws to a canvas that is in a document with no > browsing context, what should happen? It should draw. In theory, anywhere in the canvas API where it depends on computed styles, it has prose saying what should happen if the computed style cannot be used. This is needed for display:none canvases, for 2D contexts in workers, and for the case you describe. > For example, there is no locale for font family resolution I'm not clear on what you mean by "locale" here. What is the locale that a displayed <canvas> in a Document in a browsing context has, that a non-displayed <canvas> outside a Document and without a browsing context does not have? > and it is not possible to resolve font sizes in physical length units > unless the document is associated with a view. Why not? The canvas has a pixel density (currently always 1:1), no? > My 2 cents: specifying fallback behaviors for all use cases that are > context dependent could be tedious and I have yet to see a real-world > use case that requires being able to paint a canvas in a frame-less > document. Therefore, I think the spec should clearly state <canvas> > elements that are in a document without a browsing context are unusable. > Not sure what the exact behavior should be though. Should an exception > be thrown upon trying to use the rendering context? Perhaps canvas draws > should fail silently, and using the canvas as an image source should > give transparent black pixels? As far as I can tell, this is all already specified, and it just gets treated like a normal canvas. On Wed, 5 Mar 2014, Rik Cabanier wrote: > > Testing all browsers (except IE since > document.implementation.createHTMLDocument() doesn't work) they seem to > handle canvas contexts with no browsing context except when you use > text. Chrome crashes, firefox throws an exception and Safari draws the > text with a very small scale I don't really understand why this is problematic in practice. What does a browsing context provide that is needed for rendering text that a user agent couldn't fake for itself in other contexts? We're definitely going to need text in worker canvases. On Thu, 6 Mar 2014, Justin Novosad wrote: > > Thanks for checking. The reason I started this thread is that I just > recently solved the crash in Chrome, and I wasn't satisfied with my > resolution. I just added an early exit, so Chrome 35 will fail silently > on calls that depend on style resolution when the canvas has no browsing > context. So now we have three different behaviors. Yay! > > I don't think the Safari behavior is the right thing to do because it > will never match the developer's intent. I agree. The developer's intent is that text be drawn as specified in the API. Why would we do anything else? On Wed, 12 Mar 2014, Rik Cabanier wrote: > On Wed, Mar 12, 2014 at 3:44 PM, Ian Hickson wrote: > > On Thu, 28 Nov 2013, Rik Cabanier wrote: > > > On Thu, Nov 28, 2013 at 8:30 AM, J?rg Lehni wrote: > > > > > > > > I meant to say that it I think it would make more sense if the > > > > path was in the current transformation matrix, so it would > > > > represent the same coordinate values in which it was drawn, and > > > > could be used in the same 'context' of transformations applied to > > > > the drawing context later on. > > > > > > No worries, it *is* confusing. For instance, if you emit coordinates > > > and then scale the matrix by 2, those coordinates from > > > getCurrentPath will have a scale of .5 applied. > > > > That's rather confusing, and a pretty good reason not to have a way to > > go from the current default path to an explicit Path, IMHO. > > > > Transformations affect the building of the current default path at > > each step of the way, which is really a very confusing API. The Path > > API on the other hand doesn't have this problem -- it has no > > transformation matrix. It's only when you use Path objects that they > > get transformed. > > This happens transparently to the author so it's not confusing. I've been confused by it multiple times over the years, and I wrote the spec. I am confident in calling it confusing. > For instance: > > ctx.rect(0,0,10,10); > ctx.scale(2,2); <- should not affect geometry of the previous rect > ctx.stroke(); <- linewidth is scaled by 2, but rect is still 10x10 It's confusing because it's not at all clear why this doesn't result in two rectangles of different sizes: ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); ctx.scale(2,2); ctx.stroke(); ...while this does: ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); ctx.beginPath(); ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke(); It appears to be the same path in both cases, after all. > > > > So this is not how most implementations currently have it defined. > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > definitely do store the path in user coordinates. The spec currently > > > says otherwise [1] though. > > > > I'm not sure what you're referring to here. > > All graphics backends for canvas that I can inspect, don't apply the CTM > to the current path when you call a painting operator. Instead, the path > is passed as segments in the current CTM and the graphics library will > apply the transform to the segments. Right. That's what the spec says too, for the current default path. This is the confusing behaviour to which I was referring. The "Path" API (or Path2D or whatever we call it) doesn't have this problem. > > > Another use case is to allow authors to quickly migrate to hit regions. > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); > > > ... // lots of complex drawing operation for a control > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); > > > > > > > > > To migrate that to a region (with my proposed shape interface [1]): > > > > > > var s = new Shape(); > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > Shape(ctx.currentPath)); > > > ... > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke calls? > > That does not work as the second addHitRegion will remove the control and > id from the first one. > The 'add' operation is needed to get a union of the region shapes. Just use two different IDs with two different addHitRegion() calls. That's a lot less complicated than having a whole new API. > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > > > > > > Instead of using getCurrentPath and setCurrentPath methods as a > > > solution, this could perhaps be solved by returning the internal > > > path instead of a copy, but with a flag that would prevent further > > > alterations on it. > > > > > > The setter of the currentPath accessor / data member could then make > > > the copy instead when a new path is to be set. > > > > > > This would also make sense from a a caching point of view, where > > > storing the currentPath for caching might not actually mean that it > > > will be used again in the future (e.g. because the path's geometry > > > changes completely on each frame of an animation), so copying only > > > when setting would postpone the actual work of having to make the > > > copy, and would help memory consummation and performance. > > > > I don't really understand the use case here. > > Jurg was just talking about an optimization (so you don't have to make > an internal copy) Sure, but that doesn't answer the question of what the use case is. On Wed, 12 Mar 2014, Rik Cabanier wrote: > > > > > > > > You can do unions and so forth with just paths, no need for > > > > regions. > > > > > > How would you do a union with paths? If you mean that you can just > > > aggregate the segments, sure but that doesn't seem very useful. > > > > You say, here are some paths, here are some fill rules, here are some > > operations you should perform, now give me back a path that describes > > the result given a particular fill rule. > > I think you're collapsing a couple of different concepts here: > > path + fillrule -> shape > union of shapes -> shape > shape can be converted to a path I'm saying "shape" is an unnecessary primitive. You can do it all with paths. union of (path + fillrule)s -> path > > A shape is just a path with a fill rule, essentially. > > So, a path can now have a fillrule? Sorry, that makes no sense. I'm saying a shape is just the combination of a fill rule and a path. The path is just a path, the fill rule is just a fill rule. > > Anything you can do > > with one you can do with the other. > > You can't add segments from one shape to another as shapes represent > regions. > Likewise, you can't union, intersect or xor path segments. But you can union, intersect, or xor lists of pairs of paths and fillrules. > > > > > The path object should represent the path in the graphics state. > > > > > You can't add a stroked path or text outline to the graphics > > > > > state and then fill/stroke it. > > > > > > > > Why not? > > > > > > As designed today, you could fill it, as long as you use non-zero > > > winding. If you use even-odd, the results will be very wrong. (ie > > > where joins and line segments meet, there will be white regions) > > > > I think "wrong" here implies a value judgement that's unwarranted. > > "Wrong" meaning: > if the author has a bunch of geometry and wants to put it in 1 path object > so he can just execute 1 fill operation, he might be under the impression > that "adding" the geometry will just work. Well, sure, an author might be under any number of false impressions. The API has a way for a bunch of paths to be merged with a single fillrule to generate a new path with no crossing subpaths (which is also fillrule agnostic), essentially giving you the union of the shapes represented by those paths interpreted with that fillrule. > There are very few use cases where you want to add partial path segments > together but I agree that there are some cases that it's useful to have. I disagree that there few such cases. Pretty much any time you create a path, you are adding partial path segments together. Whether you do so using one Path object all at once or multiple Path objects that you later add together is just a matter of programming style. > > > Stroking will be completely wrong too, because joins and end caps > > > are drawn separately, so they would be stroked as separate paths. > > > This will not give you the effect of a double-stroked path. > > > > I don't understand why you think joins and end caps are drawn > > separately. That is not what the spec requires. > > Sure it does, for instance from > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path > : > > The round value means that a filled arc connecting the two > aforementioned corners of the join, abutting (and not overlapping) the > aforementioned triangle, with the diameter equal to the line width and > the origin at the point of the join, must be added at joins. > > If you mean, "drawn with a separate fill call", yes that is true. > What I meant was that they are drawn as a separate closed path that will > interact with other paths as soon as there are different winding rules or > "holes". The word "filled" is a bit misleading here (I've removed it), but I don't see why that led you to the conclusion you reached. The step in question begins with "Create a new path that describes the edge of the areas that would be covered if a straight line of length equal to the styles lineWidth was swept along each path in path while being kept at an angle such that the line is orthogonal to the path being swept, replacing each point with the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, and replacing each join with the join necessary to satisfy the styles lineJoin type, as defined below", which seems pretty unambiguous. > > > > We seem to be going around in circles. We're in agreement that > > > > eventually we should add APIs for combining paths such that we get > > > > the equivalent of the union of their fill regions. I agree that > > > > converting text into paths is non-trivial (lots of stuff browsers > > > > do is non-trivial, that's kind of the point -- if it was trivial, > > > > we could leave it for authors). But I don't see how we get from > > > > there to you wanting the existing APIs removed. > > > > > > I want them removed because they will most likely not behave in the > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > expect that there is 'interference' between them. > > > > I don't see why not. It's exactly what happens today if you were to > > just add the same path creation statements together into the current > > default path and fill or stroke that. > > Sure but who does that? It's how all paths are built, as far as I can tell. I don't see how else you could build a path that consists of more than one line. addPath() is useful for shifting a path according to a transform. addPathByStrokingPath() is for creating a stroked path. addText() is for writing text. I don't see how removing any of them is a win. > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > > > > > > > > > > However, for your example, I'm unsure what the right solution > > > > > is. The canvas specification is silent on what the behavior is > > > > > for non-invertible matrices. > > > > > > > > What question do you think the spec doesn't answer? > > > > > > > > > I think setting scale(0,0) or another matrix operation that is > > > > > not reversible, should remove drawing operations from the state > > > > > because: - how would you stroke with such a matrix? > > > > > > > > You'd get a point. > > > > > > How would you get a point? the width is scaled to 0. > > > > That's how you get a point -- scale(0,0) essentially reverts > > everything to a zero dimensional point. > > OK, but the width of the point is also transformed to 0 so you get > nothing. Points are always zero-width, by definition. > We've gone over this several times now. > The APIs that you define, have use cases and I agree with them. > However the way you defined those APIs does not make sense and will not > give the result that authors want. The way to make this point would be to start from the use case, describe the desired effect, show the "obvious" way to achieve this using the API, and then demonstrate how it doesn't match the desired effect. > What you specified there is called "planarization". This is when you > calculate the intersections within and between closed shapes and remove the > line segments that are filled on both sides. > By specifying this: > > The subpaths in merged path must be oriented such that for any point, the > number of times a half-infinite straight line drawn from that point crosses > a subpath is even if and only if the number of times a half-infinite > straight line drawn from that same point crosses a subpath going in one > direction is equal to the number of times it crosses a subpath going in the > other direction. > > and relying on segment removal, you also get the same fill behavior for > even-odd. (Meaning that the end result can be used with either winding rule) > This is not something that is needed for just text but also when you do a > union of shapes. > > The bad news is that this algorithm is very expensive and there are few > libraries that do a decent job (I only know of 1). > So, it's not realistic to add this to the Path2D object. I don't really see why it's unrealistic. In most cases, the user agent doesn't actually have to do any work -- e.g. if all that you're doing is merging two paths so that you can fill them simultaneously later, the UA can just keep the two paths as is and, when necessary, fill them. For cases where you really want to have this effect -- e.g. when you want to get the outline of the dashed outline of text -- then I don't really see any way to work around it. > The reason for that is that even though a UA could emulate the union by > doing multiple fill operations, Path2D allows you to stroke another path > object. At that point, you really have to do planarization. By defining > a Shape2D object and not allowing it to be stroked, we can work around > this. Sure, by limiting the feature set dramatically we can avoid the cases where you have to do the hard work, but we also lose a bunch of features. > > I don't think the arguments for removing these are compelling. The > > problems with the APIs have been addressed (e.g. there's no ambiguity > > in the case of overlapping text), the use cases are clear (e.g. > > drawing text around an arc or drawing a label along a line graph's > > line), and the API now supports the constructs to do unions of fill > > regions. > > Where is the union of fill regions specified? All I see is segments > aggregation. One of the Path constructors takes an array of paths and a fill rule. > > > No one has implemented them and they are confusing the browser > > > vendors. > > > > I don't think they're confusing anyone. > > The blink people were looking at adding this until they thought it > through and realized that it wouldn't work. Realised what wouldn't work? As far as I'm aware, there's nothing that wouldn't work. > > > Until we have support for shapes, the output of these methods won't > > > be stable. > > > > These methods have been very stable. They have barely changed since > > they were added, except for some minor tweaks to fix bugs. > > How can you make that statement? No one has implemented them yet. What do you mean by "stable"? I assumed you meant "hasn't been changing a lot". The spec hasn't been changing a lot, so it seems pretty stable. On Fri, 14 Mar 2014, Justin Novosad wrote: > On Fri, Mar 14, 2014 at 2:29 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > If the bug is that Chrome resamples the image in an ugly way, then > > that's a bug with Chrome. As the bug says, browsers are allowed to > > pick whatever algorithm they want -- it's a quality-of-implementation > > issue. But if the result is ugly, that's a low quality implementation. > > Yes, and if we fixed it to make it prettier, people would complain about > a performance regression. It is impossible to make everyone happy right > now. Would be nice to have some kind of speed versus quality hint. The problem with a hint is that it will be set incorrectly, and so instead of having something that's mostly pretty but mostly fast for everyone, you'd end up with something that's slow on sites that need things to be fast, and things that are ugly on sites that need things to be pretty. In general I think it is very unwise for us to design APIs with hints that have subtle effects on developer machines but that can cripple performance on low-end devices. Instead, we should use adaptive algorithms, for example always using the prettiest algorithms unless we find that frame rate is suffering, and then stepping down to faster algorithms. On Wed, 26 Mar 2014, K. Gadd wrote: > > As I mentioned to Ryosuke off-list, I think the > interpolateEndpointsCleanly attribute is a (relatively) simple solution > to the problem I have with the current spec, and it doesn't > overcomplicate things or make it hard to improve filtering in the > future. It's also trivial to feature-detect, which means I can use it > when available and fallback to a temporary canvas otherwise. I think > providing this option would also make it easier to solve situations > where applications rely on the getImageData output after rendering a > scaled bitmap. > > I'd probably call it something (to me) clearer about semantics, though, > like 'sampleInsideRectangle' Here you are suggesting a feature that would override the requirement in the spec that reads "When the filtering algorithm requires a pixel value from outside the source rectangle but inside the original image data, then the value from the original image data must be used", right? What would you replace it with, exactly? Transparent black? The value from the nearest edge pixel inside the rectangle? Can you elaborate on the use case? On Fri, 14 Mar 2014, Rik Cabanier wrote: > On Fri, Mar 14, 2014 at 11:09 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 4 Dec 2013, J?rg Lehni wrote: > > > > > > Implementing [layering/grouping] would help us greatly to optimize > > > aspects of Paper.js, as double buffering into separate canvases is > > > very slow and costly. > > > > Can you elaborate on what precisely the performance bottleneck is? I > > was looking through this thread but I can't find a description of the > > use cases it addresses, so it's hard to evaluate the proposals. > > Let's say you're drawing a scene and there is a bunch of artwork that > you want to apply a multiply effect or opacity to. With today's code, it > would look something like this: > > var bigcanvas = document.getElementById("c"); > var ctx = bigcanvas.getContext("2d"); > ctx.moveto();.... // drawing underlying scene > > ctx.globalAlpha(.5); > var c = document.createElement("canvas"); > ctx2 = c.getContext("2d"); > ctx2.moveto();.... // drawing scene that needs the effect > ctx.drawImage(c, 0, 0); > > With layers, it would become: > > var bigcanvas = document.getElementById("c"); > var ctx = bigcanvas.getContext("2d"); > ctx.moveto();.... // drawing underlying scene > > ctx.globalAlpha(.5); > ctx.beginLayer(); > ctx.moveto();.... // drawing scene that needs the effect > ctx.endLayer(); > > So, with layers you > - avoid creating (expensive) DOM elements Not really though, right? I mean, the user agent still has to create the intermediate bitmap to apply the effects to. > - simplify the drawing (especially when there's a transformation) Why would it be simpler? There's a bug tracking this feature currently: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22704 On Fri, 14 Mar 2014, Rik Cabanier wrote: > > Path2D has now landed in Blink [1]. Blink also implemented the 'addPath' > method. > WebKit just landed a patch to rename Path to Path2D, remove currentPath and > add fill/stroke/clip with a path [2]. > A patch is under review for Firefox to add Path2D. > > Given this, can we change the spec to reflect the new name? > > 1: https://codereview.chromium.org/178673002/ > 2: https://webkit.org/b/130236 > 3: https://bugzilla.mozilla.org/show_bug.cgi?id=830734 Done. On Tue, 18 Mar 2014, J?rg Lehni wrote: > > So is currentPath going away then for sure? Will there still be a way to > to retrieve a Path2D representation of the path being drawn by the long > existing drawing commands on the context? > > I quite liked how I could use it for caching, in case the browser > supported that feature, and check wether I have a cached path the next > time I need to draw it, falling back on redrawing it using the same > drawing commands. Doing the same by feature-detecting the Path(2D) > constructor and building separate drawing approaches based on its > existence results in much more complicated code. Why is it so complicated? Here's an example of how you could do it, assuming you wanted to cache certain paths function myCircle(p) { p.moveTo(0,0); // etc... } function fillPath(c, callback) { if (window.Path2D) { var p; if (pathIsAlreadyCached(callback.name)) { p = getCachedPath(callback.name); } else { p = new Path2D(); callback(p); saveCachedPath(p, callback.name); } c.fill(p); } else { c.beginPath(); callback(c); c.fill(); } } fillPath(c, myCircle); On Tue, 18 Mar 2014, Dirk Schulze wrote: > > I am still in favor for a setter and getter as well. It had the benefit > that you were able to transform the context and it affected drawing > commands as well. It is more complicated to create a second Path2D > object and add it to a previous path with a transform. I'm not sure I understand what you mean. The interactions of transforms and path building on the 2D context was one of the biggest problems that the Path objects are intended to side-step. On Fri, 14 Mar 2014, Rik Cabanier wrote: > > > > Event retargetting now explicitly applies to "the control represented > > by the region", which is always null if the given control is now a > > text field. > > Does this change the eventTarget attribute on the event object [1]. It changes the "target" attribute, if that's what you mean. (See step 3 of the dispatch algorithm in DOM.) > > > More generally, is this event rerouting supposed to be able to > > > trigger browser default event handling behavior, or only DOM event > > > dispatch? > > > > As it was specified, I don't see how it could trigger default actions > > of anything other than the canvas and its ancestors. The canvas hook > > ran in the middle of the "When a pointing device is clicked, the user > > agent must run these steps" algorithm, which refers to the origin > > target, not the rerouted target. > > > > I've now changed this so that it does in fact trigger the default > > action if applicable. > > This will still just reroute events, right? Not sure what you mean by "just". > For instance, if the fallback element is a <a href="...">, will clicking > on the region cause the browser to follow the hyperlink? Yes. > > On Wed, 5 Mar 2014, Robert O'Callahan wrote: > > > > > > The problem is that if these retargeted events can trigger default > > > browser behavior, the browser has to be able to compute the position > > > of the event relative to the new target DOM node, and it's not clear > > > how to do that. > > > > I've made it explicit that the elements that can get clicks targetted > > to them only include elements that don't have subregions. In > > particular, image maps and image buttons are excluded. > > Thanks for updating the spec. It's getting quite complex though :-( > Maybe it's simpler to just add the id to the event and leave the canvas > element as the target? Since this is not a major feature, the complexity > might stop implementors. I don't understand what part you think is complicated here. Can you elaborate? > > > Currently, the specification states that if you create a region and > > > then create another region that completely covers region, the first > > > region is removed from the hit region list [1] > > > > > > This is a complex operation that involves either drawing the regions > > > to a bitmaps and counting pixels, or path intersection. > > > > There's two trivial ways to implement this, depending on whether the > > hit regions are backed by a bitmap (the simplest and fastest solution > > but uses a lot of memory) or a region list (slower, but much more > > memory efficient). In the case of a bitmap, you just draw on the new > > region, and the old region is no longer in the bitmap, so it's > > trivially gone. > > > > In the case of a list, you put the new region ahead of the old region > > so that you never actually get around to checking the old region. > > The following step still needs to run though: > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#garbage-collect-the-regions > > Let victim be the first hit region in list to have an empty set of > pixels and a zero child count, if any. > > If this was implemented with a bitmap, the only way to figure this out > is to walk the individual pixels (= expensive). This is garbage collection, it doesn't have to run often. When it _is_ run, it's actually pretty fast -- in the bitmap case, for example, you just need to walk the bitmap and for every pixel with a defined region mark the region as non-empty. This is O(N) with the size of the bitmap, but with a _very_ low constant factor (lower than recolourising a bitmap, say, which is something we expect authors to do in JS). > We should also not forget that a11y needs the bounding box of the hit > region which also means constantly walking of the pixels. Not "constantly". This kind of thing is trivially cacheable. It's also relatively simple to just check the pixels you're about to overwrite and note those regions as needing updating; when you _do_ update them, they can only have gotten smaller so you can just walk the edge of the bounding rectangle until you hit a pixel on each side. Plus, the bounding box doesn't have to be updated often -- the user isn't going to be jumping to the area every ten milliseconds or anything, and even if the user did, using a slightly out-of-date bounding box is fine (it'll just be bigger than strictly necessary). > > > It is also unintuitive because an author might expect that he could > > > remove the second region and still have the first region active. > > > > That would be inconsistent with how canvas works. Canvas is an > > immediate-mode API. If you draw on the canvas, and then clear it, you > > don't get back what was there before. > > What if an author doesn't clear it but just calls fillRect or is smart > and just invalidates/redraws portions of the canvas? Hit regions should > keep state, regardless of the canvas pixels. Those would just work, as far as I can tell. Do you have a concrete example? > > > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/thread.html#36556 > > > > > > It looks like that thread never came to a conclusion. > > > > Is there anything specifically that was raised in that thread that you > > think hasn't been responded to? > > Well, you had the last response but I don't think it came to a > conclusion :-) If people don't respond to my requests for clarification or if they don't disagree with the last thing I say, then that's a conclusion... > At the time, I was under the impression that we could mimic it with > paths but when I read the spec closer, the step that removes the region > pixels is too complex to implement and unintuitive for authors [2] As discussed earlier in this thread, it's easy to implement this using a list of paths, you just draw the cleared pixels as a new region on the top of your list. I don't see what's unintuitive here. > > > The arguments against using a bitmap presentation still stand: - it > > > will be too expensive to keep an actual copy of the canvas pixels in > > > memory to do hit testing > > > > It's actually pretty common to do exactly this. Note that you don't > > necessarily need a bitmap that has the same bit depth or pixel density > > as the visible bitmap. > > Where else does this happen? A Google search for "hit test bitmap" shows some examples, but unfortunately it's a hard topic to search for -- I kept running into examples of people trying to do collision detection with bitmaps instead! > Creating a canvas bitmap for constant reading will also be extremely > costly since so many implementations run canvas operations on the GPU. > I'm unsure if anyone supports a 8 bit backbuffer so at best, the hit > region bitmap is half the size. This is too expensive. Don't forget that this doesn't have to be a very high fidelity bitmap. It doesn't get any anti-aliasing, it has no alpha transparency, there's no bitmap drawing, it doesn't necessarily have to be full-density, either (it's unlikely that authors are going to have hit regions that are half a CSS pixel high, for instance). It's quite plausible to do all the work for this bitmap in software on the CPU, as far as I can tell. You can also use a hybrid approach, with the most recent regions added to a list, and the list regularly compressed down to a bitmap when the CPU load is low, or on a separate thread, such that the bitmap generation cost is a non-issue, while still not having to pay the cost of having all the regions in a long list, and while having the GC computations described earlier be reasonably straight-forward to compute (modulo inter-thread communication, which is always fun). > > > - if you have to mimic the behavior with paths, you need access to > > > expensive/difficult path manipulation algorithms > > > > The maths for determining if a region is contained in another region > > is pretty well understood at this point, as far as I can tell. > > It's still a hard problem. Looking at Firefox' and Apple's > implementation, I don't know how they could determine if a path is > contained within another path. Google has a library in development. We > looked at it 6 months ago and it had many issues. Our job is to implement these hard problems so that authors don't have to. > > > Hit regions should be redesigned so they work on the path geometry > > > as opposed to pixels. We already have the necessary code to do hit > > > testing on paths (see isPointInPath) > > > > isPointInPath() works on pixels just like hit regions works on pixels. > > No, this is not how it's implemented. > WebKit, Blink and Firefox use the geometry of the path. They don't use > pixels. That's an implementation detail. My point is that to an author, it's all pixels. The API takes in two coordinates, and gives you a boolean result. > > On Wed, 12 Mar 2014, Dirk Schulze wrote: > > > > > > In SVG we tried to avoid having hit testing based on pixel values > > > obviously for performance reasons. > > > > SVG is a retained-mode API, so naturally it has a different model. > > I don't see why. A browser draws the SVG DOM to a screen bitmap and then > does hit testing with fine paths. Canvas could do the exact same thing. If Canvas and SVG do "the exact same thing", then we should drop one. The whole point of <canvas> is to be an immediate-mode API that complements SVG. > People think of this API as populating a hit region OM. Why not go this > route? What people? > > > clearRect is currently defined as a subtraction mechanism for hit > > > regions [1]. > > > > > > It's unlikely that a UA will implement hit regions using pixels so > > > this would have to be done using path subtraction which is > > > expensive. > > > > I'm not sure why you think it's expensive. It's trivial to just add a > > rectangle to the front of the list of regions. > > That is true. This does mean that if there are a lot of small clearRect > calls, the list of regions could become very long. Sure. Same with if there are a lot of rectanglular hit regions added. The model above, where you start off with a list, but regularly flatten it to a bitmap, would lower the cost of maintaining such a list. > > > Why was this special behavior added to clearRect? > > > > Because it's the most obvious mechanism for authors. You clear a part > > of the canvas, naturally that part of the canvas no longer has > > regions. > > Why is that naturally? Because nothing is rendered there any more. > So, if an author clears an area there are no more regions in it, but if > he draws over it, they are still there? Right. Same as with regular drawing. If you clear it, it's gone. If you draw on top of it, it contributes (e.g. in the colour of anti-aliased lines, showing through where the content on top is transparent, etc). > Clipping also doesn't affect regions. Hm, good point. Fixed. > > On Tue, 4 Mar 2014, Rik Cabanier wrote: > > > > > > The spec implies-- > > > > The spec doesn't imply anything. It either requires something, or > > doesn't. If you ever find yourself reading between the lines, then > > there is either a spec bug, or you are reading something that the spec > > doesn't require. > > I know that. So, if I write "the spec implies", you can assume that I > believe that the spec is incomplete. I would rather you just said "the spec doesn't say whether..." rather than "the spec implies", since the latter has a very different meaning. On Sat, 15 Mar 2014, Dirk Schulze wrote: > > I would suggest a filter attribute that takes a list of filter > operations similar to the CSS Image filter function. Similar to > shadows[2], each drawing operation would be filtered. The API looks like > this: > > partial interface CanvasRenderingContext2D { > attribute DOMString filter; > } > > A filter DOMString could looks like: ?contrast(50%) blur(3px)? > > With the combination of grouping in canvas it would be possible to > group drawing operations and filter them together. > > Filter functions include a reference to a <filter> element and a > specification of SVG filters. I am unsure if a reference do an element > within a document can cause problems. If it does, we would just not > support SVG filter references. I've filed a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25243 On Mon, 17 Mar 2014, Justin Novosad wrote: > > Hmmm, I gave this a bit more thought... To apply the construction > algorithm in transformed space, the ellipse parameters (radiusX, > radiusY, rotation) would have to be transformed. Transforming the > parameters would be intractable under a projective transform (e.g. > perspective), but since we are limitted to affine transforms, it can be > done. Now, in the case of a non-invertible CTM, we would end up with > radiusX or radiusY or both equal to zero. And what happens when you > have that? Your arcTo just turned into lineTo(x1, y1). Tada! On Mon, 17 Mar 2014, Dirk Schulze wrote: > > Why does radiusX or radiusY need to be zero? Because you define it that > way for a non-invertible matrix? That makes sense for scale(0,0). What > about infinity or NaN? If Ian didn?t update the spec then this is still > undefined and therefore up to the UA to decide. How can it be infinity or NaN? (Recall that except where otherwise specified, for the 2D context interface, any method call with a numeric argument whose value is infinite or a NaN value must be ignored.) On Mon, 17 Mar 2014, Rik Cabanier wrote: > > I'm unsure if anyone has shipped that part of the spec. There's > certainly no interop... I am loathe to keep changing this kind of thing. We settled this part of the spec years ago. Let's not go back now. If we keep changing things like this, people will (rightly) complain that they can't trust the spec. > So, what we could say is: > - when drawing paths, ignore all calls if the matrix is non-invertible > (WebKit and Blink do this) > - when filling/stroking/clipping, ignore all calls if the matrix is > non-invertible (Firefox, WebKit and Blink do this) As far as I can tell, this is unnecessary. On Mon, 17 Mar 2014, Justin Novosad wrote: > > Yes, but there is still an issue that causes problems in Blink/WebKit: > because the canvas rendering context stores its path in local > (untransformed) space, whenever the CTM changes, the path needs to be > transformed to follow the new local spcae. This transform requires the CTM > to be invertible. So now webkit and blink have a bug that causes all > previously recorded parts of the current path to be discarded when the CTM > becomes non-invertible (even if it is only temporarily non-invertible, even > if the current path is not even touched while the matrix is > non-invertible). I have a fix in flight that fixes that problem in Blink by > storing the current path in transformed coordinates instead. I've had the > fix on the back burner pending the outcome of this thread. Indeed. It's possible to pick implementation strategies that just can't be compliant; we shouldn't change the spec every time any implementor happens to make that kind of mistake, IMHO. (Of course the better long-term solution here is the Path objects, which are transform-agnostic during building.) Just to be clear, we should support this because otherwise the results are just wrong. For example, here some browsers currently show a straight line in the default state, and this causes the animation to look ugly in the transition from the first frame to the secord frame (hover over the yellow to begin the transition): http://junkyard.damowmow.com/538 Contrast this to the equivalent code with the transforms explicitly multiplied into the coordinates: http://junkyard.damowmow.com/539 I don't see why we would want these to be different. From the author's perspective, they're identical. On Thu, 20 Mar 2014, Rik Cabanier wrote: > > It would be great if we could get clarification on this. I'm not sure what needs clarifying. The spec seems clear here. > Firefox and IE are conformant per the spec when it comes to drawing paths > but not fill/stroke/clip. Can you elaborate on how Firefox doesn't match the spec for stroke and clip? For fill, it does indeed seem to ignore the rule in the spec that says that fill solid colours are unaffected by the current transformation. It has a similar impact on renderings as the examples above: http://junkyard.damowmow.com/540 > Supporting this small edge case comes at a large cost in Firefox and > likely also IE. Can you elaborate on this cost? > Many APIs in canvas are running into this issue which results in lack of > interoperability. As far as I can tell, the spec is unambiguous. Certainly it does appear that browsers haven't yet converged on what the spec says, but that isn't unusual; it takes time for browsers to converge, especially for edge cases like this where there's not much pressure (since authors tend to just work around the bugs). On Wed, 19 Mar 2014, Dirk Schulze wrote: > > I just looked at the definition of Path.addPath[1]: > > void addPath(Path path, SVGMatrix? transformation); > > SVGMatrix is nullable but can not be omitted all together. Why isn?t it > optional as well? I think it should be optional [...] That seems reasonable. Done. On Wed, 19 Mar 2014, Rik Cabanier wrote: > > [context . currentTransform] > > As currently specified, this must return a live SVGMatrix object, > meaning that as you change the CTM on the 2d context, your reference to > the SVGMatrix should change as well. > > It's unlikely that you actually want this... Why? See Chris' original proposal here: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Mar/0269.html I would be reluctant to change this to a different design without their input. On Fri, 21 Mar 2014, Joe Gregorio wrote: > On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze <dschulze at adobe.com> wrote: > > > > I just looked at the definition of Path.addPath[1]: > > > > void addPath(Path path, SVGMatrix? transformation); > > > > SVGMatrix is nullable but can not be omitted all together. Why isn?t it > > optional as well? I think it should be optional, especially because > > creating an SVGMatrix at the moment means writing: > > > > var matrix = document.createElementNS('http://www.w3.org/2000/svg > > ','svg').createSVGMatrix(); > > Agreed, that's painful, +1 for making it optional. Just so we're clear, even when it wasn't optional, you didn't have to do any of that. You can just pass null. (It's still not optional for some of the other methods where it's in the middle of the arguments and making it optional doesn't make much sense.) On Sat, 22 Mar 2014, Dirk Schulze wrote: > > Does some one think it would be necessary to make SVGMatrix nullable > (optional SVGMatrix?)? I think it would be superfluous. It's needed for consistency with the other methods. On Thu, 20 Mar 2014, Rik Cabanier wrote: > > addPath is currently defined on the Path2D object. [1] > Is there a reason why it's not defined on CanvasPathMethods instead? > That way this method is available on the 2d contest so you can append a > path to the current graphics state. What's the use case? On Thu, 20 Mar 2014, Dirk Schulze wrote: > > I am supportive for this idea! I agree that this would solve one of the > reasons why I came up with currentPath for WebKit in the first place. Can you elaborate on the reason for this? On Thu, 20 Mar 2014, Justin Novosad wrote: > > This would apply the CTM to the incoming path, correct? I am a little > bit concerned that this API could end up being used in ways that would > cancel some of the performance benefits (internal caching opportunities) > of Path2D objects. Right, that's why it's not currently on CanvasPathMethods. The idea is to make a clean break from the world where the transforms affect the building of the path. On Thu, 20 Mar 2014, Dirk Schulze wrote: > > Where is the difference to fill(Path2D), stroke(Path2D) and > clip(Path2D)? The path will always need to be transformed to the CTM. > Graphic libraries usually do this already for you. The addPath() > proposal is not different to that. The difference is that there, you only have one path with one transform, not different parts of the path built with different transforms. On Thu, 20 Mar 2014, Justin Novosad wrote: > > The recently added currentTransform attribute on > CanvasRenderingContext2D gives shared access to the rendering context's > transform. By "shared", I mean: > > a) this code modifies the CTM: > var matrix = context.currentTransform; > matrix.a = 2; > > b) In this code, the second line modifies matrix: > var matrix = context.currentTransform; > context.scale(2, 2); > > This behavior is probably not what most developers would expect. It's the behaviour that was requested by the pdf.js developers. :-) On Thu, 20 Mar 2014, Simon Sarris wrote: > > FF (at least Aurora/Nightlies) has for some time had mozCurrentTransform > (and mozCurrentTransformInverse), which return an Array (so not > spec-compliant, since spec wants SVGMatrix). It is not shared, so it > does not do what your a) and b) examples do. > > I agree that changing it to a getter method would be better, it would be > more intuitive and clear for developers. On Mon, 24 Mar 2014, Hwang, Dongseong wrote: > > Looking over this thread, we make a consensus not to expose > currentTransform attribute. Consensus is not how we decide things in the WHATWG. It's based on the strength of arguments. So far, it seems the arguments either way are about equal. On the one hand you have a developer asking for the current API. On the other hand you have implementors saying that the current API is bad for developers. What we need to make more progress, I think, is more concrete arguments, for example sample code that uses both APIs so we can see how authors would experience the two APIs in the real world. On Mon, 24 Mar 2014, Simon Sarris wrote: > > I think using "Current" in the naming convention is silly. The transform > just as much a part of state as lineWidth/etc, but nobody would propose > naming lineWidth something like currentLineWidth! There's no way to get > a *non-current* transformation matrix (or lineWidth), so I think the > distinction is unnecessary. > > CTM only seems like a good idea if we're worried that the name is too > long, but since "Current" is redundant/extraneous, I don't think an > initialism is worth the added layer of confusion. These are solid arguments if we agree that we should change the spec. On Sun, 23 Mar 2014, Dirk Schulze wrote: > > 1) I noticed that createImageData() is explicit that it represent a > transparent black rectangle. The constructor for ImageData is not that > explicit. Fixed. > 2) The last step of the 2nd constructor that takes an Uint8ClampedArray > says: " ? Return a new ImageData object whose width is sw, whose height > is height, and whose data is source.? > > Is data a reference to the original source or a copy of source? For the > former, there might be two ImageData objects referencing the same > ByteArray. How would that be useful? The steps say that the data is the Uint8ClampedArray "source". I've added a note making the fact that it's not a copy more explicit. On Mon, 24 Mar 2014, J?rg Lehni wrote: > > Non-scaling Strokes in Canvas. > > The request has come up multiple times on the paper.js mailing list [1], > and we will emulate this in JavaScript. > > But since this will involve baking the CTM into the path to be drawn, > and setting the CTM to the identity matrix, I was wondering if this is > something worth supporting natively for the obvious reason of improved > performance? You can do this with the new Path2D API, right? On Tue, 25 Mar 2014, Dirk Schulze wrote: > > [...] currentTransform [...] > what should be returned for a CTM that is singular (not invertible)? Even when the transform is not invertible, it's precise value is still well-defined, no? > In WebKit we do not track all transformations of the CTM that caused a > singular matrix or are following a transformation that would have caused > a singular matrix. > > Example: > > ctx.scale(0,0); > ct.translate(10,10); The matrix should be 0,0,0,0,0,0 here. It starts as 1 0 0 0 1 0 0 0 1 Then you apply a scale transform to 0,0: 1 0 0 0 0 0 0 0 0 0 1 0 x 0 0 0 = 0 0 0 0 0 1 0 0 1 0 0 1 Then you post-multiply that by the translation by 10,10: 1 0 0 0 0 0 1 0 10 0 0 0 0 1 0 x 0 0 0 x 0 1 10 = 0 0 0 0 0 1 0 0 1 0 0 1 0 0 1 ...and that's the matrix you should return. > In webkit we would not apply the transformation scale(0,0) and mark the > CTM as not-invertible instead. I do not believe this is an implementation strategy that can lead to a conforming implementation. Note that this is the same as what you would get if you did: var a = new SVGMatrix(1,0,0,1,0,0); // assuming this interface gets a constructor, anyway a = a.scale(0,0); a = a.translate(10,10); ...so this is not unique to the canvas API. On Tue, 25 Mar 2014, Justin Novosad wrote: > > I prepared a code change to that effect, but then there was talk of > changing the spec to skip path primitives when the CTM is not > invertible, which I think is a good idea. It would avoid a lot of > needless hoop jumping on the implementation side for supporting weird > edge cases that have little practical usefulness. I'm not sure I agree that they have little practical usefulness. Zeros often occur at the edges of transitions, and if we changed the spec then these transitions would require all the special-case code to go in author code instead of implementor code. On Sun, 30 Mar 2014, Dirk Schulze wrote: > > Canvas let you set alignment baselines with the textBaseline attribute > [1]. > > One of the baseline values is ?middle?. The description of the ?middle? > baseline seems to be in conflict with the definition for the > alignment-baseline property in CSS[2]. > > Canvas: The middle of the em square > CSS: [..] it may be computed using 1/2 the "x-height? > > What Canvas uses as middle is described as ?center? in CSS. Is there a > way that we can change the naming and/or definition of ?middle? in > Canvas? This seems like something that's too late to change. (I think using "middle" for what is between "top" and "bottom" makes eminent sense, though, so it doesn't seem like that big a problem.) On Mon, 31 Mar 2014, Justin Novosad wrote: > > Wow, that is confusing. How can this be fixed without breaking existing > web content? Are browsers currently compliant with the canvas spec, or > do they implement the CSS definition of middle? Looks like everyone does it per the canvas spec: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2924 The CSS 'vertical-align' property works per the CSS spec on the browsers I tested, too, FWIW: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2925 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Tue Apr 8 09:07:21 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 09:07:21 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDRtCREBBG5koWfR-PDv_=dJejfA-WOniSwygSD4YhhWg@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > So this is not how most implementations currently have it defined. > > > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > > definitely do store the path in user coordinates. The spec currently > > > > says otherwise [1] though. > > > > > > I'm not sure what you're referring to here. > > > > All graphics backends for canvas that I can inspect, don't apply the CTM > > to the current path when you call a painting operator. Instead, the path > > is passed as segments in the current CTM and the graphics library will > > apply the transform to the segments. > > Right. That's what the spec says too, for the current default path. No, the spec says this: For CanvasRenderingContext2D objects, the points passed to the methods, and the resulting lines added to current default path by these methods, must be transformed according to the current transformation matrix before being added to the path. > This is the confusing behaviour to which I was referring. The "Path" API > (or > Path2D or whatever we call it) doesn't have this problem. > That is correct. The Path2D object is in user space and can be passed directly to the graphics API (along with the CTM). > > > > Another use case is to allow authors to quickly migrate to hit > regions. > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); > > > > ... // lots of complex drawing operation for a control > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); > > > > > > > > > > > > To migrate that to a region (with my proposed shape interface [1]): > > > > > > > > var s = new Shape(); > > > > > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new > > > > Shape(ctx.currentPath)); > > > > ... > > > > ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new > > > > Shape(ctx.currentPath, ctx.currentDrawingStyle)); > > > > > > > > ctx.addHitRegion({shape: s, id: "control"}); > > > > > > Why not just add ctx.addHitRegion() calls after the fill and stroke > calls? > > > > That does not work as the second addHitRegion will remove the control and > > id from the first one. > > The 'add' operation is needed to get a union of the region shapes. > > Just use two different IDs with two different addHitRegion() calls. That's > a lot less complicated than having a whole new API. > That doesn't work if you want to have the same control for the 2 areas, from the spec for addHitRegion: If there is a previous region with this control, remove it from the scratch bitmap's hit region list; then, if it had a parent region, decrement that hit region's child count by one. Even if you don't use the control, it would be strange to have 2 separate hit regions for something that represents 1 object. > > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > ... > > > > copy, and would help memory consummation and performance. > > > > > > I don't really understand the use case here. > > > > Jurg was just talking about an optimization (so you don't have to make > > an internal copy) > > Sure, but that doesn't answer the question of what the use case is. > >From my recent experiments with porting canvg ( https://code.google.com/p/canvg/) to use Path2D, they have a routine that continually plays a path into the context which is called from a routine that does the fill, clip or stroke. Because that routine can't simply set the current path, a lot more changes were needed. Some pseudocode that shows the added complexity, without currentPath: function drawpath() { if(Path2DSupported) { return myPath; } else for(...) { ctx.moveTo/lineTo/... } } function fillpath() { var p = drawpath(); if(p) ctx.fill(p); else ctx.fill(); } with currentPath: function drawpath() { if(Path2DSupported) { // only 2 extra lines of code ctx.currentPath = myPath; } else for(...) { ctx.moveTo/lineTo/... } function fillpath() { drawpath(); ctx.fill(); } > On Wed, 12 Mar 2014, Rik Cabanier wrote: > > > > > > > > > > You can do unions and so forth with just paths, no need for > > > > > regions. > > > > > > > > How would you do a union with paths? If you mean that you can just > > > > aggregate the segments, sure but that doesn't seem very useful. > > > > > > You say, here are some paths, here are some fill rules, here are some > > > operations you should perform, now give me back a path that describes > > > the result given a particular fill rule. > > > > I think you're collapsing a couple of different concepts here: > > > > path + fillrule -> shape > > union of shapes -> shape > > shape can be converted to a path > > I'm saying "shape" is an unnecessary primitive. You can do it all with > paths. > > union of (path + fillrule)s -> path > No, that makes no sense. What would you get when combining a path with a fillrule and no fillrule? > > > A shape is just a path with a fill rule, essentially. > > > > So, a path can now have a fillrule? Sorry, that makes no sense. > > I'm saying a shape is just the combination of a fill rule and a path. The > path is just a path, the fill rule is just a fill rule. > After applying a fillrule, there is no longer a path. You can *convert* it back to a path that describes the outline of the shape if you want, but that is something different. The way you've defined things now, you can apply another fill rule on a path with a fill rule. What would the result of that be? > > > Anything you can do > > > with one you can do with the other. > > > > You can't add segments from one shape to another as shapes represent > > regions. > > Likewise, you can't union, intersect or xor path segments. > > But you can union, intersect, or xor lists of pairs of paths and > fillrules. > would you start throwing when doing these operations on paths without fill rules? > ... > > > > "Wrong" meaning: > > if the author has a bunch of geometry and wants to put it in 1 path > object > > so he can just execute 1 fill operation, he might be under the impression > > that "adding" the geometry will just work. > > Well, sure, an author might be under any number of false impressions. > > The API has a way for a bunch of paths to be merged with a single fillrule > to generate a new path with no crossing subpaths (which is also fillrule > agnostic), essentially giving you the union of the shapes represented by > those paths interpreted with that fillrule. > Is this the API you're referring to? path = new Path2D(paths [, fillRule ] ) The first argument could point to paths that need different winding rules so this won't work. What if one of the paths already had a fill rule? This doesn't seem implementable/stable. > There are very few use cases where you want to add partial path segments > > together but I agree that there are some cases that it's useful to have. > > I disagree that there few such cases. Pretty much any time you create a > path, you are adding partial path segments together. Whether you do so > using one Path object all at once or multiple Path objects that you later > add together is just a matter of programming style. > It's the multiple path objects use case that is unclear to me. Is there any tool/library that does this? Looking at Adobe's graphics applications, there isn't anything like it. Looking at graphics APIs, I don't see any calls that combine paths directly. hmm, it seems the spec has changed. It didn't used to start with "Create a new path that describes the edge of the areas" With the new wording, the last sentence should be updated: Subpaths in the newly created path must wind clockwise, regardless of the direction of paths in path. Since you now create 'holes', the separate paths need to be reoriented like you specify in other parts. > > > > > We seem to be going around in circles. We're in agreement that > > > > > eventually we should add APIs for combining paths such that we get > > > > > the equivalent of the union of their fill regions. I agree that > > > > > converting text into paths is non-trivial (lots of stuff browsers > > > > > do is non-trivial, that's kind of the point -- if it was trivial, > > > > > we could leave it for authors). But I don't see how we get from > > > > > there to you wanting the existing APIs removed. > > > > > > > > I want them removed because they will most likely not behave in the > > > > way that an author expects. When he "adds" 2 paths, he wouldn't > > > > expect that there is 'interference' between them. > > > > > > I don't see why not. It's exactly what happens today if you were to > > > just add the same path creation statements together into the current > > > default path and fill or stroke that. > > > > Sure but who does that? > > It's how all paths are built, as far as I can tell. I don't see how else > you could build a path that consists of more than one line. > > addPath() is useful for shifting a path according to a transform. > Why not just transform() then? addPathByStrokingPath() is for creating a stroked path. > addText() is for writing text. > > I don't see how removing any of them is a win. > Yes, they are useful. The issue is that they are not implementable as currently specified. > > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > ... > > > > > > > > How would you get a point? the width is scaled to 0. > > > > > > That's how you get a point -- scale(0,0) essentially reverts > > > everything to a zero dimensional point. > > > > OK, but the width of the point is also transformed to 0 so you get > > nothing. > > Points are always zero-width, by definition. > You can still stroke it though and get a point of the strokewidth. > > We've gone over this several times now. > > The APIs that you define, have use cases and I agree with them. > > However the way you defined those APIs does not make sense and will not > > give the result that authors want. > > The way to make this point would be to start from the use case, describe > the desired effect, show the "obvious" way to achieve this using the API, > and then demonstrate how it doesn't match the desired effect. > The obvious way is to go with Shape2D. It's not because I invented it; many advanced graphics APIs came offer this (including D2D and skia) > ... > > So, it's not realistic to add this to the Path2D object. > > I don't really see why it's unrealistic. In most cases, the user agent > doesn't actually have to do any work -- e.g. if all that you're doing is > merging two paths so that you can fill them simultaneously later, the UA > can just keep the two paths as is and, when necessary, fill them. > > For cases where you really want to have this effect -- e.g. when you want > to get the outline of the dashed outline of text -- then I don't really > see any way to work around it. > That is true. That is why I proposed to make the interface more limited for now until there is a time that this functionality is available. >From Ian Hickson: > I don't think the spec should be written with a particular > implementation in mind, nor should it dictate one. I agree it shouldn't (and doesn't) dictate one. But it's crazy to not consider implementations at all when writing a spec. That way lies madness like requiring O(N^2) algorithms and solving the halting problem and all kinds of other disasters (all of which I've seen in real proposals). > > The reason for that is that even though a UA could emulate the union by > > doing multiple fill operations, Path2D allows you to stroke another path > > object. At that point, you really have to do planarization. By defining > > a Shape2D object and not allowing it to be stroked, we can work around > > this. > > Sure, by limiting the feature set dramatically we can avoid the cases > where you have to do the hard work, but we also lose a bunch of features. > For now. They can be added later. Until then, this is confusing implementors. > > > I don't think the arguments for removing these are compelling. The > > > problems with the APIs have been addressed (e.g. there's no ambiguity > > > in the case of overlapping text), the use cases are clear (e.g. > > > drawing text around an arc or drawing a label along a line graph's > > > line), and the API now supports the constructs to do unions of fill > > > regions. > > > > Where is the union of fill regions specified? All I see is segments > > aggregation. > > One of the Path constructors takes an array of paths and a fill rule. > See above. > > > > No one has implemented them and they are confusing the browser > > > > vendors. > > > > > > I don't think they're confusing anyone. > > > > The blink people were looking at adding this until they thought it > > through and realized that it wouldn't work. > > Realised what wouldn't work? As far as I'm aware, there's nothing that > wouldn't work. > See this thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/168925.html I think you already addressed some of the concerns. Doing the planarization is now the problem so we can't implement this. > > > > Until we have support for shapes, the output of these methods won't > > > > be stable. > > > > > > These methods have been very stable. They have barely changed since > > > they were added, except for some minor tweaks to fix bugs. > > > > How can you make that statement? No one has implemented them yet. > > What do you mean by "stable"? > > I assumed you meant "hasn't been changing a lot". The spec hasn't been > changing a lot, so it seems pretty stable. > You've been making a lot of changes lately so this not quite true. Because you wrote it a long time ago and nobody looked at it until now, doesn't mean that it is stable. From junov at google.com Tue Apr 8 12:25:04 2014 From: junov at google.com (Justin Novosad) Date: Tue, 8 Apr 2014 15:25:04 -0400 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> On Mon, Apr 7, 2014 at 6:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > For example, there is no locale for font family resolution > > I'm not clear on what you mean by "locale" here. What is the locale that a > displayed <canvas> in a Document in a browsing context has, that a > non-displayed <canvas> outside a Document and without a browsing context > does not have? > I am not sure exactly how this relates to the specification, but when reading the code in Blink, I saw that font family resolution goes through different paths if the view has a Korean, Chinese or Japanese locale. Some OSes allow you to have different locales on a per window basis, so you need to have a view (i.e. a browsing context) associated with the Document in order to resolve this. > > and it is not possible to resolve font sizes in physical length units > > unless the document is associated with a view. > > Why not? The canvas has a pixel density (currently always 1:1), no? > 1:1 is not a physical pixel density. To resolve a font size that is specified in physical units (e.g. millimeters or inches) you need something like a DPI value, which requires information about the output device. > > > My 2 cents: specifying fallback behaviors for all use cases that are > > context dependent could be tedious and I have yet to see a real-world > > use case that requires being able to paint a canvas in a frame-less > > document. Therefore, I think the spec should clearly state <canvas> > > elements that are in a document without a browsing context are unusable. > > Not sure what the exact behavior should be though. Should an exception > > be thrown upon trying to use the rendering context? Perhaps canvas draws > > should fail silently, and using the canvas as an image source should > > give transparent black pixels? > > As far as I can tell, this is all already specified, and it just gets > treated like a normal canvas. > Agreed. The fallback behavior is specified. But is it good enough? There will be discrepancies, sometimes large ones, between text rendered with and without a browsing context. On Wed, 5 Mar 2014, Rik Cabanier wrote: > > > > Testing all browsers (except IE since > > document.implementation.createHTMLDocument() doesn't work) they seem to > > handle canvas contexts with no browsing context except when you use > > text. Chrome crashes, firefox throws an exception and Safari draws the > > text with a very small scale > > I don't really understand why this is problematic in practice. What does a > browsing context provide that is needed for rendering text that a user > agent couldn't fake for itself in other contexts? We're definitely going > to need text in worker canvases. > It is because the browsing context serves as a bridge between the document and the OS/window manager/display device. Therefore some of the system configuration info that comes into play in font style resolution and text rendering is not accessible when the document is not associated with a browsing context. For example to know which locale to use, the document needs to be linked to a window; to know the display density (dpi) we need to know which display device will be used for displaying the document; to use subpixel text anti-aliasing, we need to know the display device's LCD configuration; etc. If we fake this information by using fallbacks and defaults, we may end up with text that looks different when rendering in a Worker or into a Document without a browsing context. If we want everything to look the same, perhaps the spec should specify how to get to a browsing context that can be used for retrieving display settings. For example, if the current document has no browsing context, use the settings from the browsing context of the global 'document' object. That would probably match the developer's intent almost all the time. > > On Fri, 14 Mar 2014, Justin Novosad wrote: > > On Fri, Mar 14, 2014 at 2:29 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > If the bug is that Chrome resamples the image in an ugly way, then > > > that's a bug with Chrome. As the bug says, browsers are allowed to > > > pick whatever algorithm they want -- it's a quality-of-implementation > > > issue. But if the result is ugly, that's a low quality implementation. > > > > Yes, and if we fixed it to make it prettier, people would complain about > > a performance regression. It is impossible to make everyone happy right > > now. Would be nice to have some kind of speed versus quality hint. > > The problem with a hint is that it will be set incorrectly, and so instead > of having something that's mostly pretty but mostly fast for everyone, > you'd end up with something that's slow on sites that need things to be > fast, and things that are ugly on sites that need things to be pretty. > > In general I think it is very unwise for us to design APIs with hints that > have subtle effects on developer machines but that can cripple performance > on low-end devices. > The point of it being a hint is that the UA is free to disregarded it precisely in that kind of situation (e.g. fallback to fastest filtering on a low-end device) > Instead, we should use adaptive algorithms, for example always using the > prettiest algorithms unless we find that frame rate is suffering, and then > stepping down to faster algorithms. > Such an adaptive algorithm implies making some kind of weighted decision to chose a reasonable compromise between quality and performance. Sounds like the perfect place to use a hint. > > > On Mon, 17 Mar 2014, Justin Novosad wrote: > > > > Yes, but there is still an issue that causes problems in Blink/WebKit: > > because the canvas rendering context stores its path in local > > (untransformed) space, whenever the CTM changes, the path needs to be > > transformed to follow the new local spcae. This transform requires the > CTM > > to be invertible. So now webkit and blink have a bug that causes all > > previously recorded parts of the current path to be discarded when the > CTM > > becomes non-invertible (even if it is only temporarily non-invertible, > even > > if the current path is not even touched while the matrix is > > non-invertible). I have a fix in flight that fixes that problem in Blink > by > > storing the current path in transformed coordinates instead. I've had the > > fix on the back burner pending the outcome of this thread. > > Indeed. It's possible to pick implementation strategies that just can't be > compliant; we shouldn't change the spec every time any implementor happens > to make that kind of mistake, IMHO. > > (Of course the better long-term solution here is the Path objects, which > are transform-agnostic during building.) > > > Just to be clear, we should support this because otherwise the results are > just wrong. For example, here some browsers currently show a straight line > in the default state, and this causes the animation to look ugly in the > transition from the first frame to the secord frame (hover over the yellow > to begin the transition): > > http://junkyard.damowmow.com/538 > > Contrast this to the equivalent code with the transforms explicitly > multiplied into the coordinates: > > http://junkyard.damowmow.com/539 > > I don't see why we would want these to be different. From the author's > perspective, they're identical. If we stick to that, there are still some behaviors that need to resolved. One issue that comes to mind is what happens if stroke or fill are called while the CTM is non-invertible? To be more precise, how would the styles be mapped? If the fillStyle is collapsed to a point, does that mean the path gets filled in transparent black? If we go down this road, we will likely uncover more questions of this nature. > On Tue, 25 Mar 2014, Justin Novosad wrote: > > > > I prepared a code change to that effect, but then there was talk of > > changing the spec to skip path primitives when the CTM is not > > invertible, which I think is a good idea. It would avoid a lot of > > needless hoop jumping on the implementation side for supporting weird > > edge cases that have little practical usefulness. > > I'm not sure I agree that they have little practical usefulness. Zeros > often occur at the edges of transitions, and if we changed the spec then > these transitions would require all the special-case code to go in author > code instead of implementor code. > Yes, I think that may be the strongest argument so far in this discussion. The examples you provided earlier illustrate it well. I would like to hear what Rik and Dirk think about this now. From jackalmage at gmail.com Tue Apr 8 13:54:39 2014 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Tue, 8 Apr 2014 13:54:39 -0700 Subject: [whatwg] summary/details - proposal In-Reply-To: <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> Message-ID: <CAAWBYDCAr4C-fSYx9a_y=D3aZe0_9e_UOLo5yUJrk9TXs46Meg@mail.gmail.com> On Tue, Apr 8, 2014 at 5:25 AM, Steve Faulkner <faulkner.steve at gmail.com> wrote: > avoiding unnecessary recourse to web component use is a reasonable and > expected goal - built in vs bolt on accessibility is better. Having to use > a web component to overcome the inability to make a html control usable > without relying on CSS and Js and ARIA is unfortunate, and as you said > yesterday I still don't understand. Do you think that what Hixie is saying (about clicking on non-interactive text in <summary> toggling the <details>) is wrong? The behavior that Hixie describes is roughly what implementations do today. In Blink, clicking on any bare text in the <summary> toggles the <details>, while clicking on an <input> does not. However, Blink current behavior with <label> is different - it basically ignores the presence of the <label>, as far as I can tell, and still toggles the <details> even if the <label> is redirecting the click to an <input>. I would strongly object to any suggestion that <summary> should only toggle <details> when you click on the disclosure triangle, unless you add some additional markup like <label>. That would be terrible UI. ~TJ From cabanier at gmail.com Tue Apr 8 15:10:09 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 15:10:09 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> Message-ID: <CAGN7qDDJKmx1T9_8cu--T7mAUy2uucTde+S6atnJTBe7baBQRg@mail.gmail.com> On Tue, Apr 8, 2014 at 12:25 PM, Justin Novosad <junov at google.com> wrote: > > > > > On Mon, 17 Mar 2014, Justin Novosad wrote: > > > > > > Yes, but there is still an issue that causes problems in Blink/WebKit: > > > because the canvas rendering context stores its path in local > > > (untransformed) space, whenever the CTM changes, the path needs to be > > > transformed to follow the new local spcae. This transform requires the > > CTM > > > to be invertible. So now webkit and blink have a bug that causes all > > > previously recorded parts of the current path to be discarded when the > > CTM > > > becomes non-invertible (even if it is only temporarily non-invertible, > > even > > > if the current path is not even touched while the matrix is > > > non-invertible). I have a fix in flight that fixes that problem in > Blink > > by > > > storing the current path in transformed coordinates instead. I've had > the > > > fix on the back burner pending the outcome of this thread. > > > > Indeed. It's possible to pick implementation strategies that just can't > be > > compliant; we shouldn't change the spec every time any implementor > happens > > to make that kind of mistake, IMHO. > > > > (Of course the better long-term solution here is the Path objects, which > > are transform-agnostic during building.) > > > > > > Just to be clear, we should support this because otherwise the results > are > > just wrong. For example, here some browsers currently show a straight > line > > in the default state, and this causes the animation to look ugly in the > > transition from the first frame to the secord frame (hover over the > yellow > > to begin the transition): > > > > http://junkyard.damowmow.com/538 > > > > Contrast this to the equivalent code with the transforms explicitly > > multiplied into the coordinates: > > > > http://junkyard.damowmow.com/539 > > > > I don't see why we would want these to be different. From the author's > > perspective, they're identical. > These examples are pretty far fetched. How many time do people change the CTM in the middle of a drawing operation and not change the geometry? If we stick to that, there are still some behaviors that need to resolved. > One issue that comes to mind is what happens if stroke or fill are called > while the CTM is non-invertible? To be more precise, how would the styles > be mapped? If the fillStyle is collapsed to a point, does that mean the > path gets filled in transparent black? If we go down this road, we will > likely uncover more questions of this nature. Indeed > > On Tue, 25 Mar 2014, Justin Novosad wrote: > > > > > > I prepared a code change to that effect, but then there was talk of > > > changing the spec to skip path primitives when the CTM is not > > > invertible, which I think is a good idea. It would avoid a lot of > > > needless hoop jumping on the implementation side for supporting weird > > > edge cases that have little practical usefulness. > > > > I'm not sure I agree that they have little practical usefulness. Zeros > > often occur at the edges of transitions, and if we changed the spec then > > these transitions would require all the special-case code to go in author > > code instead of implementor code. > > > > Yes, I think that may be the strongest argument so far in this discussion. > The examples you provided earlier illustrate it well. > I would like to hear what Rik and Dirk think about this now. > I looked at the webkit and chrome bug databases and I haven't found anyone who complained about their current behavior. Implementing this consistently will either add a bunch of special case code to deal with non-singular matrices or double (triple?) conversion of all segment points like firefox does. After that, fill, stroke and clip will still not work when there's a non-invertible matrix. I do not think it's worth the effort... From cabanier at gmail.com Tue Apr 8 16:50:48 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 16:50:48 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> Message-ID: <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > ... > > > > > Stroking will be completely wrong too, because joins and end caps > > > > are drawn separately, so they would be stroked as separate paths. > > > > This will not give you the effect of a double-stroked path. > > > > > > I don't understand why you think joins and end caps are drawn > > > separately. That is not what the spec requires. > > > > Sure it does, for instance from > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path > > : > > > > The round value means that a filled arc connecting the two > > aforementioned corners of the join, abutting (and not overlapping) the > > aforementioned triangle, with the diameter equal to the line width and > > the origin at the point of the join, must be added at joins. > > > > If you mean, "drawn with a separate fill call", yes that is true. > > What I meant was that they are drawn as a separate closed path that will > > interact with other paths as soon as there are different winding rules or > > "holes". > > The word "filled" is a bit misleading here (I've removed it), but I don't > see why that led you to the conclusion you reached. The step in question > begins with "Create a new path that describes the edge of the areas that > would be covered if a straight line of length equal to the styles > lineWidth was swept along each path in path while being kept at an angle > such that the line is orthogonal to the path being swept, replacing each > point with the end cap necessary to satisfy the styles lineCap attribute > as described previously and elaborated below, and replacing each join with > the join necessary to satisfy the styles lineJoin type, as defined below", > which seems pretty unambiguous. > Thinking about this some more, it looks like you came around and specified stroking like I requested from the beginning. For instance, http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0354.html or http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0213.html Now that you made that change, 'addPathByStrokingPath' is specified correctly. I still don't know how it could be implemented though... (It *could* as a shape but not as a path) From cabanier at gmail.com Tue Apr 8 17:17:39 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 8 Apr 2014 17:17:39 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> <CAGN7qDDpGt41MCT35ieQvBij1xUcLgXCe1NPv-uV6DSCDvCjBQ@mail.gmail.com> Message-ID: <CAGN7qDBfO_7katfwHTX+CT_HgRcEuq3AL7544y+YTJU54HbahQ@mail.gmail.com> On Tue, Apr 8, 2014 at 4:50 PM, Rik Cabanier <cabanier at gmail.com> wrote: > > > > On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > >> ... >> >> >> > > > Stroking will be completely wrong too, because joins and end caps >> > > > are drawn separately, so they would be stroked as separate paths. >> > > > This will not give you the effect of a double-stroked path. >> > > >> > > I don't understand why you think joins and end caps are drawn >> > > separately. That is not what the spec requires. >> > >> > Sure it does, for instance from >> > >> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path >> > : >> > >> > The round value means that a filled arc connecting the two >> > aforementioned corners of the join, abutting (and not overlapping) the >> > aforementioned triangle, with the diameter equal to the line width and >> > the origin at the point of the join, must be added at joins. >> > >> > If you mean, "drawn with a separate fill call", yes that is true. >> > What I meant was that they are drawn as a separate closed path that will >> > interact with other paths as soon as there are different winding rules >> or >> > "holes". >> >> The word "filled" is a bit misleading here (I've removed it), but I don't >> see why that led you to the conclusion you reached. The step in question >> begins with "Create a new path that describes the edge of the areas that >> would be covered if a straight line of length equal to the styles >> lineWidth was swept along each path in path while being kept at an angle >> such that the line is orthogonal to the path being swept, replacing each >> point with the end cap necessary to satisfy the styles lineCap attribute >> as described previously and elaborated below, and replacing each join with >> the join necessary to satisfy the styles lineJoin type, as defined below", >> which seems pretty unambiguous. >> > > Thinking about this some more, it looks like you came around and specified > stroking like I requested from the beginning. > For instance, > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0354.html > or > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0213.html > Now that you made that change, 'addPathByStrokingPath' is specified > correctly. I still don't know how it could be implemented though... (It > *could* as a shape but not as a path) > The spec is still confusingly written and could be misinterpreted: Create a new path that describes the edge of the areas that would be covered if a straight line of length equal to the styles lineWidth was swept along each subpath in path while being kept at an angle such that the line is orthogonal to the path being swept, replacing each point with the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, and replacing each join with the join necessary to satisfy the styles lineJoin type, as defined below. Maybe could become: Create a new path that describes the edge of the coverage of the following areas: - a straight line of length equal to the styles lineWidth that was swept along each subpath in path while being kept at an angle such that the line is orthogonal to the path being swept, - the end cap necessary to satisfy the styles lineCap attribute as described previously and elaborated below, - the join with the join necessary to satisfy the styles lineJoin type, as defined below. From junov at google.com Wed Apr 9 07:14:42 2014 From: junov at google.com (Justin Novosad) Date: Wed, 9 Apr 2014 10:14:42 -0400 Subject: [whatwg] <canvas> feedback In-Reply-To: <CAGN7qDDJKmx1T9_8cu--T7mAUy2uucTde+S6atnJTBe7baBQRg@mail.gmail.com> References: <8B436330-DB08-4DDB-A32A-DEE64D86A102@adobe.com> <CABpaAqS4DEnYJ3okeCAQgsb3bX5Q3OTtamTXh-kkei3y12DAZQ@mail.gmail.com> <alpine.DEB.2.00.1404022111350.11249@ps20323.dreamhostps.com> <CABpaAqSKi2m0SDU-Qq9EvgbDz3kXXrF5HXeYm6t_SJotX4MtPg@mail.gmail.com> <CAGN7qDDJKmx1T9_8cu--T7mAUy2uucTde+S6atnJTBe7baBQRg@mail.gmail.com> Message-ID: <CABpaAqSfmKu2mkeZg39Nn_OeOaSWdW0ZwvGuhq0+jiYWq_v0PQ@mail.gmail.com> On Tue, Apr 8, 2014 at 6:10 PM, Rik Cabanier <cabanier at gmail.com> wrote: > > > On Tue, 25 Mar 2014, Justin Novosad wrote: >> > > >> > > I prepared a code change to that effect, but then there was talk of >> > > changing the spec to skip path primitives when the CTM is not >> > > invertible, which I think is a good idea. It would avoid a lot of >> > > needless hoop jumping on the implementation side for supporting weird >> > > edge cases that have little practical usefulness. >> > >> > I'm not sure I agree that they have little practical usefulness. Zeros >> > often occur at the edges of transitions, and if we changed the spec then >> > these transitions would require all the special-case code to go in >> author >> > code instead of implementor code. >> > >> >> Yes, I think that may be the strongest argument so far in this discussion. >> The examples you provided earlier illustrate it well. >> I would like to hear what Rik and Dirk think about this now. >> > > I looked at the webkit and chrome bug databases and I haven't found anyone > who complained about their current behavior. > Implementing this consistently will either add a bunch of special case > code to deal with non-singular matrices or double (triple?) conversion of > all segment points like firefox does. After that, fill, stroke and clip > will still not work when there's a non-invertible matrix. > > I do not think it's worth the effort... > If I did not feel bad about using laziness as an argument, I might agree. :-) From fantasai.lists at inkedblade.net Wed Apr 9 13:48:52 2014 From: fantasai.lists at inkedblade.net (fantasai) Date: Wed, 09 Apr 2014 13:48:52 -0700 Subject: [whatwg] [CSSWG][css-scoping] CSS Scoping FPWD Published Message-ID: <5345B234.2020603@inkedblade.net> The CSS WG has published a First Public Working Draft of the CSS Scoping Module Level 1: http://www.w3.org/TR/css-scoping-1/ This specification defines various scoping/encapsulation mechanisms for CSS, including scoped styles and the @scope rule, Shadow DOM selectors, and page/region-based styling. It is an early-stage working draft, and the features described therein are not well-baked and may change dramatically or be removed. The CSSWG encourages comments on both design and details of these features. Please send any comments to this mailing list, <www-style at w3.org>, and please, prefix the subject line with [css-scoping] (as I did on this message). For the CSS WG, ~fantasai From faulkner.steve at gmail.com Thu Apr 10 08:49:55 2014 From: faulkner.steve at gmail.com (Steve Faulkner) Date: Thu, 10 Apr 2014 16:49:55 +0100 Subject: [whatwg] summary/details - proposal In-Reply-To: <CAAWBYDCAr4C-fSYx9a_y=D3aZe0_9e_UOLo5yUJrk9TXs46Meg@mail.gmail.com> References: <CA+ri+Vkm8u-9_d0VfPH0DzrjFX=2Co0SNx=6PF63MDwSjizy2g@mail.gmail.com> <alpine.DEB.2.00.1404060407130.21310@ps20323.dreamhostps.com> <CA+ri+Vnaqr=YG7m8ACMCDxzNOeUAezv_n60CO0A71P-BEtAGnQ@mail.gmail.com> <alpine.DEB.2.00.1404061959000.21310@ps20323.dreamhostps.com> <CA+ri+V=L2zFSrr3RWwdSD1Vh3fjz3SiUQvh9ucYTayRn=LczpA@mail.gmail.com> <alpine.DEB.2.00.1404071857200.21310@ps20323.dreamhostps.com> <CA+ri+VndCh9DK=DRQudSX5mJ5rKEP82XXYZU5ZO33CFY+PprWA@mail.gmail.com> <CAAWBYDCAr4C-fSYx9a_y=D3aZe0_9e_UOLo5yUJrk9TXs46Meg@mail.gmail.com> Message-ID: <CA+ri+V=3xcOHhnxO=q9UVaNhg4UU4w3QmhjZXjkCHjOAHVN5WA@mail.gmail.com> On 8 April 2014 21:54, Tab Atkins Jr. <jackalmage at gmail.com> wrote: > I still don't understand. Do you think that what Hixie is saying > (about clicking on non-interactive text in <summary> toggling the > <details>) is wrong? > nope. > > The behavior that Hixie describes is roughly what implementations do > today. In Blink, clicking on any bare text in the <summary> toggles > the <details>, while clicking on an <input> does not. However, Blink > current behavior with <label> is different - it basically ignores the > presence of the <label>, as far as I can tell, and still toggles the > <details> even if the <label> is redirecting the click to an <input>. > Implementations today have the summary element as the focusable/interactive element. this has several pros/cons what I am trying to achieve is to have the pros defined as part of the feature. I would strongly object to any suggestion that <summary> should only > toggle <details> when you click on the disclosure triangle, > I cannot agree more, which is why I have brought up the issue here and elsewhere. Hixie talks about platform conventions and UAs deciding, and as I have pointed out several times the OSX platform convention is just what you describe. and as you say "would be terrible UI." unless you > add some additional markup like <label>. That would be terrible UI. > I would prefer that the summary element acted as the label the disclosure triangle of the details element, thus providing a reasonable default click area and focus are and source for the accessible name of the control. I see a few issues, which is why I have suggested allowing the use of <label> (to provide both a clickable area that can be assigned by the author and provide an explicit method to assign an accessible name) 1. When the summary element also includes links or other controls each with their own accessible name, providing an unambiguous accessible name for the disclosure triangle becomes problematic. 2. I have observed that assigning an accessible name for a control in the shadow DOM from the DOM is not possible. Thus my question to the list/hixie: "What's the mechanism by which the anonymous control for details can be assigned an accessible name?" -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> From ian at hixie.ch Thu Apr 10 13:49:49 2014 From: ian at hixie.ch (Ian Hickson) Date: Thu, 10 Apr 2014 20:49:49 +0000 (UTC) Subject: [whatwg] <input type=number> for year input In-Reply-To: <87zjl0cy02.fsf@dieweltistgarnichtso.net> References: <5303E843.4010403@jwatt.org> <8761nptdfp.fsf@dieweltistgarnichtso.net> <001b01cf3afd$94f980b0$beec8210$@net> <87zjl0cy02.fsf@dieweltistgarnichtso.net> Message-ID: <alpine.DEB.2.00.1404101715001.6826@ps20323.dreamhostps.com> On Wed, 19 Feb 2014, Michael[tm] Smith wrote: > Ian Hickson <ian at hixie.ch>, 2014-02-18 23:59 +0000: > > On Tue, 18 Feb 2014, Jonathan Watt wrote: > > > > > > I wonder if it would be that bad to have a 'year' type to compliment > > > the 'month' and 'day' types... > > > > This has come up a few times, but so far the use cases have not been > > compelling enough. This is probably the most compelling use case, but > > even here, I don't know that it's that compelling. > > > > I would be interested in hearing more about the locales where not > > using separators even for four digits is bad/suboptimal. If it wasn't > > for those, I would say that just not using separators for four-digit > > numbers would be an easy and effective solution. > > The following info seems relevant - > > http://www.thepunctuationguide.com/comma.html#numbers > "Most authorities, including The Associated Press Stylebook and The Chicago > Manual of Style, recommend a comma after the first digit of a four-digit > number. The exceptions include years, page numbers, and street addresses." > > To me that appears to be a strong argument that formatting of years is > in fact clearly an exception, and that's compelling enough to warrant > having a type for them separate from the normal number type (in which > four-digit numbers would instead have a separator, to follow existing > longstanding conventions). Interesting. For street addresses, we are moving in the direction of larger fields not smaller fields, so I'm not too worried about that use case. (I do know one form that looks just for a street address number, but presumably it has to handle non-numeric data anyway, as in "23A".) If that left just page numbers, I'd probably ignore it, since the use cases are pretty limited there. But years are clearly a major use case. Doing further research along these lines, it seems that it's specifically page numbers and years _that are four digits long_ that are at issue, when it comes to English: | MLA style is to use a comma in four-digit numbers except in page | numbers, line numbers, addresses, and years, unless the year has more | than four digits, such as 10,000 BCE. -- http://www.esc.edu/online-writing-center/resources/punctuation/commas/ Though some people say that applies to more than just years and page numbers: | Use commas to separate groups of 3 numbers in numbers of 5 digits or | more unless decimals are used. The comma in a 4-digit number may be | omitted. -- http://mtdesk.com/Numbers However, in other languages, as Karl showed, the pattern is different. As I see it, we have two possible paths: 1. We consider this a stylistic issue, and we add something to CSS to make it possible to control the formatting of numbers in <input type=number>. Then, someone doing a page-number control in English can use CSS to make it not include commas in four-digit numbers but include numbers otherwise, and so forth. 2. We consider this a semantic issue, and we add one or more new input types to handle the new smenatics. For example, we add type=year and type=page-number. We can also follow a combinations of both, providing a new control for the cases that need more than just style, and providing style for the cases that are just presentational. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: > > The point is that year numbers aren't really "numbers" in a normal > sense, any more than car plate numbers, credit card numbers, product > numbers, or social security numbers are. Surely they can be regarded as > numbers, but so can car plate numbers and the others. On Wed, 19 Feb 2014, Smylers wrote: > > Except that years do actually form a sequence, and it's possible to > perform maths on them; for instances, subtracting one year from another > yields a duration, which is a meaningful quantity, whereas subtracting a > couple of credit card numbers is completely useless. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: > > Mathematically, you are right, but input types aren't based on general > properties of quantities but on practical classification of input data. > All the examples I gave, including year numbers, are normally input by > typing the digits - in contrast with, say, using a color picker, a data > picker, or a slider. Your annual income, when enterested into an electronic tax form, is usually "input by typing the digits", but it's definitely a number. I think the only way, in western locales, that years differ from other numbers is with respect to formatting, and that's not unique to years, as Mike pointed out (c.f. page numbers). On Wed, 19 Feb 2014, Smylers wrote: > > There are situations where up/down arrows makes sense on years. For > instance, a chart of various baby names could have a box for the year > currently being displayed, and it's handy to be able to nudge that along > by a year at a time to see it change, without having to manually retype > the year. Or when displaying one year's tax return, with the ability to > display other years' returns ? with adjacent years being likely options. Indeed. This is why so far we haven't included a type=year control: type=number, semantically, is the right control. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: > > And year numbers differ, as mentioned, from normal numbers as regards to > conventional formats (e.g., 2014 vs. 2,014 or 2'014 or 2 014 or...). But as noted above, this is not unique to years. Indeed in some locales, it's all numbers with four digits; in others it's also page numbers and street addresses. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: > > What else could <input type=year> be other than reading some digits? This is an interesting question. If the answer is "nothing", then type=number with styling hints is the right answer for addressing the "no commas in years" problem. But if the answer is "in some locales, years are completely different", then we have a semantic on our hands. On Fri, 7 Mar 2014, Ryosuke Niwa wrote: > > Let me point out that not every calendar uses simple 2-4 digit numbers > to denote years. > > The Japanese era name calendar system, for example, requires an era name > such as Showa and Heisei associated with each year. > > For example, I was born in Gregorian year 1986 but any Japanese > government document would say I was born in Showa 61. My brother was > born in 1989 but, again, he must write "Heisei 1" instead on any > government form. > > There are also even quite few banks and other organizations in Japan > that use the era name system for various forms and documents. This is a pretty strong argument for a type=date feature, in principle. However: Some eras start mid-way through a year. For example, Meiji 45 lasts until July 30th 1912, and Taish? 1 starts then. Without date context, how would such values get round-tripped? If we assume a hypothetical type=year displays Japanese era years in the UI, but transmits Gregorian years over the wire, how do we ensure that the same year comes back? If round-tripping is important, then this is actually a _different_ input type than Gregorian years. Presumably, round-tripping is important here. For example, I would presume that the sentence "Emperor Meiji said 'Hello' in Meiji 45" has rather different connotations than "Emperor Meiji said 'Hello' in Taish? 1". On Tue, 11 Mar 2014, Smylers wrote: > > [..] But if <input?type=year> isn't otherwise useful, there may be a > more generic way of addressing the ?no commas in 4-digit years? issue > which also addresses 4-digit page numbers (and the like). Indeed. On Tue, 11 Mar 2014, Ryosuke Niwa wrote: > > This is why iOS allows users to pick either representation instead of > always using either based on locale. How does iOS handle the round-tripping issue? On Tue, 11 Mar 2014, Smylers wrote: > > It follows that any site which wants a year for any purpose and has a > Japanese audience would therefore benefit from a year widget which also > offers both Gregorian and Japanese ways of specifying a year. > > I could find such sites in English, and hypothesize that equivalent > Japanese sites would also exist. But in terms of providing requirements > to the HTML spec, it'd be better to have examples of actual sites, not > mere hypothetical ones. Indeed. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: > > And what about page numbers and street addresses (and other exceptions)? > If we have <input type=year>, then it would be rather odd to use it for > reading a page number. > > Most importantly, though, this would introduce yet another value for the > type attribute for something that can well be handled with existing > tools: <input pattern=\d{4}>. It is improbable that any year selection > widget would be useful. Years are normally best entered by typing them. The pattern="" attribute is about the wire format constraints, not about the display format. They are orthogonal issues. I think trying to reuse pattern="" in the context of numeric formatting is not a winning strategy. > On the other hand, as this is about input, not output, a simple > additional rule (which has other usability benefits, too) would solve > the issue, too: User agents may allow locale-specific group separators > in a number (e.g., ?1,500? when the locale is English), but they shall > accept a number without group separators, too (e.g., ?1500?, in any > locale). The problem is what the display should be, not what input should be accepted. One would not want this: <label> Year: <input type=number value="2014"> </label> ...to render, in an English context, as: Year: [ 2,014 ] On Wed, 19 Feb 2014, Nils Dagsson Moskopp wrote: > > Some calendars do have an integer offset to the gregorian calendar, > allowing localization. If I understand the Wikipedia pages correctly, to > get the year in the Thai solar calendar one has to add 543 to the ISO > year and for both the Republic of China calendar and North Korean > calendar one has to substract 1911. > > <http://en.wikipedia.org/wiki/Thai_solar_calendar> > <http://en.wikipedia.org/wiki/North_Korean_calendar> > <http://en.wikipedia.org/wiki/Minguo_calendar> These appear to all map cleanly to Gregorian years, which increases the argument for a type=year control. > Interface-wise, a dialog for <input type=year> without a value might > focus the current year initially ? I would consider that a usability > boon. Year selection dialogs do already exist: > <http://www.yuiblog.com/blog/2009/04/03/multi-layer-calendar/> > <http://msdn.microsoft.com/en-us/library/windows/desktop/bb760913(v=vs.85).aspx#SELECT_DIFF_YEAR> It's a pity those are Western only, it would have been interesting to see how they handled the overlap issues with Japanese eras. > Consider the following grouping of <input type=number>: > > [ 210 000 ] [+|-] > [ 19 250 ] [+|-] > [ 1 500 ] [+|-] This is a strong argument for not special-casing four-digit numbers. It looks like there's some demand for type=year; I've filed a bug to track implementor interest: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25315 It also looks like it would be good to have a way to style input controls, in particular <input type=number>, to use specific kinds of formatting. This is somewhat out of scope for HTML; I recommend developing a CSS feature for this purpose in conjunction with browser vendors, if anyone is interested in pursuing this. I've abandoned the idea of making the spec suggest that four-digit numbers should not have separators. On Wed, 19 Feb 2014, Nils Dagsson Moskopp wrote: > > I hereby ? only half-jokingly ? propose a @unit-type attribute for both > <input type=number> and <input type=range>, which conveys what the given > number represents. Thee @unit-type attribute can have the values ?K", > "s", "m", "kg", "cd", "A" and "mol" to enable hints for the seven SI > base units. A microsyntax using the tokens ?(?, ?)?, "+", "-", "*", "/" > and "^" could be used to specify derived units. User agents would be > encouraged to localized the displayed data. What problem is this solving? > Example for <input> element on a cooking form: > > <label>temperature <input type=number unit-type="K" value=453.15></label> > <label>cooking time <input type=number unit-type="s" value=900></label> > <label>beep frequency <input type=range unit-type="1/s" value=1></label> > > A user agent could display this ? localized ? as follows: > > temperature [ 180 ?C ][+|-] > cooking time [ 15 min ][+|-] > beep frequency [ each second ][+|-] > > The @unit-type attribute could also provide useful when allowed on the > <data>, <var>, <output> and <meter> elements. Mark my words. Is this something that has real author demand? What pages are working around the lack of this feature today? On Thu, 20 Feb 2014, Qebui Nehebkau wrote: > > When I first read this, I considered it unnecessary complexity. On > reflection, though, I find that I kind of like it. Perhaps it should be > allowed for <data> as well? Of course, I'm not sure that anyone would > really use it in practice. If no-one would use it... On Sat, 8 Mar 2014, David Dailey wrote: > > I think there are two interesting questions here: 1. What is a number? > A magnitude, an ordinal value (obeying the transitive property), a > rotational value (like day of year, degrees, day of week), an interval > value, a nominal labeling (take the SS Stevens taxonomy and add > rotational [1])? In the context of <input type=number>, a number is something for which it makes sense to have a up/down buttons. > 2. What sort of interface is best used to elicit a numerical response > from a person? We often assume that the human will type such a thing, > though for small n, radios and even selects work okay. Can a widget be > developed called a "throttle" which allows the user to use a joystick to > accelerate through an ordinal collection of n ordinal values (for large > n>10000) and to pick a number more quickly using the throttle than by > using the keyboard? Since the words of an alphabetic language have a > natural ordering (imposed by alphabetization) are not words numeric, and > cannot a throttle be used more effectively than a keyboard? That's up to the browser. On Tue, 18 Feb 2014, David Dailey wrote: > > <input > [magnitude|quantity|quality|time|thing|person|place|action|epistemic|quantif > ier|URI|anaphora|mediatype|direction|influence|...]=attribute-value-expressi > on-with-micro-syntax> > > with all appropriate cross-cultural studies underlying each > attribute-value. > > I am reminded of the Navajo verb system, in which epistemic values > (certainty), influence (transitive/intransitive), deixis > (this/that/yonder), and quantifiers (unique, none, all, some) are not > strictly orthogonal. Nle`i dzilh bits'i`i d'shighan : the unique and > well-known hill over yonder, beyond it there is my house. Were the hill > or the direction not well known, then it might be expressed differently > (as I seem to recall). It's maybe a bad example since bits'i`i could be > viewed as a preposition, but heck, it's been decades since I had a > Navajo-speaking hitchhiker in my car (and we seemed never to agree on > etymology)! > > What sorts of things might people want to say to us as web-folk? Are not > those all the possible types of input? I'm not sure I follow what you are asking here. On Tue, 18 Feb 2014, David Dailey wrote: > > Thanks to jwatt for raising the issue and to Karl for casting it in the > context that I presume jwatt was intending it to be cast. > > It reminds me of the early discussions, circa 2007 on > whatwg/public-html, of what exactly was meant by 'semantics'. Is it > merely HTML or is it meaning? > > In a cross-cultural sense, do we really expect that <p> and <aside> and > <quote> and <grid> and <section> and all the other things (that > HTML5.5555555... might ultimately asymptote with itself to include) are > inclusive of the ways that cultures, the world wide, might choose to > partition their discourse, into tags, elements, and taxonomies, replete > with meaning, context, style and behavior? > > Perhaps at the core of human expression is the <idea> and until we > respect one another for that core expression, distinctions between > semantics, behavior, presentation and context are askew, or at least > un-worldwidish. HTML7 should be radically different than HTML5: a new > prime number requires new thinking and new participation and perhaps, > even, reinvention at the expense of a broken wheel or two. I don't understand what you are proposing here, but it's worth noting that (a) "5" is also prime, and (b) we've dropped the number entirely. For further discussion on the issue of reinvention, I recommend this post: https://plus.google.com/+IanHickson/posts/SiLdNL9MsFw -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From estade at chromium.org Fri Apr 11 11:19:27 2014 From: estade at chromium.org (Evan Stade) Date: Fri, 11 Apr 2014 11:19:27 -0700 Subject: [whatwg] Additional details for invoking requestAutocomplete In-Reply-To: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> Message-ID: <CAO4XGS-iAaBRtV-3QW7xY4u4gh2bYgMURtg8gv_EmtoxwYKyhA@mail.gmail.com> Perhaps now is a more appropriate time for this discussion, given that requestAutocomplete is now published in the spec (!). -- Evan Stade On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade <estade at chromium.org> wrote: > Hi WhatWG. > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=?cc-number? the browser might provide an experience tailored > for a payment flow, or if there?s an element with autocomplete=?bday? the > browser might use an experience that?s tailored for sharing identiy. > > We?ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element.requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: ?transactionAmount? > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: ?transactionCurrency? > value: string > description: a valid ISO 4217 currency code that describes the > currency for transactionAmount. If not provided, the default is ?USD?. > > Justification? There are upper bounds on certain payment instruments, for > example different credit cards have different credit limits; a debit card > is linked to a bank account with a certain balance. It?s a much preferable > user experience to be able to catch these problems earlier rather than > waiting for the merchant to attempt the transaction and have it fail (or > have a user?s account overdrawn). Concretely, Chromium wants to handle > transactions over $2000 differently from transactions under that amount. > > Does this seem reasonable? > > > -- Evan Stade > From eoconnor at apple.com Fri Apr 11 15:36:41 2014 From: eoconnor at apple.com (Edward O'Connor) Date: Fri, 11 Apr 2014 15:36:41 -0700 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> Message-ID: <m2k3av5w92.fsf@apple.com> Hi, Ian wrote: > Is there any reason to have two fields here, why not just "new" both > times? That works for me. Browsers can supply the same value for multiple autocomplete=new-password fields in the same form. > Also, should we have an "old" field for the old password, or is the > lack of an autofill field sufficient? I think it makes sense to have an old/current password token, for change password forms. It also helps to distinguish sign up forms from sign in forms, as Mike mentioned in the bug. > I've filed a bug to track this: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25236 > > It needs multiple vendors on board to make progress. [?] > I've filed a bug to track this: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25237 > > It needs multiple vendors on board to make progress. Chrome has also expressed interest on both of these bugs. >> Also, consider the case of login forms without username fields. You >> see this sort of thing a lot these days, when sites remember who was >> last logged in: >> >> <form> >> <label>Password for hober: <input type=password name=pw></label> >> <p>Not hober? <a href=...>Click here to sign in</a>. >> </form> >> >> It's difficult for tools to manage the user's auth info for such >> pages. How can tools discover what the username is? The obvious >> solution, in a world with autocomplete=username, would be to add >> <input type=hidden autocomplete=username name=username value=hober> >> to the form. > > So far, autocomplete="" hasn't applied to <input type=hidden>. This > would be a bit weird, giving it a different meaning than usual > (providing information to the UA, rather than getting information from > the UA). I'm a bit skeptical of this kind of overloading. It is kind of weird. Given that, maybe this case should have new syntax. I'm OK with overloading autocomplete=username or with new syntax. I don't have a particular color to suggest for the bikeshed. > For the real submission case, I guess what we want is a way to say > "autocomplete=off" after the fact, basically. An HTTP header seems > like the most obvious solution. > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 > > Again, these need multiple vendors on board to make progress. Browsers are moving away from respecting autocomplete=off. I don't think we should be adding a new but basically equivalent mechanism. > I actually have a similar problem with purely JS-handled forms even > unrelated to credentials. Because the form is never really submitted > (even if we reuse the submit infrastructure, we cancel the 'submit' > event and handle the work on the JS side), there's never an indication > to the UA that it should save the fields, and so autofill never works > right on these forms, even for things like postal addresses or e-mail > addresses. > > For the pure JS case, an API (probably on the <form> itself) would > make sense and seems relatively easy. I've filed a bug on this: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 This case is pretty weird. Authors are going out of their way to avoid using the built in platform features that would get them autofill saving for free. In some cases, they might be doing this precisely because they want to prevent autofill but can't count on autocomplete=off anymore. > The requestAutocomplete() API is a Chrome proprietary feature right > now so it's sort of acadmic, but: > > Why would this only apply to requestAutocomplete()? Surely it would be > just as important for the case where the user agent is filling in a > form without using that API. Agreed. I don't see the benefit of requestAutocomplete() here. Ted From ian at hixie.ch Fri Apr 11 16:10:07 2014 From: ian at hixie.ch (Ian Hickson) Date: Fri, 11 Apr 2014 23:10:07 +0000 (UTC) Subject: [whatwg] Proposal: requestBackgroundProcessing() In-Reply-To: <20140220214338.GW770@pobox.com> References: <CAABs73iJcgcPFC5cKn=h1qHRCMfcaNNKm=jvVoKitWs8wOJKTQ@mail.gmail.com> <20140220214338.GW770@pobox.com> Message-ID: <alpine.DEB.2.00.1404102328350.6826@ps20323.dreamhostps.com> On Thu, 20 Feb 2014, Ashley Gullen wrote: > > We're building a browser-based P2P multiplayer engine on top of WebRTC > DataChannels. You can try out our work-in-progress here: > http://www.scirra.com/labs/multiplayer/test1/ > > The first player in to a room is assigned the host, and all other > subsequently joining peers connect to the host with WebRTC DataChannels > and start exchanging game data. Like all responsible HTML5 games, it > runs based on a requestAnimationFrame loop. requestAnimationFrame() is for animations, not for logic. For logic, your better bet is to use a worker or, at worst, setInterval(). > To prevent multiplayer games commonly hanging, perhaps there could be a > new API to request that a page can keep running at full capacity even in > the background, such as window.requestBackgroundProcessing(). Workers are the mechanism for running code in the background. I would strongly recommend not using a peer server architecture, though. Doing this requires trusting the client, which is highly dubious. A hostile player could just inject arbitrary code into your logic, and subtly cheat without being detected. It also means that handling the host crashing or closing their laptop or going into a tunnel is different than the same for another player, which is a sucky experience for everyone. On Thu, 20 Feb 2014, Glenn Maynard wrote: > On Thu, Feb 20, 2014 at 12:35 PM, Rik Cabanier wrote: > > > > Is WebRTC available in a worker? > > I don't know, but if not, fixing that is probably closer to the right > direction than letting people run fast timers in minimized UI threads. Yeah. If WebRTC isn't being exposed to workers, I recommend bringing that up with the editor of the WebRTC spec. On Thu, 20 Feb 2014, Ashley Gullen wrote: > > There's a lot of worker features that aren't widely supported yet, like > rendering to canvas with WebGL and 2D, Web Audio support, inputs, > various APIs like speech and fullscreen, so I don't think that's > practical right now. Presumably your server logic doesn't need to be fullscreen... On Thu, 20 Feb 2014, Ashley Gullen wrote: > > Since it's a peer-to-peer engine, the user acting as the server is also > a participant in the game. This means the server is also running the > full game experience with rendering and audio. That part of the logic should be in the tab. Then the tab just acts as a client to the server in the worker, in the same way that the other clients for the other players do. > The game logic is tied to rAF, since we intend to step the world once > per screen draw, including for the player acting as a server. Different players are going to have different frame rates, so it doesn't make sense to make one player's frame rate more important than another's. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From eoconnor at apple.com Fri Apr 11 16:23:16 2014 From: eoconnor at apple.com (Edward O'Connor) Date: Fri, 11 Apr 2014 16:23:16 -0700 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <alpine.DEB.2.00.1404071735580.21310@ps20323.dreamhostps.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> <alpine.DEB.2.00.1404071735580.21310@ps20323.dreamhostps.com> Message-ID: <m2d2gn5u3f.fsf@apple.com> Hi, >> The consensus opinion at WebRTC and MediaCapture seemed to be that >> the ability to let an app say "which of these 5 microphones do you >> want?" is more amenable to creating good apps than leaving this UI to >> the browser chrome. > > Seems to me that the privacy aspects (the fingerprinting > vulnerabilities from exposing this data), and the abuse aspects > (giving hostile sites the ability to access all the user's devices if > any are made available) would trump this. Surely we can rely on user > agents to provide nice UIs. I agree with Ian. For instance, on iOS we provide features that allow Web developers to take AirPlay into account when building custom video controls, but we do not expose the list of AirPlay targets to Web content. Ted From glenn at zewt.org Fri Apr 11 16:48:22 2014 From: glenn at zewt.org (Glenn Maynard) Date: Fri, 11 Apr 2014 18:48:22 -0500 Subject: [whatwg] Media sink device selection on <audio>/<video> In-Reply-To: <m2d2gn5u3f.fsf@apple.com> References: <CAHuR8a9JUb=Lxpc3fVFnmzw619PSR8P5mPNUgNPD3mvwc0_ehA@mail.gmail.com> <alpine.DEB.2.00.1312190423021.27766@ps20323.dreamhostps.com> <CAHuR8a_DGzVTy0xMZ=ouH1T4i=xX3VAD_WciB8M1LH6ojbZUGQ@mail.gmail.com> <CAMQvoC=E3nipTO98RSb75f4B7VuAvgBw2N3n=X6v71uFWhGKOQ@mail.gmail.com> <alpine.DEB.2.00.1402072226590.30855@ps20323.dreamhostps.com> <CAHuR8a8wFd_33Go3GxArnuqWGvD4Q5irOPKsO+BYrgb8s0HbnA@mail.gmail.com> <alpine.DEB.2.00.1402080054200.30855@ps20323.dreamhostps.com> <CAHuR8a_xPwTUbd8gjsw-Ap0S6NuS_FkoYSwc3587OdFAfSz6dA@mail.gmail.com> <alpine.DEB.2.00.1404021748220.11249@ps20323.dreamhostps.com> <5342B517.1080401@alvestrand.no> <alpine.DEB.2.00.1404071604580.21310@ps20323.dreamhostps.com> <5342E04D.3010301@alvestrand.no> <alpine.DEB.2.00.1404071735580.21310@ps20323.dreamhostps.com> <m2d2gn5u3f.fsf@apple.com> Message-ID: <CABirCh9S=7o7+DYq4zB2a+FtVL3Zv7wuUdOnn-JkwO3euUpFaw@mail.gmail.com> On Fri, Apr 11, 2014 at 6:23 PM, Edward O'Connor <eoconnor at apple.com> wrote: > >> The consensus opinion at WebRTC and MediaCapture seemed to be that > >> the ability to let an app say "which of these 5 microphones do you > >> want?" is more amenable to creating good apps than leaving this UI to > >> the browser chrome. > > > > Seems to me that the privacy aspects (the fingerprinting > > vulnerabilities from exposing this data), and the abuse aspects > > (giving hostile sites the ability to access all the user's devices if > > any are made available) would trump this. Surely we can rely on user > > agents to provide nice UIs. > The fingerprinting could be pretty specific, too. For example, my apple TV advertises itself with a custom AirPlay name. I agree with Ian. For instance, on iOS we provide features that allow > Web developers to take AirPlay into account when building custom video > controls, but we do not expose the list of AirPlay targets to Web > content. > Some other issues: - The browser will give a consistent UI. I don't get a different "Save As" dialog for each site, and I shouldn't get a different "which mic do you want to use?" dialog for each site either. - The browser will give a UI. My guess is that the vast majority of web apps wouldn't provide a selection UI *at all* for mics or speakers, and just use the default. - Web apps shouldn't need to implement basic UI for things like this, just like they shouldn't have to implement their own Save As dialogs. That's the platform's job. -- Glenn Maynard From brettz9 at yahoo.com Sat Apr 12 20:13:15 2014 From: brettz9 at yahoo.com (Brett Zamir) Date: Sun, 13 Apr 2014 11:13:15 +0800 Subject: [whatwg] Self-imposed script or networking restrictions (toward privacy and XSS-protection, and stimulating offline tool creation and increased but safer privilege escalation) Message-ID: <534A00CB.6060007@yahoo.com> *Problem:* I believe that if Ajax or other forms of dynamic scripting had been absent but were proposed today, people would probably say things like: 1. "What, you want to allow sites to have the ability out of the box to track my mouse movements?" 2. "You want sites to be able to know what I'm typing in a text box before I choose to explicitly submit?" 3. "You want to allow executable code, including third party code, to update itself without a means for a developer to review the source?" 4. "You want my generic offline build tool to cause users concern about whether the data I've added locally will be sent back to the server?" While browsers will hopefully allow user-directed control of this regardless of standards, ala NoScript or the like, there is no means (to my knowledge), besides perhaps packaging the file as an add-on with limited privileges or a sandboxed site-specific_browser ( https://en.wikipedia.org/wiki/Site-specific_browser ), by which a website author can cause its own particular web app loaded over the web to be issued in such as manner as to allay privacy or cross-site scripting concerns by having the browser inform the user that a given type of (safe) app has been loaded, one which is either not able to: 1. execute any scripts at all 2. phone home at all 3. phone home at all after the initial static HTML payload 4. phone home at all after the initial static HTML payload except to a list of origins indicated to the user The above ought to also allay security concerns in the case that a script uses eval capabilities on a post-load network-delivered string. *Proposed Solution:* I would like to propose that HTTP headers, an internal HTML tag attribute (like the offline apps manifest attribute), and/or changes to the AppCache manifest structure be created which will cause desired security principal restrictions to be enforced, in particular either: 1. preventing all scripting 2. allowing scripting but prohibiting all Ajax or other networking requests (dynamic insertion of iframes, image or link tags with remote URLs, dynamic form submissions, etc.) 3. allowing scripting but prohibiting all Ajax or other networking requests except to URL origins or pages indicated within a whitelist (where the browser UI would display any such whitelist to users and/or prevent requests to the whitelist until the user approved, ideally providing them first a view of the proposed payload, and if approved, with a preview of the response payload and a choice as to whether to accept, and with the option to remember any such outgoing or incoming approvals in the future). Perhaps the AppCache manifest could be extended to provide this directive of prohibited or conditional updating. 4. optionally excluding loading of other resources within even the initial declarative HTML payload. Data: URIs and blobs could, however, be allowed dynamically where scripting was allowed (e.g., whether through window.open(), a dynamic execution of an <a download=""> tag or the like) as well as statically without the need for a whitelist. *Benefits:* 1. The designation by authors of this status could give assurance to users that privacy between page loads will not be violated on sites of general interest. This would be especially useful in apps utilizing IndexedDB where the user might make a lot of local modifications but not wish to share these back with the origin server. 2. It could also be a boon to web developers who wish to share generic build tools (whether ones that are online, offlinable via AppCache, and/or which run from file://) in a manner which does not raise privacy concerns. Currently, many web apps are distributed along with OS-dependent build scripts or scripts using non-client-side languages such as Node.js, Python, or Java, and whose interpretation requires the downloading of additional tools. If the developer could create a tool which would not raise privacy concerns but would instead inform users that the code they have loaded locally will not be able to update itself without their permission (at least without giving consent to a proposed payload back to the server), developers may prefer to write in client-side JavaScript for their own convenience (given the ubiquity of client-side JavaScript), and with the benefit of facilitating modifications on their tools whether by paid developers or open source contributors who may be most likely to know at least some JavaScript. Their code could provide build functionality by compiling locally designated files or other content into a file download, texarea, etc. 3. If implemented, the sandboxing capability could be leveraged to blur the line between add-ons, web apps, and mobile apps and be used by site-specific browser implementations. Web app users would gain the same peace of mind and more granular privilege control of mobile apps. As a result of users knowing there would be this sandboxing, the door could, moreover, be opened for websites to request any privilege allowed to add-ons without needing the step of special packaging and encouraging the development of standardized privileged APIs which would work across the web, mobile, and packaged add-ons*. A website may already currently ask users from the web whether they wish to install a privileged add-on, so there should be no net increase in security risk by allowing sandboxed websites from doing the same; on the contrary, the requirement of granting privileges granularly (unlike in some add-on systems), will ensure that users are well-informed as to the exact security or privacy implications of granting approval, as well as let websites be designed for progressive enhancement (e.g., an app might only ask for privileges as needed, a user might allow the app one high-level privilege but not another (e.g., granting arbitrary local file access on an app deemed by the user to be safe in its current snapshot, but disallow networking-related privileges), etc.). My Firefox add-on, AsYouWish (at https://github.com/brettz9/asyouwish/ ), is meant as a current workaround in this regard for Firefox, https://github.com/brettz9/asyouwish/ , but while it offers granular privileges, it suffers from not being currently sandboxable and not being standard across browser. Best wishes, Brett * Proposed to Mozilla at https://bugzilla.mozilla.org/show_bug.cgi?id=848647 From dbeam at chromium.org Mon Apr 14 21:41:51 2014 From: dbeam at chromium.org (Dan Beam) Date: Mon, 14 Apr 2014 21:41:51 -0700 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise Message-ID: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> Hey whatwg@, I propose requestAutocomplete()[1] should return a Promise. This has been requested since the creation of this API[2][3] and seems like a natural fit. Web authors can then call requestAutocomplete() like this: form.requestAutocomplete().then(function() { // form.submit() or some other success action }, function(errorDetails) { // handle error based on errorDetails.reason (e.g. "cancel") }); The returned promise would be resolved after the corresponding "autocomplete" or "autocompleteerror" event is dispatched on the form. Null would be passed on fulfillment* and {"reason": <matching AutocompleteErrorEvent#reason>} would be passed on rejection. There should be little compatibility risk as requestAutocomplete() currently returns undefined. Thoughts? Concerns? Questions? -- Dan Beam dbeam at chromium.org * until I think of something useful for the success case... [1] http://www.whatwg.org/specs/web-apps/current-work/#dom-form-requestautocomplete [2] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/0TnqLOvC2ZY [3] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/aqKcZkCMsUI From domenic at domenicdenicola.com Mon Apr 14 21:44:59 2014 From: domenic at domenicdenicola.com (Domenic Denicola) Date: Tue, 15 Apr 2014 04:44:59 +0000 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise In-Reply-To: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> References: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> Message-ID: <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Dan Beam > I propose requestAutocomplete()[1] should return a Promise. This has been requested since the creation of this API[2][3] and seems like a natural fit. Web authors can then call requestAutocomplete() like this: I strongly support this. > Null would be passed on fulfillment* and `undefined` would be better, as that is what normal JavaScript functions return when they have nothing to return. > {"reason": <matching AutocompleteErrorEvent#reason>} would be passed on rejection. Rejection reasons should always be instanceof Error: https://github.com/w3ctag/promises-guide#rejection-reasons-should-be-errors From vnicolas at mozilla.com Tue Apr 15 09:08:23 2014 From: vnicolas at mozilla.com (Vivien Nicolas) Date: Tue, 15 Apr 2014 18:08:23 +0200 Subject: [whatwg] Add a |transient| mechanism to the notifications API Message-ID: <534D5977.4040307@mozilla.com> Hello, Would it be possible to add a |transient| mechanism to the notifications spec ? In the context of FirefosOS, one of the use case is for example an email application. For instance the user can write a message, click the send button, and then leave the application to do something else. It would be useful if the application is able to give the user a transient notification that the email has been correctly sent. This kind of notifications are not particularly useful after a while and should dismiss automatically after a small delay. Looking at what others are doing, it seems related to 'Toasts'. Here is what I found on google: Gnome is using a |transient| hint (https://bugzilla.gnome.org/show_bug.cgi?id=633412) Windows 8 call those type of notifications Toast and display them for 7 seconds (http://msdn.microsoft.com/en-us/library/windows/apps/hh779727.aspx) Android also call that Toasts and let the user specify a duration (http://developer.android.com/guide/topics/ui/notifiers/toasts.html) iOS: It seems like this is not part of the default UI toolkit. Looking at Growl for mac (http://growl.info/) it seems like there is no possibility for the notifications to be transient or not. Instead everything is customizable by the user, and all notifications ends up into the 'Rollup' database (even when you mount/unmount a hard drive). Regards, Vivien. From domenic at domenicdenicola.com Tue Apr 15 09:12:12 2014 From: domenic at domenicdenicola.com (Domenic Denicola) Date: Tue, 15 Apr 2014 16:12:12 +0000 Subject: [whatwg] Add a |transient| mechanism to the notifications API In-Reply-To: <534D5977.4040307@mozilla.com> References: <534D5977.4040307@mozilla.com> Message-ID: <67441e562cde478ca71bab7e0ce09d0e@BN1PR05MB325.namprd05.prod.outlook.com> This seems like a valuable feature. I am hopeful something like it can be added. >From my reading of Windows Phone 8.1 reviews, the way they handle this is by allowing applications to remove notifications themselves. This seems like the most flexible approach: applications could automatically remove the notification after 7 seconds, or e.g. remove them after the email has been read on another computer. From annevk at annevk.nl Tue Apr 15 10:46:55 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Tue, 15 Apr 2014 18:46:55 +0100 Subject: [whatwg] Add a |transient| mechanism to the notifications API In-Reply-To: <67441e562cde478ca71bab7e0ce09d0e@BN1PR05MB325.namprd05.prod.outlook.com> References: <534D5977.4040307@mozilla.com> <67441e562cde478ca71bab7e0ce09d0e@BN1PR05MB325.namprd05.prod.outlook.com> Message-ID: <CADnb78jw3NvPmdJm2zbEcBe=_CZu1U5v1Ke8BV_3L=g22A2Pfg@mail.gmail.com> On Tue, Apr 15, 2014 at 5:12 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote: > From my reading of Windows Phone 8.1 reviews, the way they handle this is by allowing applications to remove notifications themselves. We already have this actually: var = n = new Notification(...) n.onshow = () => setTimeout(() => n.close(), 7000) I guess this would be for the case where you close the window before that timer is able to run. Normally that would leave the notification in the notification center, but with say a duration member set to non-zero it would be removed. -- http://annevankesteren.nl/ From dbeam at chromium.org Tue Apr 15 16:29:05 2014 From: dbeam at chromium.org (Dan Beam) Date: Tue, 15 Apr 2014 16:29:05 -0700 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise In-Reply-To: <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> References: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> Message-ID: <CANpe7K25BCCFJuS89YQ9Od81ZhPDVdxUoyzP0uz=BTUpnzJqTw@mail.gmail.com> On Mon, Apr 14, 2014 at 9:44 PM, Domenic Denicola < domenic at domenicdenicola.com> wrote: > > From: whatwg-bounces at lists.whatwg.org [mailto: whatwg-bounces at lists.whatwg.org] On Behalf Of Dan Beam > > > I propose requestAutocomplete()[1] should return a Promise. This has been requested since the creation of this API[2][3] and seems like a natural fit. Web authors can then call requestAutocomplete() like this: > > I strongly support this. > > > Null would be passed on fulfillment* and > > `undefined` would be better, as that is what normal JavaScript functions return when they have nothing to return. So just pass no argument at all (i.e. arguments.length == 0)? I was under the impression some type of value should always be returned (but I'm biased by blink/v8's current implementation). > > > {"reason": <matching AutocompleteErrorEvent#reason>} would be passed on rejection. > > Rejection reasons should always be instanceof Error: https://github.com/w3ctag/promises-guide#rejection-reasons-should-be-errors > Great, will figure out a way to subclass Error to provide some type of "reason" property on the rejection argument. -- Dan Beam dbeam at chromium.org From bzbarsky at MIT.EDU Tue Apr 15 22:08:16 2014 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Wed, 16 Apr 2014 01:08:16 -0400 Subject: [whatwg] canvas drawImage and EXIF orientation metadata Message-ID: <534E1040.3040103@mit.edu> Right now canvas drawImage ignores EXIF orientation metadata. Could we add a version that doesn't do that? Especially with CSS growing things like the image-orientation property, it would be good to support drawing the image in its correct orientation. -Boris From vnicolas at mozilla.com Wed Apr 16 03:37:04 2014 From: vnicolas at mozilla.com (Vivien Nicolas) Date: Wed, 16 Apr 2014 12:37:04 +0200 Subject: [whatwg] Add a |transient| mechanism to the notifications API In-Reply-To: <CADnb78jw3NvPmdJm2zbEcBe=_CZu1U5v1Ke8BV_3L=g22A2Pfg@mail.gmail.com> References: <534D5977.4040307@mozilla.com> <67441e562cde478ca71bab7e0ce09d0e@BN1PR05MB325.namprd05.prod.outlook.com> <CADnb78jw3NvPmdJm2zbEcBe=_CZu1U5v1Ke8BV_3L=g22A2Pfg@mail.gmail.com> Message-ID: <534E5D50.5010507@mozilla.com> On 15/04/2014 19:46, Anne van Kesteren wrote: > On Tue, Apr 15, 2014 at 5:12 PM, Domenic Denicola > <domenic at domenicdenicola.com> wrote: >> From my reading of Windows Phone 8.1 reviews, the way they handle this is by allowing applications to remove notifications themselves. > > We already have this actually: > > var = n = new Notification(...) > n.onshow = () => setTimeout(() => n.close(), 7000) > > > I guess this would be for the case where you close the window before > that timer is able to run. Normally that would leave the notification > in the notification center, but with say a duration member set to > non-zero it would be removed. > It could be done this way as mentioned. What I'm looking for is a hint for the user agent, so such notifications can be displayed differently by the user-agent if it is the one rendering notifications, or forwarded to the underlying platform notifications API. From junov at google.com Wed Apr 16 07:22:28 2014 From: junov at google.com (Justin Novosad) Date: Wed, 16 Apr 2014 07:22:28 -0700 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <534E1040.3040103@mit.edu> References: <534E1040.3040103@mit.edu> Message-ID: <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> +1 But why a new version of drawImage? Couldn't we just modify the existing drawImage definition to state that it takes into account the image-orientation property on the source image? The default value for image-orientation is 0deg, which corresponds to the current drawImage behavior. So I think we can make that change to the drawImage spec without breaking stuff, as long as we make the change while image-orientation is still an experimental feature. On Tue, Apr 15, 2014 at 10:08 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > Right now canvas drawImage ignores EXIF orientation metadata. > > Could we add a version that doesn't do that? Especially with CSS growing > things like the image-orientation property, it would be good to support > drawing the image in its correct orientation. > > -Boris > From annevk at annevk.nl Wed Apr 16 07:26:55 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 16 Apr 2014 15:26:55 +0100 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> Message-ID: <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> On Wed, Apr 16, 2014 at 3:22 PM, Justin Novosad <junov at google.com> wrote: > But why a new version of drawImage? Couldn't we just modify the existing > drawImage definition to state that it takes into account the > image-orientation property on the source image? The default value for > image-orientation is 0deg, which corresponds to the current drawImage > behavior. So I think we can make that change to the drawImage spec without > breaking stuff, as long as we make the change while image-orientation is > still an experimental feature. Why is image-orientation in CSS for <img>? For background-image that makes sense, but if you are actually affecting the semantics of the image that is displayed, it seems like it should be in HTML or a hint in the image format. (My reply to Boris was going to be that drawImage() should follow whatever flag we introduce for <img> to have this behavior, seems weird for that flag to be in CSS though.) -- http://annevankesteren.nl/ From junov at google.com Wed Apr 16 07:45:46 2014 From: junov at google.com (Justin Novosad) Date: Wed, 16 Apr 2014 07:45:46 -0700 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> Message-ID: <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> On Wed, Apr 16, 2014 at 7:26 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > On Wed, Apr 16, 2014 at 3:22 PM, Justin Novosad <junov at google.com> wrote: > > But why a new version of drawImage? Couldn't we just modify the existing > > drawImage definition to state that it takes into account the > > image-orientation property on the source image? The default value for > > image-orientation is 0deg, which corresponds to the current drawImage > > behavior. So I think we can make that change to the drawImage spec > without > > breaking stuff, as long as we make the change while image-orientation is > > still an experimental feature. > > Why is image-orientation in CSS for <img>? For background-image that > makes sense, but if you are actually affecting the semantics of the > image that is displayed, it seems like it should be in HTML or a hint > in the image format. I was wondering the same thing. From the image-orientation spec: "It applies only to content images (e.g. replaced elements and generated content), not decorative images (such as background-image)." So this property apparently has a considerably larger scope than just correcting the orientation of images from files, which I guess explains why it is in CSS. > (My reply to Boris was going to be that drawImage() should follow > whatever flag we introduce for <img> to have this behavior, seems > weird for that flag to be in CSS though.) > > > -- > http://annevankesteren.nl/ > From bzbarsky at MIT.EDU Wed Apr 16 07:53:46 2014 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Wed, 16 Apr 2014 10:53:46 -0400 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> Message-ID: <534E997A.5090504@mit.edu> On 4/16/14 10:22 AM, Justin Novosad wrote: > But why a new version of drawImage? Couldn't we just modify the existing > drawImage definition to state that it takes into account the > image-orientation property on the source image? We could do that, though it introduces a dependency of drawImage on style computation that isn't there right now. > So I think we can make that change to the drawImage spec > without breaking stuff, as long as we make the change > while image-orientation is still an experimental feature. Note that image-orientation has been shipping in Firefox for several releases now. -Boris From annevk at annevk.nl Wed Apr 16 08:09:04 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 16 Apr 2014 16:09:04 +0100 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> Message-ID: <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> On Wed, Apr 16, 2014 at 3:45 PM, Justin Novosad <junov at google.com> wrote: > I was wondering the same thing. From the image-orientation spec: "It applies > only to content images (e.g. replaced elements and generated content), not > decorative images (such as background-image)." > So this property apparently has a considerably larger scope than just > correcting the orientation of images from files, which I guess explains why > it is in CSS. I don't really follow the reasoning. But I guess if this has been shipping in Firefox for a while we might be out of luck changing this. -- http://annevankesteren.nl/ From bzbarsky at MIT.EDU Wed Apr 16 08:15:46 2014 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Wed, 16 Apr 2014 11:15:46 -0400 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> Message-ID: <534E9EA2.1000602@mit.edu> On 4/16/14 11:09 AM, Anne van Kesteren wrote: > I don't really follow the reasoning. But I guess if this has been > shipping in Firefox for a while we might be out of luck changing this. I doubt image-orientation is widely used, esp. in combination with drawImage. But if we want to use it here, we should coordinate with the CSS WG at least. -Boris From junov at google.com Wed Apr 16 09:54:24 2014 From: junov at google.com (Justin Novosad) Date: Wed, 16 Apr 2014 09:54:24 -0700 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <534E9EA2.1000602@mit.edu> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> <534E9EA2.1000602@mit.edu> Message-ID: <CABpaAqSWOZ+HyEAPc1mJgj=s5-SFTYPbZe=rFZrQv-h+yHdc6g@mail.gmail.com> Another use case to think about is: XHR->Blob->ImageBitmap->Canvas(2D or WebGL) With that data flow, there is no opportunity to use a CSS property to tweak image orientation. There is this idea though: http://wiki.whatwg.org/wiki/ImageBitmap_Options Boris' point about adding a dependency on style computation is concerning. This could potentially seriously regress performance of existing apps that (inadvertently?) invalidate style of image elements at each animation frame. >From an implementation standpoint though, it would make sense for image elements to to store decoded images with the corrected orientation baked-in, and to be able to use that cached decoded image buffer directly in drawImage, without having to re-apply (or even verify) orientation correction at that time. But of course, that implies resolving style at image decode time. What to do? On Wed, Apr 16, 2014 at 8:15 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 4/16/14 11:09 AM, Anne van Kesteren wrote: > >> I don't really follow the reasoning. But I guess if this has been >> shipping in Firefox for a while we might be out of luck changing this. >> > > I doubt image-orientation is widely used, esp. in combination with > drawImage. > > But if we want to use it here, we should coordinate with the CSS WG at > least. > > -Boris > > > From annevk at annevk.nl Wed Apr 16 10:57:41 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 16 Apr 2014 18:57:41 +0100 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CABpaAqSWOZ+HyEAPc1mJgj=s5-SFTYPbZe=rFZrQv-h+yHdc6g@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> <534E9EA2.1000602@mit.edu> <CABpaAqSWOZ+HyEAPc1mJgj=s5-SFTYPbZe=rFZrQv-h+yHdc6g@mail.gmail.com> Message-ID: <CADnb78jnvd1He-pDHnOO==8L9wWZQ6mKi7ikb8ScZdDkoudeQA@mail.gmail.com> On Wed, Apr 16, 2014 at 5:54 PM, Justin Novosad <junov at google.com> wrote: > From an implementation standpoint though, it would make sense for image > elements to to store decoded images with the corrected orientation baked-in, > and to be able to use that cached decoded image buffer directly in > drawImage, without having to re-apply (or even verify) orientation > correction at that time. But of course, that implies resolving style at > image decode time. What to do? We could consider moving this property into markup. It seems somewhat more semantic than stylistic too. Image orientation affects the content. -- http://annevankesteren.nl/ From junov at google.com Wed Apr 16 12:23:39 2014 From: junov at google.com (Justin Novosad) Date: Wed, 16 Apr 2014 12:23:39 -0700 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CADnb78jnvd1He-pDHnOO==8L9wWZQ6mKi7ikb8ScZdDkoudeQA@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> <534E9EA2.1000602@mit.edu> <CABpaAqSWOZ+HyEAPc1mJgj=s5-SFTYPbZe=rFZrQv-h+yHdc6g@mail.gmail.com> <CADnb78jnvd1He-pDHnOO==8L9wWZQ6mKi7ikb8ScZdDkoudeQA@mail.gmail.com> Message-ID: <CABpaAqRm5NOD+=6HAn-fvRDeroiAHwTqT--SF=A3yNJkvrBuig@mail.gmail.com> On Wed, Apr 16, 2014 at 10:57 AM, Anne van Kesteren <annevk at annevk.nl>wrote: > On Wed, Apr 16, 2014 at 5:54 PM, Justin Novosad <junov at google.com> wrote: > > From an implementation standpoint though, it would make sense for image > > elements to to store decoded images with the corrected orientation > baked-in, > > and to be able to use that cached decoded image buffer directly in > > drawImage, without having to re-apply (or even verify) orientation > > correction at that time. But of course, that implies resolving style at > > image decode time. What to do? > > We could consider moving this property into markup. It seems somewhat > more semantic than stylistic too. Image orientation affects the > content. > Yes, that makes a lot of sense IMHO. I just posted feedback to www-style > > -- > http://annevankesteren.nl/ > From eoconnor at apple.com Wed Apr 16 16:10:36 2014 From: eoconnor at apple.com (Edward O'Connor) Date: Wed, 16 Apr 2014 16:10:36 -0700 Subject: [whatwg] [notifications][editorial] tweaking the "Activating a notification" window.focus() note Message-ID: <m261m898gj.fsf@eoconnor.apple.com> Hi, In ?4.6 Activating a notification, there's a note that currently reads "User agents are strongly encouraged to make window.focus() work from within the event listener for the event named click as a means of focusing the browsing context related to the notification." This note assumes that the UA doesn't automatically focus the browsing context when a notification is activated. (Safari on OS X is one example of a UA which does this.) The note should be adjusted so that readers understand that calling window.focus() may not be necessary on some combinations of UA and system notification service. Ted From annevk at annevk.nl Wed Apr 16 16:14:41 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Thu, 17 Apr 2014 00:14:41 +0100 Subject: [whatwg] [notifications][editorial] tweaking the "Activating a notification" window.focus() note In-Reply-To: <m261m898gj.fsf@eoconnor.apple.com> References: <m261m898gj.fsf@eoconnor.apple.com> Message-ID: <CADnb78iMXJPFGS9OUq_=HsA1XOszA7hsKigvyhEkCcFkBB9_tg@mail.gmail.com> On Thu, Apr 17, 2014 at 12:10 AM, Edward O'Connor <eoconnor at apple.com> wrote: > In ?4.6 Activating a notification, there's a note that currently reads > > "User agents are strongly encouraged to make window.focus() work > from within the event listener for the event named click as a means > of focusing the browsing context related to the notification." > > This note assumes that the UA doesn't automatically focus the browsing > context when a notification is activated. (Safari on OS X is one example > of a UA which does this.) The note should be adjusted so that readers > understand that calling window.focus() may not be necessary on some > combinations of UA and system notification service. Cool, do you have a plan for shared workers? (E.g. down the road with service workers you can imagine creating Notification objects from there at which point things become a bit hazy.) -- http://annevankesteren.nl/ From glenn at zewt.org Wed Apr 16 16:45:04 2014 From: glenn at zewt.org (Glenn Maynard) Date: Wed, 16 Apr 2014 18:45:04 -0500 Subject: [whatwg] [notifications][editorial] tweaking the "Activating a notification" window.focus() note In-Reply-To: <m261m898gj.fsf@eoconnor.apple.com> References: <m261m898gj.fsf@eoconnor.apple.com> Message-ID: <CABirCh_pbd4oLxz_cS6d5GqNFq8qV58bsP01HS9nHcorihk=5g@mail.gmail.com> On Wed, Apr 16, 2014 at 6:10 PM, Edward O'Connor <eoconnor at apple.com> wrote: > Hi, > > In ?4.6 Activating a notification, there's a note that currently reads > > "User agents are strongly encouraged to make window.focus() work > from within the event listener for the event named click as a means > of focusing the browsing context related to the notification." > > This note assumes that the UA doesn't automatically focus the browsing > context when a notification is activated. (Safari on OS X is one example > of a UA which does this.) The note should be adjusted so that readers > understand that calling window.focus() may not be necessary on some > combinations of UA and system notification service. > Rather, pages should never be allowed to window.focus() when a notification is activated. If the platform's notification design wants that to happen, it's the platform's job to do that, and pages shouldn't all be required to call window.focus() to make this happen consistently. (If for some reason the platform doesn't want that to happen, the page shouldn't be able to override that, either.) If there are notifications that don't want to focus a page when activated, that should be a setting on the notification. -- Glenn Maynard From domenic at domenicdenicola.com Wed Apr 16 18:59:21 2014 From: domenic at domenicdenicola.com (Domenic Denicola) Date: Thu, 17 Apr 2014 01:59:21 +0000 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise In-Reply-To: <CANpe7K25BCCFJuS89YQ9Od81ZhPDVdxUoyzP0uz=BTUpnzJqTw@mail.gmail.com> References: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> <CANpe7K25BCCFJuS89YQ9Od81ZhPDVdxUoyzP0uz=BTUpnzJqTw@mail.gmail.com> Message-ID: <1fb95b4500944205baf2857a6525bc51@BN1PR05MB325.namprd05.prod.outlook.com> From: dbeam at google.com [mailto:dbeam at google.com] On Behalf Of Dan Beam > So just pass no argument at all (i.e. arguments.length == 0)? ?I was under the impression some type of value should always be returned (but I'm biased by blink/v8's current implementation). It's equivalent, both for promises and for return values of functions. Both `new Promise(resolve => resolve())` and `new Promise(resolve => resolve(undefined))` give a promise whose fulfillment value is `undefined`. In this sense `resolve` behaves like all non-evil JavaScript functions, where evil is defined as "checking `arguments.length`" ;) From jonas at sicking.cc Thu Apr 17 00:46:55 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 17 Apr 2014 00:46:55 -0700 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> Message-ID: <CA+c2ei9Ww7NxN-oO1eKhg5gunkidJja1NAGZpPJvjsQ3fSD0yQ@mail.gmail.com> On Wed, Apr 16, 2014 at 8:09 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > On Wed, Apr 16, 2014 at 3:45 PM, Justin Novosad <junov at google.com> wrote: >> I was wondering the same thing. From the image-orientation spec: "It applies >> only to content images (e.g. replaced elements and generated content), not >> decorative images (such as background-image)." >> So this property apparently has a considerably larger scope than just >> correcting the orientation of images from files, which I guess explains why >> it is in CSS. > > I don't really follow the reasoning. But I guess if this has been > shipping in Firefox for a while we might be out of luck changing this. The problem here stemms from that orientation data lives as "metadata" in the EXIF data of image formats. This means that many tools has simply ignored that metadata. The result seems to have been that people open their images in tools that ignore the EXIF metadata. Then rotates the pixel data using that tool. Then saves the image again while keeping the EXIF metadata unchanged. This now means the pixels have been rotated (say) 90 degrees, but the EXIF metadata still says "rotate image 90 degrees". So any tool that now honors the EXIF renders the picture *wrong*. So effectively the EXIF metadata has to be ignored in order to keep webcompat. That was the case even before image-orientation was implemented. FWIW I believe that WebP is remaking this same mistake. Would be cool if someone tried to prevent this from happening. / Jonas From glenn at zewt.org Thu Apr 17 07:30:21 2014 From: glenn at zewt.org (Glenn Maynard) Date: Thu, 17 Apr 2014 09:30:21 -0500 Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <CA+c2ei9Ww7NxN-oO1eKhg5gunkidJja1NAGZpPJvjsQ3fSD0yQ@mail.gmail.com> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <CADnb78hsU-vbqGLyQXOwj3ZuOPo27HN-yKyy0vv_vRzRbikndQ@mail.gmail.com> <CABpaAqT=i-1aVLpHOHd0j_QAtVZ6zVOrokvBu+ztXnXHTFNy1A@mail.gmail.com> <CADnb78jkqPY-RNK6kPFeFGUAcd14PwH6+rwVGfY+WzPF5boE6Q@mail.gmail.com> <CA+c2ei9Ww7NxN-oO1eKhg5gunkidJja1NAGZpPJvjsQ3fSD0yQ@mail.gmail.com> Message-ID: <CABirCh8AipxyJnt0PiPj=qAY58T+8Msm8a09JUPV7cUTvL4cBA@mail.gmail.com> On Thu, Apr 17, 2014 at 2:46 AM, Jonas Sicking <jonas at sicking.cc> wrote: > The problem here stemms from that orientation data lives as "metadata" > in the EXIF data of image formats. This means that many tools has > simply ignored that metadata. > > The result seems to have been that people open their images in tools > that ignore the EXIF metadata. Then rotates the pixel data using that > tool. Then saves the image again while keeping the EXIF metadata > unchanged. > > This now means the pixels have been rotated (say) 90 degrees, but the > EXIF metadata still says "rotate image 90 degrees". So any tool that > now honors the EXIF renders the picture *wrong*. > > So effectively the EXIF metadata has to be ignored in order to keep > webcompat. That was the case even before image-orientation was > implemented. > > FWIW I believe that WebP is remaking this same mistake. Would be cool > if someone tried to prevent this from happening. > The question was "why is this a CSS style instead of a property on <img>", not "why isn't this just the default". -- Glenn Maynard From jonas at sicking.cc Thu Apr 17 14:32:41 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 17 Apr 2014 14:32:41 -0700 Subject: [whatwg] BroadcastChannel should support structured clones Message-ID: <CA+c2ei-4u-iMSts6z0owHi2V8Z6bEXhgj1_WyJmak+mACWR1VA@mail.gmail.com> It would be very useful to be able to send structured data, including Blobs, through the BroadcastChannel API. This is something we've seen any time we've done storage or message passing, that one of the first thing authors ask for is to not have to do JSON serialization/parsing manually. The ability to pass ArrayBuffers and Blobs is somewhat less commonly asked for, likely because binary data is less often used, but seems important nonetheless. We can't allow transferring of objects, since you can't transfer something to all listeners of a broadcasting API. But plain structured clones should be no problem to support conceptually (though more work to implement of course). We've started looking at doing structured clone support for Firefox and likely won't ship until we have that implemented. / Jonas From jonas at sicking.cc Thu Apr 17 15:09:43 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 17 Apr 2014 15:09:43 -0700 Subject: [whatwg] BroadcastChannel should support structured clones In-Reply-To: <CA+c2ei-4u-iMSts6z0owHi2V8Z6bEXhgj1_WyJmak+mACWR1VA@mail.gmail.com> References: <CA+c2ei-4u-iMSts6z0owHi2V8Z6bEXhgj1_WyJmak+mACWR1VA@mail.gmail.com> Message-ID: <CA+c2ei_4hFxmegCK13LyiZV4pjwou_TyCUO44HrqizccR5VZvA@mail.gmail.com> Another thing that seems like an oversight in the spec is that the spec currently says that BroadcastChannel should be exposed in Window context. We should also expose it in Worker contexts. / Jonas On Thu, Apr 17, 2014 at 2:32 PM, Jonas Sicking <jonas at sicking.cc> wrote: > It would be very useful to be able to send structured data, including > Blobs, through the BroadcastChannel API. > > This is something we've seen any time we've done storage or message > passing, that one of the first thing authors ask for is to not have to > do JSON serialization/parsing manually. The ability to pass > ArrayBuffers and Blobs is somewhat less commonly asked for, likely > because binary data is less often used, but seems important > nonetheless. > > We can't allow transferring of objects, since you can't transfer > something to all listeners of a broadcasting API. But plain structured > clones should be no problem to support conceptually (though more work > to implement of course). > > We've started looking at doing structured clone support for Firefox > and likely won't ship until we have that implemented. > > / Jonas From gcasto at chromium.org Mon Apr 21 14:44:22 2014 From: gcasto at chromium.org (Garrett Casto) Date: Mon, 21 Apr 2014 14:44:22 -0700 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <m2k3av5w92.fsf@apple.com> References: <CAO4XGS-PnR__75fYCbarkOPNvpRTG52NebHmtjihdbGDiHw-aQ@mail.gmail.com> <alpine.DEB.2.00.1404021825530.11249@ps20323.dreamhostps.com> <m2k3av5w92.fsf@apple.com> Message-ID: <CAGQFVJgkQknT+VTV9ob6VO5tv9SPaRzpfJBY4juxd62V5NeVYQ@mail.gmail.com> > > > > For the real submission case, I guess what we want is a way to say > > "autocomplete=off" after the fact, basically. An HTTP header seems > > like the most obvious solution. > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 > > > > Again, these need multiple vendors on board to make progress. > > Browsers are moving away from respecting autocomplete=off. I don't think > we should be adding a new but basically equivalent mechanism. > > While I agree that it's a concern, I'm not overly worried that this is going to be abused for a few reasons. 1) We talked to some major US banks when disabling autocomplete=off for passwords, and though they historically have been a big proponent of the feature they didn't seem bothered that it was no longer going to be respected. It seems like sites are more accepting of password managers now. I wouldn't be surprised if a reasonable percentage of autocomplete=off usage is just inertia at this point. 2) A well-intentioned site might use autocomplete=off thinking that it's a security benefit to their site. Doing this with this new API would be obvious abuse and it doesn't seem likely that a site would do it unless they were looking for some way to block password managers. 3) If a site really wants to go out of their way to make sure that password managers don't work on their site, there are already ways of doing it. This would be an easier mechanism, but I'm not sure how much that matters. If we still think that this is too likely to be abused, another possibility might be to only allow the site to assert login succeeded not that it failed. Not sure how useful that is though, since it's generally easier to prompt on incorrect login than miss a correct login. > > I actually have a similar problem with purely JS-handled forms even > > unrelated to credentials. Because the form is never really submitted > > (even if we reuse the submit infrastructure, we cancel the 'submit' > > event and handle the work on the JS side), there's never an indication > > to the UA that it should save the fields, and so autofill never works > > right on these forms, even for things like postal addresses or e-mail > > addresses. > > > > For the pure JS case, an API (probably on the <form> itself) would > > make sense and seems relatively easy. I've filed a bug on this: > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 > > This case is pretty weird. Authors are going out of their way to avoid > using the built in platform features that would get them autofill saving > for free. In some cases, they might be doing this precisely because they > want to prevent autofill but can't count on autocomplete=off anymore. > > In most of the cases that I've seen where this comes up (e.g. Pandora) it seems like the entire site does navigation via AJAX + history.pushState(). It doesn't seem like the site is trying to avoid password managers so much as they are trying to keep the aesthetic of their site consistent. > > The requestAutocomplete() API is a Chrome proprietary feature right > > now so it's sort of acadmic, but: > > > > Why would this only apply to requestAutocomplete()? Surely it would be > > just as important for the case where the user agent is filling in a > > form without using that API. > > Agreed. I don't see the benefit of requestAutocomplete() here. > > > Ted > From atwilson at google.com Wed Apr 23 07:09:45 2014 From: atwilson at google.com (Andrew Wilson) Date: Wed, 23 Apr 2014 16:09:45 +0200 Subject: [whatwg] [notifications][editorial] tweaking the "Activating a notification" window.focus() note In-Reply-To: <CABirCh_pbd4oLxz_cS6d5GqNFq8qV58bsP01HS9nHcorihk=5g@mail.gmail.com> References: <m261m898gj.fsf@eoconnor.apple.com> <CABirCh_pbd4oLxz_cS6d5GqNFq8qV58bsP01HS9nHcorihk=5g@mail.gmail.com> Message-ID: <CAArhhit+4rDCowR4rnxwYt7u4grHCwGKXC3W7p7U0HYW1AQ=YQ@mail.gmail.com> The problem here is that the platform's notification design has no way to understand what the application wants to happen when the user clicks on a notification. As a great example - Gmail uses desktop notifications to notify the user about chat events and new emails. When the user clicks on a chat notification, gmail uses window.focus() to focus itself so the user can view the chat (which is displayed in the main gmail window via a <div> overlay). When the user clicks on an email notification, we don't want to bring up that email in the main gmail window because the user may be in the middle of some other operation (like composing an email) - in fact, we don't want to focus the gmail tab at all. Instead we pop up that email in a separate popup window. In that case, having the UA auto-focus the tab is a mistake. I'm OK if you somehow want to make auto-focus a default property of the notification and have the app determine a-priori whether a given notification should trigger auto-focus at the time the notification is created, but it seems less flexible than the current behavior that Chrome has, which is that notifications don't auto-focus, and that applications have full control over what they want to happen when a click occurs. I suppose you can make the argument that auto-focus is so overwhelmingly common that we should just make it the default as a developer convenience - do you have any data to back up this assertion? In any case, I'm OK with the status quo, which is that UAs either auto-focus (if they want to force consistent click-on-notification functionality regardless of app intent) or they should support window.focus(). Actively prohibiting window.focus() seems like a bad step. -atw On Thu, Apr 17, 2014 at 1:45 AM, Glenn Maynard <glenn at zewt.org> wrote: > On Wed, Apr 16, 2014 at 6:10 PM, Edward O'Connor <eoconnor at apple.com> > wrote: > > > Hi, > > > > In ?4.6 Activating a notification, there's a note that currently reads > > > > "User agents are strongly encouraged to make window.focus() work > > from within the event listener for the event named click as a means > > of focusing the browsing context related to the notification." > > > > This note assumes that the UA doesn't automatically focus the browsing > > context when a notification is activated. (Safari on OS X is one example > > of a UA which does this.) The note should be adjusted so that readers > > understand that calling window.focus() may not be necessary on some > > combinations of UA and system notification service. > > > > Rather, pages should never be allowed to window.focus() when a notification > is activated. If the platform's notification design wants that to happen, > it's the platform's job to do that, and pages shouldn't all be required to > call window.focus() to make this happen consistently. (If for some reason > the platform doesn't want that to happen, the page shouldn't be able to > override that, either.) > > If there are notifications that don't want to focus a page when activated, > that should be a setting on the notification. > > -- > Glenn Maynard > From bnicholson at mozilla.com Wed Apr 23 17:02:43 2014 From: bnicholson at mozilla.com (Brian Nicholson) Date: Wed, 23 Apr 2014 17:02:43 -0700 Subject: [whatwg] Additional details for invoking requestAutocomplete Message-ID: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> This optional argument sounds reasonable to me (FWIW, I'm working on the requestAutocomplete implementation for Firefox). The transaction fields also seem sensible, but I have no experience with payment APIs, so I can't give feedback on how well this will work with payment providers in general (and whether any additional fields might be useful). Those working on Mozilla's payment APIs are aware of this thread, so hopefully they'll be giving feedback if they have anything to add. When I first read this proposal, I was under the impression that the browser would somehow detect whether transactions would put users over their card limits, but maybe you're going for something simpler than that. Could you elaborate on how Chromium will handle these transactions differently? - Brian On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade <est... at chromium.org> wrote: > Hi WhatWG. > > Currently, requestAutocomplete lets a user agent provide the same user > experience across multiple sites for common data input flows. A site > describes the data it desires (via a form and autocomplete attributes), and > the user agent uses this information and what it knows about the user to > expedite data input. For example, if one of the form elements has > autocomplete=?cc-number? the browser might provide an experience tailored > for a payment flow, or if there?s an element with autocomplete=?bday? the > browser might use an experience that?s tailored for sharing identiy. > > We?ve found that there are some details of the interaction which might > affect the UX which cannot be inferred from the data inputs. We propose to > add an optional argument to the requestAutocomplete method. Thus invocation > would look like: > > form_element. requestAutocomplete(details); > > This |details| argument would be an object where key-value pairs provide > additional details regarding the request. The spec should define a set of > keys and associated data types which are recognized. There are currently > two key-value pairs we would like to add: > > key: ?transactionAmount? > value: number > description: For data that is going to be applied towards a > transaction, the /maximum/ value of the transaction. The browser does not > guarantee that the returned payment instrument will work, but keeping the > transaction under this amount will increase the likelihood of receiving a > valid card number. > > key: ?transactionCurrency? > value: string > description: a valid ISO 4217 currency code that describes the > currency for transactionAmount. If not provided, the default is ?USD?. > > Justification? There are upper bounds on certain payment instruments, for > example different credit cards have different credit limits; a debit card > is linked to a bank account with a certain balance. It?s a much preferable > user experience to be able to catch these problems earlier rather than > waiting for the merchant to attempt the transaction and have it fail (or > have a user?s account overdrawn). Concretely, Chromium wants to handle > transactions over $2000 differently from transactions under that amount. > > Does this seem reasonable? > > > -- Evan Stade > From estade at chromium.org Wed Apr 23 21:13:28 2014 From: estade at chromium.org (Evan Stade) Date: Wed, 23 Apr 2014 21:13:28 -0700 Subject: [whatwg] Additional details for invoking requestAutocomplete In-Reply-To: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> References: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> Message-ID: <CAO4XGS_rXaHxtU1oKypMixwU+iDKocPgvbBuFiV15OYWv6bTnQ@mail.gmail.com> Specifically, Chromium would disable Wallet for transactions over a certain limit (at the moment, that's $2k, but this business logic is subject to change). When Wallet is disabled, users can still store/access their data in Chrome/Chrome Sync. -- Evan Stade On Wed, Apr 23, 2014 at 5:02 PM, Brian Nicholson <bnicholson at mozilla.com>wrote: > This optional argument sounds reasonable to me (FWIW, I'm working on > the requestAutocomplete implementation for Firefox). The transaction > fields also seem sensible, but I have no experience with payment APIs, > so I can't give feedback on how well this will work with payment > providers in general (and whether any additional fields might be > useful). Those working on Mozilla's payment APIs are aware of this > thread, so hopefully they'll be giving feedback if they have anything > to add. > > When I first read this proposal, I was under the impression that the > browser would somehow detect whether transactions would put users over > their card limits, but maybe you're going for something simpler than > that. Could you elaborate on how Chromium will handle these > transactions differently? > > - Brian > > > On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade <est... at chromium.org> wrote: > > > Hi WhatWG. > > > > Currently, requestAutocomplete lets a user agent provide the same user > > experience across multiple sites for common data input flows. A site > > describes the data it desires (via a form and autocomplete attributes), > and > > the user agent uses this information and what it knows about the user to > > expedite data input. For example, if one of the form elements has > > autocomplete=?cc-number? the browser might provide an experience tailored > > for a payment flow, or if there?s an element with autocomplete=?bday? the > > browser might use an experience that?s tailored for sharing identiy. > > > > We?ve found that there are some details of the interaction which might > > affect the UX which cannot be inferred from the data inputs. We propose > to > > add an optional argument to the requestAutocomplete method. Thus > invocation > > would look like: > > > > form_element. > requestAutocomplete(details); > > > > This |details| argument would be an object where key-value pairs provide > > additional details regarding the request. The spec should define a set of > > keys and associated data types which are recognized. There are currently > > two key-value pairs we would like to add: > > > > key: ?transactionAmount? > > value: number > > description: For data that is going to be applied towards a > > transaction, the /maximum/ value of the transaction. The browser does not > > guarantee that the returned payment instrument will work, but keeping the > > transaction under this amount will increase the likelihood of receiving a > > valid card number. > > > > key: ?transactionCurrency? > > value: string > > description: a valid ISO 4217 currency code that describes the > > currency for transactionAmount. If not provided, the default is ?USD?. > > > > Justification? There are upper bounds on certain payment instruments, for > > example different credit cards have different credit limits; a debit card > > is linked to a bank account with a certain balance. It?s a much > preferable > > user experience to be able to catch these problems earlier rather than > > waiting for the merchant to attempt the transaction and have it fail (or > > have a user?s account overdrawn). Concretely, Chromium wants to handle > > transactions over $2000 differently from transactions under that amount. > > > > Does this seem reasonable? > > > > > > -- Evan Stade > > > From estade at chromium.org Thu Apr 24 09:37:45 2014 From: estade at chromium.org (Evan Stade) Date: Thu, 24 Apr 2014 09:37:45 -0700 Subject: [whatwg] Additional details for invoking requestAutocomplete In-Reply-To: <CAO4XGS_rXaHxtU1oKypMixwU+iDKocPgvbBuFiV15OYWv6bTnQ@mail.gmail.com> References: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> <CAO4XGS_rXaHxtU1oKypMixwU+iDKocPgvbBuFiV15OYWv6bTnQ@mail.gmail.com> Message-ID: <CAO4XGS9rBiX-Bz8SLa=cfbMbf7UFC1Qyv-VV9=WgiyiS8SgEyA@mail.gmail.com> Also, in response to something Ian wrote on another thread: > Why would this only apply to requestAutocomplete()? Surely it would be > just as important for the case where the user agent is filling in a form > without using that API. That is true, but I don't know of a better way to convey this information from the page to browser. Additional attributes on the cc-number field? > Also, I don't understand how these are supposed to work. How is the > browser supposed to know the balance on my credit cards or bank accounts? > How is the browser supposed to know which of my cards are good for USD and > which are good for GBP? If the browser is just a dumb number memorizer, it probably won't, in which case it may return a card that denies the transaction. The new API doesn't /guarantee/ the returned card will work, it just increases the likelihood of a successful transaction. Conceptually, how the browser /could/ know the balance on the credit cards is if it pings some remote server to obtain this information, or if it remembers each card's credit limit (ignoring how much of the limit may have already been used), etc. -- Evan Stade On Wed, Apr 23, 2014 at 9:13 PM, Evan Stade <estade at chromium.org> wrote: > Specifically, Chromium would disable Wallet for transactions over a > certain limit (at the moment, that's $2k, but this business logic is > subject to change). When Wallet is disabled, users can still store/access > their data in Chrome/Chrome Sync. > > > -- Evan Stade > > > On Wed, Apr 23, 2014 at 5:02 PM, Brian Nicholson <bnicholson at mozilla.com>wrote: > >> This optional argument sounds reasonable to me (FWIW, I'm working on >> the requestAutocomplete implementation for Firefox). The transaction >> fields also seem sensible, but I have no experience with payment APIs, >> so I can't give feedback on how well this will work with payment >> providers in general (and whether any additional fields might be >> useful). Those working on Mozilla's payment APIs are aware of this >> thread, so hopefully they'll be giving feedback if they have anything >> to add. >> >> When I first read this proposal, I was under the impression that the >> browser would somehow detect whether transactions would put users over >> their card limits, but maybe you're going for something simpler than >> that. Could you elaborate on how Chromium will handle these >> transactions differently? >> >> - Brian >> >> >> On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade <est... at chromium.org> wrote: >> >> > Hi WhatWG. >> > >> > Currently, requestAutocomplete lets a user agent provide the same user >> > experience across multiple sites for common data input flows. A site >> > describes the data it desires (via a form and autocomplete attributes), >> and >> > the user agent uses this information and what it knows about the user to >> > expedite data input. For example, if one of the form elements has >> > autocomplete=?cc-number? the browser might provide an experience >> tailored >> > for a payment flow, or if there?s an element with autocomplete=?bday? >> the >> > browser might use an experience that?s tailored for sharing identiy. >> > >> > We?ve found that there are some details of the interaction which might >> > affect the UX which cannot be inferred from the data inputs. We propose >> to >> > add an optional argument to the requestAutocomplete method. Thus >> invocation >> > would look like: >> > >> > form_element. >> requestAutocomplete(details); >> > >> > This |details| argument would be an object where key-value pairs provide >> > additional details regarding the request. The spec should define a set >> of >> > keys and associated data types which are recognized. There are currently >> > two key-value pairs we would like to add: >> > >> > key: ?transactionAmount? >> > value: number >> > description: For data that is going to be applied towards a >> > transaction, the /maximum/ value of the transaction. The browser does >> not >> > guarantee that the returned payment instrument will work, but keeping >> the >> > transaction under this amount will increase the likelihood of receiving >> a >> > valid card number. >> > >> > key: ?transactionCurrency? >> > value: string >> > description: a valid ISO 4217 currency code that describes the >> > currency for transactionAmount. If not provided, the default is ?USD?. >> > >> > Justification? There are upper bounds on certain payment instruments, >> for >> > example different credit cards have different credit limits; a debit >> card >> > is linked to a bank account with a certain balance. It?s a much >> preferable >> > user experience to be able to catch these problems earlier rather than >> > waiting for the merchant to attempt the transaction and have it fail (or >> > have a user?s account overdrawn). Concretely, Chromium wants to handle >> > transactions over $2000 differently from transactions under that amount. >> > >> > Does this seem reasonable? >> > >> > >> > -- Evan Stade >> > >> > > From dbeam at chromium.org Thu Apr 24 21:06:15 2014 From: dbeam at chromium.org (Dan Beam) Date: Thu, 24 Apr 2014 21:06:15 -0700 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise In-Reply-To: <1fb95b4500944205baf2857a6525bc51@BN1PR05MB325.namprd05.prod.outlook.com> References: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> <CANpe7K25BCCFJuS89YQ9Od81ZhPDVdxUoyzP0uz=BTUpnzJqTw@mail.gmail.com> <1fb95b4500944205baf2857a6525bc51@BN1PR05MB325.namprd05.prod.outlook.com> Message-ID: <CANpe7K0bcyBs-yb3mg+C01f=8E+q_r6yNYkiyV=sXzqWYk6ehw@mail.gmail.com> On Wed, Apr 16, 2014 at 6:59 PM, Domenic Denicola < domenic at domenicdenicola.com> wrote: > > From: dbeam at google.com [mailto:dbeam at google.com] On Behalf Of Dan Beam > > > So just pass no argument at all (i.e. arguments.length == 0)? I was under the impression some type of value should always be returned (but I'm biased by blink/v8's current implementation). > > It's equivalent, both for promises and for return values of functions. Both `new Promise(resolve => resolve())` and `new Promise(resolve => resolve(undefined))` give a promise whose fulfillment value is `undefined`. In this sense `resolve` behaves like all non-evil JavaScript functions, where evil is defined as "checking `arguments.length`" ;) > I've seen only positive feedback on this thread, so I've started implementing in Blink. Regarding the rejection argument: requestAutocomplete() can fail in a way that doesn't map intuitively to the current DOMException names (e.g. the invoking <form> has autocomplete="off" or isn't in a frame). Adding new names for these specific failure categories doesn't seem useful to the platform. Additionally, many potential failure causes may have the same reason property[1] ("disabled" => SecurityError, WrongDocumentError?, InvalidAccessError?)** and the terminology differs slightly ("cancel" => AbortError). This seems confusing to web authors, so I propose a new type instead (in IDL): interface AutocompleteError : DOMException { readonly attribute DOMString reason; // matches AutocompleteErrorEvent's reason[1] }; This new type would have a code of 0 (as other new exceptions have; code is deprecated). I've filed a bug to add this to the DOMException name table[2]. -- Dan Beam dbeam at chomium.org [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#the-autocompleteerrorevent-interface [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25457 ** names with "?" are the closest existing error names I could find (but aren?t great) From bzbarsky at MIT.EDU Thu Apr 24 21:17:10 2014 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Fri, 25 Apr 2014 00:17:10 -0400 Subject: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise In-Reply-To: <CANpe7K0bcyBs-yb3mg+C01f=8E+q_r6yNYkiyV=sXzqWYk6ehw@mail.gmail.com> References: <CANpe7K3r4qP2_jrOWJATFW=Cyi3E2n4Y5CwH-HAZwZC6pWnCvg@mail.gmail.com> <4f8a4799a402477a95ba08230c53c42c@BN1PR05MB325.namprd05.prod.outlook.com> <CANpe7K25BCCFJuS89YQ9Od81ZhPDVdxUoyzP0uz=BTUpnzJqTw@mail.gmail.com> <1fb95b4500944205baf2857a6525bc51@BN1PR05MB325.namprd05.prod.outlook.com> <CANpe7K0bcyBs-yb3mg+C01f=8E+q_r6yNYkiyV=sXzqWYk6ehw@mail.gmail.com> Message-ID: <5359E1C6.1020103@mit.edu> On 4/25/14, 12:06 AM, Dan Beam wrote: > interface AutocompleteError : DOMException { DOMException isn't an interface as currently proposed. In general, please check with public-script-coord before minting new exception types; there's been a lot of discussion on that issue recently. -Boris From ian at hixie.ch Fri Apr 25 16:54:53 2014 From: ian at hixie.ch (Ian Hickson) Date: Fri, 25 Apr 2014 23:54:53 +0000 (UTC) Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <CAO4XGS9rBiX-Bz8SLa=cfbMbf7UFC1Qyv-VV9=WgiyiS8SgEyA@mail.gmail.com> References: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> <CAO4XGS_rXaHxtU1oKypMixwU+iDKocPgvbBuFiV15OYWv6bTnQ@mail.gmail.com> <CAO4XGS9rBiX-Bz8SLa=cfbMbf7UFC1Qyv-VV9=WgiyiS8SgEyA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404251934580.7589@ps20323.dreamhostps.com> On Thu, 3 Apr 2014, Mike West wrote: > On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > Also, consider the case of login forms without username fields. You > > > see this sort of thing a lot these days, when sites remember who was > > > last logged in: > > > > > > <form> > > > <label>Password for hober: <input type=password name=pw></label> > > > <p>Not hober? <a href=...>Click here to sign in</a>. > > > </form> > > > > > > It's difficult for tools to manage the user's auth info for such > > > pages. How can tools discover what the username is? The obvious > > > solution, in a world with autocomplete=username, would be to add > > > <input type=hidden autocomplete=username name=username value=hober> > > > to the form. > > > > So far, autocomplete="" hasn't applied to <input type=hidden>. This > > would be a bit weird, giving it a different meaning than usual > > (providing information to the UA, rather than getting information from > > the UA). I'm a bit skeptical of this kind of overloading. > > > > Not sure what the right solution is, though. > > As Garrett noted, this is already a solution Google is using, though not > with explicit syntax, just taking advantage of existing heuristics. > Paving this (potential) cowpath isn't really that weird. > > That said, an alternative might be to add a mechanism of associating > autocompletion metadata with the field in order to give the UA enough > context to fill it in. For example, if a password is being requested for > a known username, that username could be added as an new > "autocomplete-username" attribute (similar to the 'data-*' construct > HTML already supports): > > <input type="password" autocomplete-username="hober"> On Fri, 11 Apr 2014, Edward O'Connor wrote: > > It is kind of weird. Given that, maybe this case should have new syntax. > I'm OK with overloading autocomplete=username or with new syntax. I'm not sure I really understand how autocomplete-* would work (e.g. would you have to specify it for all three fields of a change-password form?). Having autocomplete="" mean something slightly different on type=hidden does make some sense, even if it is overloading. It has the advantage of fitting into the current syntax machinery, too. I've made a proposal in this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25471 I would be particularly interested in feedback from vendors who haven't commented on this yet. Will this overloading work for you? On Fri, 11 Apr 2014, Edward O'Connor wrote: > > > > I actually have a similar problem with purely JS-handled forms even > > unrelated to credentials. Because the form is never really submitted > > (even if we reuse the submit infrastructure, we cancel the 'submit' > > event and handle the work on the JS side), there's never an indication > > to the UA that it should save the fields, and so autofill never works > > right on these forms, even for things like postal addresses or e-mail > > addresses. > > > > For the pure JS case, an API (probably on the <form> itself) would > > make sense and seems relatively easy. I've filed a bug on this: > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 > > This case is pretty weird. Authors are going out of their way to avoid > using the built in platform features that would get them autofill saving > for free. In some cases, they might be doing this precisely because they > want to prevent autofill but can't count on autocomplete=off anymore. I'm not sure what you mean here. The context is a form that is used in a purely scripted fashion. It's not at all obvious how to tell the user agent to save the data in this situation. I don't think authors are going out of their way to avoid using built-in platform features; what feature should they use here? On Fri, 11 Apr 2014, Edward O'Connor wrote: > > > > For the real submission case, I guess what we want is a way to say > > "autocomplete=off" after the fact, basically. An HTTP header seems > > like the most obvious solution. > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 > > > > Again, these need multiple vendors on board to make progress. > > Browsers are moving away from respecting autocomplete=off. I don't think > we should be adding a new but basically equivalent mechanism. On Mon, 21 Apr 2014, Garrett Casto wrote: > > While I agree that it's a concern, I'm not overly worried that this is > going to be abused for a few reasons. > > 1) We talked to some major US banks when disabling autocomplete=off for > passwords, and though they historically have been a big proponent of the > feature they didn't seem bothered that it was no longer going to be > respected. It seems like sites are more accepting of password managers > now. I wouldn't be surprised if a reasonable percentage of > autocomplete=off usage is just inertia at this point. > > 2) A well-intentioned site might use autocomplete=off thinking that it's > a security benefit to their site. Doing this with this new API would be > obvious abuse and it doesn't seem likely that a site would do it unless > they were looking for some way to block password managers. 3) If a site > really wants to go out of their way to make sure that password managers > don't work on their site, there are already ways of doing it. This would > be an easier mechanism, but I'm not sure how much that matters. > > If we still think that this is too likely to be abused, another > possibility might be to only allow the site to assert login succeeded > not that it failed. Not sure how useful that is though, since it's > generally easier to prompt on incorrect login than miss a correct login. I think the way to make progress on this issue would be for the vendors interested in deploying a solution to do so experimentally, and to see how authors use it. On Mon, 14 Apr 2014, Dan Beam wrote: > > I propose requestAutocomplete()[1] should return a Promise. This has > been requested since the creation of this API[2][3] and seems like a > natural fit. Web authors can then call requestAutocomplete() like this: > > form.requestAutocomplete().then(function() { > // form.submit() or some other success action > }, function(errorDetails) { > // handle error based on errorDetails.reason (e.g. "cancel") > }); > > The returned promise would be resolved after the corresponding > "autocomplete" or "autocompleteerror" event is dispatched on the form. > [...] Fine by me. How stable is the whole promise world so far? Are any APIs using it yet? I tried using it in HTML before, but the API changed radically shortly afterwards, so I'm a bit reluctant to start specifying stuff again on this topic before other specs have done so. On Thu, 24 Apr 2014, Dan Beam wrote: > > Regarding the rejection argument: requestAutocomplete() can fail in a > way that doesn't map intuitively to the current DOMException names (e.g. > the invoking <form> has autocomplete="off" or isn't in a frame). > Adding new names for these specific failure categories doesn't seem > useful to the platform. Additionally, many potential failure causes may > have the same reason property[1] ("disabled" => SecurityError, > WrongDocumentError?, InvalidAccessError?)** and the terminology differs > slightly ("cancel" => AbortError). > > This seems confusing to web authors, so I propose a new type instead (in > IDL): > > interface AutocompleteError : DOMException { > readonly attribute DOMString reason; // matches AutocompleteErrorEvent's reason > }; On Fri, 25 Apr 2014, Boris Zbarsky wrote: > > In general, please check with public-script-coord before minting new > exception types; there's been a lot of discussion on that issue > recently. Please report back on the conclusion of this discussion on this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25472 Thanks! On Wed, 23 Apr 2014, Brian Nicholson wrote: > On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: > > > > Currently, requestAutocomplete lets a user agent provide the same user > > experience across multiple sites for common data input flows. A site > > describes the data it desires (via a form and autocomplete > > attributes), and the user agent uses this information and what it > > knows about the user to expedite data input. For example, if one of > > the form elements has autocomplete=?cc-number? the browser might > > provide an experience tailored for a payment flow, or if there?s an > > element with autocomplete=?bday? the browser might use an experience > > that?s tailored for sharing identiy. > > > > We?ve found that there are some details of the interaction which might > > affect the UX which cannot be inferred from the data inputs. We > > propose to add an optional argument to the requestAutocomplete method. > > Thus invocation would look like: > > > > form_element.requestAutocomplete(details); > > > > This |details| argument would be an object where key-value pairs > > provide additional details regarding the request. The spec should > > define a set of keys and associated data types which are recognized. > > There are currently two key-value pairs we would like to add: > > > > key: ?transactionAmount? > > value: number > > description: For data that is going to be applied towards a > > transaction, the /maximum/ value of the transaction. The browser does > > not guarantee that the returned payment instrument will work, but > > keeping the transaction under this amount will increase the likelihood > > of receiving a valid card number. > > > > key: ?transactionCurrency? > > value: string > > description: a valid ISO 4217 currency code that describes the > > currency for transactionAmount. If not provided, the default is ?USD?. > > > > Justification? There are upper bounds on certain payment instruments, > > for example different credit cards have different credit limits; a > > debit card is linked to a bank account with a certain balance. It?s a > > much preferable user experience to be able to catch these problems > > earlier rather than waiting for the merchant to attempt the > > transaction and have it fail (or have a user?s account overdrawn). > > Concretely, Chromium wants to handle transactions over $2000 > > differently from transactions under that amount. > > This optional argument sounds reasonable to me (FWIW, I'm working on the > requestAutocomplete implementation for Firefox). The transaction fields > also seem sensible, but I have no experience with payment APIs, so I > can't give feedback on how well this will work with payment providers in > general (and whether any additional fields might be useful). Those > working on Mozilla's payment APIs are aware of this thread, so hopefully > they'll be giving feedback if they have anything to add. On Thu, 24 Apr 2014, Evan Stade wrote: > Ian wrote: > > Why would this only apply to requestAutocomplete()? Surely it would be > > just as important for the case where the user agent is filling in a > > form without using that API. > > That is true, but I don't know of a better way to convey this > information from the page to browser. Additional attributes on the > cc-number field? Well, if we're going to use type=hidden fields to expose the username, we could also use it to expose the amount and currency. Would that work? On Thu, 3 Apr 2014, Andy Mabbett wrote: > > Why would you define any address components other than those in vCard, a > standard with massive implementation and interoperable with most address > book applications and services? Because vCard doesn't work in China. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From estade at chromium.org Mon Apr 28 11:42:53 2014 From: estade at chromium.org (Evan Stade) Date: Mon, 28 Apr 2014 11:42:53 -0700 Subject: [whatwg] Various autocomplete="" topics In-Reply-To: <alpine.DEB.2.00.1404251934580.7589@ps20323.dreamhostps.com> References: <CAKznnP+gNaf63pHk9ffMyjhPXK0y+5Mg4HkFkFF8wJnzP8XY6Q@mail.gmail.com> <CAO4XGS_rXaHxtU1oKypMixwU+iDKocPgvbBuFiV15OYWv6bTnQ@mail.gmail.com> <CAO4XGS9rBiX-Bz8SLa=cfbMbf7UFC1Qyv-VV9=WgiyiS8SgEyA@mail.gmail.com> <alpine.DEB.2.00.1404251934580.7589@ps20323.dreamhostps.com> Message-ID: <CAO4XGS_RNkMpkobGsXLvTd=AjxTWL5F=gJnxgXQPnZ_z8WbkMw@mail.gmail.com> On Fri, Apr 25, 2014 at 4:54 PM, Ian Hickson <ian at hixie.ch> wrote: > On Thu, 3 Apr 2014, Mike West wrote: > > On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > > > Also, consider the case of login forms without username fields. You > > > > see this sort of thing a lot these days, when sites remember who was > > > > last logged in: > > > > > > > > <form> > > > > <label>Password for hober: <input type=password name=pw></label> > > > > <p>Not hober? <a href=...>Click here to sign in</a>. > > > > </form> > > > > > > > > It's difficult for tools to manage the user's auth info for such > > > > pages. How can tools discover what the username is? The obvious > > > > solution, in a world with autocomplete=username, would be to add > > > > <input type=hidden autocomplete=username name=username value=hober> > > > > to the form. > > > > > > So far, autocomplete="" hasn't applied to <input type=hidden>. This > > > would be a bit weird, giving it a different meaning than usual > > > (providing information to the UA, rather than getting information from > > > the UA). I'm a bit skeptical of this kind of overloading. > > > > > > Not sure what the right solution is, though. > > > > As Garrett noted, this is already a solution Google is using, though not > > with explicit syntax, just taking advantage of existing heuristics. > > Paving this (potential) cowpath isn't really that weird. > > > > That said, an alternative might be to add a mechanism of associating > > autocompletion metadata with the field in order to give the UA enough > > context to fill it in. For example, if a password is being requested for > > a known username, that username could be added as an new > > "autocomplete-username" attribute (similar to the 'data-*' construct > > HTML already supports): > > > > <input type="password" autocomplete-username="hober"> > > On Fri, 11 Apr 2014, Edward O'Connor wrote: > > > > It is kind of weird. Given that, maybe this case should have new syntax. > > I'm OK with overloading autocomplete=username or with new syntax. > > I'm not sure I really understand how autocomplete-* would work (e.g. would > you have to specify it for all three fields of a change-password form?). > > Having autocomplete="" mean something slightly different on type=hidden > does make some sense, even if it is overloading. It has the advantage of > fitting into the current syntax machinery, too. > > I've made a proposal in this bug: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25471 > > I would be particularly interested in feedback from vendors who haven't > commented on this yet. Will this overloading work for you? > > > On Fri, 11 Apr 2014, Edward O'Connor wrote: > > > > > > I actually have a similar problem with purely JS-handled forms even > > > unrelated to credentials. Because the form is never really submitted > > > (even if we reuse the submit infrastructure, we cancel the 'submit' > > > event and handle the work on the JS side), there's never an indication > > > to the UA that it should save the fields, and so autofill never works > > > right on these forms, even for things like postal addresses or e-mail > > > addresses. > > > > > > For the pure JS case, an API (probably on the <form> itself) would > > > make sense and seems relatively easy. I've filed a bug on this: > > > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 > > > > This case is pretty weird. Authors are going out of their way to avoid > > using the built in platform features that would get them autofill saving > > for free. In some cases, they might be doing this precisely because they > > want to prevent autofill but can't count on autocomplete=off anymore. > > I'm not sure what you mean here. The context is a form that is used in a > purely scripted fashion. It's not at all obvious how to tell the user > agent to save the data in this situation. I don't think authors are going > out of their way to avoid using built-in platform features; what feature > should they use here? > > > > On Fri, 11 Apr 2014, Edward O'Connor wrote: > > > > > > For the real submission case, I guess what we want is a way to say > > > "autocomplete=off" after the fact, basically. An HTTP header seems > > > like the most obvious solution. > > > > > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25239 > > > > > > Again, these need multiple vendors on board to make progress. > > > > Browsers are moving away from respecting autocomplete=off. I don't think > > we should be adding a new but basically equivalent mechanism. > > On Mon, 21 Apr 2014, Garrett Casto wrote: > > > > While I agree that it's a concern, I'm not overly worried that this is > > going to be abused for a few reasons. > > > > 1) We talked to some major US banks when disabling autocomplete=off for > > passwords, and though they historically have been a big proponent of the > > feature they didn't seem bothered that it was no longer going to be > > respected. It seems like sites are more accepting of password managers > > now. I wouldn't be surprised if a reasonable percentage of > > autocomplete=off usage is just inertia at this point. > > > > 2) A well-intentioned site might use autocomplete=off thinking that it's > > a security benefit to their site. Doing this with this new API would be > > obvious abuse and it doesn't seem likely that a site would do it unless > > they were looking for some way to block password managers. 3) If a site > > really wants to go out of their way to make sure that password managers > > don't work on their site, there are already ways of doing it. This would > > be an easier mechanism, but I'm not sure how much that matters. > > > > If we still think that this is too likely to be abused, another > > possibility might be to only allow the site to assert login succeeded > > not that it failed. Not sure how useful that is though, since it's > > generally easier to prompt on incorrect login than miss a correct login. > > I think the way to make progress on this issue would be for the vendors > interested in deploying a solution to do so experimentally, and to see how > authors use it. > > > On Mon, 14 Apr 2014, Dan Beam wrote: > > > > I propose requestAutocomplete()[1] should return a Promise. This has > > been requested since the creation of this API[2][3] and seems like a > > natural fit. Web authors can then call requestAutocomplete() like this: > > > > form.requestAutocomplete().then(function() { > > // form.submit() or some other success action > > }, function(errorDetails) { > > // handle error based on errorDetails.reason (e.g. "cancel") > > }); > > > > The returned promise would be resolved after the corresponding > > "autocomplete" or "autocompleteerror" event is dispatched on the form. > > [...] > > Fine by me. > > How stable is the whole promise world so far? Are any APIs using it yet? > > I tried using it in HTML before, but the API changed radically shortly > afterwards, so I'm a bit reluctant to start specifying stuff again on this > topic before other specs have done so. > > > On Thu, 24 Apr 2014, Dan Beam wrote: > > > > Regarding the rejection argument: requestAutocomplete() can fail in a > > way that doesn't map intuitively to the current DOMException names (e.g. > > the invoking <form> has autocomplete="off" or isn't in a frame). > > Adding new names for these specific failure categories doesn't seem > > useful to the platform. Additionally, many potential failure causes may > > have the same reason property[1] ("disabled" => SecurityError, > > WrongDocumentError?, InvalidAccessError?)** and the terminology differs > > slightly ("cancel" => AbortError). > > > > This seems confusing to web authors, so I propose a new type instead (in > > IDL): > > > > interface AutocompleteError : DOMException { > > readonly attribute DOMString reason; // matches > AutocompleteErrorEvent's reason > > }; > > On Fri, 25 Apr 2014, Boris Zbarsky wrote: > > > > In general, please check with public-script-coord before minting new > > exception types; there's been a lot of discussion on that issue > > recently. > > Please report back on the conclusion of this discussion on this bug: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25472 > > Thanks! > > > On Wed, 23 Apr 2014, Brian Nicholson wrote: > > On Mon, Mar 10, 2014 at 1:33 PM, Evan Stade wrote: > > > > > > Currently, requestAutocomplete lets a user agent provide the same user > > > experience across multiple sites for common data input flows. A site > > > describes the data it desires (via a form and autocomplete > > > attributes), and the user agent uses this information and what it > > > knows about the user to expedite data input. For example, if one of > > > the form elements has autocomplete=?cc-number? the browser might > > > provide an experience tailored for a payment flow, or if there?s an > > > element with autocomplete=?bday? the browser might use an experience > > > that?s tailored for sharing identiy. > > > > > > We?ve found that there are some details of the interaction which might > > > affect the UX which cannot be inferred from the data inputs. We > > > propose to add an optional argument to the requestAutocomplete method. > > > Thus invocation would look like: > > > > > > form_element.requestAutocomplete(details); > > > > > > This |details| argument would be an object where key-value pairs > > > provide additional details regarding the request. The spec should > > > define a set of keys and associated data types which are recognized. > > > There are currently two key-value pairs we would like to add: > > > > > > key: ?transactionAmount? > > > value: number > > > description: For data that is going to be applied towards a > > > transaction, the /maximum/ value of the transaction. The browser does > > > not guarantee that the returned payment instrument will work, but > > > keeping the transaction under this amount will increase the likelihood > > > of receiving a valid card number. > > > > > > key: ?transactionCurrency? > > > value: string > > > description: a valid ISO 4217 currency code that describes the > > > currency for transactionAmount. If not provided, the default is ?USD?. > > > > > > Justification? There are upper bounds on certain payment instruments, > > > for example different credit cards have different credit limits; a > > > debit card is linked to a bank account with a certain balance. It?s a > > > much preferable user experience to be able to catch these problems > > > earlier rather than waiting for the merchant to attempt the > > > transaction and have it fail (or have a user?s account overdrawn). > > > Concretely, Chromium wants to handle transactions over $2000 > > > differently from transactions under that amount. > > > > This optional argument sounds reasonable to me (FWIW, I'm working on the > > requestAutocomplete implementation for Firefox). The transaction fields > > also seem sensible, but I have no experience with payment APIs, so I > > can't give feedback on how well this will work with payment providers in > > general (and whether any additional fields might be useful). Those > > working on Mozilla's payment APIs are aware of this thread, so hopefully > > they'll be giving feedback if they have anything to add. > > On Thu, 24 Apr 2014, Evan Stade wrote: > > Ian wrote: > > > Why would this only apply to requestAutocomplete()? Surely it would be > > > just as important for the case where the user agent is filling in a > > > form without using that API. > > > > That is true, but I don't know of a better way to convey this > > information from the page to browser. Additional attributes on the > > cc-number field? > > Well, if we're going to use type=hidden fields to expose the username, we > could also use it to expose the amount and currency. Would that work? > I agree with those upthread who said that overloading autocomplete= to provide information to the user agent is confusing. If we introduce something like autocomplete="transaction-currency" then it's easy to misinterpret that as the site asking the browser what the currency is for the payment method, then having a site author use transaction-currency in a non type=hidden input. So I would prefer a separate attribute called autocomplete-hint="" or something, which has its own set of tags. (also added this comment to the bug) > > > On Thu, 3 Apr 2014, Andy Mabbett wrote: > > > > Why would you define any address components other than those in vCard, a > > standard with massive implementation and interoperable with most address > > book applications and services? > > Because vCard doesn't work in China. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > From beverloo at google.com Tue Apr 29 10:24:42 2014 From: beverloo at google.com (Peter Beverloo) Date: Tue, 29 Apr 2014 18:24:42 +0100 Subject: [whatwg] [Notifications] Notification.hasPermission() instead of Notification.permission Message-ID: <CALt3x6=kNZwZPT7a6aGHnRXHkOQT4mCi_Z=NCkXCGUJHj1_F3A@mail.gmail.com> The Notification specification defines a static Notification.permission accessor, which returns one of {granted, denied, default}. This requires the browser to synchronously determine whether the page has permission to show notifications, whereas checking this may be an asynchronous operation. This is the case in Chrome. Before this becomes a paradigm, could we consider having a static hasPermission() instead, returning a Promise? I'll add a UseCounter to Blink for tracking Notification.permission usage, but it will take some time before conclusive usage data comes in. Thanks, Peter From ian at hixie.ch Tue Apr 29 10:55:13 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 29 Apr 2014 17:55:13 +0000 (UTC) Subject: [whatwg] HTML spec incorrectly suggests that <br> can have its rendering changed with CSS In-Reply-To: <CAAWBYDBxpkUYRiaa-z9YVHUTtbkdpYLuT3zoS4nMHRH+P0forA@mail.gmail.com> References: <52E03D6C.6090406@mozilla.com> <CAAWBYDBxpkUYRiaa-z9YVHUTtbkdpYLuT3zoS4nMHRH+P0forA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404291649590.7589@ps20323.dreamhostps.com> This discussion focused around the various behaviours that browsers have around the rendering of <br>. On Thu, 23 Jan 2014, Boris Zbarsky wrote: > > What Gecko does with <br> is basically to treat it like a special box > type that has special sizing/painting/linebreak behavior. But we do > still allow that box to be positioned/floated, just like an <img>... On Tue, 28 Jan 2014, Elliott Sprehn wrote: > > Blink treats <br> (conceptually) like a subclass of Text, there's > nothing to style because it's just a run of text with a forced break. On Wed, 29 Jan 2014, Tab Atkins Jr. wrote: > > We talked this over in the CSSWG meeting, and came up with a proposal > for non-magical styling that is still very close to current behavior in > all browsers: > > br { > display-box: contents; > content: "\A"; > white-space: pre; > } I've filed a bug to track this. It would be useful if browser vendors could indicate whether they think Tab's proposal is satisfactory (in particular, is 'display-box' something that browsers will implement? Apparently Gecko is doing it, anyone else?). https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503 -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bruant.d at gmail.com Tue Apr 29 14:32:39 2014 From: bruant.d at gmail.com (David Bruant) Date: Tue, 29 Apr 2014 23:32:39 +0200 Subject: [whatwg] hidden attribute useless with display: flex? Message-ID: <53601A77.9050102@gmail.com> Hi, // CSS: div{ display: flex; } // HTML: <div hidden></div> Per spec, the div should be shown right? I imagine there is no way back on that? Does it mean hidden only works when the default (UA stylesheet) display value is kept? Does it mean hidden is completely useless when trying to combine it with display:flex? What I'm trying to do is just that an element have display:flex and to hide it with the hidden attribute when I don't need the element to be shown. I guess my only option is changing style.display? Thanks, David From ian at hixie.ch Tue Apr 29 15:27:59 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 29 Apr 2014 22:27:59 +0000 (UTC) Subject: [whatwg] <canvas> feedback In-Reply-To: <69477B5B-A7A4-4674-B267-09EC2499C1F0@adobe.com> References: <69477B5B-A7A4-4674-B267-09EC2499C1F0@adobe.com> Message-ID: <alpine.DEB.2.00.1404291905070.7589@ps20323.dreamhostps.com> On Tue, 8 Apr 2014, Rik Cabanier wrote: > On Mon, Apr 7, 2014 at 3:35 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > > > > > > > So this is not how most implementations currently have it > > > > > > defined. > > > > > > > > > > I'm unsure what you mean. Browser implementations? If so, they > > > > > definitely do store the path in user coordinates. The spec > > > > > currently says otherwise [1] though. > > > > > > > > I'm not sure what you're referring to here. > > > > > > All graphics backends for canvas that I can inspect, don't apply the > > > CTM to the current path when you call a painting operator. Instead, > > > the path is passed as segments in the current CTM and the graphics > > > library will apply the transform to the segments. > > > > Right. That's what the spec says too, for the current default path. > > No, the spec says this: > > For CanvasRenderingContext2D objects, the points passed to the methods, > and the resulting lines added to current default path by these methods, > must be transformed according to the current transformation matrix > before being added to the path. As far as I can tell, these are block-box indistinguishable statements. Can you show a test case that demonstrates how the spec doesn't match browsers? > > > [use case: two paths mapping to the same region] > > > > Just use two different IDs with two different addHitRegion() calls. > > That's a lot less complicated than having a whole new API. > > That doesn't work if you want to have the same control for the 2 areas, > from the spec for addHitRegion: > ># If there is a previous region with this control, remove it from the ># scratch bitmap's hit region list; then, if it had a parent region, ># decrement that hit region's child count by one. Interesting. You mean like a case where you had a button that got split into multiple segments animated separately that then joined together, but where you want to be able to click on any part of that split-up button? Hmm. There's several ways we could support that. The simple way would be to allow multiple regions to refer to a control. The more subtle way would be to allow the control logic to defer to the parent region, but that's probably a bad idea (where would you put the parent region?). So I guess the question is: is it more useful to be able to refer to the same control from multiple regions, or is it more useful for the previous region to be automatically discarded when you add a new one? It's probably more useful to have multiple regions. You can always do the discarding using IDs. > Even if you don't use the control, it would be strange to have 2 > separate hit regions for something that represents 1 object. Why? I think that makes a lot of sense. There are multiple regions, why not have multiple hit regions? This becomes especially true when the multiple regions might be differently overlapped by other regions, or where different parts of the canvas are renderings from different angles of the same underlying scene. It would be silly for things to be easier to do with two canvases than one, in that kind of case, no? I've changed the spec to not discard regions based on the control. > > > > On Fri, 6 Dec 2013, J?rg Lehni wrote: > > > > > > > > > > Instead of using getCurrentPath and setCurrentPath methods as a > > > > > solution, this could perhaps be solved by returning the internal > > > > > path instead of a copy, but with a flag that would prevent > > > > > further alterations on it. > > > > > > > > > > The setter of the currentPath accessor / data member could then > > > > > make the copy instead when a new path is to be set. > > > > > > > > > > This would also make sense from a a caching point of view, where > > > > > storing the currentPath for caching might not actually mean that > > > > > it will be used again in the future (e.g. because the path's > > > > > geometry changes completely on each frame of an animation), so > > > > > copying only when setting would postpone the actual work of > > > > > having to make the copy, and would help memory consummation and > > > > > performance. > > > > > > > > I don't really understand the use case here. > > > > > > Jurg was just talking about an optimization (so you don't have to > > > make an internal copy) > > > > Sure, but that doesn't answer the question of what the use case is. > > From my recent experiments with porting canvg ( > https://code.google.com/p/canvg/) to use Path2D, they have a routine > that continually plays a path into the context which is called from a > routine that does the fill, clip or stroke. Because that routine can't > simply set the current path, a lot more changes were needed. Sure, but the brief transitional cost of moving from canvas current default paths to Path2D objects is minor on the long run, and not worth the added complexity cost paid over the lifetime of the Web for the feature. So for something like this, we need a stronger use case than "it makes transitioning to Path2D slightly easier". > > On Wed, 12 Mar 2014, Rik Cabanier wrote: > > > > > > > > > > > > You can do unions and so forth with just paths, no need for > > > > > > regions. > > > > > > > > > > How would you do a union with paths? If you mean that you can > > > > > just aggregate the segments, sure but that doesn't seem very > > > > > useful. > > > > > > > > You say, here are some paths, here are some fill rules, here are > > > > some operations you should perform, now give me back a path that > > > > describes the result given a particular fill rule. > > > > > > I think you're collapsing a couple of different concepts here: > > > > > > path + fillrule -> shape > > > union of shapes -> shape > > > shape can be converted to a path > > > > I'm saying "shape" is an unnecessary primitive. You can do it all with > > paths. > > > > union of (path + fillrule)s -> path > > No, that makes no sense. What would you get when combining a path with a > fillrule and no fillrule? Why would you combine a path with a fillrule and no fillrule? I'm saying that you can replace "shape" with "path+fillrule", that's all. > > > > A shape is just a path with a fill rule, essentially. > > > > > > So, a path can now have a fillrule? Sorry, that makes no sense. > > > > I'm saying a shape is just the combination of a fill rule and a path. > > The path is just a path, the fill rule is just a fill rule. > > After applying a fillrule, there is no longer a path. You can *convert* > it back to a path that describes the outline of the shape if you want, > but that is something different. The way you've defined things now, you > can apply another fill rule on a path with a fill rule. What would the > result of that be? Exactly what you say -- you'd take the path, and apply the other fill rule to it. Applying fill rules to paths seems like a known operation. > > > > Anything you can do with one you can do with the other. > > > > > > You can't add segments from one shape to another as shapes represent > > > regions. Likewise, you can't union, intersect or xor path segments. > > > > But you can union, intersect, or xor lists of pairs of paths and > > fillrules. > > would you start throwing when doing these operations on paths without > fill rules? I'm not saying Path2D objects would get a built-in fill rule. I'm saying that you would pass Path2D objects and fill rules together. An analogy: You could have a "Length" object that represented a particular length, e.g. "4cm" or "12 lightyears". You could add these "Length" objects together, so "1 inch" plus "2cm" is "0.0454m" or some such. You could, instead, have numbers and units, e.g. "4" "cm" and "12" "lightyears". Then you could add pairs of numbers and units, as in "1" "inch" plus "2" "cm" is "0.0454" "m". Numbers are like paths, units are like fill rules. > > > > > > > The path object should represent the path in the graphics > > > > > > > state. You can't add a stroked path or text outline to the > > > > > > > graphics state and then fill/stroke it. > > > > > > > > > > > > Why not? > > > > > > > > > > As designed today, you could fill it, as long as you use > > > > > non-zero winding. If you use even-odd, the results will be very > > > > > wrong. (ie where joins and line segments meet, there will be > > > > > white regions) > > > > > > > > I think "wrong" here implies a value judgement that's unwarranted. > > > > > > "Wrong" meaning: if the author has a bunch of geometry and wants to > > > put it in 1 path object so he can just execute 1 fill operation, he > > > might be under the impression that "adding" the geometry will just > > > work. > > > > Well, sure, an author might be under any number of false impressions. > > > > The API has a way for a bunch of paths to be merged with a single > > fillrule to generate a new path with no crossing subpaths (which is > > also fillrule agnostic), essentially giving you the union of the > > shapes represented by those paths interpreted with that fillrule. > > Is this the API you're referring to? > > path = new Path2D(paths [, fillRule ] ) > > The first argument could point to paths that need different winding > rules. Sure, if you happen to make your paths with different winding rules, you might have that. In that case, merge all your paths that need one winding rule together, then merge all your paths that need the other winding rule together, then merge the two resulting paths together. If this is something that people do a lot (why would it be?) then we can provide a dedicated API for that. > > > There are very few use cases where you want to add partial path > > > segments together but I agree that there are some cases that it's > > > useful to have. > > > > I disagree that there few such cases. Pretty much any time you create > > a path, you are adding partial path segments together. Whether you do > > so using one Path object all at once or multiple Path objects that you > > later add together is just a matter of programming style. > > It's the multiple path objects use case that is unclear to me. Is there > any tool/library that does this? Right now, with canvas, any time you create a path with a transform in the middle of creating the path, you are doing the equivalent of using multiple Path2D objects then merging them. > With the new wording, the last sentence should be updated: > > Subpaths in the newly created path must wind clockwise, regardless of > the direction of paths in path. > > Since you now create 'holes', the separate paths need to be reoriented > like you specify in other parts. Good point, fixed. Thanks. > > addPath() is useful for shifting a path according to a transform. > > Why not just transform() then? I'm not sure what you're proposing here. Can you elaborate? > > addPathByStrokingPath() is for creating a stroked path. > > addText() is for writing text. > > > > I don't see how removing any of them is a win. > > Yes, they are useful. The issue is that they shouldn't be implemented as > currently specified. Instead of arguing for their removal, then, describe the use case that they do not handle. > > > > > > On Mon, 4 Nov 2013, Rik Cabanier wrote: > > > > > > > > > > > > > > However, for your example, I'm unsure what the right > > > > > > > solution is. The canvas specification is silent on what the > > > > > > > behavior is for non-invertible matrices. > > > > > > > > > > > > What question do you think the spec doesn't answer? > > > > > > > > > > > > > I think setting scale(0,0) or another matrix operation that > > > > > > > is not reversible, should remove drawing operations from the > > > > > > > state because: - how would you stroke with such a matrix? > > > > > > > > > > > > You'd get a point. > > > > > > > > > > How would you get a point? the width is scaled to 0. > > > > > > > > That's how you get a point -- scale(0,0) essentially reverts > > > > everything to a zero dimensional point. > > > > > > OK, but the width of the point is also transformed to 0 so you get > > > nothing. > > > > Points are always zero-width, by definition. > > You can still stroke it though and get a point of the strokewidth. If you are scaling by 0, the strokeWidth essentially gets scaled to 0 also. > > > The APIs that you define, have use cases and I agree with them. > > > However the way you defined those APIs does not make sense and will > > > not give the result that authors want. > > > > The way to make this point would be to start from the use case, > > describe the desired effect, show the "obvious" way to achieve this > > using the API, and then demonstrate how it doesn't match the desired > > effect. > > The obvious way is to go with Shape2D. At no point in the steps I just described does giving a solution enter into the equation. > It's not because I invented it; many advanced graphics APIs came offer > this (including D2D and skia) I'm not arguing that Shape2D is a bad idea, nor that it is a good idea. I'm arguing that you haven't explained the use cases or shown why the current spec doesn't address the use cases. > > > The bad news is that this algorithm is very expensive and there are > > > few libraries that do a decent job (I only know of 1). So, it's not > > > realistic to add this to the Path2D object. > > > > I don't really see why it's unrealistic. In most cases, the user agent > > doesn't actually have to do any work -- e.g. if all that you're doing > > is merging two paths so that you can fill them simultaneously later, > > the UA can just keep the two paths as is and, when necessary, fill > > them. > > > > For cases where you really want to have this effect -- e.g. when you > > want to get the outline of the dashed outline of text -- then I don't > > really see any way to work around it. > > That is true. That is why I proposed to make the interface more limited > for now until there is a time that this functionality is available. Making the interface more limited fails to address the use cases that are currently addressed. > > > The reason for that is that even though a UA could emulate the union > > > by doing multiple fill operations, Path2D allows you to stroke > > > another path object. At that point, you really have to do > > > planarization. By defining a Shape2D object and not allowing it to > > > be stroked, we can work around this. > > > > Sure, by limiting the feature set dramatically we can avoid the cases > > where you have to do the hard work, but we also lose a bunch of > > features. > > For now. They can be added later. > Until then, this is confusing implementors. The only thing I see that is confusing implementors here is the forking of the canvas spec that you and W3C staff are doing at the W3C. If you are concerned about confusion, then stop doing that. Then, maybe, arguments about the WHATWG spec being confusing could have credibility. > > > > > No one has implemented them and they are confusing the browser > > > > > vendors. > > > > > > > > I don't think they're confusing anyone. > > > > > > The blink people were looking at adding this until they thought it > > > through and realized that it wouldn't work. > > > > Realised what wouldn't work? As far as I'm aware, there's nothing that > > wouldn't work. > > See this thread: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/168925.html I see nothing in that e-mail that shows anyone confused. Could you be more specific? On Tue, 8 Apr 2014, Justin Novosad wrote: > > > > > > For example, there is no locale for font family resolution > > > > I'm not clear on what you mean by "locale" here. What is the locale > > that a displayed <canvas> in a Document in a browsing context has, > > that a non-displayed <canvas> outside a Document and without a > > browsing context does not have? > > I am not sure exactly how this relates to the specification, but when > reading the code in Blink, I saw that font family resolution goes > through different paths if the view has a Korean, Chinese or Japanese > locale. Some OSes allow you to have different locales on a per window > basis, so you need to have a view (i.e. a browsing context) associated > with the Document in order to resolve this. Ah, I see. I don't think the HTML spec mentions this (I don't know what it would say exactly), but I would recommend using the script's script settings object's responsible browsing context or script's script setting object's responsible document or something similar. That way it's defined regardless of what the <canvas> element is. > > > and it is not possible to resolve font sizes in physical length > > > units unless the document is associated with a view. > > > > Why not? The canvas has a pixel density (currently always 1:1), no? > > 1:1 is not a physical pixel density. To resolve a font size that is > specified in physical units (e.g. millimeters or inches) you need > something like a DPI value, which requires information about the output > device. No, not any more. CSS "physical" units are defined as mapping to CSS pixels at 96 CSS pixels per CSS inch, and canvas is defined as mapping CSS pixels to canvas coordinate space units at one CSS pixel per coordinate space unit. As far as I know, all browsers do this now. > > > My 2 cents: specifying fallback behaviors for all use cases that are > > > context dependent could be tedious and I have yet to see a > > > real-world use case that requires being able to paint a canvas in a > > > frame-less document. Therefore, I think the spec should clearly > > > state <canvas> elements that are in a document without a browsing > > > context are unusable. Not sure what the exact behavior should be > > > though. Should an exception be thrown upon trying to use the > > > rendering context? Perhaps canvas draws should fail silently, and > > > using the canvas as an image source should give transparent black > > > pixels? > > > > As far as I can tell, this is all already specified, and it just gets > > treated like a normal canvas. > > Agreed. The fallback behavior is specified. But is it good enough? There > will be discrepancies, sometimes large ones, between text rendered with > and without a browsing context. I don't think there should be any discrepancies. > > Instead, we should use adaptive algorithms, for example always using > > the prettiest algorithms unless we find that frame rate is suffering, > > and then stepping down to faster algorithms. > > Such an adaptive algorithm implies making some kind of weighted decision > to chose a reasonable compromise between quality and performance. > Sounds like the perfect place to use a hint. If we really need a hint. But do we? Do we have data showing that adaptive algorithms can't do a good job without a hint? > One issue that comes to mind is what happens if stroke or fill are > called while the CTM is non-invertible? To be more precise, how would > the styles be mapped? If the fillStyle is collapsed to a point, does > that mean the path gets filled in transparent black? If we go down this > road, we will likely uncover more questions of this nature. The spec handles fills already as far as I can tell (e.g. "When the value is a color, it must not be affected by the transformation matrix when used to draw on bitmaps", "If a radial gradient or repeated pattern is used when the transformation matrix is singular, the resulting style must be transparent black", and so on). For strokes, you get nothing if the stroke is transformed to 0. On Tue, 8 Apr 2014, Rik Cabanier wrote: > > > > > > Just to be clear, we should support this because otherwise the > > > results are just wrong. For example, here some browsers currently > > > show a straight line in the default state, and this causes the > > > animation to look ugly in the transition from the first frame to the > > > secord frame (hover over the yellow to begin the transition): > > > > > > http://junkyard.damowmow.com/538 > > > > > > Contrast this to the equivalent code with the transforms explicitly > > > multiplied into the coordinates: > > > > > > http://junkyard.damowmow.com/539 > > > > > > I don't see why we would want these to be different. From the > > > author's perspective, they're identical. > > These examples are pretty far fetched. > > How many time do people change the CTM in the middle of a drawing > operation and not change the geometry? That kind of reasoning is not how we design a good platform. A good platform is consistent and predictable. It doesn't have surprises. Intuitively, a transform (as in 538) is equivalent to the same logic with the transform explicitly applied (as in 539). It is surprising if this is not the case. We should make sure our platform is a good platform when we can. It has enough crazy surprises that we can't prevent as it is. On Tue, 8 Apr 2014, Rik Cabanier wrote: > > The spec is still confusingly written and could be misinterpreted: > > Create a new path that describes the edge of the areas that would be > covered if a straight line of length equal to the styles lineWidth was > swept along each subpath in path while being kept at an angle such that > the line is orthogonal to the path being swept, replacing each point > with the end cap necessary to satisfy the styles lineCap attribute as > described previously and elaborated below, and replacing each join with > the join necessary to satisfy the styles lineJoin type, as defined > below. > > Maybe could become: > > Create a new path that describes the edge of the coverage of the following > areas: > - a straight line of length equal to the styles lineWidth that was swept > along each subpath in path while being kept at an angle such that the line > is orthogonal to the path being swept, > - the end cap necessary to satisfy the styles lineCap attribute as > described previously and elaborated below, > - the join with the join necessary to satisfy the styles lineJoin type, as > defined below. Can you elaborate on what the possible misinterpretation of the current paragraph is that is resolved by this change? On Thu, 3 Apr 2014, J?rg Lehni wrote: > > When both filling and stroking a path and then drawing it with with an > opacity of less than 100%, the path will be rendered differently than in > an SVG (a large stroke width will make the issue more apparent): > > - In Canvas, both the fill and the stroke will be rendered with the > given opacity, and the fill will shine through the inner half of the > stroke. > > - In SVG, the stroke will cover the fill, and the fill will not shine > through the inner half of the stroke, regardless of the opacity. > > If you'd like to emulate the SVG behavior in Canvas (which we happen to > do in Paper.js), then the only way to do so currently is to draw the > path's fill and stroke at 100% opacity into a separate canvas, and then > blit the whole thing over with the given opacity. > > This is *much* slower than directly drawing into the Canvas, and happens > to be one of the worst bottlenecks in Paper.js > > I would really appreciate a solution to this problem. Interesting. Would you still want the overlapping in the case of the stroke itself being semi-transparent, though? On Mon, 7 Apr 2014, Rik Cabanier wrote: > > Maybe this would better be solved by a function that does fill and > stroke at the same time, for instance: > > void fillAndStroke(optional CanvasFillRule fillRule = "nonzero"); > void fillAndStroke(Path2D path, optional CanvasFillRule fillRule = > "nonzero"); > > globalAlpha would then apply to the operation as a whole. This would also allow us to shift the fill so that it doesn't overlap with the stroke, so that in the case of a semi-transparent stroke, it doesn't overlap the fill. On Mon, 7 Apr 2014, J?rg Lehni wrote: > > Well this particular case, yes. But in the same way we allow a group of > items to have an opacity applied to in Paper.js, and expect it to behave > the same ways as in SVG: The group should appear as if its children were > first rendered at 100% alpha and then blitted over with the desired > transparency. > > Layers would offer exactly this flexibility, and having them around > would make a whole lot of sense, because currently the above can only be > achieved by drawing into a separate canvas and blitting the result over. > The performance of this is real low on all browsers, a true bottleneck > in our library currently. It's not clear to me why it would be faster if implemented as layers. Wouldn't the solution here be for browsers to make canvas-on-canvas drawing faster? I mean, fundamentally, they're the same feature. On Sat, 5 Apr 2014, Dirk Schulze wrote: > > I looked at the behavior of negative width or height for the rect() and > strokeRect() functions. > > All browsers normalize the passed parameters for strokeRect() to have > positive width and height. > > strokeRect(90,10,-80,80) ?> strokeRect(10,10,80,80) > > http://jsfiddle.net/za945/ http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2978 > Just WebKit seems to normalize for rect() as well: > > http://jsfiddle.net/VT4MG/ http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2979 > The behavior of normalizing is not specified. Especially it seems odd > that the behavior for fillRect()/strokeRect() should differ from rect(). > So we should either normalize for all functions or don?t do it for all > IMO. > > Note: fillRect() and clearRect() are not affected. The behavior for > rect() is important for filling with different winding rules as well. It > is not just stroking with dash arrays that is effected. On Sat, 5 Apr 2014, Rik Cabanier wrote: > > yes, the spec needs to say "in that order" as it does for fillRect and > strokeRect. On Sat, 5 Apr 2014, Rik Cabanier wrote: > > It also seems that only firefox is following the spec [1] when width or > height are 0: http://jsfiddle.net/za945/2/ http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2981 > I'm unsure why such a rectangle is defined as a straight line. On Sun, 6 Apr 2014, Dirk Schulze wrote: > > You mean you would rather let it draw a one dimensional rectangle? So > for the dimension that is not zero, you would see two overlapping lines > + the 0 dimensional sides? > > That seems indeed to be the case for IE, Safari and Blink: > http://jsfiddle.net/Gh9XK/ On Mon, 7 Apr 2014, Justin Novosad wrote: > > Dashing is one thing that would be affected. I think some > implementations are currently in a non-compliant state probably because > the line dashing feature was added recently. Back when strokeRect was > originally implemented, we could get away with blindly normalizing > rectangles because there was no impact on the rendering result. The > other thing that is affected is fill rule application. For example, if > you have a path that contains two intersecting rectangles and you are > filling in with the nonzero rule. If one of the two rectangles is > flipped, then the intersection region should be unfilled. If the > rectangles are "normalized" internally by the implementation, then you > will get the wrong (non spec compliant) result. I've added "in that order" to rect(). I couldn't find the original reason for strokeRect() only drawing one line in the one-dimensional case, though it dates back to 2007 at least. I haven't changed rect() to do that too. On Sun, 6 Apr 2014, Dirk Schulze wrote: > > The spec says that the object TextMetrics[1] must return font and actual > text metrics. All things require information from the font or the font > system. In many cases either font or font system just do not provide > these information. Which cases? The information is needed for text layout purposes; if the browser can't get the information, how is it conforming to CSS? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Apr 29 16:26:13 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 29 Apr 2014 23:26:13 +0000 (UTC) Subject: [whatwg] canvas drawImage and EXIF orientation metadata In-Reply-To: <534E997A.5090504@mit.edu> References: <534E1040.3040103@mit.edu> <CABpaAqRx0Meo+bS9TnzBO_AVTm8K1zVeEmfobDV-Za9QCYEtSA@mail.gmail.com> <534E997A.5090504@mit.edu> Message-ID: <alpine.DEB.2.00.1404292247220.7589@ps20323.dreamhostps.com> On Wed, 16 Apr 2014, Boris Zbarsky wrote: > > Right now canvas drawImage ignores EXIF orientation metadata. > > Could we add a version that doesn't do that? Especially with CSS > growing things like the image-orientation property, it would be good to > support drawing the image in its correct orientation. On Wed, 16 Apr 2014, Justin Novosad wrote: > > But why a new version of drawImage? Couldn't we just modify the existing > drawImage definition to state that it takes into account the > image-orientation property on the source image? The default value for > image-orientation is 0deg, which corresponds to the current drawImage > behavior. So I think we can make that change to the drawImage spec > without breaking stuff, as long as we make the change while > image-orientation is still an experimental feature. On Wed, 16 Apr 2014, Anne van Kesteren wrote: > > Why is image-orientation in CSS for <img>? For background-image that > makes sense, but if you are actually affecting the semantics of the > image that is displayed, it seems like it should be in HTML or a hint in > the image format. On Wed, 16 Apr 2014, Justin Novosad wrote: > > Yes, that makes a lot of sense IMHO. I just posted feedback to www-style The feedback seemed positive: http://lists.w3.org/Archives/Public/www-style/2014Apr/thread.html#msg179 This proposal seems pretty reasonable. I'm tracking this in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 On Wed, 16 Apr 2014, Justin Novosad wrote: > > Another use case to think about is: XHR->Blob->ImageBitmap->Canvas(2D or > WebGL) With that data flow, there is no opportunity to use a CSS > property to tweak image orientation. > There is this idea though: http://wiki.whatwg.org/wiki/ImageBitmap_Options Tracking this in: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25507 If other vendors want to do this, please comment on the bug (or here). Here is a summary of related bugs: Regarding EXIF: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23510 Allow EXIF data to be passed to toBlob() This is pending implementation interest from browsers outside Mozilla, and someone coming up with a way to map EXIF to JSON in a well-defined way. https://www.w3.org/Bugs/Public/show_bug.cgi?id=23511 Expose EXIF data of images in <img> elements This is pending implementation interest and would also benefit from a way to map EXIF to an API in a well-defined way. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25507 Have createImageBitmap() take options, e.g. to honour EXIF orientation This is pending implementation interest outside Chrome. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 Have an attribute that honours EXIF orientation This seems to have implementation interest from everyone, and I'll hopefully be adding it soon. Need a good name; if you have a suggestion, add it to the bug. Regarding drawImage(): https://www.w3.org/Bugs/Public/show_bug.cgi?id=17427 drawImage() should accept SVGImageElement (<svg:image>) This is blocked on the SVG spec being updated to define image loading in a suitable level of detail. It could also do with interest from browser vendors other than Mozilla. Regarding ImageBitmap: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21346 Have ImageBitmap expose height and width attributes This is pending implementation interest outside Chrome. Regarding <img>: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842 Feature to make <img> elements not load their images until needed This is something I plan to deal with at the same time as <script> preloading, <object> preloading, et al. Right now I'm waiting to see if public-web-perf (the W3C WG) is going to move on this topic. No ETA. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24711 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24958 Refactor the image loading model; When exactly should "update the image data" run? The current <img> loading model doesn't match browsers well enough and I need to work on that. If you have thoughts on how image loading should work, please comment on bug 24711 soon. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From junov at google.com Tue Apr 29 16:35:52 2014 From: junov at google.com (Justin Novosad) Date: Tue, 29 Apr 2014 16:35:52 -0700 Subject: [whatwg] <canvas> feedback In-Reply-To: <alpine.DEB.2.00.1404291905070.7589@ps20323.dreamhostps.com> References: <69477B5B-A7A4-4674-B267-09EC2499C1F0@adobe.com> <alpine.DEB.2.00.1404291905070.7589@ps20323.dreamhostps.com> Message-ID: <CABpaAqQGbexMVgO6Nq6JrXg4c7_1bpG_0QF=Vg2K+e=B=OBScA@mail.gmail.com> > > > > > > and it is not possible to resolve font sizes in physical length > > > > units unless the document is associated with a view. > > > > > > Why not? The canvas has a pixel density (currently always 1:1), no? > > > > 1:1 is not a physical pixel density. To resolve a font size that is > > specified in physical units (e.g. millimeters or inches) you need > > something like a DPI value, which requires information about the output > > device. > > No, not any more. CSS "physical" units are defined as mapping to CSS > pixels at 96 CSS pixels per CSS inch, and canvas is defined as mapping CSS > pixels to canvas coordinate space units at one CSS pixel per coordinate > space unit. As far as I know, all browsers do this now. > Right... So I think there is a bug in Blink then. Thanks. > > > > > My 2 cents: specifying fallback behaviors for all use cases that are > > > > context dependent could be tedious and I have yet to see a > > > > real-world use case that requires being able to paint a canvas in a > > > > frame-less document. Therefore, I think the spec should clearly > > > > state <canvas> elements that are in a document without a browsing > > > > context are unusable. Not sure what the exact behavior should be > > > > though. Should an exception be thrown upon trying to use the > > > > rendering context? Perhaps canvas draws should fail silently, and > > > > using the canvas as an image source should give transparent black > > > > pixels? > > > > > > As far as I can tell, this is all already specified, and it just gets > > > treated like a normal canvas. > > > > Agreed. The fallback behavior is specified. But is it good enough? There > > will be discrepancies, sometimes large ones, between text rendered with > > and without a browsing context. > > I don't think there should be any discrepancies. > One major discrepancy I noticed is that web font resolution fails but I don't think that is due to lack of a browsing context per se. It is more precisely due to the fact that we don't compute style on documents that are not displayed (web fonts are defined in CSS). > > > Instead, we should use adaptive algorithms, for example always using > > > the prettiest algorithms unless we find that frame rate is suffering, > > > and then stepping down to faster algorithms. > > > > Such an adaptive algorithm implies making some kind of weighted decision > > to chose a reasonable compromise between quality and performance. > > Sounds like the perfect place to use a hint. > > If we really need a hint. But do we? Do we have data showing that adaptive > algorithms can't do a good job without a hint? > Fair enough. Will give it a try. > On Mon, 7 Apr 2014, Justin Novosad wrote: > > > > Dashing is one thing that would be affected. I think some > > implementations are currently in a non-compliant state probably because > > the line dashing feature was added recently. Back when strokeRect was > > originally implemented, we could get away with blindly normalizing > > rectangles because there was no impact on the rendering result. The > > other thing that is affected is fill rule application. For example, if > > you have a path that contains two intersecting rectangles and you are > > filling in with the nonzero rule. If one of the two rectangles is > > flipped, then the intersection region should be unfilled. If the > > rectangles are "normalized" internally by the implementation, then you > > will get the wrong (non spec compliant) result. > > I've added "in that order" to rect(). > Thanks. > I couldn't find the original reason for strokeRect() only drawing one line > in the one-dimensional case, though it dates back to 2007 at least. That speaks for itself: If no one has complained about that since 2007... > I haven't changed rect() to do that too. > Good. I think it is best for rect to not optimize to a line because that would affect filling in an undesirable way and it would affect the start point of the next sub-path. That being said, it is probably safe to optimize it to two lines, but that does not have to be detailed in the spec since it is an implementation optimization that has no effect on the rendered result. > > On Sun, 6 Apr 2014, Dirk Schulze wrote: > > > > The spec says that the object TextMetrics[1] must return font and actual > > text metrics. All things require information from the font or the font > > system. In many cases either font or font system just do not provide > > these information. > > Which cases? The information is needed for text layout purposes; if the > browser can't get the information, how is it conforming to CSS? > It conforms by applying approximation rules (or guesses?) that derive the missing metrics from the ones that are available. It's ugly, but it kinda works. From ian at hixie.ch Tue Apr 29 16:48:41 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 29 Apr 2014 23:48:41 +0000 (UTC) Subject: [whatwg] BroadcastChannel should support structured clones In-Reply-To: <CA+c2ei_4hFxmegCK13LyiZV4pjwou_TyCUO44HrqizccR5VZvA@mail.gmail.com> References: <CA+c2ei-4u-iMSts6z0owHi2V8Z6bEXhgj1_WyJmak+mACWR1VA@mail.gmail.com> <CA+c2ei_4hFxmegCK13LyiZV4pjwou_TyCUO44HrqizccR5VZvA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404292331410.7589@ps20323.dreamhostps.com> On Thu, 17 Apr 2014, Jonas Sicking wrote: > > It would be very useful to be able to send structured data, including > Blobs, through the BroadcastChannel API. > > This is something we've seen any time we've done storage or message > passing, that one of the first thing authors ask for is to not have to > do JSON serialization/parsing manually. The ability to pass ArrayBuffers > and Blobs is somewhat less commonly asked for, likely because binary > data is less often used, but seems important nonetheless. > > We can't allow transferring of objects, since you can't transfer > something to all listeners of a broadcasting API. But plain structured > clones should be no problem to support conceptually (though more work to > implement of course). > > We've started looking at doing structured clone support for Firefox and > likely won't ship until we have that implemented. This would make a lot of sense. I think when I was first speccing this I wanted to avoid transferring and forgot that you could clone without transferring! I see that you filed a bug on this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25415 ...so I'll track it there. For implementation purposes you can assume that I'm going to make this change. On Thu, 17 Apr 2014, Jonas Sicking wrote: > > Another thing that seems like an oversight in the spec is that the spec > currently says that BroadcastChannel should be exposed in Window > context. We should also expose it in Worker contexts. I had filed a bug to track this earlier: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24414 If you want to implement this in workers please do go ahead. I was just waiting for people to implement it at all before doing the minor work of updating the spec for workers (mostly, as noted in the bug, changing the "responsible document" stuff to check for worker event loops instead when in a worker, and excluding suspended workers). I've moved the bug back onto my radar. For people following on at home, there's also this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25414 ...relating to the order of events in a broadcast channel, and this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25413 ...wherein I'm about to change how channel names are exposed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From bruant.d at gmail.com Wed Apr 30 02:36:19 2014 From: bruant.d at gmail.com (David Bruant) Date: Wed, 30 Apr 2014 11:36:19 +0200 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <53601A77.9050102@gmail.com> References: <53601A77.9050102@gmail.com> Message-ID: <5360C413.5070003@gmail.com> Ok, sorry, I was pissed off... The web platform triggers this sort of reactions sometimes :-) Constructive proposal: * a special value for the hidden attribute that forces the element to be hidden regardless of what the CSS or style attribute says for the display value. Maybe `hidden="force"`? This might break existing website which would use the "force" value, but since it had no special meaning currently and there is no good reason to use this value, I'd say the odds are very low. Any implementor interested? David Le 29/04/2014 23:32, David Bruant a ?crit : > Hi, > > // CSS: > div{ > display: flex; > } > > // HTML: > <div hidden></div> > > Per spec, the div should be shown right? I imagine there is no way > back on that? > Does it mean hidden only works when the default (UA stylesheet) > display value is kept? Does it mean hidden is completely useless when > trying to combine it with display:flex? > > What I'm trying to do is just that an element have display:flex and to > hide it with the hidden attribute when I don't need the element to be > shown. I guess my only option is changing style.display? > > Thanks, > > David From annevk at annevk.nl Wed Apr 30 04:01:44 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Wed, 30 Apr 2014 12:01:44 +0100 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <5360C413.5070003@gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> Message-ID: <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> > Le 29/04/2014 23:32, David Bruant a ?crit : >> >> Hi, >> >> // CSS: >> div{ >> display: flex; >> } >> >> // HTML: >> <div hidden></div> >> >> Per spec, the div should be shown right? I imagine there is no way back on >> that? We could change the specification to use display-box instead. That might work. -- http://annevankesteren.nl/ From bruant.d at gmail.com Wed Apr 30 04:51:11 2014 From: bruant.d at gmail.com (David Bruant) Date: Wed, 30 Apr 2014 13:51:11 +0200 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> Message-ID: <5360E3AF.8000506@gmail.com> Le 30/04/2014 13:01, Anne van Kesteren a ?crit : >> Le 29/04/2014 23:32, David Bruant a ?crit : >>> Hi, >>> >>> // CSS: >>> div{ >>> display: flex; >>> } >>> >>> // HTML: >>> <div hidden></div> >>> >>> Per spec, the div should be shown right? I imagine there is no way back on >>> that? > We could change the specification to use display-box instead. That might work. Just read about display-box [1]. (Sorry, I'm lagging behind on CSS innovations) Just to be sure I understand, are you suggesting to change the default UA stylesheet from *[hidden]{ display: none; } to *[hidden]{ display-box: none; } Also, what's the intention/implementation status of display-box across various browsers? Thanks, David [1] http://dev.w3.org/csswg/css-display-3/#the-display-box From robin at w3.org Wed Apr 30 05:24:12 2014 From: robin at w3.org (Robin Berjon) Date: Wed, 30 Apr 2014 14:24:12 +0200 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> Message-ID: <5360EB6C.1020700@w3.org> On 30/04/2014 13:01 , Anne van Kesteren wrote: >> Le 29/04/2014 23:32, David Bruant a ?crit : >>> // CSS: >>> div{ >>> display: flex; >>> } >>> >>> // HTML: >>> <div hidden></div> >>> >>> Per spec, the div should be shown right? I imagine there is no way back on >>> that? > > We could change the specification to use display-box instead. That might work. Isn't that just moving the problem though? If the CSS uses display-box: contents (or whatever else might get added next) for some reason then hidden won't work either. Less likely, but still. Maybe having the default style use both display and display-box might fly? -- Robin Berjon - http://berjon.com/ - @robinberjon From glenn at zewt.org Wed Apr 30 07:32:37 2014 From: glenn at zewt.org (Glenn Maynard) Date: Wed, 30 Apr 2014 09:32:37 -0500 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> Message-ID: <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> Previous discussion: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037905.html On Wed, Apr 30, 2014 at 6:01 AM, Anne van Kesteren <annevk at annevk.nl> wrote: > >> <div hidden></div> > >> > >> Per spec, the div should be shown right? I imagine there is no way back > on > >> that? > > We could change the specification to use display-box instead. That might > work. > It's too bad that display-box also has multiple uses--it doesn't only display or hide the content, it has a third "contents" mode. That means the same problem would happen as soon as you set "display-box: contents" on something--it would override [hidden]. What we really need is a CSS property that only sets whether the element is visible or not and nothing else, like "visible: false". That way, the only way [hidden] gets overridden is if you're actually setting the visibility style. I assume it's too late to change the style [hidden] uses, though. Lots of pages do things like "d = elem.style.display; elem.style.display = "block"; width = elem.style.offsetWidth; elem.style.display = d;" to work around offset* being 0 while hidden, and if [hidden] changes to some other style (or to !important) that code will break. I always just put [hidden] { display: none !important; } in my stylesheets to work around this. That sucks, since it makes [hidden] in pages and scripts I write incompatible with everyone else, who may be writing scripts that don't understand this (such as the above pattern), or may work around it in some other way. -- Glenn Maynard From ian at hixie.ch Wed Apr 30 13:22:49 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 30 Apr 2014 20:22:49 +0000 (UTC) Subject: [whatwg] Feedback on seamless iframe attribute In-Reply-To: <CAA-7dEo9ZyhJABdE1O4H5E2d=xpxwWs=mm=uNn_H3oijOPZpCQ@mail.gmail.com> References: <CAA-7dEo9ZyhJABdE1O4H5E2d=xpxwWs=mm=uNn_H3oijOPZpCQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404302011570.30416@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Ben Vinegar wrote: > > But while we?re not interested in the style component of the seamless > attribute, we ? and probably all developers that hack on iframes ? are > interested in the resizing behaviour it introduces. Right now we deploy > fairly complex code, both inside the iframed document, and on the parent > document, to resize the iframe element when the iframed content changes > size. Every iframed application with dynamically-sized content does the > same. Thanks for descrbing this use case. It has come up before, as it happens. Combined with the desire for other aspects of seamless="" to apply to cross-origin iframes, the current proposal is to have headers that enable these features on the embedee site, with CSP being used to decide which origins are allowed to use the feature at all. You can see more about this at these links: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0207.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html https://www.w3.org/Bugs/Public/show_bug.cgi?id=23513 The current blocker is getting implementor interest; right now, most implementors haven't finished (or in some cases even started) supporting seamless="" even for same-origin iframes, so we don't want to start adding more features yet lest we get too far ahead of the browsers. > To me, it?s crazy that it?s 2013 and there?s still no native way to have > the browser automatically resize an iframe. And yet we have seamless. > But it not only resizes: it adds all this other bundled behaviour, and > strictly serves a fringe use case where somebody is distributing iframes > on the same origin. The main use case is same-origin-served blog comments, which isn't that fringe, to be fair. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ben at benv.ca Wed Apr 30 13:31:46 2014 From: ben at benv.ca (Ben Vinegar) Date: Wed, 30 Apr 2014 13:31:46 -0700 Subject: [whatwg] Feedback on seamless iframe attribute In-Reply-To: <alpine.DEB.2.00.1404302011570.30416@ps20323.dreamhostps.com> References: <CAA-7dEo9ZyhJABdE1O4H5E2d=xpxwWs=mm=uNn_H3oijOPZpCQ@mail.gmail.com> <alpine.DEB.2.00.1404302011570.30416@ps20323.dreamhostps.com> Message-ID: <CAA-7dEqo8ekcN+EvaLfXR=rzXQCSP3n2OoDbT0_48Hf9ozPoxA@mail.gmail.com> > The main use case is same-origin-served blog comments, which isn't that fringe, to be fair. Are you aware of any other products/companies using same-origin-served blog comments, that aren't Google Plus/Blogger? Genuinely curious. - Ben On Wed, Apr 30, 2014 at 1:22 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Feb 2014, Ben Vinegar wrote: > > > > But while we?re not interested in the style component of the seamless > > attribute, we ? and probably all developers that hack on iframes ? are > > interested in the resizing behaviour it introduces. Right now we deploy > > fairly complex code, both inside the iframed document, and on the parent > > document, to resize the iframe element when the iframed content changes > > size. Every iframed application with dynamically-sized content does the > > same. > > Thanks for descrbing this use case. > > It has come up before, as it happens. Combined with the desire for other > aspects of seamless="" to apply to cross-origin iframes, the current > proposal is to have headers that enable these features on the embedee > site, with CSP being used to decide which origins are allowed to use the > feature at all. You can see more about this at these links: > > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0207.html > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html > https://www.w3.org/Bugs/Public/show_bug.cgi?id=23513 > > The current blocker is getting implementor interest; right now, most > implementors haven't finished (or in some cases even started) supporting > seamless="" even for same-origin iframes, so we don't want to start adding > more features yet lest we get too far ahead of the browsers. > > > > To me, it?s crazy that it?s 2013 and there?s still no native way to have > > the browser automatically resize an iframe. And yet we have seamless. > > But it not only resizes: it adds all this other bundled behaviour, and > > strictly serves a fringe use case where somebody is distributing iframes > > on the same origin. > > The main use case is same-origin-served blog comments, which isn't that > fringe, to be fair. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Wed Apr 30 14:12:19 2014 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 30 Apr 2014 14:12:19 -0700 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> Message-ID: <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> On Wed, Apr 30, 2014 at 7:32 AM, Glenn Maynard <glenn at zewt.org> wrote: > It's too bad that display-box also has multiple uses--it doesn't only > display or hide the content, it has a third "contents" mode. That means > the same problem would happen as soon as you set "display-box: contents" on > something--it would override [hidden]. What we really need is a CSS > property that only sets whether the element is visible or not and nothing > else, like "visible: false". That way, the only way [hidden] gets > overridden is if you're actually setting the visibility style. Mind bringing this up in www-style? My thinking in that design is that display-box controls whether an element generates boxes at all, which seems consistent with including the 'contents' value. But if it seems useful to have a property dedicated to literally just hiding the element, we can see about rejiggering things. ~TJ From ian at hixie.ch Wed Apr 30 14:32:32 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 30 Apr 2014 21:32:32 +0000 (UTC) Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404302119290.30416@ps20323.dreamhostps.com> On Wed, 30 Apr 2014, David Bruant wrote: > Le 29/04/2014 23:32, David Bruant a ?crit : > > > > // CSS: > > div { > > display: flex; > > } > > > > // HTML: > > <div hidden></div> > > > > Per spec, the div should be shown right? I imagine there is no way > > back on that? Right. You want: div[hidden] { display: block } ...in your style sheet. It's the equivalent of: strong { font: 1em sans-serif; } ...removing the bold, or: td.foo { display: none; } ...making all the cells after <td class=foo> end up in the wrong column. > > Does it mean hidden only works when the default (UA stylesheet) > > display value is kept? Does it mean hidden is completely useless when > > trying to combine it with display:flex? No, it just means you have to be careful with your CSS. Personally I often use this rule: [hidden] { display: block; opacity: 0; } ...combined with CSS transitions to animate elements that are being hidden or shown. This is one example of why it's important that author CSS be able to override the default CSS. > > What I'm trying to do is just that an element have display:flex and to > > hide it with the hidden attribute when I don't need the element to be > > shown. I guess my only option is changing style.display? Just add "[hidden] { display: none }" to your style sheet. > Constructive proposal: > * a special value for the hidden attribute that forces the element to be > hidden regardless of what the CSS or style attribute says for the display > value. > Maybe `hidden="force"`? Hidden how? 'visibility'? 'display'? 'opacity'? Why? What if you later want to style it differently? On Wed, 30 Apr 2014, Anne van Kesteren wrote: > > We could change the specification to use display-box instead. That might > work. Would that break sites that are intentionally replacing the styling for hidden="" from 'display:none' to 'opacity:0' ? On Wed, 30 Apr 2014, Glenn Maynard wrote: > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037905.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0143.html -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Wed Apr 30 14:39:15 2014 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 30 Apr 2014 14:39:15 -0700 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <alpine.DEB.2.00.1404302119290.30416@ps20323.dreamhostps.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> <alpine.DEB.2.00.1404302119290.30416@ps20323.dreamhostps.com> Message-ID: <CAAWBYDAWjkE3hywtgBXG52H=DiogZpUfYH19QjkbLVYVv+T-YA@mail.gmail.com> On Wed, Apr 30, 2014 at 2:32 PM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 30 Apr 2014, Anne van Kesteren wrote: >> We could change the specification to use display-box instead. That might >> work. > > Would that break sites that are intentionally replacing the styling for > hidden="" from 'display:none' to 'opacity:0' ? Yes. ~TJ From domenic at domenicdenicola.com Wed Apr 30 14:56:53 2014 From: domenic at domenicdenicola.com (Domenic Denicola) Date: Wed, 30 Apr 2014 21:56:53 +0000 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CAAWBYDAWjkE3hywtgBXG52H=DiogZpUfYH19QjkbLVYVv+T-YA@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> <alpine.DEB.2.00.1404302119290.30416@ps20323.dreamhostps.com>, <CAAWBYDAWjkE3hywtgBXG52H=DiogZpUfYH19QjkbLVYVv+T-YA@mail.gmail.com> Message-ID: <C57F3B27-2A57-4646-97B2-8A1F1E3CFEF6@domenicdenicola.com> > On Apr 30, 2014, at 17:44, "Tab Atkins Jr." <jackalmage at gmail.com> wrote: > >> On Wed, Apr 30, 2014 at 2:32 PM, Ian Hickson <ian at hixie.ch> wrote: >>> On Wed, 30 Apr 2014, Anne van Kesteren wrote: >>> We could change the specification to use display-box instead. That might >>> work. >> >> Would that break sites that are intentionally replacing the styling for >> hidden="" from 'display:none' to 'opacity:0' ? > > Yes. I have done this (overwritten hidden to be opacity zero) on multiple client sites. Please don't break them :) From ian at hixie.ch Wed Apr 30 15:35:07 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 30 Apr 2014 22:35:07 +0000 (UTC) Subject: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online In-Reply-To: <CAHpoE=ighx=+X8LLoVhdUDEGJ+6K_W-wGSrSG_y2opuQPLZhRA@mail.gmail.com> References: <CAM2RUGM93QEdJpac7=WqYZ6VV5tU0vx8VJNmgYVf2TLOG_dBLQ@mail.gmail.com> <CAM2RUGNv=rqh85jO9nB=h0UTuduuM5hYzCxqzmB+kXuQTQ1oEA@mail.gmail.com> <Pine.LNX.4.64.1212101917340.9975@ps20323.dreamhostps.com> <CA+iXHYOchgdHLtoLvnZopig3Or1eSU0ZrnLvi9UX8XQNC0=OGQ@mail.gmail.com> <Pine.LNX.4.64.1212172128400.20758@ps20323.dreamhostps.com> <50D2E754.5010007@peda.net> <CAHpoE=ighx=+X8LLoVhdUDEGJ+6K_W-wGSrSG_y2opuQPLZhRA@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1404302224270.30416@ps20323.dreamhostps.com> On Mon, 17 Dec 2012, David Barrett-Kahn wrote: > On Mon, Dec 17, 2012 at 3:30 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Tue, 11 Dec 2012, David Barrett-Kahn wrote: > > > > > > We ran into this same problem on Google Docs offline. Our solution > > > was to add a proprietary response header to Chrome which instructs > > > the browser that the response is not to trigger the fallback entry, > > > despite its response code. Something like it could be considered > > > for standardization. I know there are some people on the Chrome team > > > looking to advance some new appcache features, and that this use > > > case is on their list. > > > > Can you elaborate on the need for this feature? Why would you ever > > send the user to a 404 page intentionally (i.e. when the server isn't > > broken)? Similarly, why would you not consider the server returning > > 500 a good indication that the cache should be used? > > Generally speaking, this feature is useful where the error page is > somewhat routine and contains information comprehensible and actionable > by the user, which would otherwise be lost in the fallback. > > This was mainly about 404s, which docs will serve when a requested > document id doesn't exist, which includes cases where it was deleted. > All our offline application could say (once triggered) was that the > document was not present in our local storage. It couldn't say the > document didn't actually exist. We therefore wanted the server's > version of the error page to be displayed. 401/403 were also of > interest, mainly for cases where the user had previously had access to a > document, but that access had been rescinded. Whether it's a good idea > to divert 500s kind of depends on what they are, especially whether the > served error page contains user-actionable information. > > The current generation of docs offline attempts to only engage the > browser's offline machinery when truly offline. For example, the > regular docs pages one interacts with when online do not bind appcaches. > We have a fallback entry covering the entire origin which engages this > machinery, loading a 'controller' style application which decides how to > handle whatever URL was provided. We have this strict separation for > two reasons. First, we were very keen to ensure that instability in the > new offline technologies we were using never lead to disruption of the > online solution, especially during early development. Second, the > online start-up procedures used by our applications are complex and > highly optimized, and fundamentally incompatible with appcache due to a > 'blending' of the document and the application. We wanted to preserve > those optimizations online and have a different startup procedure when > offline. Interesting. The AppCache API was really designed more around a model where the editor and the data were completely separate, and the data was obtained by the script using XHR or WebSocket and cached locally manually using IndexDB or Web Storage or some such. So yeah, the above use case isn't handled. I've filed a bug to track this, but in pracrice I expect that Service Workers will subsume most of the appcache feature requests. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25525 On Thu, 20 Dec 2012, Mikko Rantalainen wrote: > > I'm not sure about 404 but if the UA is able to connect the server and > gets HTTP 410 Gone, I'd be pretty upset if cached offline copy would be > used automatically. The server has clearly responded that the requested > document is intentionally removed. End user seeing cached (stale) copy > instead is very far from intented result in this case. > > In my opinion the UA should *always* use server returned response if > server responded at all. The original thinking here was that the server here might not be the original server, but might instead be a captive portal. It's far worse to start clearing appcaches because you happened to be connected to a captive portal than it is to display the old offline file instead of saying the file is now gone. After all, if the file is gone, why is it listed in the manifest? On Thu, 20 Dec 2012, Michael Nordman wrote: > > It'd be loads better if application logic were directly responsible for > making these sort of policy decisions regarding what cached resource to > use under what circumstance. I believe that's the approach that Service Workers will provide. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Wed Apr 30 15:36:14 2014 From: ian at hixie.ch (Ian Hickson) Date: Wed, 30 Apr 2014 22:36:14 +0000 (UTC) Subject: [whatwg] Any plan for a TIMEOUT section on appcache manifests ? In-Reply-To: <50D06D66.1040105@yahoo.fr> References: <50D06D66.1040105@yahoo.fr> Message-ID: <alpine.DEB.2.00.1404302235410.30416@ps20323.dreamhostps.com> On Tue, 18 Dec 2012, Nicolas Froidure wrote: > > I'm using the appcache since it's adoption on major browsers and i think > it lacks of a section to specify fallbacks with a specific timeout in > order to avoid slow networks to damage user experience. To me this is > the main issue still remaining in order to have the same experience than > installed apps. > > It could take the form of a section like this (with a 2 seconds timeout): > TIMEOUT 2: > onlineres.html fallbackres.html > > Or maybe be done with the connection types : > BANDWIDTH EDGE: > onlineres.html fallbackres.html > ... > > Is it planned to have some similar mechanism ? Isn't this something browsers should just implement themselves? It's not clear to me how an author is supposed to know what timeout to give. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From glenn at zewt.org Wed Apr 30 16:08:11 2014 From: glenn at zewt.org (Glenn Maynard) Date: Wed, 30 Apr 2014 18:08:11 -0500 Subject: [whatwg] hidden attribute useless with display: flex? In-Reply-To: <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> References: <53601A77.9050102@gmail.com> <5360C413.5070003@gmail.com> <CADnb78gkjeWAD8oO1xyx_gvU_n2LySsN9bOC=r7wG4XHw8DMTQ@mail.gmail.com> <CABirCh_5B0G5XC41aBpe4k1gpTG_X45uZBV_BzDxS1MNcL_i8A@mail.gmail.com> <CAAWBYDA2SLiZwK91zduzj4i5KQD=si-eqDL+GHhZZFN5PQ7dPg@mail.gmail.com> Message-ID: <CABirCh_guMWOn4WeAhJ0y3HQ8rquT+RsDfW0R+jhd=SUfpq5jg@mail.gmail.com> On Wed, Apr 30, 2014 at 4:12 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > On Wed, Apr 30, 2014 at 7:32 AM, Glenn Maynard <glenn at zewt.org> wrote: > > It's too bad that display-box also has multiple uses--it doesn't only > > display or hide the content, it has a third "contents" mode. That means > > the same problem would happen as soon as you set "display-box: contents" > on > > something--it would override [hidden]. What we really need is a CSS > > property that only sets whether the element is visible or not and nothing > > else, like "visible: false". That way, the only way [hidden] gets > > overridden is if you're actually setting the visibility style. > > Mind bringing this up in www-style? My thinking in that design is > (It's confusing to move conversations to lists some people aren't subscribed to, since they'll inevitably miss part of the discussion. It'd help a lot if the lists wouldn't bounce mails if you're subscribed to *any* w3 mailing list, so cross-posting would work better. But, I think that starting a new thread on another list without copying it to this one is even more confusing, so I've CC'd both.) that display-box controls whether an element generates boxes at all, > which seems consistent with including the 'contents' value. But if it > seems useful to have a property dedicated to literally just hiding the > element, we can see about rejiggering things. > If an element is @hidden, I don't want style rules for other behaviors to override that. Just as today I don't want a display: block; style to break hidden ("I just wanted this inline element to be block when it's not hidden, not override hidden entirely!"), I don't want display-box: contents; to break hidden either ("I just wanted to cause the element itself to not be rendered when it's not hidden, not override hidden entirely!").. That said, we may be past the point where it will really help. It's too late to actually use this with the default [hidden] rule, which means authors will have to put a [hidden] { rendered: false; } (or something) rule in their stylesheet. If authors all need to add a boilerplate rule to fix @hidden anyway, [hidden] { display: none !important; } works. -- Glenn Maynard