| 06:51 | <ondras> | so I understand that the attributeChanged callback is executed only when the custom element's own attribute chanegs |
| 06:52 | <ondras> | *changes |
| 06:52 | <ondras> | what if my custom element need to know when its size changes? |
| 07:18 | <cdan> | good morning |
| 09:02 | <zcorpan> | ondras: size as in rendered size? |
| 09:11 | <ondras> | zcorpan: yes |
| 09:12 | <ondras> | zcorpan: my use case is an interactive map |
| 09:12 | <ondras> | zcorpan: the underlying JS api needs to be notified when the viewport size changes |
| 09:12 | <zcorpan> | ondras: use window.onresize |
| 09:14 | <ondras> | zcorpan: what if the size of my element changes due to interaction with other elements in page? |
| 09:14 | <zcorpan> | ondras: is the map you want to be notified about a <canvas>? |
| 09:15 | <ondras> | zcorpan: no, but it behaves similarly |
| 09:15 | <ondras> | zcorpan: think of a google maps api |
| 09:15 | <ondras> | zcorpan: so its container might have width:50%, but can be situated within other element whose size might change independently... |
| 09:33 | <ondras> | 11:15 < ondras> zcorpan: no, but it behaves similarly |
| 09:33 | <ondras> | 11:15 < ondras> zcorpan: think of a google maps api |
| 09:33 | <ondras> | 11:15 < ondras> zcorpan: so its container might have width:50%, but can be situated within other element whose size might change independently... |
| 09:33 | <zcorpan> | ondras: can you point to a page that does that? |
| 09:33 | <zcorpan> | ondras: i can think of ways to hack around it, e.g. use an iframe and onresize. or if you control the other things whose size might change, let them send a notification when they change their size |
| 09:34 | <zcorpan> | (sorry for dropping off, i'm on the train) |
| 09:36 | <ondras> | zcorpan: well have a look at http://api4.mapy.cz/ |
| 09:36 | <ondras> | zcorpan: I want to implement the map as a custom element |
| 09:36 | <ondras> | zcorpan: but I have no explicit control on its size and placement |
| 09:37 | <ondras> | zcorpan: so a user might want to put it in a sidebar with variable width or so |
| 09:37 | <ondras> | zcorpan: and the underlying mapping JS absolutely needs to know when its "viewport" size changes |
| 09:39 | <zcorpan> | ondras: ok, thanks |
| 09:39 | zcorpan | 101 switching trains |
| 10:03 | <zcorpan> | ondras: it's not clear to me if this is something that's specific to custom elements or if we should provide it for elements in general |
| 10:04 | <ondras> | zcorpan: agreed. |
| 10:04 | <zcorpan> | ondras: also, is it OK if it's just an event that's queued after the fact, or does the JS need to be notified before the new layout actually happens? |
| 10:04 | <ondras> | zcorpan: anyway, without a custom element, the situation is more explicit |
| 10:05 | <ondras> | zcorpan: people are used to call JS API "syncSize" or so when situation changes |
| 10:05 | <ondras> | but when the map becomes a declarative element |
| 10:05 | <ondras> | as in <our-map x=... y=... /> |
| 10:05 | <zcorpan> | yeah |
| 10:05 | <ondras> | people might want to evade any further JS interaction at all |
| 10:05 | <ondras> | zcorpan: queued after the fact, it can be delayed |
| 10:06 | <ondras> | zcorpan: the JS API needs to fetch additional map tiles to fill in the viewport as it resizes |
| 10:06 | <zcorpan> | ok |
| 10:08 | <zcorpan> | ondras: i'd say bring up the use case to the custom element people. if it's something that should work for ordinary elements also then [cssom-view] on www-style |
| 10:09 | <ondras> | zcorpan: okay, can you please point me to some directions? is this irc channel not sufficient? |
| 10:38 | <zcorpan> | ondras: see "Participate" at the top of http://w3c.github.io/webcomponents/spec/custom/ |
| 10:41 | <ondras> | okay, thanks |
| 11:07 | <smaug____> | which one is the current promise spec |
| 11:08 | <smaug____> | maybe http://promises-aplus.github.io/promises-spec/ ? |
| 11:11 | <smaug____> | but that doesn't define clearly how it all integrates with the event loop |
| 12:11 | <IZh> | benschwarz: Hi. |
| 12:13 | <zcorpan> | smaug____: https://people.mozilla.org/~jorendorff/es6-draft.html maybe? |
| 12:29 | <IZh> | Is it possible to get PDF-version of HTML5? :-) |
| 12:30 | <IZh> | I want to read it from my smartphone in offline. But I can't find actual offline-version or PDF. |
| 12:45 | <jorendorff> | promises spec will be better in a month, i'm told |
| 12:45 | <jorendorff> | kind of a disaster right now |
| 12:48 | <zcorpan> | IZh: there was for a while but is no longer because it took too much resources on the server or something. ask Hixie if you want to set up a web service he can run in the build process |
| 12:48 | <odinho_> | IZh: There was, -- but the generators kept crashing when it was created. This was way back though, I haven't had an urge to read spec any other place than web these days. |
| 12:51 | <zcorpan> | also see https://hsivonen.fi/printing-wa10/ (this was earlier still) |
| 12:52 | <IZh> | zcorpan: Thanks. I will ask him. |
| 12:54 | <IZh> | odinho: I have most of the spare time on the road in train or subway where there is no Internet. :-) I tried to use single-page from W3C but it is too heavy for mobile devices. And it has an annoying banner on the left and more annoying button on top of the text. |
| 12:55 | <IZh> | Also I tried to download developers.whatwg.org and tried to build it. It doesn't work offline. |
| 12:56 | <jgraham> | IZh: You should try getting Hixie to add offline support for the multipage spec :) |
| 12:57 | <IZh> | jgraham: I think, yes. :-) |
| 12:57 | <IZh> | Hixie: Hi. |
| 12:57 | <jgraham> | IZh: (it is before 6am Hixie time) |
| 12:58 | <IZh> | By the way, http://archive.germanforblack.com/articles/html5-for-web-developers states: It features find-as-you-type search, offline access, beautiful typography, technical references pulled inline, and alternate styles for handheld devices or low resolution displays. |
| 12:58 | <IZh> | Where is promised offline access? ;-) |
| 12:59 | <jgraham> | That version, which isn't the whole spec, does seem to have offline access |
| 13:00 | <IZh> | jgraham: I can't find it. |
| 13:00 | <IZh> | I mean, how to make it work offline? |
| 13:01 | <jgraham> | IZh: At least on Desktop Firefox it does an offline sync when you first load it and then transparently keeps working when you put the browser in offline mode |
| 13:01 | <jgraham> | YOu don't have to "do" anything |
| 13:02 | <IZh> | jgraham: Ahh... That offline... I used wget -r -p ;-) |
| 13:04 | <jgraham> | Yeah, the one targeted at people who, when confronted with a problem, don't think "I know, I'll use wget" ;) |
| 13:05 | <IZh> | I thought about "total offline" where I will have static version on my disk, and could open it by any local browser. |
| 13:08 | <sangwhan> | does anyone know if http://test.csswg.org/harness/suite/css-multicol-1_dev is still in use? tests are 404 |
| 13:09 | <IZh> | By the way, it there any document describing difference between W3C's and WHATWG's HTML5? |
| 13:09 | <sangwhan> | IZh: http://www.w3.org/html/landscape/ |
| 13:10 | <zcorpan> | sangwhan: http://hg.csswg.org/test/file/ccd08e6ef255/approved/css3-multicol/src ? |
| 13:11 | <IZh> | sangwhan: Thank you. Both standards says that there is no such document. :-) |
| 13:12 | <zcorpan> | there is no spoon |
| 13:12 | <sangwhan> | zcorpan: thanks, so the suite i was looking at earlier is dead now? |
| 13:12 | sangwhan | knows nothing about css-wg or processes there, it seems quite different from the other groups |
| 13:12 | <zcorpan> | sangwhan: no idea. ask in #css or #testing on irc.w3.org |
| 13:13 | <sangwhan> | zcorpan: ok, gotcha |
| 13:16 | <Ms2ger> | sangwhan, the csswg likes Process. A lot. |
| 13:17 | <sangwhan> | Ms2ger: process with a capital P? |
| 13:18 | <Ms2ger> | Yep |
| 13:20 | <jgraham> | Although not with a capital PR, sadly |
| 13:20 | <zcorpan> | PROcess |
| 13:20 | <zcorpan> | for the pros |
| 13:22 | <jgraham> | You have to have a recognised qualification in bureaucracy to get entry? |
| 15:23 | <dglazkov> | good morning, Whatwg! |
| 16:48 | <TabAtkins> | Replacing lone surrogates with U+FFFD wouldn't corrupt much, if any, I'd think. |
| 16:51 | <TabAtkins> | gsnedders: There is no way to MQ based on device pixels directly. 'resolution' is based on the device-pixel-to-px ratio, if that's helpful. |
| 16:56 | <gsnedders> | TabAtkins: But then I have the fact there's no image-resolution supported, right? :( |
| 16:57 | <TabAtkins> | Yes. What are you trying to do? |
| 16:57 | <gsnedders> | Just have a header image that's high quality, and not always loading the full DPI one |
| 16:57 | <gsnedders> | s/DPI/resolution/ |
| 16:57 | <gsnedders> | bleh |
| 16:58 | <TabAtkins> | In CSS or HTML? |
| 16:58 | <TabAtkins> | Sounds like CSS. |
| 16:58 | <gsnedders> | CSS really. |
| 16:58 | <TabAtkins> | Use -webkit-image-set(). |
| 16:58 | <gsnedders> | What about other browsers? :( |
| 16:58 | <TabAtkins> | File bugs for them to implement image-set(). It's in Images 4. |
| 16:59 | <gsnedders> | Does image-set not still render stuff at the CSS 96dpi-apparent? |
| 17:00 | <TabAtkins> | I don't know what you're asking. But it believes you when you tell it what resolution the image is, and renders appropriately. |
| 17:00 | <wilhelm> | I didn't see your original question, but *-device-pixel-ratio plus a background-size property usually gets the job done. |
| 17:00 | <TabAtkins> | Yeah, manual sizing works too. Browsers'll downscale the high-DPI image to the size you specify, which is basically the same thing. |
| 17:01 | gsnedders | wonders if he even has any high DPI hardware to test this on… |
| 17:01 | <gsnedders> | :P |
| 17:02 | <TabAtkins> | I recommend not doing anything at all if you don't have the ability to test it. |
| 17:02 | <gsnedders> | Oh, my tablet does. Okay. |
| 17:02 | <Hixie> | sangwhan: note that that landscape document is woefully incomplete (e.g. misses all the editorial changes, and a number of (unintentional?) normative changes |
| 17:02 | <gsnedders> | TabAtkins: Oh, I can borrow stuff to test, just slower turn-around town. :) |
| 17:02 | SamB | wonders how much overlap there is between "high resolution hardware" and (say) "200% zoom" |
| 17:02 | <gsnedders> | s/town/time/ |
| 17:02 | <gsnedders> | What am I even thinking. |
| 17:03 | <wilhelm> | gsnedders: I use manual sizing and queries on the banner with a person on it here: https://kreftforeningen.no/ |
| 17:03 | <sangwhan> | Hixie: it's better than nothing... |
| 17:03 | <TabAtkins> | SamB: Ideally, a 2x device and a 1x device on 200% zoom should be treated identically by all the things that care about resolution. |
| 17:03 | <SamB> | TabAtkins: exactly my thoughts |
| 17:04 | <Hixie> | sangwhan: sure, just making sure people don't have the wrong expectations :-) |
| 17:05 | <sangwhan> | Hixie: point |
| 17:06 | <wilhelm> | gsnedders: (Actually, on that banner I have a ton of different images. I have a 1-column, 2-column and 3-column version of the image, depending on your screen width. Double that for 1x and 2x resolution of each. And then there's 7 different people it rotates between. :D ) |
| 17:08 | <Hixie> | i really wish i could work out what people are doing ot accidentially file copy-and-paste content as bugs |
| 17:10 | <SamB> | against html? |
| 17:11 | <SamB> | perhaps they use devices on which it is easy to accidentally paste? |
| 17:12 | <TabAtkins> | I dont' think those devices exist. |
| 17:12 | <SamB> | so you don't think pocket-drag-and-drop is likely? |
| 17:13 | <TabAtkins> | I don't, no. ^_^ |
| 17:13 | <gsnedders> | wilhelm: Well ooooh, aren't you fancy. :P |
| 17:13 | <wilhelm> | Unix middle click? (c: |
| 17:14 | <SamB> | Hixie: do you have user-agent data? |
| 17:14 | <wilhelm> | gsnedders: Responsive photography is fun, mmkay. |
| 17:14 | <SamB> | I guess that goes into the bugs, doesn't it |
| 17:14 | <gsnedders> | wilhelm: :) |
| 17:15 | <gsnedders> | I know I'm not going to get this done in the week I have before exam panic time :( |
| 17:15 | <wilhelm> | You're procastina-hacking? |
| 17:16 | <gsnedders> | Nah, I put aside this week to do stuff *I* want to do and don't have external deadlines for. |
| 17:16 | <Hixie> | SamB: yeah |
| 17:16 | <gsnedders> | Except dealing with taxes. Have external deadline for that. |
| 17:16 | <gsnedders> | And I have to file taxes *on paper*. Ergh. |
| 17:17 | <gsnedders> | Pretty sure that's cruel or unusual punishment. |
| 17:17 | <wilhelm> | Is your government from the past? |
| 17:18 | <gsnedders> | It can be done: a) online (except if 1, 2, or 3 apply); b) using third-party commerical software; c) on paper. |
| 17:18 | <gsnedders> | I refuse to pay for the third-party software, and I'm in one of the categories forbidden from online, so… |
| 17:26 | <Hixie> | hey, i found a bug in the tokeniser tests |
| 17:27 | <Hixie> | "Bad named entity: Abreve without a semi-colon" doesn't have a "ParserError" |
| 17:28 | <gsnedders> | file a bug |
| 17:28 | <gsnedders> | To quote your normal retort :) |
| 17:29 | <Hixie> | i have a patch |
| 17:29 | <Hixie> | what do i do with it? |
| 17:30 | <Hixie> | (also, are none of you actually checking the parser errors in the tokeniser tests? how was this not caught earlier?) |
| 17:30 | <SimonSapin> | zcorpan: CSSOM doesn’t say anything about surrogate code point. Does that mean they’re valid in any input and end up untouched in selectors, property values, etc? |
| 17:30 | <gsnedders> | The same as you did for the last contribution you made to html5lib! Create a pull request on it. |
| 17:30 | <gsnedders> | Hixie: html5lib definitely doesn't check parse errors, I think Nolan's Obj-C parser does, but I don't know if he uses the tokenizer tests |
| 17:31 | <gsnedders> | The tokenizer tests are somewhat dead, everybody just uses the tree-construction tests. |
| 17:31 | <Hixie> | gsnedders: do the tree-construction tests subsume all the tokeniser tests? |
| 17:31 | <Hixie> | (would be good to put that in the README if it's true) |
| 17:31 | <gsnedders> | Not quite. jgraham had a programmatic conversion to tree constructor tests which I believe is public somewhere. |
| 17:31 | <Hixie> | (how the heck do i do a pull thingy. the google isn't helping me.) |
| 17:32 | <Hixie> | well right now my tokeniser is just entity parsing, so i'll keep using them for now and see how bad they are |
| 17:32 | <Hixie> | if they're actually useless, i'll propose killing them entirely. |
| 17:32 | <jgraham> | They shouldn't be useless |
| 17:33 | <gsnedders> | There's also the difficulty that different impls rely on different amounts of feedback from the tree constructor |
| 17:33 | <Hixie> | git commit, git push? |
| 17:33 | <gsnedders> | (i.e., some make transitions defined in the tree construction in the tokenizer) |
| 17:33 | <gsnedders> | Hixie: Yeah, then go onto GH and create a PR. |
| 17:33 | <Hixie> | yeah i never really understood why we had tokeniser tests at all, but since we have them i figured i'd use them |
| 17:33 | <jgraham> | Hixie: On a branch |
| 17:34 | <gsnedders> | Hixie: but if jgraham's around he can help |
| 17:34 | <gsnedders> | Because I need to go :) |
| 17:34 | <jgraham> | I'm not, really |
| 17:34 | <Hixie> | i miss the good old days where submitting a patch was just svn diff | email |
| 17:34 | jgraham | doesn't :p |
| 17:35 | <Hixie> | jesus, you have to git add first |
| 17:35 | <jgraham> | (this is a good thing) |
| 17:35 | <Hixie> | if you say so |
| 17:35 | <Hixie> | what username is git push asking me for? |
| 17:36 | <jgraham> | You need to set up ssh keys for github |
| 17:37 | <Hixie> | to _submit a patch_ i need an _ssh key_?! |
| 17:37 | <jgraham> | Yes |
| 17:37 | <Hixie> | ok forget that |
| 17:37 | <Hixie> | i'll just send gsnedders a diff when i'm done |
| 17:38 | <Ms2ger> | Hixie, I think you can push over https with your password |
| 17:38 | <SamB> | Hixie: yes, it'd be better if you could just submit merge requests by email like you used to be able to do with bzr |
| 17:40 | <Hixie> | hm, actually, this whole patch is wrong anyway. turns out "&Abreve" alone isn't a parse error, since it's not a valid entity and there's no trailing semicolon |
| 17:40 | <SamB> | what is a "parse error" |
| 17:42 | <Hixie> | SamB: http://www.whatwg.org/specs/web-apps/current-work/#parse-error |
| 17:42 | <SamB> | I guess I should have checked for that before saying that |
| 17:44 | <gsnedders> | Hixie: I think html5lib-python tests *number* of parse errors (but not order), so I think the number /should/ be right |
| 17:44 | <Hixie> | yeah, i just misread the test |
| 17:44 | <Hixie> | my implementation had a big "XXX need to only fire parse error in certain cases" thing where my bug was |
| 17:44 | <Hixie> | i didn't expect that to be one of the first things i'd run into |
| 17:45 | <SamB> | FR: source code should be in color |
| 17:45 | <SamB> | so it could be a big *red* XXX |
| 17:45 | <gsnedders> | As the top of source shows, Hixie is a fan of text-mode |
| 17:45 | <SamB> | hmm, actually that's not a very good joke, since you can actually do that ... |
| 17:46 | <Hixie> | actually i'm using delphi-mode here. |
| 17:46 | <Hixie> | though it really doesn't colour much |
| 17:46 | <SamB> | can't you add more patterns like usual? |
| 17:50 | <Hixie> | SamB: that would involve figuring out elisp... |
| 18:03 | hober | <3 elisp |
| 18:04 | <Ms2ger> | Hixie, you don't do elisp? What kind of emacs user are you? :) |
| 18:04 | <Hixie> | a busy one? :-) |
| 18:28 | <TabAtkins> | Hixie: Github wants your login if you're submitting a patch. It prefers if you've set up ssh keys for identity, but you can do un/pw if necessary. You have to swap what url you're pushing to, though. |
| 18:29 | <TabAtkins> | If you want to pretend that git add doesn't exist, just always commit with the -a flag as well, like `git commit -am "foo"`. |
| 18:29 | <TabAtkins> | (This won't catch new files that get added - you still have to manually add them - but it'll catch all your edits.) |
| 18:32 | <Hixie> | good to know |
| 18:40 | <Hixie> | load average: 37.79, 27.83, 16.00 |
| 18:40 | <Hixie> | that explains why i was getting high latency... |
| 18:41 | <Hixie> | all seems to be blog traffic |
| 18:41 | <Hixie> | lots of lines of: |
| 18:41 | <Hixie> | 10372 25923 lhunt 1:19.59 1.3 265m 39m 2.6 ? php53.cgi |
| 18:47 | <Hixie> | looks like lots and lots of traffic from 50.56.236.169 |
| 19:15 | <jochen__> | Domenic_: around? |
| 19:17 | <aklein> | jochen__: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296 has lots of background here but as Hixie said it didn't exactly land at a complete conclusion |
| 19:18 | <aklein> | jochen__: some thoughts from Domenic_ in particular at https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296#c36 |
| 19:21 | <jochen__> | i wonder how the spec sets up the execution context |
| 19:24 | <Domenic_> | jochen__: for a bit yeah |
| 19:24 | <jochen__> | cool |
| 19:25 | <jochen__> | Domenic_: so my question is, in https://code.google.com/p/chromium/issues/detail?id=346167 you say that chrome violates the es spec |
| 19:25 | <jochen__> | but I fail to understand which part |
| 19:25 | <aklein> | jochen__: "A new execution context is created whenever control is transferred from the executable code associated with the currently running execution context to executable code that is not associated with that execution context." |
| 19:25 | <Domenic_> | jochen__: I believe that was fixed looking at the code recently; I haven't re-run the tests yet though. |
| 19:25 | <jochen__> | as the spec allows the embedder to schedule whatever other tasks it feels like |
| 19:26 | <Domenic_> | jochen__: oh we are talking about the scheduler, not chrome's nonstandard tests, sorry. |
| 19:26 | <Domenic_> | s/tests/methods |
| 19:26 | <jochen__> | right |
| 19:26 | <jochen__> | the spec says the embedder might mix in arbitrary other tasks as long as the js tasks are executed FIFO |
| 19:26 | <aklein> | jochen__: and [[Call]] creates one too: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-built-in-function-objects-call-thisargument-argumentslist |
| 19:28 | <jochen__> | aklein: yes, I meant, are there any guarntess about the context |
| 19:29 | <Domenic_> | jochen__: you may be right. but i am not sure an entire event loop turn is allowed to pass. |
| 19:30 | <jochen__> | does the es spec talk about event loops at all? |
| 19:30 | <Domenic_> | No |
| 19:30 | <Domenic_> | I guess if you pretended the entire rendering-etc-cycle was one Task |
| 19:30 | <Domenic_> | so that the ES task queue never emptied |
| 19:31 | <Domenic_> | then you could interleave rendering between promise Tasks |
| 19:32 | <jochen__> | maybe we shouldn't have mutation observers, but use object.observe on the javascript objects representing the dom nodes |
| 19:32 | <jochen__> | then all tasks are speced by ES |
| 19:32 | <aklein> | jochen__: heh |
| 19:32 | <Domenic_> | i think there are backcompat restrictions on mutation observer firing order that make any FIFO model fail |
| 19:33 | <SamB> | jochen__: does that work nicely with different objectspaces seeing the same DOM? |
| 19:33 | <aklein> | jochen__: actually the more I read the more it seems like we need a SetAutorunMicrotasks(false) for the ES6 spec just like rafaelw added for V8 |
| 19:33 | <SamB> | i.e. in "content scripts" |
| 19:33 | <aklein> | jochen__: and then HTML would say how to treat the queues in ES |
| 19:34 | <Domenic_> | i generally think the fact that ES and HTML are both speccing this is a disgrace |
| 19:34 | <aklein> | as it is ES is trying to defer to HTML but isn't being specific enough |
| 19:34 | <Hixie> | i'm happy to integrate or provide hooks or whatever is needed |
| 19:34 | <SamB> | so, maybe HTML people need to rewrite that attempt to defer and send in the patch? |
| 19:34 | <jochen__> | aklein: sure, if the es guys are ok with saying "there's no guarantee about the tasks at all other that then the ones that get eventually executed are run in fifo order" |
| 19:34 | <aklein> | Domenic_: I don't see how that's avoidable given the existence of non-browser embedders |
| 19:35 | <aklein> | Hixie: have you read the task queues stuff that's in the ES6 draft? |
| 19:35 | <SamB> | aklein: well, it would be nice to reduce the duplication as much as possible |
| 19:35 | <Domenic_> | aklein: i guess. do browser embedders actually act significantly different from the HTML spec? |
| 19:35 | <Domenic_> | er, non-browser embedders |
| 19:36 | <aklein> | Domenic_: I guess you could just have ES say nothing about running tasks, just queueing them |
| 19:36 | <Hixie> | aklein: i read it at some point. i was hoping to get contacted by whoever was writing it. |
| 19:36 | <aklein> | but that would be kinda funny |
| 19:36 | <Domenic_> | Hixie: I would hope that too :(. Allen seems pretty set on "I'm just going to spec a general model, I don't need to collaborate" |
| 19:36 | <jochen__> | an alternative is that ES requires the tasks to run before any other embedder event |
| 19:37 | <Ms2ger> | Domenic_, sounds like Allen |
| 19:37 | <aklein> | jochen__: amusingly that's what we had implemented while object.observe was behind a flag |
| 19:38 | <aklein> | just because it was convenient |
| 19:38 | <jochen__> | why did you change it? |
| 19:39 | smaug____ | wonders how stable object.observe is |
| 19:40 | <aklein> | jochen__: see wycats__ asking for basically that behavior in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296#c16, and Rafael's response |
| 19:42 | <jochen__> | ok |
| 19:43 | <jochen__> | but I disagree with that statement |
| 19:43 | <jochen__> | fifo requires to run a nasty message loop at the end of each event |
| 19:43 | <jochen__> | and appears to be hard to spec |
| 19:43 | <Hixie> | (woot, i pass namedEntities.test!) |
| 19:43 | <jochen__> | thus hard to explain |
| 19:43 | <jochen__> | = error prone |
| 19:43 | <jochen__> | :) |
| 19:45 | <smaug____> | sounds odd if ES tasks had higher priority |
| 19:45 | <aklein> | jochen__: it sounds like you're arguing for something that's simpler to spec/simpler to implement and disregarding how weird the actual behavior is? |
| 19:46 | <jochen__> | hum, i think it's also less weird |
| 19:46 | <jochen__> | like, now, in what context are the promise tasks executed? |
| 19:46 | <jochen__> | a mutation observer could just do document.write() |
| 19:47 | <aklein> | jochen__: as I said in my email, I think that's colored because you're one of like 20 people on the planet who have a very secure grasp of what's "javascript" and what's "embedder" |
| 19:47 | <jochen__> | and so the promise task gets an entirely different world |
| 19:47 | <aklein> | so could a promise task, though |
| 19:47 | <jochen__> | right |
| 19:47 | <aklein> | maybe you're arguing that Promises should just go first? |
| 19:47 | <jochen__> | but then it's a defined series of updates to the context |
| 19:47 | <jochen__> | (defined as in pure ES defined) |
| 19:48 | <jochen__> | yes, that's what i meant to say |
| 19:48 | <aklein> | what about Object.observe callbacks? |
| 19:49 | <jochen__> | all ES tasks should go in FIFO order |
| 19:49 | <jochen__> | (basically using the microtasks autorun = true mode in v8) |
| 19:50 | <SamB> | that sounds a bit overconstrained ... |
| 19:50 | <aklein> | jochen__: so my argument there is, what's special about ES tasks? |
| 19:50 | <SamB> | or I guess you mean tasks that are unblocked? |
| 19:51 | <aklein> | as smaug____ said above, it seems sort of odd just to choose ES tasks |
| 19:52 | <jochen__> | why is it odd? |
| 19:52 | <aklein> | how are they different than embedder tasks? |
| 19:52 | <jochen__> | or more odd to prefer es tasks and mutation observers over postMessage() |
| 19:52 | <jochen__> | (i think postMessage is a better example than setTimeout because the latter is a delayed task) |
| 19:52 | <aklein> | jochen__: so there's a whole argument about why observers want to go before postMessage |
| 19:52 | <Domenic_> | es tasks (= promises, object.observe) + mutation observers are microtasks |
| 19:52 | <Domenic_> | postMessage() is macrotask |
| 19:52 | SamB | sort of suspects that HTML would have some nasty cases which the rules ES would come up with wouldn't handle compatibly ... |
| 19:53 | <aklein> | which I was hoping rafaelw would provide on the email thread since he's good at stating it |
| 19:53 | <aklein> | but it really goes back to the birth of MutationObservers |
| 19:53 | <aklein> | which were designed as a replacement for Mutation Events |
| 19:53 | <SamB> | so nobody already wrote up the argument somewhere? |
| 19:53 | <jochen__> | i know |
| 19:53 | <aklein> | we wanted them to run asynchronously (to avoid the performance and security problems of Mutation Events) |
| 19:54 | <aklein> | but not so asynchronously that there'd be a paint before they ran |
| 19:54 | <aklein> | (so they can be used, e.g., to polyfill custom elements) |
| 19:54 | <SamB> | eww |
| 19:54 | <SamB> | I hope you mean "new elements"? |
| 19:54 | <Domenic_> | microtasks are a Good Thing |
| 19:54 | <smaug____> | ! |
| 19:55 | <Domenic_> | they are one of the innovations of the web platform IMO |
| 19:55 | <aklein> | SamB: sure: polyfill DOM features |
| 19:55 | <Domenic_> | traditional async data binding frameworks suffer badly from having only macrotasks |
| 19:55 | <jochen__> | but you realize that this is not possible, right? |
| 19:55 | <jochen__> | if I modify a polyfilled element and immediately query it, the polyfill didn't have a chance to run yet |
| 19:55 | <SamB> | jochen__: I was just thinking that ... |
| 19:56 | <smaug____> | also giving separate view of world for event listeners played part in microtask design |
| 19:57 | <aklein> | jochen__: sure, there are some things you lose by not acting synchrously |
| 19:58 | <smaug____> | mutation events have shown that doing stuff synchronously isn't just workable solution for everything. And we need good performance |
| 19:58 | <smaug____> | in Gecko MutationObservers were even initially 7x faster way to observer changes in DOM than Mutation Events |
| 19:58 | <smaug____> | (and should be better now ) |
| 19:59 | <jochen__> | i guess in the end, i'd just like this behavior to be specified |
| 20:00 | SamB | wonders if there are any attempts to standardize the treatment of "content scripts" which have their own javascript objects, but which nevertheless interact with the same DOM tree |
| 20:00 | <aklein> | jochen__: indeed, that I can totally agree with, it sounds like we need to get Hixie and Allen in a room together |
| 20:00 | <Domenic_> | IMO someone (whether HTML or ES or heck a third spec why not) should spec out something that matches all existing implementations. Which will be closer to HTML than what ES has. |
| 20:00 | <Domenic_> | Then both HTML and ES delegate to that |
| 20:01 | <jochen__> | SamB: i don't think so |
| 20:01 | <Domenic_> | http://esdiscuss.org/topic/es6-tasks-and-taskqueues#content-3 if you guys haven't seen Allen's response |
| 20:01 | <smaug____> | SamB: what is the context here? |
| 20:02 | <smaug____> | (In Gecko content script is a privileged script which has access to the top level window object) |
| 20:03 | <SamB> | yeah, I know that there are some big differences between how Gecko and Chromium treat such scripts |
| 20:04 | <SamB> | or, mmm, maybe you mean a different top level |
| 20:04 | <SamB> | smaug____: anyway, the Grease-style scripts for starters |
| 20:04 | <smaug____> | I don't know what is "content script" in blink |
| 20:04 | <smaug____> | ah |
| 20:04 | <aklein> | jochen__: I have to run, sorry (I realize it's much later for you :) |
| 20:05 | <SamB> | er, +Monkey |
| 20:07 | <SamB> | smaug____: anyway, https://developer.chrome.com/extensions/content_scripts describes them as they apply to Chrome extensions |
| 20:08 | <smaug____> | oh, but they get totally different view from page's scripts, right? |
| 20:08 | <SamB> | yeah, as do GreaseMonkey scripts now |
| 20:09 | <SamB> | though with GreaseMonkey the scripts *can* actually mess with the page's objects too |
| 20:09 | <smaug____> | yes |
| 20:09 | <smaug____> | gecko background shows up there, I guess |
| 20:16 | <SamB> | Okay, some people are just crazy. Naming a browser "Web"? For real? |
| 20:21 | <SamB> | my, what lovely documentation Chrome has for userscripts: http://www.chromium.org/developers/design-documents/user-scripts/ |
| 20:40 | <zcorpan> | anyone know where aryeh's innerText spec went? and tests? http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030179.html |
| 20:40 | <smaug____> | Ms2ger: ^ |
| 20:41 | <Ms2ger> | I think he put it up somewhere and then nobody implemented it |
| 20:41 | <Ms2ger> | Looks like it was at http://aryeh.name/spec/innertext/innertext.html |
| 20:42 | <Ms2ger> | I don't think I have a copy |
| 20:44 | <Ms2ger> | Wayback has it at http://web.archive.org/web/20121127212525/http://aryeh.name/spec/innertext/innertext.html |
| 20:46 | <Ms2ger> | I'll email him |
| 20:47 | <jochen__> | is somebody here involved with MediaQueryListListeners? |
| 20:47 | <jochen__> | i wonder why MediaQueryList doesn't simple define an onchanged event or something |
| 20:47 | <Ms2ger> | TabAtkins, by default, I guess |
| 20:47 | <jochen__> | but instead defines it's on kind of event that's completely different from the rest |
| 20:48 | <TabAtkins> | Probably because MQL is dumb and stupid. |
| 20:48 | <jochen__> | can we update the spec |
| 20:48 | <jochen__> | pretty please |
| 20:48 | <TabAtkins> | Mail www-style? |
| 20:48 | <jochen__> | with sugar on top |
| 20:48 | <jochen__> | will do |
| 20:51 | <jochen__> | done |
| 20:54 | <Hixie> | Domenic_: re your exception "proximate cause" thing, what we could do is have each place that fires an exception get a unique ID (maybe even a real GUID, though that would be a bit overlong, maybe something shorter) |
| 20:59 | <TabAtkins> | Where is MQL defined? |
| 21:06 | <TabAtkins> | Ah, OM View |
| 21:08 | <jochen__> | TabAtkins: so what would be the process to make that change happen? |
| 21:09 | <TabAtkins> | I just responded. We figure out what to do, edit the spec accordingly, file bugs, done. |
| 21:09 | <jochen__> | cool |
| 21:11 | <zcorpan> | SimonSapin: my thinking was to let them pass through as in the dom. but it's not explicit. also see https://www.w3.org/Bugs/Public/show_bug.cgi?id=25110 |
| 21:13 | <SimonSapin> | well CSS backslash-escapes explicitly decode surrogates to U+FFFD |
| 21:13 | <SimonSapin> | but yeah, they otherwise pass through implicitly |
| 21:13 | <SimonSapin> | I wish we could change that |
| 21:13 | <zcorpan> | SimonSapin: that's a JS-escape, not a CSS escape |
| 21:14 | <SimonSapin> | zcorpan: quoting from the bug: "CSS.escape('\uD800')" |
| 21:14 | <zcorpan> | SimonSapin: yep. JS escape |
| 21:14 | <SimonSapin> | ok, yes, \uD800 is a JS escape |
| 21:15 | <SimonSapin> | but CSS.escape() just lets it though |
| 21:15 | <zcorpan> | yeah |
| 21:15 | <SimonSapin> | encoding it as \D800 would not work |
| 21:15 | <zcorpan> | right |
| 21:15 | <zcorpan> | but we could change it i guess |
| 21:16 | <zcorpan> | but i don't see the point if it's not possible to change in the dom |
| 21:16 | <zcorpan> | is it? |
| 21:17 | <SimonSapin> | document.write() and innerHTML might be more constrained |
| 21:17 | <SimonSapin> | but still, I’d prefer rust-cssparser to work with UTF-8 input rather than UCS-2 |
| 21:23 | <zcorpan> | SimonSapin: you have to do better than that :-P |
| 21:23 | <SimonSapin> | surrogates are evil and we should limit the spread of the infection as much as possible |
| 21:25 | <zcorpan> | now you're not making sense. evil is not a diseases |
| 21:25 | <zcorpan> | s/s// |
| 21:26 | <SimonSapin> | not making ense? |
| 21:26 | <zcorpan> | that's right |
| 21:39 | <TabAtkins> | "now you're not making ene. evil i not a dieae" |
| 21:44 | <SimonSapin> | well he didn’t use a s/s//g |
| 21:46 | <zcorpan> | s/// on irc always has dwim flags implied |
| 21:48 | <SimonSapin> | dwim? |
| 21:50 | <zcorpan> | do what i mean |
| 21:56 | <Hixie> | lol |
| 21:56 | <Hixie> | i refactored my code, changing hundreds of lines, using a different approach, etc. |
| 21:57 | <Hixie> | it fixed my test! U+0000 numeric character references now parse ok! |
| 21:57 | <Hixie> | next bug: U+0001. |
| 21:57 | <Hixie> | -_- |
| 22:01 | <Domenic_> | Hixie: sounds good re: exception IDs |
| 22:03 | <Hixie> | do you think anyone would go for it? |
| 22:05 | <Domenic_> | I guess we haven't shown very compelling use cases yet. Although it's clearly better than the current "name" stuff. |
| 22:05 | <Hixie> | well, it's interesting for loggin |
| 22:05 | <Hixie> | g |
| 22:05 | <Domenic_> | I think blink-dev discussed doing something similar for app cache errors? |
| 22:06 | <Hixie> | (though i wonder if the messages aren't good enough in practice) |
| 22:06 | <Hixie> | yeah |
| 22:07 | <Domenic_> | I think the relying-on-messages argument you made is a strong incentive to do something better. |
| 22:08 | <Hixie> | i'd be worried about how effective it would be. We have enough trouble getting people to just fire the right exception in the first place, let alone the right exception with the right unique code. |
| 22:10 | <Domenic_> | that's true, hmm. perhaps because "the right exception" gives only incremental benefits so not worth the effort? the question is, would this be worth the effort. |
| 22:11 | <Domenic_> | Blink has recently done a major exception message cleanup so at least their thoughts are with developers on these issues… |
| 22:18 | <Domenic_> | Wait so innerText is not cross-browser yet? |
| 22:20 | <Hixie> | innerText is a disaster |
| 22:20 | <Hixie> | it depends on CSS, e.g. |
| 22:21 | <TabAtkins> | Do you mean .textContent, Domenic_ ? |
| 22:22 | <Domenic_> | Nope I meant innerText. Didn't know it was a disaster… |
| 22:23 | <TabAtkins> | Yup, total disaster. |
| 22:23 | <jsbell> | re: exception IDs + proximate cause: as long as we realize that the developer workflow is not "see exception X, search the spec for X, gain enlightenment, fix bug". Rather, it's "see exception X, google X, find the stackoverflow article, copy/paste the fix" :) |
| 22:23 | <jsbell> | Either case benefits from a reasonably unique X, though. |
| 22:24 | <Domenic_> | jsbell: yeah that's a good point to keep in mind. I was in particular thinking about more advanced use cases trying to recover from specific errors and let others bubble. |
| 22:26 | <wilhelm> | WebDriver specs how to get readable text from an element: https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html#rendering-text |
| 22:26 | <wilhelm> | It's not pretty. |
| 22:28 | <Hixie> | jsbell: i think the workflow for which this matters is more "script catches unexpected exception x, logs it to server, author looks at aggregate data regarding exceptions to figure out what to fix next" |
| 22:30 | <TabAtkins> | I think a guid would be fine for this. Why not do a full guid? |
| 22:30 | <SamB> | ewww |
| 22:30 | <TabAtkins> | SamB: It's just for identification purposes. |
| 22:30 | <Hixie> | TabAtkins: full guid is a bit excessively verbose in a log and would make specs look ugly |
| 22:30 | <Hixie> | TabAtkins: we probably only need a fraction of the digits |
| 22:31 | <TabAtkins> | Ok, I guess so. |
| 22:31 | <TabAtkins> | Just want it large enough that I can randomly-generate it and still be assured that it's unique. |
| 22:31 | <Hixie> | as an anecdotal data point, the freepascal compiler guys use YYYYMMDDNN for their internal errors. |
| 22:31 | <Hixie> | i don't think we should use that because we have less coordination |
| 22:31 | <TabAtkins> | That doesn't help multiple specs, yeah. |
| 22:32 | <Hixie> | but it's the kind of size identifier that i think would make sense |
| 22:32 | <TabAtkins> | You can get much smaller if you can coordinate. You need more than 10 digits for randomness to work. |
| 22:32 | <Hixie> | might be better for the IDs to be [spec author][whatever] where [spec author] is two digits and [whatever] is, well, whatever. |
| 22:33 | <TabAtkins> | Still need coordination for that. |
| 22:33 | <Hixie> | well some minimal coordination is fine |
| 22:33 | <SamB> | yeah, two digits should be enough for everyone |
| 22:33 | <Hixie> | (i mean, we have that today for exceptions) |
| 22:33 | <TabAtkins> | Hixie: We have massive overlap today for exceptions, which is what we're trying to avoid. |
| 22:33 | <Hixie> | we are? |
| 22:34 | <TabAtkins> | SamB: let "digit" be alphnum. |
| 22:34 | <TabAtkins> | I thought that was the point, yes. |
| 22:34 | <Hixie> | not sure what you mean by "avoid overlap" |
| 22:34 | <Hixie> | i thought the goal here was just to provide uniquely identifiable IDs per exception throw site |
| 22:34 | <TabAtkins> | Today, the "coordination" is "fire one of the errors from this list". |
| 22:35 | <Hixie> | by coordination, i mean that today if you want a new exception you just ask anne to addi t |
| 22:35 | <TabAtkins> | This list does not get extended by people. It's short and more or less static. |
| 22:35 | <SamB> | clearly sha1:file:line:column |
| 22:35 | <Domenic_> | TabAtkins: not great for discriminatory catching |
| 22:35 | <TabAtkins> | Domenic_: I'm not sure what you're replying to. |
| 22:35 | <Hixie> | SamB: i do like the idea of hashing the final result somehow so that the spec author part is not derivable |
| 22:35 | <SamB> | I was kidding |
| 22:35 | <Domenic_> | Sorry got offline for a bit, replying to guid idea |
| 22:35 | <SamB> | I mean what is a "throw site" |
| 22:35 | <TabAtkins> | Hixie: That's why you choose enough digits that the ID can be randomly generated without fear of collision. |
| 22:36 | <TabAtkins> | Domenic_: I thought the idea was to be able to tell better what place the exception came from. A guid identifying each place that can throw an error does that, no? |
| 22:36 | <TabAtkins> | SamB: A line in the spec that throws something. |
| 22:36 | <Hixie> | another option is we just make a web service for ourselves that vends unique IDs |
| 22:36 | <Hixie> | then it could trivially avoid duplicates |
| 22:37 | <SamB> | and without coordination, people *will* end up seeing values without being able to find out any indication of their meaning ... |
| 22:37 | <TabAtkins> | Yeah, that would let you be smaller without collision fear. |
| 22:38 | <Domenic_> | TabAtkins: my use case is being able to write catch clauses that only catch a specific expected error and let others bubble or hit window.onerror. |
| 22:38 | <SamB> | (don't tell me you've never had a GUID for which you couldn't find any corresponding name ...) |
| 22:40 | <Domenic_> | So human readable, yet unique, names would give more readable catch code. |
| 22:41 | <Hixie> | are we thinking integers here, or strings? |
| 22:41 | <Domenic_> | I was thinking strings |
| 22:42 | <Domenic_> | Integers for IDs seems bad in general |
| 22:48 | <aretecode> | I love to learn, feel free to teach me what you are the most passionate about :) |
| 22:54 | <zcorpan> | the id generator could take 4 random words from this channel from the past 48h. then make sure that google brings up no results for that identifier, and that it hasn't been generated before. |
| 22:55 | <zcorpan> | choosecatchesalthoughpolyfill |
| 23:01 | <SamB> | zcorpan: that doesn't help the reader to make any sense of anything |
| 23:02 | <zcorpan> | SamB: i didn't see that as a requirement above |
| 23:03 | <zcorpan> | SamB: i guess it will make the reader go "wtf" and then google it and find relevant information, though |
| 23:09 | <Hixie> | SamB: the .message is the way the reader makes sense of something |
| 23:09 | <Hixie> | zcorpan: that's a bit long, ideally these should be short so the don't make specs unreadable |
| 23:10 | <jsbell> | (Guru meditation number: 1314c98d-8667-4599-a4ac-ffc56420d7ba) |
| 23:10 | <SamB> | Hixie: point ... |
| 23:10 | <Hixie> | jsbell: yeah. but shorter. :-) |
| 23:11 | <SamB> | so, how to keep the search results from being flooded with people asking about the exceptions rather than what one might actually want to find? |
| 23:11 | <TabAtkins> | A stack overflow link about it would be fine |
| 23:12 | <zcorpan> | we set up google alerts for the ids and give useful answers on stackoverflow |
| 23:13 | <zcorpan> | Hixie: the generator could just try fewer words or other words until it finds an id shorter than X characters |
| 23:42 | <Hixie> | http://software.hixie.ch/utilities/cgi/exception-id-generator/ |
| 23:42 | <Hixie> | all up to y'all now if we actually want to do this |
| 23:43 | <Hixie> | i checked and that won't generate any duplicates for at least the next 100,000 IDs. |
| 23:43 | <Hixie> | (after 100,000 it started getting a little crazy to check for duplicates the way i was doing it) |
| 23:44 | <zewt> | Hixie: ... what |
| 23:44 | <zewt> | is it april 1 in your time, heh |
| 23:44 | <Hixie> | hm? |
| 23:44 | <zewt> | re: link looks like joke |
| 23:45 | <Hixie> | why? |
| 23:45 | <zewt> | how does it not look like joke. heh |
| 23:45 | <Hixie> | well it's not very funny to start with? :-) |
| 23:45 | <zewt> | re: if an API expects me to use opaque strings in my source code as exception identifiers, API will be shot directly into sun |
| 23:45 | <zewt> | no april 1 "jokes" are funny |
| 23:46 | <Hixie> | sounds like you missed the earlier conversation |
| 23:46 | <zewt> | whatever it was, this result seems catastrophic enough to make me dubious of its conclusion :P |
| 23:47 | <TabAtkins> | Hixie - Bikeshed style: The user agent must throw an <code>SyntaxError</code> exception with ID "<dfn exception-code>3d7geaa26h</dfn>". |
| 23:47 | <zewt> | but I will happily scroll back |
| 23:49 | <Hixie> | TabAtkins: thanks, added |
| 23:51 | <Hixie> | uh |
| 23:51 | Hixie | fixes the error in the bikeshed one where he'd hardcoded the code TabAtkins gave |
| 23:51 | <TabAtkins> | hahaha |
| 23:55 | <Hixie> | ok i generated 1,575,472 codes in the order it's going to generate them, and still no dupes |
| 23:55 | <Hixie> | so i'm pretty confident that this will work out ok, dupe-wise |
| 23:55 | <zewt> | it sounds like the core problem it's trying to solve is "it's hard to find where the unexpected thing you're seeing is defined in a spec somewhere, so google for this magic thing" |
| 23:56 | <zewt> | that sort of sounds like an ineffective whack-a-mole, though; exceptions are one extremely tiny subset of "can't find this thing in a spec" (or on stackoverflow, or whatever) |
| 23:56 | <TabAtkins> | Hixie: Yeah, you have to gen about 60M before you should expect the first dupe. |
| 23:56 | <TabAtkins> | zewt: That's one reason, not all. |
| 23:56 | <TabAtkins> | It's not even Domenic_'s primary reason. |
| 23:57 | <zewt> | what i suspect would be the actual result (to describe my initial reaction) is that people would start using them in code as part of exception handlers, which would be completely horrible since they're not human-readable |
| 23:57 | <Hixie> | zewt: the main reason is that right now, InvalidStateErr is fired from zillions of places |
| 23:57 | <Hixie> | zewt: and you don't know which is the proximate cause of a particular one you're holding onto |
| 23:57 | <Hixie> | not really clear what better way to solve this |
| 23:57 | <TabAtkins> | Especially if you grab it from window.error or the like. |
| 23:57 | <Hixie> | yeah |
| 23:58 | <Hixie> | TabAtkins: it's been my experience that if i don't actually check it, there'll be some error in my logic and the dupes will abound, so i felt better actually checking it :-) |
| 23:59 | Hixie | closes all his related tabs and windows until Domenic_ manages to convince anyone else to use this |
| 23:59 | <zewt> | i always just log a stack trace to the server (we really need better stack trace support) and moving on, since at least with the way I write things, if an exception gets to window (unless it's an event delegation thing, which it isn't for onerror), that's not the place where I'm going to examine the exception and try to recover from it |
| 23:59 | <TabAtkins> | Hixie: Certainly, just letting you know what your expected range will be. |
| 23:59 | <zewt> | (some interesting half-edits in that run-on sentence) |