| 01:05 | <Hixie_> | scheib: adding to the list later is cheap, in this brave new world of living standards |
| 02:59 | <Hixie_> | http://www.nngroup.com/articles/stagnating-expertise/ |
| 02:59 | <Hixie_> | (i assume this applies to programming languages too, in which case, it's an argument against us adding features) |
| 04:16 | <pdr> | Hixie_, TabAtkins, I'd like to double-check my understanding of srcset wrt pixel densities. If I have a 100x100 png, what is the width and height of <img srcset="100x100.png 2x">? My reading is it would be 100x100 in css pixels, but it's being implemented in Blink differently. |
| 04:17 | <TabAtkins> | 50x50. (I forgot to specify that in my spec, but it's specified thusly in whatwg.) |
| 04:19 | <pdr> | TabAtkins, got it. Would the intrinsic size be (100 x 100) and the natural size (50 x 50)? |
| 04:20 | <TabAtkins> | dunno what the difference is, but the intrinsic size (per CSS) would be 50x50 |
| 04:22 | <pdr> | TabAtkins, http://www.w3.org/TR/css3-images/#intrinsic-dimensions says intrinsic dimensions are not a factor of the context the image is used in |
| 04:22 | <TabAtkins> | Correct. But this isn't quite the same thing. |
| 04:26 | <pdr> | Can you expand a bit? I'm trying to nail down how srcset interacts with svg and the intrinsic size wording is tricky |
| 04:27 | <TabAtkins> | The intrinsic size is just the input for the CSS algorithms. srcset/srcN happen at a level before that, and set the intrinsic size. |
| 04:28 | <TabAtkins> | This should be pretty natural if you don't run yourself in circles - an image with 100 pixels, at 2x density, naturally covers 50 CSS pixels. That's its intrinsic size, given that density. |
| 04:31 | <pdr> | TabAtkins, what happens if this image is drawn into a canvas with drawImage(...), without specifying a width and height? Would it be drawn with size 50x50 or 100x100? |
| 04:32 | <pdr> | It sounds like 50x50, just want to verify |
| 04:33 | <TabAtkins> | yes |
| 04:34 | <pdr> | thanks for the clarification, off to make this real :) |
| 04:34 | <TabAtkins> | Dude, it's 9:30. Stop coding. ^_^ |
| 04:35 | <pdr> | but.. cats.. the people demand images of cats |
| 04:36 | <TabAtkins> | Oh, I suppose your'e right. |
| 04:39 | <cabanier1> | pdr: does canvas know about any of this? |
| 04:42 | <cabanier1> | pdr: it seems that the canvasImageSource should always use the default |
| 04:43 | <pdr> | cabanier1, yeah the spec is pretty clear about using the intrinsic size |
| 04:43 | <pdr> | for drawImage |
| 04:45 | <cabanier1> | pdr: since the image doesn't need to be in the dom, you can't do the selection except maybe by pixel density |
| 04:45 | <cabanier1> | pdr: but that would be weird if it happens |
| 04:46 | <pdr> | cabanier1, do we even load the image if it isn't in the dom? /me checks |
| 04:47 | <TabAtkins> | For <img>s, we do (I think). |
| 04:47 | <pdr> | yeah, we do |
| 04:47 | <cabanier1> | http://www.html5canvastutorials.com/tutorials/html5-canvas-images/ |
| 04:48 | <cabanier1> | that's not html image though |
| 04:49 | <pdr> | I guess you're right, we should only use the resolution for selection in that case. srcset already has to deal with dynamic srcset changes so it's not too difficult. I guess image.onload would fire twice? |
| 04:49 | <cabanier1> | pdr: but that would be weird |
| 04:50 | <cabanier1> | pdr: If you zoom in (not pinch zoom), the image might switch to having more pixels |
| 04:54 | <pdr> | cabanier1, actually, the width comes from the viewport. I think that's known w/o putting the image in the document |
| 04:55 | <pdr> | cabanier1, does the viewport change during pinch zoom? I don't think so (or, not the one srcset uses) |
| 04:55 | <cabanier1> | pdr: but dpr changes |
| 04:56 | <cabanier1> | pdr: no, not pinch zoom. |
| 04:56 | <cabanier1> | pdr: regular zoom (command + ) |
| 04:57 | <pdr> | Does browser zoom change the viewport? I don't think it does |
| 05:01 | <TabAtkins> | Ctrl-+ style zoom does indeed change the viewport. |
| 05:05 | <pdr> | Hopefully nobody promises onload |
| 05:05 | <cabanier> | :-) |
| 05:05 | <cabanier> | does that mean "hopefully nobody turns onload into a promise?" |
| 05:06 | <pdr> | nm, I think promises can return twice |
| 05:07 | <TabAtkins> | wait, what? |
| 05:13 | <pdr> | I misread http://www.html5rocks.com/en/tutorials/async/deferred. I don't know how promises and onload would work |
| 05:17 | <cabanier> | what would be the problem? |
| 05:31 | <MikeSmith> | I'm looking for a word to describe benefits of Web Components |
| 05:31 | <MikeSmith> | what't the opposite of "bolt on"? |
| 05:32 | <MikeSmith> | in the sense that Web Components give you a way to create custom UI controls that aren't just bolted on |
| 05:32 | <MikeSmith> | but instead are.. whatever the opposite of bolted on is |
| 05:32 | <MikeSmith> | "baked in"? |
| 05:37 | <Hixie_> | intergrated |
| 05:38 | <Hixie_> | but i don't know if i'd agree that web components aren't bolt-on :-) |
| 05:38 | <Hixie_> | i thought that was the whole point, a way to give you bolt-on components :-) |
| 05:40 | <MikeSmith> | Hixie_: except that "bolt on" often has a pejorative connotations |
| 05:42 | <MikeSmith> | and you can already do "bolt on" components today without needing Web Components |
| 05:43 | <MikeSmith> | so it seems not unreasonable to say that compared to the current mechanisms we have, Web Components gives you a way to bake in components rather than just bolting them on |
| 05:44 | <MikeSmith> | (I'm trying to figure out how to word it for a reporter with a short attention span.) |
| 05:45 | <Hixie_> | well, they are bolt-on. i mean, as opposed to the built-in/baked-in ones like <select>. |
| 05:45 | <Hixie_> | the advantage of web components is more that they are self-contained |
| 05:46 | <Hixie_> | modular |
| 05:49 | <TabAtkins> | pdr: the page's onload event fires once. It's appropriate for promises - you just have one promise for the page load, which fulfills when the page loads. |
| 05:50 | <TabAtkins> | pdr: Images can load multiple times, which suggests a different strategy - instead, return a new promise each time, which is either already fulfilled (if the image is currently loaded) or will be fulfilled when the image finishes loading (if it's currently loading something, or hasn't yet started loading). |
| 05:51 | <TabAtkins> | pdr: Both of these approaches are exemplified in the FontFace and FontFaceSet ready() promises: <http://dev.w3.org/csswg/css-font-load-events/>; |
| 09:19 | <zcorpan> | JS doesn't have a WeakArray thing yet, right? |
| 09:20 | <zcorpan> | maybe that wouldn't make sense |
| 09:28 | <zcorpan> | doesn't WeakMap expose GC if you hold the keys in an array and check the values in an interval? |
| 09:32 | <jgraham> | It seems that way to me as well |
| 09:33 | <rtc> | how can I subscribe to whatwg mailing list? |
| 09:34 | <foolip> | rtc, http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org |
| 09:36 | <Ms2ger> | zcorpan, wasn't WeakMap weak in the keys? |
| 09:37 | <zcorpan> | Ms2ger: yes, but you can't enumerate the keys so if you want to check all the values you've set you need to maintain the keys out of band, afaict |
| 09:38 | <annevk> | zcorpan: if you hold the keys in an array they won't be GC'd |
| 09:38 | <Ms2ger> | Right |
| 09:38 | <zcorpan> | but the values can be GC'ed |
| 09:38 | <annevk> | zcorpan: no |
| 09:39 | <zcorpan> | no? how does that make sense? |
| 09:39 | <annevk> | zcorpan: they have a strong whatever that was called to the key |
| 09:40 | <zcorpan> | var keys = [0]; var wm = new WeakMap(); wm.set[0, {}]; |
| 09:40 | <annevk> | zcorpan: e.g. you could associate some information about nodes in a WeakMap and you don't have to worry about removing that extra data when the node is removed |
| 09:40 | <Ms2ger> | Keys need to be objects, no? |
| 09:41 | <jgraham> | If the key is a node, then the weakmap will change when GC occurs |
| 09:41 | <jgraham> | If that node was deleted |
| 09:41 | <jgraham> | So you can tell whether GC occurred |
| 09:41 | <jgraham> | What am I missing? |
| 09:42 | <annevk> | Ms2ger: correct http://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.set |
| 09:42 | <Ms2ger> | How can you tell if the weakmap changed? |
| 09:42 | <annevk> | jgraham: how would you tell? |
| 09:42 | <annevk> | jgraham: you no longer have the node, so you no longer can look up its value |
| 09:42 | <zcorpan> | oh, ok. i thought they key could be anything |
| 09:44 | <Ms2ger> | It's basically improved expandos |
| 09:44 | <jgraham> | If there isn't any way to tell how big the set is |
| 09:45 | <jgraham> | I guess that is probably OK |
| 09:45 | <zcorpan> | what i'm pondering is if WeakMap + some API that sends a message to all ports in a WeakMap would be a plausible replacement for PortCollection |
| 09:45 | <jgraham> | zcorpan: I think I suggested the smae thing a few days ago |
| 09:45 | <jgraham> | It does seem better |
| 09:46 | <jgraham> | (of course you could try a timing attack ;) |
| 09:46 | <zcorpan> | would you use the port as the key and a dummy value as value? |
| 09:46 | Ms2ger | would need to think if that makes gc observable somehow |
| 09:46 | <annevk> | zcorpan: no that doesn't work |
| 09:46 | <jgraham> | Surely it's a WeakSet |
| 09:47 | <annevk> | zcorpan: e.g. you create this portcollection, set up listeners for the ports, keep sending to the portcollection, you can observe via timing when the ports get collected as the messages are no longer delivered |
| 09:48 | <jgraham> | Yeah, I think messaging + weak refs fundamentally make GC observable |
| 09:49 | <annevk> | smaug____ and I went through this exercise last weekend |
| 09:52 | <zcorpan> | jgraham: i didn't know WeakSet was a thing :-) |
| 09:53 | <Ms2ger> | Doesn't seem to be implemented in SM |
| 09:55 | <zcorpan> | i thought the use case was for sending messages, not for listening |
| 09:56 | <zcorpan> | you can't tell if a message was sent or not, unless that's communicated back in some way |
| 09:58 | <annevk> | zcorpan: you can do the whole setup in one global |
| 09:59 | <smaug____> | zcorpan: var c = new MessageChannel(); portCollection.add(c.port1); port2.addEventListener("message", function() {alert("boo")}); Then start iterating portCollection send messages |
| 09:59 | <smaug____> | at some point port1 won't be there |
| 10:01 | <zcorpan> | smaug____: yes, i know |
| 10:03 | <zcorpan> | smaug____: i was talking about WeakSet + API to send a message to all ports in the WeakSet |
| 10:03 | <smaug____> | and since PortCollection exposes GC this way, it could be used to implement "close" event in hacky way |
| 10:04 | <smaug____> | ah |
| 10:04 | <zcorpan> | but that can still expose GC, but requires the other end to cooperate, at least for the only-sending case |
| 10:05 | <zcorpan> | afaict |
| 10:05 | zcorpan | -> lunch |
| 10:50 | <rtc> | why when I place h1 h2 h3 tags one after another the h1 has smaller font size than h2? |
| 10:53 | <rtc> | http://jsfiddle.net/HARj2/ this happens only when they are in section why? |
| 11:03 | <zcorpan> | rtc: the default styling shrinks h1 in sections, but doesn't affect h2-h6 (except in hgroup, per spec anyway) |
| 11:03 | <rtc> | wwhy? |
| 11:03 | <zcorpan> | rtc: if you only use h1 you get the right styling |
| 11:03 | <rtc> | but why this happens? |
| 11:04 | <rtc> | no h1 alone is with same font size as if there are h2 h3 |
| 11:04 | <zcorpan> | because it should be possible to only use h1 + sections and get smaller headings for subheadings |
| 11:04 | <rtc> | http://jsfiddle.net/HARj2/1/ |
| 11:04 | <rtc> | http://jsfiddle.net/HARj2/ |
| 11:04 | <rtc> | compare, they are same |
| 11:05 | <zcorpan> | yes? that's the point. did you understand what i wrote? |
| 11:06 | <zcorpan> | <h1>foo</h1> <section><h1>bar</h1></section> should have the same rendering as <h1>foo</h1> <h2>bar</h2> |
| 11:06 | <rtc> | no |
| 11:06 | <rtc> | :S |
| 11:07 | <rtc> | but why |
| 11:07 | <rtc> | h1 has smaller font size than h2? |
| 11:08 | <zcorpan> | <h1>foo</h1> <section><h1>bar</h1></section> means the same thing as <h1>foo</h1> <h2>bar</h2>, and similarly a nested section makes h1 be a third-level heading |
| 11:08 | <rtc> | zcorpan, |
| 11:14 | <rtc> | zcorpan, I am confused man :S |
| 11:15 | <rtc> | please explain thanks |
| 11:16 | <zcorpan> | rtc: ok. so let's back up. the purpose of headings is to give some structure to the document, which can be represented in a "table of contents" |
| 11:16 | <zcorpan> | rtc: the table of contents will have nested sections so that e.g. "bar" is a child of "foo" |
| 11:17 | <zcorpan> | rtc: in html, this can be marked up in two ways: the old way with only <h1>foo</h1> <h2>bar</h2> and the new way with <h1>foo</h1> <section><h1>bar</h1></section> |
| 11:17 | <zcorpan> | does that help? |
| 11:18 | <rtc> | sec |
| 11:18 | <rtc> | sorry some server problems :D |
| 11:18 | <rtc> | let me read thanks man! |
| 11:18 | <rtc> | hmmmmmmm |
| 11:18 | <rtc> | yess |
| 11:19 | <rtc> | so basically in section I should not use h1 and h2 ? |
| 11:19 | <rtc> | together? |
| 11:19 | <rtc> | headings h1 h2 h3 are not intended for titles - headings in separate parts of a document? |
| 11:19 | <rtc> | and subsections? |
| 11:19 | <rtc> | only for table of contents? |
| 11:21 | <zcorpan> | if you want correct default styling, only use h1 together with sections |
| 11:22 | <rtc> | ok |
| 11:22 | <rtc> | so withing one seciton I should avoid h1 together with h2 h3 right? :) |
| 11:23 | <zcorpan> | can you give an example? i don't follow |
| 11:27 | <zcorpan> | do one of these: http://jsfiddle.net/HARj2/ |
| 11:27 | <zcorpan> | doing something else is allowed but gets more confusing and the default style will probably be wrong |
| 11:29 | <zcorpan> | note that the top-level heading should not be in a <section> |
| 11:30 | <zcorpan> | the <body> is the top-level section |
| 11:37 | <rtc> | zcorpan, sorry one server got problems |
| 11:37 | <rtc> | ok |
| 11:38 | <rtc> | h1 h2 h3 are intended for tables of contents or for headings too? |
| 11:41 | <jgraham> | rtc: They are only intended for headings |
| 11:41 | <jgraham> | Headings are loosely defined as "things that would appear in a table of contents" |
| 11:42 | <jgraham> | But aren't the actual text of the TOC itself (that would probably be a set of nested <ol>s and <li>s) |
| 11:45 | <zcorpan> | right, you would *generate* the table of contents by looking at the headings in the document |
| 11:45 | <zcorpan> | not mark up the ToC itself using headings |
| 11:52 | <rtc> | so how to make table of contents |
| 11:52 | <rtc> | using which elements? |
| 11:53 | <rtc> | ok so I guess ol li |
| 11:53 | <rtc> | ok |
| 11:53 | <rtc> | but stil I am confused |
| 11:53 | <rtc> | :S |
| 11:53 | <rtc> | why h1 is bigger than h2 in a section |
| 11:53 | <rtc> | ok |
| 11:53 | <rtc> | so I guess I should not use h1 together with h2 in same section right? |
| 11:53 | <rtc> | because I need to use h1 lonely or h2 h3 h4 withouth 1? |
| 11:53 | <rtc> | h1* |
| 11:55 | <smaug____> | hmm, which spec defines XML fragment serialization algorithm |
| 11:55 | <smaug____> | maybe Ms2ger's |
| 11:55 | <smaug____> | oh, silly me |
| 11:55 | <Ms2ger> | HTML? |
| 11:56 | <smaug____> | yes |
| 11:56 | <zcorpan> | rtc: no, you either use only h1+section or h1+h2+h3+h4+h5+h6 without section |
| 11:56 | <zcorpan> | rtc: not h2-h6 without h1, that doesn't make sense |
| 11:57 | <Ms2ger> | I should probably move those bits into my spec |
| 11:57 | <rtc> | hm ok |
| 11:57 | <rtc> | so no h2 h3 h4 with a section |
| 11:57 | <rtc> | well it makes sense |
| 11:57 | <rtc> | what if I need heading with subheadings in a section |
| 11:58 | <rtc> | oh well I guess I use section with h1 for subheading |
| 11:58 | <zcorpan> | you nest another <section> |
| 11:58 | <rtc> | :S |
| 11:58 | <rtc> | yeah then aanother sub sub heading will be another section in that one right? |
| 11:58 | <zcorpan> | yes |
| 11:59 | <rtc> | http://jsfiddle.net/HARj2/3/ |
| 11:59 | <rtc> | HAHA I GOT IT I GOT IT |
| 11:59 | <rtc> | is this ok???? ^^ |
| 11:59 | <rtc> | :D |
| 11:59 | <zcorpan> | yep |
| 11:59 | <rtc> | thanks man zcorpan !!!!!!!! thanks |
| 11:59 | <zcorpan> | :-) |
| 11:59 | <rtc> | finally headings are solved :) |
| 11:59 | <rtc> | going webgl now :) hehe |
| 11:59 | <rtc> | that will not end up so easy though :)) |
| 12:00 | <zcorpan> | maybe you can teach me webgl when you've figured it out :-) |
| 12:00 | <rtc> | zcorpan, sure !!!! |
| 12:01 | <rtc> | I had nice travel, html css javascript php mysql postregsql python c now webgl :D |
| 12:01 | <rtc> | I want opengl first than webgl because opengl is superset of webgl |
| 12:02 | <rtc> | I think right way for learning is to learn the superset first |
| 12:57 | <smaug____> | Ms2ger: so there are no tests for serialization? |
| 13:05 | <Ms2ger> | smaug____, there's some at https://github.com/whatwg/domparsing/tree/master/tests |
| 13:08 | <smaug____> | Ms2ger: nothing is testing failing serialization? |
| 13:08 | <smaug____> | (or how do I run those tests ) |
| 13:09 | <Ms2ger> | Just https://github.com/whatwg/domparsing/blob/master/tests/innerhtml-01.xhtml |
| 13:09 | <smaug____> | that gives me the source code |
| 13:09 | <smaug____> | oh, that is such test |
| 13:10 | <Ms2ger> | Yeah, you need to clone to run them |
| 13:10 | <smaug____> | uh |
| 13:10 | <smaug____> | copy paste if faster |
| 13:10 | <smaug____> | s/if/is/ |
| 13:11 | <smaug____> | except that I'd need few scripts too |
| 13:13 | <smaug____> | oh, it should have to be cloned to certain place where testharness is available :( |
| 13:14 | <Ms2ger> | Or add w3c-test.org/ before the URLs |
| 13:16 | <Ms2ger> | Maybe MikeSmith wants to also set up a clone there :) |
| 13:20 | <MikeSmith> | I can set up clones as easily as boy scouts setting up pup tents at a jamboree |
| 13:21 | <Ms2ger> | With a lot of things falling over? |
| 13:22 | <MikeSmith> | yeah, like that |
| 13:22 | <MikeSmith> | and taking smoke breaks |
| 13:35 | <smaug____> | anyone with a recent IE? |
| 13:36 | <wilhelm> | smaug____: I use this: http://browserstack.com |
| 13:37 | <smaug____> | ugh, yet another thing which requires registration |
| 13:38 | <smaug____> | and it needs Flash :( |
| 13:38 | <wilhelm> | And monies. But you get a browser in a browser. |
| 13:44 | <annevk> | "I have read the other emails." hmm, mid-aired with darobin! |
| 13:45 | darobin | triggers emergency landing |
| 13:46 | <darobin> | annevk: I don't see your side of the mid-air |
| 13:46 | <annevk> | I think the way I have my email address set up at the moment is suboptimal and causes random delays :/ |
| 13:46 | <darobin> | ah, I'll wait then |
| 13:47 | <annevk> | It basically routes through my @gmail.com account |
| 13:47 | <darobin> | ah, yeah, hops tend to really pile up for email latency |
| 13:48 | <annevk> | I'd give Google direct access to the domain, but only if they keep the damn accounts merged |
| 13:49 | <annevk> | darobin: if you want RF, why don't you publish a REC? |
| 13:49 | <annevk> | darobin: also, are the relevant parties member of the i18n WG? |
| 13:49 | <darobin> | annevk: you mean of Encoding? |
| 13:50 | <darobin> | the point is certainly to get to Rec; if you're asking me why it can't be done faster that's another question |
| 13:50 | <darobin> | my point is about hypocrisy or not — and having reviewed the various moving parts I find none |
| 13:50 | <darobin> | can *other* parts be fixed, like shipping Recs faster to get RF faster, then yeah, you're preaching to the choir bro |
| 13:51 | marcosc_ | sings like an angel in latin about living standards... |
| 13:52 | <annevk> | darobin: oh also, my email went to a different list |
| 13:52 | <annevk> | darobin: because the chairs forked the thread |
| 13:52 | <darobin> | marcosc_: it's pretty hard to get IP commitments on living standards; but it would certainly be sweet if we could have LS and then just get commitments on snapshots say once a year |
| 13:52 | <darobin> | annevk: that's mid-airing at a distance |
| 13:52 | <annevk> | darobin: well, Gmail didn't care :) |
| 13:53 | <darobin> | ah, the many, many lists of I18N |
| 13:53 | <annevk> | one for each language, oh wait, that's not i18n |
| 13:53 | <darobin> | you have to use a different encoding for each |
| 13:54 | <darobin> | which group was yours to annevk? |
| 13:54 | <annevk> | darobin: public-i18n-core |
| 13:55 | <annevk> | http://lists.w3.org/Archives/Public/public-i18n-core/2013OctDec/0005.html |
| 13:55 | <darobin> | found it, ta |
| 13:55 | <annevk> | (the context is that nobody brought up RF thus far) |
| 13:56 | <darobin> | so it doesn't change anything, my response is still right and the final sane word on the topic :) |
| 13:56 | <annevk> | so I didn't reply to that, and I kinda gotta go now, so maybe tonight |
| 13:56 | <annevk> | darobin: it depends if what you said is the motivation |
| 13:56 | <darobin> | the motivation for what? |
| 13:57 | <annevk> | for forking |
| 13:57 | <darobin> | well what other reason would there be? |
| 13:57 | <annevk> | it seems for HTML it's about more |
| 13:58 | <annevk> | because the text is actually different in quite a few cases |
| 13:58 | <darobin> | I think we both know that the HTML situation is overall way more complicated |
| 13:58 | <darobin> | but you may have noted that I've strained as hard as can be to keep things in line and remove the complications there |
| 13:58 | <darobin> | for Encoding however (and a lot of other specs) the situation is a lot simpler |
| 13:59 | <annevk> | given how Art deals with me there doesn't seem to be much respect for people doing the actual editing |
| 13:59 | <annevk> | so for me it's not quite that simple |
| 13:59 | <darobin> | well, take your problem up with Art (or with Nokia) |
| 14:00 | <darobin> | I would be surprised if Richard and Addison gave you anything other than respect |
| 14:00 | <annevk> | Art hasn't replied to my latest email about that |
| 14:00 | <darobin> | is that related to Encoding? |
| 14:00 | <annevk> | no, about XHR, Fullscreen, etc. |
| 14:01 | <darobin> | well, if there is a way in which we could make things work better in good faith, but you're having problems with Art, don't hesitate to ask for intercession |
| 14:05 | <MikeSmith> | zcorpan: about the parser hacks, I've not committed the changes and don't have them online anywhere. But I can post the TreeBuilder.java file and diff somewhere |
| 14:05 | <zcorpan> | MikeSmith: ok |
| 14:05 | <MikeSmith> | all right I'll ping you when I've got it posted |
| 14:05 | <zcorpan> | thanks |
| 14:10 | <annevk> | darobin: noted |
| 14:10 | <annevk> | darobin: happy to have a in-person discussion with a few people at TPAC |
| 14:20 | <zcorpan> | smaug____: what does [Pure] mean? |
| 14:28 | <Ms2ger> | zcorpan, "doesn't change as long as you don't do anything side-effecty" |
| 14:38 | <zcorpan> | i don't understand how making the innerHTML getter not throw makes it [Pure], then |
| 14:40 | <Ms2ger> | Well |
| 14:40 | <Ms2ger> | If it can throw, it can't be pure |
| 14:40 | <zewt> | (why not? doesn't follow any meaning of a pure function that I know of) |
| 14:41 | <Ms2ger> | Maybe pure is a bad name... It's used to move the getter call out of loops |
| 14:41 | <Ms2ger> | And you don't want to throw before the loop when the access is inside the loop |
| 14:42 | <zewt> | i guess that does follow gcc's definition ("no effects except the return value"--changing code flow is an effect) |
| 14:42 | <jgraham> | Isn't that "referentially transparent"? |
| 14:42 | <zcorpan> | so the motivation is better perf? |
| 14:43 | <zcorpan> | is it common to call innerHTML in a loop in XML? |
| 14:43 | <zcorpan> | s/call/get/ |
| 14:46 | <jgraham> | Actually it seems to be "pure" per wikipedia |
| 14:47 | <Ms2ger> | zcorpan, can't make it pure in html and not in xml |
| 14:48 | <Ms2ger> | And yes, the goal is perf |
| 14:48 | <zcorpan> | Ms2ger: yeah i figured that could be problematic |
| 14:49 | <zcorpan> | so is it common to get innerHTML in a loop in HTML? |
| 14:50 | <darobin> | zcorpan: you mean as in for (...getElementsByTagName...) if (el.innerHTML.indexOf(foo))... ? |
| 14:50 | <darobin> | if so, not uncommon yeah |
| 14:50 | <darobin> | IME at least |
| 15:00 | zcorpan | greps for "].innerHTML." |
| 15:07 | <zcorpan> | some matches are like document.getElementsByTagName("TITLE")[0].innerHTML.substring(0,100)) but others are indeed in a loop like if(tags[x].innerHTML.indexOf("href")> -1) |
| 15:09 | <zewt> | (sadface to both) |
| 15:09 | <jgraham> | Not sure why that's a sadface |
| 15:09 | <jgraham> | Well the first one is a bit silly |
| 15:10 | <zcorpan> | 175 matches |
| 15:10 | <jgraham> | And the second one is probably not super-fast, but pulling the innerHTML out of the loop in that case might be a microoptimisation |
| 15:10 | <jgraham> | That isn't worth it |
| 15:10 | <zewt> | indexOf("href") seems pretty sadface |
| 15:11 | <jgraham> | Oh, that part |
| 15:11 | <jgraham> | Well yeah |
| 15:11 | <jgraham> | I'll agree with that |
| 15:11 | <zewt> | if that's a loop over [x] then it's calling it on a separate thing on each call, so it wouldn't be able to pull it out anyway |
| 15:11 | <jgraham> | I was about to say |
| 15:11 | <jgraham> | I should apparently stop talking because I keep being wrong |
| 15:11 | <zcorpan> | this is the june data set (53,000 pages) |
| 15:13 | <zcorpan> | zewt: good point |
| 15:21 | <bholley> | Hixie_: ping |
| 15:33 | <zcorpan> | so just "\.innerHTML\." is 291 matches. looking through them i don't see anything that is calling innerHTML on a single element in a loop |
| 15:34 | <zcorpan> | so it's not clear to me that it's actually common |
| 15:35 | <zcorpan> | that said, i don't really object to changing innerHTML to not throw, if the argument is shorter path to interop and better perf in an uncommon case |
| 15:36 | <zcorpan> | next stop: örebro |
| 15:36 | <jgraham> | Not sure if it is true in this case, but it could be in a benchmark |
| 15:36 | <jgraham> | and oh, he got off the train |
| 15:37 | <jgraham> | (the point being that if there is a dumb benchmark there is significant pressure to keep the fast behaviour even if it is not a common case in the real world) |
| 15:39 | <annevk> | Utrecht here |
| 15:40 | <annevk> | what would you do in XML though? |
| 15:40 | <annevk> | return null? |
| 15:40 | <annevk> | should we start annotating exceptions in IDL? |
| 15:40 | <annevk> | I need to ask bz again what the benefit is |
| 15:40 | <annevk> | also, we should prolly first sort out exceptions |
| 15:40 | <annevk> | :/ |
| 16:04 | <zcorpan> | returning null seems like it makes it harder to debug the error |
| 16:07 | <MikeSmith> | zcorpan: https://github.com/validator/htmlparser/commit/888fba3fe33c9b0fb0df76189b9d549eae176833 |
| 16:07 | <MikeSmith> | zcorpan: full Treebuilder.java source is at https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java |
| 16:07 | <zcorpan> | MikeSmith: thanks! |
| 16:09 | <zcorpan> | MikeSmith: after after body already did the "right" thing |
| 16:09 | <MikeSmith> | oh |
| 16:09 | <zcorpan> | not in the spec but in the impl |
| 16:09 | <MikeSmith> | ah |
| 16:12 | <zcorpan> | i don't know how but the /parsetree/ result obviously put the comment in body |
| 16:16 | <MikeSmith> | must be some other magic in there |
| 16:20 | <zcorpan> | MikeSmith: do you need to flush before pop? |
| 16:21 | <darobin> | zcorpan: traditionally it's done in the other order |
| 16:21 | <zcorpan> | MikeSmith: or do them together |
| 16:21 | darobin | really, really sorry |
| 16:21 | <zcorpan> | darobin: ? |
| 16:21 | <darobin> | really, nevermind |
| 16:22 | <zcorpan> | k :-) |
| 16:22 | <zcorpan> | MikeSmith: https://github.com/validator/htmlparser/commit/888fba3fe33c9b0fb0df76189b9d549eae176833#diff-82f1ed4c3b29018e8cae550a4c376b5eR1165 |
| 16:22 | <MikeSmith> | zcorpan: I can try and see if it makes any different |
| 16:28 | <MikeSmith> | zcorpan: so yeah it makes no difference as far as the runtime failure |
| 16:28 | <zcorpan> | ok |
| 16:28 | <MikeSmith> | it's still failing at https://github.com/validator/htmlparser/commit/888fba3fe33c9b0fb0df76189b9d549eae176833#diff-82f1ed4c3b29018e8cae550a4c376b5eR1165 |
| 16:29 | <MikeSmith> | um no not there |
| 16:31 | <MikeSmith> | https://github.com/validator/htmlparser/commit/888fba3fe33c9b0fb0df76189b9d549eae176833#diff-82f1ed4c3b29018e8cae550a4c376b5eL2889 |
| 16:44 | <dglazkov> | good morning, Whatwg! |
| 16:44 | <smaug____> | How could we make sure that people don't look at a TR/ spec when there is a newer editor's draft |
| 16:45 | <smaug____> | asking w3c to change TR/ to Trash/ might not be quite nice |
| 16:50 | <TabAtkins> | zcorpan, Ms2ger: I don't think WeakSet exists in ES yet, but it's one of those things that everyone assumes will happen soon, since it's just a nice convenience API over WeakMap with dummy values. |
| 16:51 | <smaug____> | hmm, what is the usecase for WeakSet? |
| 16:51 | <Ms2ger> | TabAtkins, http://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakset-objects |
| 16:53 | <zewt> | "An implementation may impose an arbitrarily determined latency" ... very strangely written text |
| 16:55 | <zewt> | making me squint reading it to figure out that they're talking about GC, instead of just saying so |
| 16:56 | <zewt> | smaug____: not sure that there are ever strictly use cases for sets in addition to maps, typically it's just convenience |
| 16:57 | <TabAtkins> | Ms2ger: Welp, I'm wrong. They're totally specced. |
| 16:57 | <smaug____> | well, there are plenty of use cases for normal sets, but weakset is very different beast |
| 16:57 | <TabAtkins> | smaug____: Same use-case as Set over Map. A Set is nothing more than a Map with a dummy value and a more convenient API. |
| 16:58 | <TabAtkins> | It's for "I want to make a set of things for some reason, but don't want this to cause memory-leaks". |
| 16:58 | <smaug____> | sure, but WeakSet is very different from a Set |
| 16:58 | <smaug____> | you need to still keep reference to the key |
| 16:58 | <TabAtkins> | WeakSet is basically a branding mechanism. |
| 16:58 | <smaug____> | no iteration or anything |
| 16:59 | <TabAtkins> | You can throw things into a WeakSet to indicate that they have some hidden, unforgeable property. |
| 17:00 | <TabAtkins> | Doing so with a Set, obviously, would leak like a sieve. |
| 17:00 | <smaug____> | sure |
| 17:00 | <TabAtkins> | But yeah, the only thing you can do with a WeakSet is put things in it, and check if something is in it. |
| 17:00 | <TabAtkins> | Those are still useful operations. |
| 17:02 | <smaug____> | WeakMap is just so close... |
| 17:02 | <smaug____> | but ok, that is a use case |
| 17:04 | <smaug____> | Ms2ger: so, what do you think of W3C Bug 23460 |
| 17:05 | <Ms2ger> | smaug____, I'm fine either way |
| 17:05 | <TabAtkins> | smaug____: And Map is so close to Set. ^_^ But having the ability to union/intersect/etc is worth the pain of essentially just having syntax sugar over a Map. |
| 17:07 | <Ms2ger> | TabAtkins, oh, and here I thought you always wore ties to csswg meetings |
| 17:07 | <TabAtkins> | Ms2ger: Nope, just on Fridays. |
| 17:08 | <smaug____> | Ms2ger: well, the question is should we spec the reality, or something that we hope browsers to do |
| 17:08 | <TabAtkins> | By the way, still disappointed I only got to see you through a window in a door. :/ |
| 17:08 | <Ms2ger> | TabAtkins, not like I was hiding during the break... |
| 17:08 | <Ms2ger> | smaug____, has anyone tested IE already? |
| 17:09 | <TabAtkins> | Sure you were! By the time I was done talking about colors, you'd run away. |
| 17:09 | <smaug____> | Ms2ger: I did, using that browserstack thing |
| 17:10 | <smaug____> | hmm, but, we need to define the algorithm somewhere |
| 17:10 | <Ms2ger> | smaug____, I'll go with not throwing, then |
| 17:10 | <Ms2ger> | Hixie_, ping |
| 17:10 | <smaug____> | HTML spec's XML serialization is used elsewhere too, I think |
| 17:13 | <Ms2ger> | I think xhr used to use it directly? |
| 17:16 | <smaug____> | Ms2ger: http://domparsing.spec.whatwg.org/#innerhtml points to HTML spec's XML serialization, http://xhr.spec.whatwg.org/#dom-xmlhttprequest-send points to http://domparsing.spec.whatwg.org/#concept-serialize which points to http://domparsing.spec.whatwg.org/#concept-serialize-xml |
| 17:17 | <Ms2ger> | Right |
| 17:17 | <smaug____> | which is somewhat odd |
| 17:18 | <smaug____> | but anyhow, this change could all be done in the domparsing spec |
| 17:19 | <Ms2ger> | But then we should remove the bit from HTML, if nobody else uses it |
| 17:20 | <smaug____> | Ms2ger: we use it for Document, I think |
| 17:20 | <Ms2ger> | Hmm? |
| 17:20 | <smaug____> | http://domparsing.spec.whatwg.org/#concept-serialize-xml Document part links to HTML spec |
| 19:22 | <zcorpan> | MikeSmith: https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2534 |
| 19:27 | <zcorpan> | also https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2478 |
| 19:28 | <zcorpan> | https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2886 |
| 19:30 | <zcorpan> | MikeSmith: the spec has "act as if in body" language for e.g. <html> in head that v.nu parser has inline |
| 19:34 | <zcorpan> | MikeSmith: https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L4019 also looks wrong (for </head><style></style>...) |
| 19:35 | <zcorpan> | or rather https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L4021 |
| 19:39 | <zcorpan> | need pop() here? https://github.com/validator/htmlparser/blob/888fba3fe33c9b0fb0df76189b9d549eae176833/src/nu/validator/htmlparser/impl/TreeBuilder.java#L2981 |
| 20:04 | <jgraham> | function add2(a, b) { |
| 20:04 | <jgraham> | return Task.spawn(function () { |
| 20:04 | <jgraham> | let sum = yield a + b; |
| 20:04 | <jgraham> | throw new Task.Result(sum); |
| 20:04 | <jgraham> | }); |
| 20:04 | <jgraham> | } I for one welcome our new ES6 overlords |
| 20:05 | <jgraham> | (hopefully that's just some perversion in that library) |
| 20:05 | <jgraham> | (but oh boy is it ugly) |
| 20:09 | <jsbell> | Never look at the implementation details of coroutines. *shudder* |
| 20:10 | <jgraham> | But this is supposed to be user-level code! |
| 20:13 | <jsbell> | I think it's proof that while generators enable you to implement such things, without syntax to support it no mere mortal should be expected to do it. |
| 20:30 | <annevk> | http://www.ietf.org/mail-archive/web/json/current/msg01783.html lol, also :/ |
| 20:31 | <annevk> | jgraham: only yield is in ES6 |
| 20:43 | <zcorpan> | jgraham: throw? that looks weird... |
| 20:49 | <TabAtkins> | jgraham: Where's that example from? "yield a+b" in Task is completely worthless, because "a+b" doesn't return a Task. |
| 20:49 | <TabAtkins> | That's just inserting useless asynchrony. |
| 20:50 | <TabAtkins> | But yeah, I suspect in ES7 we'll get sugar for this stuff, since fully async functions are just generators + a CPS transform. |
| 20:51 | <TabAtkins> | function^ add2(a,b) { let sum = await a+b; return sum; }, or something like that. Automatically returns a promise for the return value. |
| 20:52 | <smaug____> | slightlyoff: is there any API for https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md stuff? |
| 20:53 | <smaug____> | really hard to understand that all without seeing interfaces |
| 20:53 | <jgraham> | TabAtkins: It's from mozilla.dev.platform |
| 20:54 | <Domenic_> | jgraham: I think that is Mozilla generator stuff, that is the only way it makes sense |
| 20:54 | <Domenic_> | not ES6 generators |
| 20:54 | <jsbell> | smaug____ (give or take a _): look at https://github.com/slightlyoff/ServiceWorker/blob/master/service_worker.ts |
| 20:54 | <jsbell> | Per the guy sitting next to me who's implementing ServiceWorker that's the closest thing to an API doc at the moment |
| 20:54 | <smaug____> | ahaa |
| 20:55 | <smaug____> | using some odd form of idl |
| 20:55 | <jsbell> | ts = TypeScript apparently |
| 20:55 | <smaug____> | or perhaps that is some es thing |
| 20:55 | <smaug____> | ah, hm, right |
| 21:14 | <miketaylr> | zcorpan: http://simon.html5.org/specs/quirks-mode -> https://dvcs.w3.org/hg/quirks-mode/raw-file/tip/Overview.html -> "error: Overview.html@936eae1aa829: not found in manifest" |
| 21:15 | <zcorpan> | miketaylr: http://quirks.spec.whatwg.org |
| 21:15 | <miketaylr> | zcorpan: thanks. possible to update the link on the "This document has been superseded. See http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/Overview.html. " message? |
| 21:15 | <jgraham> | Domenic_: Ah, I assumed they were compatible |
| 21:16 | <Domenic_> | generally Mozilla's stuff is pretty far off from ES6... :-/ |
| 21:17 | <zcorpan> | miketaylr: maybe |
| 21:17 | <matjas> | or just 301 to quirks.spec.whatwg.org |
| 21:17 | <miketaylr> | yeah or meta refresh :P |
| 21:18 | <zcorpan> | i'll just <marquee> the message |
| 21:18 | <miketaylr> | wfm. |
| 21:18 | <matjas> | ah, the good ol’ special miketaylr treatment |
| 21:20 | <yoav> | TabAtkins: You around? |
| 21:21 | <TabAtkins> | yoav: pong |
| 21:21 | <pdr> | TabAtkins, more srcset questions :) |
| 21:21 | <yoav> | Hey! I've got a question regarding srcset/srcN, intrinsic size and natural dimensions. |
| 21:22 | <yoav> | Do naturalWidth/naturalHeight return the real natural dimensions, or the corrected intrinsic dimensions? |
| 21:22 | <TabAtkins> | Where are those defined? I know those properties exist, but I'm not familiar with them. |
| 21:22 | <pdr> | (See: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#dom-img-naturalwidth) |
| 21:22 | <TabAtkins> | Thanks, pdr. ^_^ |
| 21:23 | <TabAtkins> | The intrinsic width and height of <img>s are corrected by the chosen resolution multiplier. Pretty sure this is specified for srcset in HTML, and it's an oversight I haven't yet corrected in srcN. |
| 21:24 | <pdr> | Just to be extra concrete, <img srcset="100x100.png 2x"> would have an intrinsic size of 50x50, a natural size of 50x50, and an actual size of 50x50. There is no way to access the original 100x100 dimensions via javascript |
| 21:25 | <Hixie_> | bholley: poing |
| 21:25 | <pdr> | Is that correct? |
| 21:25 | <TabAtkins> | Yes. |
| 21:25 | <bholley> | Hixie_: too late at this point in the French evening ;-) |
| 21:25 | <bholley> | Hixie_: but tomorrow, if that works for you |
| 21:25 | <zcorpan> | pdr: what do you mean by natural and actual? |
| 21:25 | <Hixie_> | bholley: sure thing |
| 21:25 | <bholley> | Hixie_: cool |
| 21:25 | <pdr> | zcorpan, nautral is defined in the link above. Actual is the dimensions that the image gets in the dom |
| 21:27 | <zcorpan> | pdr: naturalWidth returns the intrinsic width, so yeah |
| 21:27 | <zcorpan> | pdr: i don't follow "gets in the dom" |
| 21:28 | <pdr> | yeah, we were just making extra sure as we implement this in Blink. By "gets in the dom" I just mean what image.width returns |
| 21:28 | <TabAtkins> | yoav: Okay, it's now specified in the spec. |
| 21:28 | <yoav> | TabAtkins: Awesome! |
| 21:28 | <TabAtkins> | pdr: ...assuming that the author doesn't specify width='', etc. |
| 21:28 | <zcorpan> | pdf: ok. then img.width can return something else, because it returns the rendered width, which can be set by CSS |
| 21:29 | <TabAtkins> | zcorpan: No, img.width doesn't care about CSS, iirc. |
| 21:29 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#dom-img-width |
| 21:29 | <zcorpan> | yes it does :-P |
| 21:29 | <TabAtkins> | Whoops, never mind. |
| 21:29 | <TabAtkins> | Yeah, that's right, that's why .naturalWidth/Height exist. |
| 21:30 | <pdr> | Lets walk through that example. <img srcset="100x100.png 2x" width="5" height="5">. This will have an intrinsic size of 50x50, a natural size of 50x50, and an image size of 5x5, if I understand correctly |
| 21:30 | <TabAtkins> | Yup. |
| 21:30 | <TabAtkins> | naturalWidth/Height is just the name of the properties. It's defined as returning the intrinsic width/height. |
| 21:30 | <zcorpan> | well, it would be reasonable for width/height to reflect the width/height attributes, like all other HTML elements with width/height attributes, but <img> is special |
| 21:30 | <TabAtkins> | There's no separate notion of "natural width/height". |
| 21:31 | <yoav> | TabAtkins: OK. So intrinsic==natural. |
| 21:32 | <zcorpan> | naturalWidth just has a stupid name because it was implemented before it was specced :-) |
| 21:32 | <zcorpan> | (<video> has videoWidth, btw) |
| 21:33 | <zcorpan> | (which might also be a stupid name, but for a different reason. iirc videoWidth predated naturalWidth in the spec.) |
| 21:34 | <zcorpan> | pdr: also, for completeness, <img srcset="100x100.png 2x" width="5" height="5" style="width:10px; height:10px"> would have an image size of 10x10 |
| 21:35 | <pdr> | zcorpan, that's a great point, thank you |
| 21:35 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#dom-img-width also has different rules for when the image isn't actually rendered |
| 21:46 | <zcorpan> | miketaylr: fixed |
| 21:46 | <miketaylr> | zcorpan: gracias |
| 22:13 | <zcorpan> | so speaking of json, i recall when we implemented json support in carakan, everyone did their own thing and we tried to follow the spec to the letter but had to derivate for some things because of web compat |
| 22:13 | <zcorpan> | i wonder what the situation is today |
| 22:13 | <zcorpan> | i guess the spec hasn't changed because it MUST NOT CHANGE |
| 22:15 | <annevk_> | All this fuss about JSON and it still doesn't support comments. |
| 22:15 | <zcorpan> | (or maybe it was before carakan) |
| 22:16 | <annevk> | zcorpan: yeah, that argument seems to be repeated a lot. |
| 22:33 | <zcorpan> | "JSON can't change since it's not versioned.", no, it can't change because people believe that it can't change |
| 22:43 | <Hixie_> | that's a pretty funny thing to say since we stopped versioning HTML precisely to make it easier to change :-P |