| 02:45 | <MikeSmith> | isn't the plan still to integrate Streams into the EcmaScript spec itself |
| 02:45 | <MikeSmith> | if so it seems like Domenic's approach is the right one |
| 02:48 | <MikeSmith> | anyway smaug is fast asleep by now I guess |
| 02:48 | <MikeSmith> | we need an inform bot here |
| 02:50 | <MikeSmith> | Hixie: would it be OK if I had an inform bot join here? |
| 02:50 | <MikeSmith> | kind of like MsgServ but more lightweight and easier |
| 02:50 | <MikeSmith> | we could just do like this: |
| 02:51 | <MikeSmith> | foobot, inform smaug____ I think if the plan is still to integrate Streams into the EcmaScript spec itself, then Domenic's approach would seem to make a lot of sense... |
| 02:52 | <MikeSmith> | and then when smaug joined, the bot would do: |
| 02:52 | <MikeSmith> | smaug, at 2014-12-04 00:54 UTC, MikeSmith said, I think if the plan is still to integrate Streams into the EcmaScript spec itself, then Domenic's approach would seem to make a lot of sense... |
| 02:56 | <Hixie> | MikeSmith: fine by me |
| 02:56 | <MikeSmith> | k |
| 02:57 | <MikeSmith> | will try to set one up this weekend |
| 05:25 | <MikeSmith> | layout.css.vertical-text.enabled=true |
| 05:33 | <MikeSmith> | doesn't work with my test page though |
| 05:33 | <MikeSmith> | http://people.w3.org/mike/demo/melos/ |
| 05:33 | <jgraham> | MikeSmith: smaug____ is probably not asleep yet |
| 05:33 | <MikeSmith> | ah yeah yall are in Portland |
| 05:34 | <MikeSmith> | glyph-orientation-vertical is what I'm using in my (old) demo. I guess I may need to update that |
| 05:35 | <MikeSmith> | "Unknown property 'glyph-orientation-vertical'. Declaration dropped." in console in Nightly |
| 05:35 | <smaug____> | not yet |
| 05:35 | <MikeSmith> | also "Unknown property 'align'. Declaration dropped" |
| 05:36 | smaug____ | looks at the logs |
| 05:37 | <smaug____> | MikeSmith: oh, right, *if* Streams will be part of ecma, then sure, using whatever odd syntax ecma is using for the specs is fine |
| 05:38 | <smaug____> | but it is not clear to me why Streams should be part of ecma |
| 05:52 | <MikeSmith> | Hixie: fyi this is the bot I was talking about https://github.com/w3c/infobot |
| 05:53 | <MikeSmith> | smaug____: I personally don't know enough about Streams to have a position either way on whether it rightly should be in the ES spec or not |
| 05:54 | <MikeSmith> | smaug____: but I do vaguely recall that there was some agreement within TC39 that it should be moved into the ES spec |
| 05:55 | <smaug____> | if so, fine. I wouldn't be looking at that spec ever again :p |
| 05:55 | <MikeSmith> | but I could be misremembering that and anyway Domenic would know of course |
| 05:55 | <MikeSmith> | smaug____: well that's sad to hear |
| 05:55 | <smaug____> | (not quite true, I've looked at some ecma drafts occasionally ) |
| 05:56 | <smaug____> | MikeSmith: but in practice, it would mean I'd expect js engine devs to review it |
| 05:57 | <smaug____> | not dom implementation devs |
| 05:57 | <MikeSmith> | ah OK. I was going to say that if you're not looking at a particular spec because it's hard for you to read than that could be a sign of the spec having a serious problem |
| 05:58 | <MikeSmith> | but if it's more about division of labor (between DOM and JS teams), that's a different thing |
| 05:59 | <smaug____> | I guess it is about both. If the spec is easy to read and happens to be somewhere in whatwg, it is likely that I'll read it |
| 06:19 | <MikeSmith> | smaug____: ok |
| 07:11 | <zcorpan> | Hixie: looks like it's due to https://github.com/Fyrd/caniuse/commit/2455f144fa5a261e7f15f7d03a234ee426e5432c |
| 07:16 | <Hixie> | o_O |
| 08:14 | <zcorpan> | hmm, for background-color:9.9aa gecko rounds the number so it becomes #0010aa. but for 9.9 it rejects. blink rounds both numbers and dimensions |
| 08:16 | <zcorpan> | hmm, scientific notation is interesting. 9e1 |
| 10:27 | <estellevw> | does anyone want to take a look at my webcomponents talk and give me feedback tonight? My preso is tomorrow morning. |
| 10:27 | <estellevw> | (tonight as in it's 9:26 pm in AU right now) |
| 10:27 | <estellevw> | oops, wrong IRC channel. |
| 10:27 | <estellevw> | sorry for the disturbance |
| 10:27 | <estellevw> | though if someone is interested, that would be great too |
| 12:04 | <MikeSmith> | Ms2ger: small assistance needed with something |
| 12:04 | <Ms2ger> | Shoot |
| 12:04 | <Ms2ger> | (I'm in class, though) |
| 12:05 | <MikeSmith> | will DM you about it since it's so highly sensitive |
| 12:06 | <gsnedders> | Ms2ger: stop procrastinating while in class! |
| 12:08 | <Ms2ger> | gsnedders, well, my prof just walked out, so... :) |
| 12:11 | <Ms2ger> | ... and he's back |
| 12:11 | <MikeSmith> | infobot, tell annevk what happened to irccloud |
| 12:12 | <MikeSmith> | bah this bot sucks |
| 12:12 | <MikeSmith> | oh it's not actually here |
| 12:42 | <zcorpan> | TabAtkins: fixed hashless now https://github.com/whatwg/quirks/commit/f84b11e4abb561317c407c1a0d47ff45ad6e4fcf https://github.com/w3c/web-platform-tests/pull/1442 |
| 13:49 | <JakeA> | wanderview: thanks for thinking through that partial cache stuff! |
| 13:50 | <wanderview> | JakeA: np, I've been thinking about how I would implement it for a while... streaming the partial file will be tricky for us due to how our streams infrastructure works |
| 13:50 | <wanderview> | thanks for working on the algorithms to make it work, though! |
| 13:50 | <wanderview> | I definitely think its something we want to solve |
| 13:50 | wanderview | wonders why irccloud is running slow... |
| 14:41 | <Domenic> | MikeSmith: smaug____: I was hoping to work with TC39 on making streams part of the ES standard library, but they were not willing to work with me/WHATWG really; they wanted to take over the spec themselves. So that idea kinda floundered. Still, I think it (as well as Encoding and URL, actually) should be part of a theoretical "extended ES standard library", |
| 14:41 | <Domenic> | not managed by Ecma, but still appropriate for implementation in the JS engine. |
| 14:58 | <smaug____> | well, couldn't any spec be part of the theoretical ES sl |
| 14:58 | <smaug____> | whether or not webidl is used for example |
| 15:00 | <gsnedders> | What spec it is in is relatively irrelevant. |
| 15:01 | <smaug____> | indeed. Where the spec is "published" can be somewhat relevant since it may affect to who reviews and implements it |
| 15:01 | <gsnedders> | But at the end of the day, there's some lack of desire to avoid extending the ES stdlib beyond things that cannot be implemented in JS itself. |
| 15:01 | <Domenic> | smaug____: IMO specs would need to be platform-independent, so e.g. no use of DOMException etc. And IMO (but not everyone's unfortunately) I should be able to work on JS standard library specs in WHATWG. |
| 15:02 | <gsnedders> | What makes a spec a JS stdlib spec? |
| 15:02 | <gsnedders> | (honest question) |
| 15:02 | smaug____ | thinks we should make webidl more platform independent and then use it also for APIs which non-browser implementations want to have |
| 15:03 | <smaug____> | and this is mainly from practical point of view. having webidl interfaces tends to just make the spec significantly easier to read comparing to some ways to write specs |
| 15:04 | <smaug____> | if we need some other syntax to express new es features, we should change webidl |
| 15:04 | <Domenic> | I somewhat agree with that except that WebIDL is so hard to read for anyone used to JS semantics |
| 15:04 | <Domenic> | e.g. wtf is an attribute or interface |
| 15:05 | <Domenic> | thus https://streams.spec.whatwg.org/#rs-class-definition |
| 15:06 | <annevk> | Yeah, we should just rename interface to class and attribute to property |
| 15:06 | <Domenic> | I'd like something like `get/set prop` or `get prop` |
| 15:06 | <annevk> | And instead of readonly have something like get property |
| 15:07 | <Domenic> | yeah |
| 15:07 | <annevk> | Seems easy enough to fix |
| 15:07 | <Domenic> | but hard to justify given the churn |
| 15:09 | <annevk> | Given the upsides it seems worth it |
| 15:09 | <annevk> | IDL is after all a way to convey something as well and if it's doing a poor job at that we should fix it |
| 15:12 | <smaug____> | why get/set ? |
| 15:12 | <smaug____> | readonly attribute is quite good abstraction |
| 15:13 | <gsnedders> | presumably because get/set is like the {get foo() { return 1; }} syntax |
| 15:13 | <Domenic> | getters and setters are what the semantics actually are |
| 15:13 | <annevk> | plus usually an internal slot |
| 15:14 | <Domenic> | attributes are not a real thing; they make people think you're talking about HTML attributes (especially because people usually read their first IDL in the HTML spec) |
| 15:14 | <smaug____> | yes. and readonly attribute is rather nice abstraction of a getter |
| 15:14 | <Domenic> | readonly sounds like non-writable which sounds like non-writable data property which is extremely different from a getter |
| 15:14 | <smaug____> | that DOM attributes vs webidl attributes case is a real issue |
| 15:15 | <smaug____> | having both getter and setter for each attribute in the interface would be rather annoying |
| 15:16 | <annevk> | I don't see how attribute is a nice abstraction of something that's actually called a property |
| 15:16 | <smaug____> | harder to read |
| 15:16 | <annevk> | smaug____: I don't think anyone is suggesting that per se |
| 15:16 | <Domenic> | yeah, I like separate getter setter but in the interests of not being annoying something like `get/set foo` seems fine |
| 15:17 | <annevk> | smaug____: although that would open up some possibilities such as accepting more in the setter than in the getter which we've had requests for |
| 15:18 | <smaug____> | attribute hides the fact that the thing is implemented using a getter/setter |
| 15:18 | <smaug____> | since most cases one shouldn't need to think about that it is a getter or setter |
| 15:18 | <gsnedders> | yeah, I find the fact that readonly attributes are actually getter/setter pairs a bit confusing |
| 15:19 | <smaug____> | (readonly attributes are getters) |
| 15:19 | <gsnedders> | (pedant :)) |
| 15:20 | <annevk> | smaug____: but if you come from a JavaScript background the term attribute makes no sense and gives you no idea what's going on |
| 15:20 | <annevk> | smaug____: that seems way more important |
| 15:20 | <smaug____> | depends on the audience |
| 15:21 | <smaug____> | if you're some random js dev, you may not really use getters/setters explictly |
| 15:22 | <annevk> | but you will know about properties |
| 15:22 | <annevk> | and that there are such things as getters and setters |
| 15:22 | <annevk> | you won't have a clue about attributes other than DOM attributes which are completely different |
| 15:23 | smaug____ | is not sure all the devs even know about getters/setters |
| 15:24 | <smaug____> | given all the really old documentation etc |
| 15:24 | <gsnedders> | I'm just weird coming from the JS engine side nowadays :) |
| 15:33 | <JakeA> | annevk: in the env settings object, there's no document for (shared)workers right? |
| 15:34 | <annevk> | JakeA: yup |
| 15:35 | <annevk> | Domenic: how is it explained in "web implemented in JS" idea how a random object, say <a>, gets to the internal slot of some other object, say document's base URL? |
| 15:36 | <JakeA> | annevk: so I'd have to use the creation url for workers. CurrentURL would make that easier. Will suggest that |
| 15:43 | <Domenic> | annevk: shared access to the weak map. (Can gist up an example if you like.) |
| 15:44 | <annevk> | Domenic: access is given upon creation? |
| 15:45 | <Domenic> | Or just using a shared scope |
| 15:45 | <annevk> | fair I guess |
| 16:08 | <JakeA> | annevk: if memory serves, you were keen on having ServiceWorkerClient represent window clients, and have SharedWorker / Worker represent worker clients. Have I got that right? I'm kinda uncomfortable returning a mix of objects from clients.getAll() |
| 16:13 | <JakeA> | Could have different APIs to get each type, or a type param on getAll. Or stick with ServiceWorkerClient that represents all (and provide values for visibility & focus state) |
| 17:21 | <annevk> | JakeA: so I was wrong about that |
| 17:22 | <annevk> | JakeA: APIs should be similar for each |
| 17:22 | <annevk> | JakeA: might want some things different for window vs worker still I suppose |
| 17:35 | <JakeA> | annevk: need a type property I think. Also, new ServiceWorkerClient doesn't make sense anymore as a way to create a window. clients.openWindow(url) feels better, but I guess there'll be a "but constructors" argument to have |
| 17:35 | <annevk> | JakeA: so is ServiceWorkerClient exposed outside service workers as well? |
| 17:36 | <annevk> | JakeA: otherwise we could have Client, WindowClient, WorkerClient |
| 17:36 | <annevk> | and not support new WorkerClient I suppose |
| 17:37 | <annevk> | I like how mounir announced Google left sysapps after trying to convince me for a while this was the way to go |
| 17:37 | <JakeA> | annevk: works for me. |
| 17:38 | <annevk> | JakeA: I've lost track a bit of what objects we have where unfortunately, but if this sounds reasonable, great |
| 17:38 | <annevk> | JakeA: I should probably read through it again |
| 17:38 | <annevk> | JakeA: perhaps we should make a diagram that explains the relationship between the objects |
| 18:39 | <hallvors> | annevk: have a moment? I'm where the webcompat team tends to sit (F room) |
| 18:40 | <annevk> | hallvors: yeah |
| 19:05 | <mounir> | annevk: things are never black or white |
| 19:05 | <annevk> | mounir: rainbows |
| 19:06 | <jgraham> | Black holes? |
| 19:06 | <annevk> | ClampBetween(0, 255) Domenic, that's called ToUint8 |
| 19:07 | <rubys> | the sun is white: http://blog.chron.com/sciguy/2013/12/what-color-is-the-sun/#28933101=0 |
| 19:08 | <TabAtkins> | rubys: That's not what my crayon drawings say. |
| 19:09 | <rubys> | TabAtkins: tl;dr: the sun is yellow because the sky is blue. |
| 19:09 | <TabAtkins> | Yeah, I know. ^_^ |
| 19:10 | <TabAtkins> | A combination of blue light getting scattered across the sky, so the leftover is more yellowish, and the opponency of our visual pathway contrasting blue against yellow. |
| 19:21 | <Domenic> | annevk: unclear whether it's EnsureBetween or ClampBetween IMO. |
| 19:21 | <Domenic> | annevk: also unclear why you would use ClampBetween(0, 255) more often than ClampBetween(0, 100) or whatever |
| 19:25 | <Domenic> | annevk: exciting to see element.closest() starting to ship. It's almost as if we can actually make the DOM better by adding things to standards :) |
| 19:26 | <annevk> | Domenic: but are they stable?! |
| 19:26 | <TabAtkins> | Domenic: Because clamping behavior in APIs is almost always dictated by the size of the int used to store it. |
| 19:27 | <TabAtkins> | Also: ClampBetween(0, 65536) is obnoxious. ^_^ |
| 19:27 | <TabAtkins> | 65535, rather. |
| 19:27 | <TabAtkins> | See?!? |
| 19:27 | <Domenic> | TabAtkins: but how often do you actually want to clamp on the web |
| 19:27 | <TabAtkins> | Whenever you're dealing with bytes. |
| 19:27 | <Domenic> | TabAtkins: colors, *maybe*, otherwise unsure when |
| 19:28 | <Domenic> | how many APIs actually deal with bytes instead of just dealing with arraybuffers |
| 19:28 | <Domenic> | annevk: made it to Chrome beta... only 6 weeks left |
| 19:28 | <annevk> | Domenic: it was a lame joke about the standard |
| 19:28 | <Domenic> | annevk: oh lollll |
| 19:32 | <Domenic> | so for longdesc, is it productive to just vote against publishing and say "we agree with the previous formal objection"? or is that a lost cause? |
| 19:32 | <TabAtkins> | Continue doing minimal-effort objecting. |
| 19:33 | <TabAtkins> | I mean, yes, it's a lost cause, but we can at least put forth a modicum of effort showing that everything is bullshit forever. |
| 19:33 | <Domenic> | also lol apparently browser extensions count for the purposes of interoperable implementations https://w3c.github.io/test-results/html-longdesc/cr-report.html |
| 19:34 | <Domenic> | *also* apparently my TAG status lets me fill out the voting form despite not being the AC rep... I'll quietly close that window I guess and talk to my AC rep. |
| 19:35 | <Domenic> | (Oh nevermind: all the form field controls are clickable but there's a "You are allowed to read the questionnaire, but you are not authorized to answer with your current credentials!" at the top of the page) |
| 19:50 | <annevk> | imagine if all that time put into longdesc and alt was put into making things accessible |
| 19:51 | <tantek> | annevk - have you spoke with dbolter about that while you're in the same room? |
| 19:52 | tantek | looks over and sees them at the same table, with only marcosc between them! |
| 19:56 | <annevk> | (we talked about getComputedRole()) |
| 21:01 | <tnelis> | hello, i'm seeking help clarifying the removal of a paragraph in XHR, is this the right place to ask? |
| 21:03 | <caitp> | here or bugmail is proabably a good place for it |
| 21:05 | <tnelis> | alright let's try; xhr 4.5.6 (the send method), the following paragraph is in f18fc52 and removed in c99000a |
| 21:05 | <tnelis> | "For 304 Not Modified responses that are a result of a user agent generated conditional request the user agent must act as if the server gave a 200 OK response with the appropriate content. The user agent must allow author request headers to override automatic cache validation (e.g. If-None-Match or If-Modified-Since), in which case 304 Not Modified responses must be passed through. [HTTP]" |
| 21:06 | <tnelis> | i essentially question the intent behind the removal and wonder if this behavior can still be relied on (i would assume so, there'd be some serious breakage otherwise) |
| 21:07 | <tnelis> | (also note that it's still in the w3 draft) |
| 21:20 | <tnelis> | nvm, found it reworded, just had to look closer |
| 21:22 | <annevk> | zcorpan: "If the element does not have a srcset attribute specified and it does not have a parent or it has a parent but it is not a picture element, and it has a src attribute specified and its value is not the empty string, let selected source be the value of the element's src attribute, and selected pixel density be 1.0." is really hard to parse |
| 21:23 | <tantek> | that's quite a long sentence |
| 21:27 | <annevk> | following that algorithm :-( |