| 02:12 | <MikeSmith> | foolip: I see that Denis responded to some (but not all) of your review comments at https://critic.hoppipolla.co.uk/r/604 |
| 02:13 | <MikeSmith> | foolip: if you could check and see if any of the remaining open issues in that review can be close that would be great |
| 02:13 | <MikeSmith> | foolip: that way we can get them down to just the ones that are actually still waiting on Denis |
| 02:14 | <MikeSmith> | foolip: and then I can ping Denis and ask him if he can make time to look back at them |
| 02:15 | <MikeSmith> | foolip: we're no longer paying Denis to work on the testsuite, and this is the last PR we still have open from the time when we did have him working on tests |
| 02:34 | <MikeSmith> | so the "is" attribute is not actually formally defined anywhere yet, right? |
| 02:35 | <MikeSmith> | at least not in http://w3c.github.io/webcomponents/spec/custom/ |
| 02:35 | <MikeSmith> | it's mentioned there but never defined |
| 02:35 | <MikeSmith> | dglazkov: ↑☃ |
| 03:12 | <caitp> | hixie linked me to a sufficiently normative definition of it, but I can't recall where it was, @MikeSmith |
| 03:13 | <caitp> | there are like dozens of those specs, makes it really hard to find things =) |
| 03:14 | <MikeSmith> | caitp: yeah |
| 03:14 | <MikeSmith> | caitp: OK thanks I guess I'll give up looking for it for now |
| 03:14 | <caitp> | if i still have the bugmail i can probably dig it up |
| 03:15 | <caitp> | mm, nope, gone |
| 04:34 | <TabAtkins> | Hixie: We just agreed to kill the image-orientation property, so we need the exif autorotate attr. (dbaron needs the functionality *somehow*, and wants to make sure it's a sure thing). |
| 04:34 | <TabAtkins> | http://lists.w3.org/Archives/Public/www-style/2013Jul/0568.html |
| 04:35 | <TabAtkins> | wrong window, sorry |
| 05:42 | <mikey85> | hello everyone :) |
| 05:42 | <mikey85> | God bless everyone :) |
| 05:42 | <mikey85> | message me if you would like to make friends with a good hearted Christian :) |
| 05:45 | <MikeSmith> | TabAtkins: wrong window again man, plus you've now exposed you super-secret mikey85 alternate nick |
| 06:31 | <hober> | MikeSmith|| |
| 06:31 | <hober> | err, ++ even |
| 06:40 | <sangwhan> | MikeSmith: smooth |
| 07:04 | <TabAtkins> | MikeSmith: That's hardly even a secret. |
| 07:06 | <zcorpan> | Hixie: i notice there's an "HTML - <img>" component in bugzilla now. maybe the bug filer should select that component for img bugs? and i guess i can move the existing ones |
| 07:07 | <MikeSmith> | zcorpan: yeah Hixie asked me to make that component for exactly what you just described |
| 07:10 | <zcorpan> | ok cool |
| 07:12 | <zcorpan> | Hixie: for the record i don't like the fading thing. i'd prefer if the styles are stable so i don't have to keep moving my mouse while reading and not lose track of where the links are |
| 07:12 | <zcorpan> | Hixie: i'd be OK with having the links always be black and underlined, or some such |
| 07:15 | <TabAtkins> | Fading thing? |
| 07:15 | <TabAtkins> | Oh, I saw it. |
| 07:18 | <TabAtkins> | But yeah, agree that the fading thing is annoying. At least keep the underlines. |
| 07:21 | <zcorpan> | i'd find the fading annoying even if it keeps the underlines. it's distracting me that it fades back and forth |
| 07:34 | <Ms2ger> | gsnedders, IE6 still supported? I missed it |
| 07:53 | <MikeSmith> | I like the fading thing. But I guess I'm weird. |
| 07:54 | <MikeSmith> | But I like the colors too, so I'd rather have the colors than having the links always be black or whatever other compromise |
| 07:55 | <MikeSmith> | and the complainers that are color-averse would just have to find some way to live with it |
| 08:03 | <annevk_> | http://www.openbsd.org/papers/bsdcan14-libressl/mgp00013.html whoa, OpenSSL had EBCDIC support |
| 08:42 | <sangwhan> | wonder if libressl is nuking that perl generated assembly nonsense in openssl |
| 09:01 | <MikeSmith> | can the empty string be a valid "source size list"? http://picture.responsiveimages.org/#valid-source-size-list |
| 09:01 | <MikeSmith> | is that BNF? does the lack of brackets around something mean it's required? |
| 09:01 | <MikeSmith> | what does "#" means? |
| 09:14 | MikeSmith | finds "A hash mark (#) indicates that the preceding type, word, or group occurs one or more times, separated by comma tokens (which may optionally be surrounded by white space and/or comments)." http://drafts.csswg.org/css-values/#component-multipliers |
| 09:14 | <MikeSmith> | good times |
| 09:15 | <mounir> | annevk: I believe the array thing is on purpose |
| 09:16 | <annevk> | mounir: can you restate that? |
| 09:19 | <mounir> | annevk: regarding navigator.languages |
| 09:19 | <mounir> | it returns an Array that has to be the same unless the values have changed |
| 09:19 | <mounir> | so you get previousValue == navigator.languages |
| 09:30 | <annevk> | mounir: so you return a JavaScript Array? |
| 09:30 | <annevk> | mounir: the IDL says otherwise |
| 09:30 | <mounir> | annevk: that's a Gecko quirks |
| 09:30 | <annevk> | mounir: in the spec |
| 09:31 | <mounir> | annevk: the spec says DOMString[] |
| 09:31 | <mounir> | annevk: this is what my Blink patch does |
| 09:31 | <mounir> | annevk: and in Gecko, sicking said that for some reasons, the right way was sequence<DOMString> |
| 09:31 | <mounir> | because of binding generator or something |
| 09:32 | <Ms2ger> | mounir, DOMString[] is bad |
| 09:33 | <mounir> | Ms2ger: don't be judgmental with that poor thing |
| 09:34 | <tobie> | Is there a palatable doc somewhere that explains the diff between DOMString[], sequence<DOMString>, Foo extends Array and the like? |
| 09:34 | <annevk> | mounir: [] is an IDL bug and needs to die |
| 09:34 | <mounir> | annevk: I understand that |
| 09:34 | <annevk> | tobie: not really, mostly we need someone to maintain IDL |
| 09:34 | <Ms2ger> | Then why are you using it in blink? |
| 09:35 | <tobie> | annevk: the language in WebIDL is NOT palatable. |
| 09:35 | <Ms2ger> | tobie, there will be no need to explain DOMString[] if DOMString[] is gone, though |
| 09:36 | <tobie> | Ms2ger: right, but in the meantime would be useful. |
| 09:36 | <tobie> | Ms2ger: I expect it's going to last a while before it is gone. |
| 09:39 | <annevk> | tobie: depends on when IDL becomes maintained again |
| 09:40 | <tobie> | annevk: sure, but we're still going to see references to it all over the place. |
| 09:41 | <annevk> | tobie: except at that point it'll be "oh this is invalid IDL, please fix" |
| 09:41 | <Ms2ger> | We can't, it's in CR |
| 09:41 | <tobie> | ^ that. |
| 09:41 | <annevk> | lol |
| 09:42 | <Ms2ger> | We'll just reference a WebIDL draft from 2008 |
| 09:42 | <tobie> | or already published as a REC, etc. |
| 09:42 | <annevk> | something something http://annevankesteren.nl/2012/11/process |
| 09:45 | <tobie> | I thought heycam was maintaining WebIDL (and that he currently was on holidays, hence the delay) |
| 09:46 | <Ms2ger> | He's not exactly quick to respond when he's not on holiday either |
| 09:47 | <annevk> | heycam has a ton of other responsibilities |
| 09:47 | <annevk> | IDL at this point requires about three to six months FTE |
| 09:55 | <annevk> | http://www.w3.org/TR/DOM-Level-3-Events/#widl-DocumentEvent-createEvent o_O |
| 09:55 | <SimonSapin> | sangwhan: http://youtu.be/GnBbhXBDmwU?t=51m9s |
| 09:59 | <darobin> | heh, annevk talking in FTEs |
| 09:59 | <darobin> | you can almost feel the manager waking up in there :) |
| 09:59 | darobin | ducks |
| 10:08 | <annevk> | mounir: I guess I still don't understand; are we returning a JavaScript Array? |
| 10:08 | <annevk> | mounir: seems like in Gecko we are; what about Blink? |
| 10:10 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=25800 #w3confusion |
| 10:11 | <mounir> | annevk: isn't what the spec says? |
| 10:11 | <annevk> | mounir: no |
| 10:15 | <mounir> | annevk: the spec says DOMString[], how isn't that a JS array? |
| 10:15 | <mounir> | I'm confused |
| 10:15 | <annevk> | mounir: it's an IDL array |
| 10:15 | <mounir> | annevk: and that's not seen as an array in JS? |
| 10:15 | <annevk> | mounir: correct |
| 10:15 | <annevk> | mounir: read http://heycam.github.io/webidl/#es-array and weep |
| 10:16 | <mounir> | oh boy... |
| 10:19 | <mounir> | annevk: btw, the sequence<T> of Gecko is a hack in the sense that WebIDL doesn't allow returning sequence<T> from an attribute |
| 10:20 | <annevk> | yeah I know about that; I don't like how IDL has the same "types" for arguments and return values |
| 10:22 | <sangwhan> | SimonSapin: oh boy, the perl is still there |
| 10:24 | jgraham | is quite confused about why you would want different types for arguments and return values |
| 10:24 | <annevk> | jgraham: the argument one is not a type, it's a coercion |
| 10:25 | <jgraham> | A coercion to a type |
| 10:25 | <mounir> | annevk: seriously, this "platform array" thing is pretty confusing |
| 10:26 | <annevk> | mounir: you can consider it dead |
| 10:26 | Ms2ger | promotes mounir to WebIDL editor |
| 10:26 | <mounir> | Ms2ger: if you do that, don't complain when you become a Gecko DOM peer ;) |
| 10:27 | <Ms2ger> | Ha |
| 10:27 | <Ms2ger> | Not like I have time to do Gecko reviews anyway |
| 10:28 | <mounir> | Ms2ger: you wouldn't be the first reviewer without time for reviews ;) |
| 10:29 | <Ms2ger> | Hmm |
| 10:29 | <Ms2ger> | Should window.HTMLAllCollection exist? |
| 10:29 | <Ms2ger> | I guess so |
| 10:34 | <mounir> | annevk: what's the simplest/quickest way to check if an array is a js-array? |
| 10:35 | <annevk> | mounir: use isArray maybe |
| 10:36 | <mounir> | annevk: that wouldn't return true for a non-js array? |
| 10:36 | <annevk> | mounir: it shouldn't |
| 10:36 | <mounir> | it seems that the Blink bindings return a JS array then |
| 10:37 | <annevk> | mounir: another test you could do is push a number or string on the array and see if it's there |
| 10:39 | <mounir> | annevk: working in Blink, failing in Gecko |
| 10:39 | <annevk> | weird |
| 10:40 | <mounir> | annevk: it says that l.push() isn't extensible in Gecko |
| 10:41 | <annevk> | mounir: but Array.isArray(obj) returns true in Gecko? |
| 10:41 | <mounir> | yep |
| 10:41 | <annevk> | o_O |
| 10:42 | <annevk> | "ask bz" |
| 10:46 | <mounir> | annevk: I probably did something wrong ;) |
| 11:28 | <foolip> | MikeSmith: I've commented on the open issues |
| 11:37 | <tobie> | Sounds like I'm not the only one utterly confused by the []/sequence, etc. mess. |
| 11:37 | <MikeSmith> | foolip: thanks much |
| 11:39 | <tobie> | annevk: isn't sequence<foo> just saying: this function/attribute will duck-type? |
| 11:39 | <TabAtkins> | So, if I'm returning a Promise which will resolve to a JS array of FontFace objects, the right type for the return value is Promise<sequence<FontFace>>, right? |
| 11:40 | TabAtkins | put that in Font Loading today, so he hopes it's right. |
| 11:40 | <tobie> | yup |
| 11:40 | <TabAtkins> | kk |
| 11:41 | <tobie> | actually, I'm not sure you can use sequence<foo> for return types. |
| 11:42 | <annevk> | tobie: as argument it means the implementation will iterate over the object (using Symbol.iterator) to get the list of values; as return value it means JS Array |
| 11:42 | <TabAtkins> | ARGH |
| 11:42 | <TabAtkins> | annevk: Okay, cool. |
| 11:42 | <tobie> | oh. OK. |
| 11:45 | <tobie> | It would be helpful to use different syntax for these two different things. |
| 11:46 | <tobie> | Why don't we use Array<Foo> for the return type? |
| 11:57 | <tobie> | Looking at the WebIDL bug tracker, I get a better sense of what annevk, Ms2ger were referring to. |
| 12:02 | <barnabywalters> | anyone here know if work to add native Promise support to XMLHttpRequest is being done somewhere? |
| 12:03 | <zcorpan> | barnabywalters: i think that will be called "fetch()" |
| 12:03 | <annevk> | tobie: see above where I said we should have different syntax for argument / return value (or get vs set) |
| 12:04 | <barnabywalters> | zcorpan: interesting, do you have a URL to a spec? I couldn’t find one easily, might not be looking in the right places |
| 12:04 | <zcorpan> | barnabywalters: i saw something in ServiceWorker but it's wasn't fleshed out when i looked at it |
| 12:04 | <gsnedders> | Ms2ger: Yeah. I mean, pretty much everyone using IE6 isn't using a server OS, but still. :) |
| 12:05 | <tobie> | annevk: yeah. I guess it's inevitable with a not strongly typed language. |
| 12:05 | <annevk> | tobie: ToPromise / Promise; Iterable / Array |
| 12:06 | <tobie> | annevk: on second thought, I'm not even sure strong type has anything to do with it. |
| 12:06 | <tobie> | annevk: ++ |
| 12:07 | <tobie> | annevk: how does that work for attributes which are rw? |
| 12:07 | <annevk> | tobie: I think for properties we need to be more clear on whether they have getter/setter or are a data property |
| 12:07 | <annevk> | tobie: currently everything is a getter/setter, but that seems somewhat wrong |
| 12:09 | <barnabywalters> | zcorpan: hrm okay, might try diving into ServiceWorker then |
| 12:09 | <tobie> | barnabywalters: there's also the fetch spec. |
| 12:09 | <barnabywalters> | tobie: that sounds good — link? |
| 12:09 | <annevk> | barnabywalters: the idea is fetch(Request req).then(Response r => ...) |
| 12:09 | <barnabywalters> | http://fetch.spec.whatwg.org/? |
| 12:10 | <tobie> | barnabywalters: yes |
| 12:10 | <tobie> | but the fetch JS API isn't defined there. |
| 12:10 | <annevk> | barnabywalters: that's where the API will eventually end up, currently it's just defining the network stack |
| 12:10 | <barnabywalters> | annevk: ah so xhr is being split into Request and Response objects now? |
| 12:10 | <annevk> | barnabywalters: roughly |
| 12:11 | <annevk> | barnabywalters: if you look at http://xhr.spec.whatwg.org/ you'll see it's defined in terms of Fetch too |
| 12:12 | <TabAtkins> | annevk: I'd be happy if WebIDL arguments were all named interface-like and return types were named object-like. |
| 12:12 | <barnabywalters> | annevk: tobie: thanks, I’ll have a read through those |
| 12:13 | <annevk> | TabAtkins: I'm not sure what that means I'm afraid; we do have some ideas on revamping the whole interface / [NoInterfaceObject] mess in terms of classes and such |
| 12:38 | <zcorpan> | MikeSmith: pointer? https://critic.hoppipolla.co.uk/showcomment?chain=3809 |
| 12:41 | <zcorpan> | MikeSmith: i can't see anything in www-archive :-( |
| 12:46 | <TabAtkins> | annevk: Interface-like means names like "iterable" and "promise-like" and whatnot - adjectives, mostly. "object-like" are nouns. |
| 12:46 | <TabAtkins> | Like difference between "functor" (terrible name, also a noun, so misleading) and "mappable" (accurately describes, indicates that it's a quality of an object) |
| 12:50 | <zewt> | functor: callable |
| 12:50 | <TabAtkins> | That's part of why the name is so terrible, because it has nothing to do with "function". |
| 12:51 | <zewt> | i guess functor is specifically a callable object (in C++), so in that case being a noun is correct |
| 12:51 | <TabAtkins> | (A function *is a* functor, but for reasons that have nothing to do with calling.) |
| 12:52 | <TabAtkins> | A functor is any object with a .map() operation or equivalent - it holds some values/values in a container or context, and lets you pass functions inside of it to operate on the inner values and return the same context with the return values. |
| 12:52 | <zewt> | i'm only talking about c++; i've never seen "functor" used in any other context (and I don't know why anyone would) |
| 12:53 | <zewt> | though I guess people call c++ functions functors too, for templates |
| 12:53 | <jgraham> | functor in C++ means something entirely different to Haskell I think |
| 12:53 | <TabAtkins> | Functor is a category theory term. |
| 12:53 | <jgraham> | (I think that mappable is a terrible name) |
| 12:53 | <TabAtkins> | It's a thing you can map. What better name could it have? |
| 12:54 | <jgraham> | Well the problem might be that map is a bad name |
| 12:54 | <zewt> | without knowing anything about it in advance, it sounds like "can be used as a the key in a dictionary" |
| 12:54 | <zcorpan> | TabAtkins: did the @charset use counter ever materialize? |
| 12:54 | <zewt> | (the effect of hashable in python) |
| 12:56 | <TabAtkins> | zcorpan: No, I haven't actually coded any Blink since the fork. |
| 12:57 | <zcorpan> | TabAtkins: ok |
| 12:57 | <annevk> | thanks tobie for the ScalarValueString patch |
| 12:57 | <TabAtkins> | zewt: The word "map" is pretty common in functional languages (including JS) to mean "call this on every element of the {array, set, etc} and give me a new container with the results". |
| 12:57 | <TabAtkins> | Python's map(), JS's Array#map, etc. |
| 12:57 | <TabAtkins> | JS also has a Map, to be sure, but Python calls it Dict to avoid confusion. |
| 12:58 | <TabAtkins> | (Also, a Map is a functor. ^_^) |
| 12:58 | <zewt> | TabAtkins: a terrible mechanism (python's comprehensions are 100x more readable), but i've never seen "map" adjectived |
| 13:00 | <zewt> | okay, i only just noticed the "Show: [x] inherited" checkbox on the right of these docs http://msdn.microsoft.com/en-us/library/system.windows.controls.treeviewitem(v=vs.110).aspx |
| 13:00 | <TabAtkins> | Comprehensions are great, but not a replacement in all cases. |
| 13:00 | <TabAtkins> | [foo(bar) for bar in bars] is worse than bars.map(foo) |
| 13:00 | <zewt> | been growling at these horrible docs for making me squint through endless pages of inherited mess for days because they decided to have an obscure "[x] show pages of useless crap" default tucked off to the side |
| 13:01 | <zewt> | TabAtkins: i prefer it, to me the extra typing is worth not having to parse two different patterns |
| 13:02 | <zewt> | it's also nicer to have (foo(bar) for bar in bars) and {bar: foo(bar) for bar in bars} without having to change modes when i want a different type |
| 13:03 | <zcorpan> | all i hear is "foo bar foo bar foo bar" |
| 13:03 | <TabAtkins> | Yeah, the other comprehensions are quite nice. |
| 13:06 | <zewt> | incidentally, special thanks to c# for adding comprehensions... in a different order, from foo in bar select foo |
| 13:06 | <zewt> | just to make sure it's a pain for everyone to context switch |
| 13:07 | <darobin> | I always thought "comprehensions" was what you wish you had when you saw Python code |
| 13:07 | <jgraham> | darobin: Nah, it's what ruby doesn't give you |
| 13:08 | <zewt> | darobintroooooll |
| 13:27 | Ms2ger | wonders if http://code.google.com/p/chromium/issues/detail?id=43394 is ever going to land |
| 13:31 | <zcorpan> | Ms2ger: "any time now" |
| 13:56 | <TabAtkins> | Note that it's still receiving useful activity. We keep poking at it and trying it out, but it keeps causing perf regressions. |
| 13:56 | <TabAtkins> | But they're getting smaller and smaller. |
| 13:59 | <zcorpan> | MikeSmith: w3c-test:mirror seems like it doesn't bite for me again :-( |
| 14:00 | <Ms2ger> | Without a space? |
| 14:00 | <zcorpan> | MikeSmith: https://github.com/w3c/web-platform-tests/pull/996 |
| 14:00 | <zcorpan> | should there be a space? |
| 14:00 | <Ms2ger> | That's what I've done, I think |
| 14:01 | <zcorpan> | no dice |
| 14:01 | <jgraham> | zcorpan: There is (theoretically) never any point in putting w3c-test:mirror on your own PR |
| 14:01 | <jgraham> | If you have permissions to mirror stuff your own PRs should be automatically mirrored |
| 14:02 | <jgraham> | So you either don't have permissions or (more likely) the script is broken |
| 14:02 | <zcorpan> | yeah ok |
| 14:04 | <mathiasbynens> | hsivonen: validator.nu seems down again |
| 14:07 | <annevk> | JakeA: we need a story for fetch() outside service workers |
| 14:08 | <annevk> | JakeA: I don't think we can squat a global name like that |
| 14:08 | <annevk> | JakeA: is it going to be navigator.fetch() outside of workers? |
| 14:10 | <JakeA> | annevk: why is window.fetch bad? Likely to be taken by app code? |
| 14:11 | <annevk> | JakeA: yeah, taking global names is icky |
| 14:11 | <annevk> | JakeA: I'm open to try it I guess |
| 14:11 | <JakeA> | annevk: What about Cache and caches? |
| 14:15 | <zcorpan> | fetch seems a bit weird to put on navigator |
| 14:15 | <annevk> | JakeA: dunno |
| 14:15 | <Ms2ger> | location.fetch() |
| 14:15 | <jgraham> | Ms2ger is winning |
| 14:15 | <zcorpan> | URL.fetch() ? |
| 14:16 | <jgraham> | zcorpan takes the lead |
| 14:16 | <Ms2ger> | Blob.fetch() |
| 14:16 | <zcorpan> | Fetch.fetch() |
| 14:16 | <jgraham> | Ms2ger crashes into a wall |
| 14:16 | <Ms2ger> | :D |
| 14:16 | <JakeA> | f.etch() |
| 14:16 | <Ms2ger> | .sketch()? |
| 14:17 | <zcorpan> | JakeA: f is unlikely to be taken, seems ok |
| 14:17 | <jgraham> | This has gone very Wacky Races all of a sudden |
| 14:17 | <jgraham> | With JakeA playing Dastardly |
| 14:18 | <JakeA> | haha |
| 14:19 | <JakeA> | window.fetch, caches, Cache would obviously be my first choice… |
| 14:20 | <JakeA> | window.fetchXML() |
| 14:20 | <JakeA> | but it can be used (and will mainly be used) to fetch not-XML |
| 14:20 | <gsnedders> | jgraham: Do you want me to rewrite the history of https://critic.hoppipolla.co.uk/r/287 before you review it? |
| 14:20 | <Ms2ger> | XMLHttpRequest.fetchHTML() |
| 14:20 | <JakeA> | haha |
| 14:21 | <Ms2ger> | XMLHttpRequest.fetchHTMLSpdy() |
| 14:21 | <JakeA> | The problem with putting it on navigator is it won't be on navigator in the SW |
| 14:21 | <jgraham> | The problem with putting it on navigator is that it makes no sense |
| 14:22 | <jgraham> | It just ends up as a duming ground for things we were too scared to put on window |
| 14:22 | <jgraham> | *dumping |
| 14:22 | <jgraham> | gsnedders: Yes |
| 14:22 | <JakeA> | like navigator.serviceWorker :D |
| 14:23 | <jgraham> | Yeah, pretty much. Things only make sense on navigator if they don't depend on the Window |
| 14:30 | <annevk> | jgraham: navigator is a dumping ground |
| 14:38 | <jgraham> | annevk: Perhaps, but it's not good |
| 14:43 | <Domenic> | annevk: you could block on modules!??! |
| 14:43 | <annevk> | Domenic: block service workers on modules? |
| 14:43 | <Domenic> | annevk: I assume fetch-outside-workers doesn't block service workers... |
| 14:47 | <jgraham> | You could add a .send() method to Request |
| 14:49 | <annevk> | new Request(...).send().then(r => ...) |
| 14:50 | <Domenic> | hmm |
| 14:50 | <gsnedders> | jgraham: there's no prepare rebase link on Critic on that page? |
| 14:50 | <tobie> | Request.fetch? |
| 14:50 | <Domenic> | feels enough like XHR to trigger some bad feels |
| 14:51 | <Domenic> | Request.fetch seems better |
| 14:53 | <tobie> | Would be nice to ship fetch outside of SW at the same time (or even before) it is shipped within SW. |
| 14:53 | <jgraham> | Do you "fetch" a Request? Surely you "send" a Request? |
| 14:53 | <jgraham> | gsnedders: No, you do the opposite |
| 14:54 | <jgraham> | gsnedders: https://github.com/mozilla/servo/wiki/Github-&-Critic-PR-handling-101 |
| 14:54 | <gsnedders> | jgraham: huh? |
| 14:54 | <Domenic> | if it's a method on Request.prototype, then send. But if it's a static factory method, then fetch seems better. |
| 14:54 | <tobie> | ^ that |
| 14:54 | <annevk> | you fetch a response using a request |
| 14:54 | <tobie> | IO.fetch |
| 14:54 | <jgraham> | Request.fetch(request) is going to sound very odd |
| 14:55 | <annevk> | jgraham: agreed |
| 14:55 | <gsnedders> | jgraham: the first commit on the branch and not the merge-base? |
| 14:55 | <jgraham> | Even though it is probably no more verbose than other options, it feels like it is due to the repetition |
| 14:55 | <jgraham> | gsnedders: Do your rebase, force push, follow the steps to update critic. |
| 14:56 | <gsnedders> | jgraham: I'm following the steps. "Ask for help if this step is daunting" |
| 14:56 | <jgraham> | Heh |
| 14:56 | <annevk> | this latest email to webkit-dev... |
| 14:56 | <annevk> | MikeSmith is gonna love it |
| 14:56 | <gsnedders> | jgraham: The parent of the first commit on the branch? So the merge-base? |
| 14:56 | <jgraham> | gsnedders: It's the SHA1 of the parent of the first commit on the branch |
| 14:57 | <jgraham> | gsnedders: Yes. |
| 14:57 | <gsnedders> | jgraham: Okay, done |
| 14:57 | <jgraham> | gsnedders: Basically critic constructs a diff of the post-rebase branch compared to the pre-rebase branch |
| 14:57 | <jgraham> | So you need to tell it where the post-rebase branch starts |
| 14:58 | <gsnedders> | jgraham: Note that this still fails a whole load of tests, but mostly because the tests are kinda broken |
| 14:59 | <tobie> | annevk: np. thanks for merging it (SW patch). |
| 15:03 | <gsnedders> | jgraham: Why is the review not tracking any more? |
| 15:05 | <Domenic> | I didn't realize that fetch() accepted a request. in that case there should almost certainly be a Request.prototype.send() for when you already have a Request object |
| 15:05 | <jgraham> | gsnedders: You need to reenable that |
| 15:05 | <Domenic> | fetch(), wherever it ends up, seems mostly for the URL-accepting case to me. |
| 15:05 | <tobie> | annevk, seems you didn't push it to gh-pages though. |
| 15:07 | <tobie> | annevk: which reminds of https://github.com/slightlyoff/ServiceWorker/issues/266 |
| 15:08 | <annevk> | Domenic: you want Request for all the additional parameters |
| 15:09 | <gsnedders> | jgraham: I pressed the button. Nothing happeend. |
| 15:09 | <Domenic> | annevk: you could add those as an options object to fetch, hmm. fetch(url, { timeout: 5000 }) vs. (new Request({ url: url, timeout: 5000 }).send() |
| 15:09 | <Ms2ger> | gsnedders, force-refresh |
| 15:10 | <Domenic> | woah why is there a synchronous flag O_O |
| 15:10 | <jgraham> | gsnedders: Force reload |
| 15:11 | <jgraham> | gsnedders: Then blame jl |
| 15:22 | <gsnedders> | I blame jl. |
| 15:53 | <annevk> | Domenic: I think I filed a bug on that, if that's exposed it should only be readonly |
| 15:55 | <Domenic> | annevk: when is it useful? |
| 15:55 | <annevk> | Domenic: I guess a service worker might want to know about synchronous requests so it can log errors somewhere for the frontend team |
| 15:55 | <Domenic> | annevk: ah right i forgot to context switch from fetch to SW's onfetch |
| 16:22 | <annevk> | Domenic: I think the idea for fetch() was String or Request |
| 16:22 | <Domenic> | annevk: yeah, I guess, just thinking of what people are used to from jQuery etc. |
| 16:22 | <annevk> | Domenic: or a dictionary |
| 16:22 | <Domenic> | it's a small step from dictionary to string + dictionary ;) |
| 16:22 | <annevk> | fetch({url:...}) should work I think |
| 16:23 | <Domenic> | the nice thing about fetch(url, {...}) is that it's an easy change from code that does fetch(url) |
| 16:23 | <jgraham> | Putting a non-optional parameter into a dict seems ugly |
| 16:24 | <Domenic> | that too |
| 16:25 | <annevk> | I guess that's fair, ideally we align the Request constructor with that pattern |
| 16:25 | <annevk> | I should probably take ownership at some point, not moving very quickly at the moment |
| 16:27 | <tobie> | node.js request accepts both req(url, options) and req({url: url, options... }) |
| 16:27 | <tobie> | fwiw |
| 16:28 | <Ms2ger> | That seems somewhat unhelpful |
| 16:30 | <tobie> | Ms2ger: people tend to have strongly diverging opinions when it comes to API design. |
| 16:32 | <Domenic> | jQuery also accepts both |
| 16:32 | <Domenic> | i kind of dislike the both approach also, but not strongly |
| 16:45 | <JakeA> | Domenic: annevk: fetch(url) is not as common as maybe originally thought. I'm happy to ditch fetch() for request.send() |
| 16:46 | <JakeA> | As long as new Request(url) works |
| 16:46 | <Domenic> | JakeA: hmm why is that? $.get(url) is very common... |
| 16:46 | <JakeA> | Domenic: actually, I was thinking of ServiceWorker, in a page fetch(url) would be common |
| 16:47 | <JakeA> | But new Request(url) seems ok to me. Happy to be wrong though. Feels like a smaller footprint for the window object |
| 16:50 | <annevk> | JakeA: we can do fetch(url, rest); new Request(url, rest); fetch(Request); and maybe new Request(Request) (for downgrading a UA-generated object) |
| 16:52 | <jsbell> | annevk's suggestion is what I had in my head (apart from Request(Request) but that makes perfect sense) |
| 16:58 | <JakeA> | So function fetch(args...) { return new Request(arts)} |
| 16:58 | <JakeA> | Ffs, coding on phone |
| 16:58 | <JakeA> | So function fetch(args...) { return new Request(args...).send(); } |
| 16:59 | <Ms2ger> | ...args? |
| 16:59 | <JakeA> | Yeah, that, probably (can never remember which side the ... goes on) |
| 17:02 | <jsbell> | If it was exactly that, it auto-downgrades a UA-generated object. |
| 17:03 | <Domenic> | I like that |
| 17:05 | <jsbell> | BTW, is there a doc/thread yet, or just noodling here? (I'm catching up on email after being away for a bit, so may discover it shortly) |
| 17:12 | <annevk> | jsbell: noodling here |
| 17:12 | <jsbell> | thx |
| 17:12 | <JakeA> | What do we mean by downgrades? |
| 17:13 | <JakeA> | That happens on .send() right? It becomes "connect" in CSP terms |
| 17:32 | <annevk> | JakeA: yeah, I was thinking we could offer explicit syntax for it as well so people can reason about it without doing a fetch |
| 17:32 | <annevk> | JakeA: I'm not sure I like the .send() design |
| 17:37 | <annevk> | On the other hand, if we name it .send() there's less of a confusion between fetching and fetch() |
| 17:46 | <Hixie> | zcorpan: i figured i would filter the incoming bugs for you rather than just automatically send img bugs to you |
| 17:46 | <Hixie> | TabAtkins: autorotate="" is in zcorpan's area now, unfortunately, but maybe i can send him a patch or something |
| 17:47 | <Hixie> | as far as the fading thing goes, yeah, i don't like it either |
| 17:47 | <Hixie> | i'm trying to figure out how to address the feedback that some people have asking for the spec to be less busy, while still addressing the needs of people like me who use the styles to understand what's going on. |
| 17:48 | <annevk> | and here I thought my browser had a bug |
| 17:50 | <jgraham> | Uh yeah. That seems like a bad idea |
| 17:50 | <jgraham> | Why not just drop the underlines? |
| 17:52 | <Hixie> | there are two groups of people i'm trying to cater for. group A wants no colour and no underlines. Group B wants colour and underlines. |
| 17:53 | <Hixie> | (group A basically wants no hyperlinks visible, the point as far as i can tell is to feel like you're reading a book rather than feel like you're reading a spec with deep links everywhere.) |
| 17:53 | <Hixie> | (group B might be just me.) |
| 17:54 | <jgraham> | Since I apparently don't fall into either group, I doubt your characterisation is accurate |
| 17:55 | <Hixie> | well it's quite likely there are other groups that i should also be trying to cater for, but those were the groups i was trying to cater for. |
| 17:56 | <boogyman> | Hixie: I don't think it would be terribly difficult to use alternate stylesheets, right? The question there though is what interface to use to switch between them. |
| 17:57 | <jgraham> | I think that hypertext is a great thing and I think it is especially great in the spec, since you basically can't understand it without following links. So I think the "Group A" people have either been mischaracterised or don't really want what they say they want. OTOH I think that underlines are a particularly poor typographical technique since they compete with the letters themselves |
| 17:57 | <Hixie> | boogyman: most users don't touch that kind of UI |
| 17:57 | <Hixie> | boogyman: so it doesn't solve the problem |
| 17:57 | <IZh> | Hixie: Hi. What's the purpose of lots of empty <span></span> in the spec? |
| 18:00 | <jgraham> | http://www2003.org/cdrom/papers/refereed/p391/p391-obendorf.html seems relevant |
| 18:00 | <Hixie> | jgraham: the feedback specifically is things like "i wish it didn't look like a christmas tree", "too bright and contrasty", "don't like the colour formatting", "excessive hyperlinks make it too busy", "it's a little cluttered and busy", "it's not the prettiest thing in the world", "dislike layout & font", "looks cheap", "ugly colors", "when everything is highlighted italic red green or blue it is hard to distinguish content" |
| 18:00 | <jgraham> | "Underlined links seem to substantially decrease the reading performance on Web pages and may add to the reasons why users donít like to read on the Web" |
| 18:02 | <jgraham> | Hixie: Those are all arguments in favour of more subtle design, not in favour of removing the most important elements needed to navigate the spec. |
| 18:02 | <Hixie> | (not clear that whoever formatted that page is allowed to comment on formatting, but... *reads*) |
| 18:02 | <Hixie> | jgraham: concrete suggestions welcome |
| 18:05 | <jgraham> | Hixie: Well so far I made one |
| 18:06 | <Hixie> | "To reduce the influence that different degrees of interest in the test items would have, we selected a very homogeneous user group. The target group consisted of regular and experienced internet users, as we wanted to assess the willingness of these users to adopt changes in the Web interface." |
| 18:06 | <Hixie> | +1 for making a plausible argument for why they only selected people within shouting distance of their office :-) |
| 18:07 | <IZh> | Hixie: Sorry. It seems there are no in latest version. |
| 18:07 | <Hixie> | IZh: hey, sorry, missed your question. dunno what could cause that, but probably a markup error on my side. |
| 18:10 | <jgraham> | Hixie: I also think that the green and the blue and the yellow don't really go together. The green italic text is quite hard to read, and I wonder if CSS-style boxes with a background colour and black text would work better for notes (more like examples) |
| 18:11 | <jgraham> | I am terrible at design though so I am really the wrong person to fix things |
| 18:12 | <IZh> | Hixie: please look at 4.12.4.2.7 at definition list after "Run the appropriate step..." It consists of only <dd> and no <dt>. Is it correct? |
| 18:13 | <Hixie> | jgraham: that paper's interesting, but the conclusion for the spec isn't to get rid of underlines and even less to make hyperlinks only visible on demand, imho. Assuming we treat reading the spec as more like their "link" tasks, it would suggest hyperlinks should be always visible (fewer errors in that case), and looking at the feedback of their overlay vs underline thing, it seems like a toss-up regarding which people like best. |
| 18:13 | <Hixie> | jgraham: yeah, same here |
| 18:13 | <Hixie> | jgraham: what's yellow? |
| 18:14 | <Ms2ger> | The sun? |
| 18:14 | <Hixie> | in the spec, doofus |
| 18:14 | <Hixie> | IZh: what's the heading of that section? |
| 18:14 | <Hixie> | IZh: (i don't have section numbers in the source) |
| 18:15 | <IZh> | Hixie: Path2d objects |
| 18:16 | <Hixie> | that's weird, wonder why the validator didn't catch that |
| 18:17 | <Hixie> | IZh: fixed, thanks |
| 18:17 | <IZh> | Hixie: I have bought one commercial validator. And of course couldn't test it against the spec. ;-) |
| 18:18 | <annevk> | There's commercial validators now? |
| 18:18 | <jgraham> | Hixie: Links on hover are yellow. And link targets |
| 18:18 | <IZh> | Hixie: I mean couldn't not test ;-) |
| 18:19 | <IZh> | annevk: Yes. There are some good. |
| 18:19 | <Hixie> | jgraham: oh the hover effect, ok |
| 18:20 | <annevk> | Hixie: I like the new Example / Note / Warning / etc. thing |
| 18:21 | <jgraham> | Hixie: I think the conclusions of the study are a) too suble link styling makes people not use links and b) too invasive link styling makes text hard to read. I think that dropping the underlines will help with linear reading |
| 18:21 | <IZh> | Hixie: by the way, what is the source for the spec? Xml? |
| 18:21 | <jgraham> | I doubt it will make the links invisible, so I don't think we'll hit the error case |
| 18:22 | <Hixie> | IZh: some weird variant of HTML with preprocessor directives |
| 18:23 | <Hixie> | jgraham: they specifically say in the study (without data sadly) that they think that links that are only distinguished by colour are too subtle (they think it would be the same as tplain text), so that would be case (a) |
| 18:24 | <IZh> | Hixie: validator also complains about very long lines. There is, for example, the table of named entities, that is only single line. |
| 18:24 | <jgraham> | Hixie: They say without data is about as valuable as I say the opposite without data :) |
| 18:24 | <jgraham> | Except that they are presumably trying to justify not taking the time to test that case |
| 18:25 | <Hixie> | IZh: that |
| 18:25 | <Hixie> | IZh: that's an error in the validator :-) |
| 18:25 | <Hixie> | jgraham: exactly :-) |
| 18:26 | <IZh> | Hixie: it only complains about syntax highlighting. Also is is not very huumsn |
| 18:26 | <IZh> | Hixie: human readable |
| 18:26 | jgraham | discovers that http://usability.gov doesn't underline links |
| 18:27 | <jgraham> | Actually I think the fact that so many sites now don't underline links sort of puts the anecdata on my side of the argument |
| 18:27 | <IZh> | Hixie: and some browsers performed bad when you try to view source of the document with such long lines. |
| 18:29 | <Hixie> | i find sites that don't underline links very confusing, personally |
| 18:31 | <annevk> | I think I agree with jgraham |
| 18:32 | <annevk> | color is quite a good indicator and the underline makes the text harder to parse |
| 18:37 | <Hixie> | so without the underline, how do you distinguish a <code> snippet that's a link from one that isn't? |
| 18:38 | <IZh> | Hixie: one long line contains 314187 characters. :-) |
| 18:38 | <Hixie> | IZh: yeah, it's machine-generted :-) |
| 18:42 | <IZh> | Hixie: the links to [CSSFONTLOAD] and [PAGEVIS] at the end of the spec are 404. |
| 18:42 | <annevk> | Hixie: maybe that should have the color of :link / :visited and simply use monospace |
| 18:42 | <Hixie> | annevk, sicking: ok, reload a whatwg spec, tell me how bad it is... |
| 18:42 | <annevk> | Hixie: :hover / :focus could add the underline |
| 18:43 | <Hixie> | IZh: sigh, w3c |
| 18:43 | <annevk> | Hixie: in http://url.spec.whatwg.org/#dom-url TypeError is grey |
| 18:43 | <Hixie> | anyone know the currently URLs of http://dev.w3.org/csswg/css-font-load-events/ and http://www.w3c-test.org/webperf/specs/PageVisibility/ ? |
| 18:44 | <Hixie> | annevk: yeah, that's a non-hyperlink, non-definition <Ccode> block. |
| 18:44 | <Hixie> | <code> even |
| 18:44 | <annevk> | so only code that's hyperlink or <dfn> is orange? |
| 18:44 | <IZh> | Hixie: Is this it? http://dev.w3.org/csswg/css-font-loading/ |
| 18:45 | <annevk> | TabAtkins: ^^ might want to set up redirects |
| 18:45 | <IZh> | http://dev.w3.org/csswg/css-font-loading/ |
| 18:45 | <IZh> | http://dev.w3.org/csswg/css-fonts-3/ |
| 18:46 | <annevk> | Hixie: there's http://www.w3.org/TR/page-visibility/ can't find editor's draft :/ |
| 18:46 | <Hixie> | IZh: none of those seem to define FontLoader... i wonder if FontLoader is dead or something |
| 18:46 | <Hixie> | annevk: currently, yeah |
| 18:46 | <Hixie> | annevk: i've no idea if that's reasonable |
| 18:46 | <annevk> | Hixie: FontLoader is dead I think |
| 18:47 | <Hixie> | huh |
| 18:47 | <Hixie> | guess i'd better file a bug to handle that... |
| 18:47 | <annevk> | Hixie: no editor's draft would mean no maintenance |
| 18:47 | <annevk> | Hixie: http://dev.w3.org/csswg/css-font-loading/ has an alternative AIP |
| 18:47 | <IZh> | Hixie: http://www.w3.org/TR/2012/WD-css3-fonts-20121211/ The old one defines it. |
| 18:47 | <annevk> | API* |
| 18:47 | <Hixie> | file a bug |
| 18:47 | <Hixie> | er |
| 18:47 | <Hixie> | fileD a bug |
| 18:47 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=25812 |
| 18:48 | <Hixie> | IZh: (thanks for finding these!) |
| 19:12 | <IZh> | Hixie: Is it good or bad when quoted string attributes spans across several lines? |
| 19:16 | <IZh> | Like: <a href=#syntax title="the |
| 19:16 | <IZh> | HTML syntax">HTML syntax</a> |
| 19:27 | <IZh> | There are some of these in the spec. |
| 19:31 | <caitp> | it works in current browsers, so presumably the parsing spec allows for it |
| 19:31 | <caitp> | unless it's just a happy accident |
| 19:36 | <IZh> | Hixie: In the end of the section "The WorkerGlobalScope common interface" there is empty link <a href=#dom-workerglobalscope-location></a> before the word "attribute". |
| 19:37 | <IZh> | Hixie: The same thing in the section "Standard metadata names": using the <code title=attr-lang><a href=#attr-lang></a></code> attribute... |
| 19:39 | <Hixie> | izh: looking... |
| 19:40 | <Hixie> | TabAtkins: what's the state of the art with respect to positioning something relative to an ancestor element (e.g. one with position:relative) for 'top', and relative to another (e.g. the root element or ICB) for 'left'? |
| 19:41 | <Hixie> | IZh: thanks, fixed |
| 19:41 | <SamB> | Hixie: don't you need nasty hacks for that? |
| 19:42 | <Hixie> | SamB: that's what i'm asking |
| 19:42 | <Hixie> | so far for elaborate cases i'm not finding any real solutions |
| 19:42 | <Hixie> | it's even worse because i have some elements with position:relative for unrelated reasons, too |
| 19:43 | <IZh> | What's the purpose of ␣? How it differs from ordinary space? |
| 19:44 | <Hixie> | it's visible, for one |
| 19:44 | <Hixie> | it's used to show that there is a space, in code examples where spaces matter |
| 19:44 | <Hixie> | (this glyph used to be a lot more commonly used in computer manuals from a few decades ago) |
| 19:45 | <IZh> | Ahh... Sonething like '_' ? |
| 19:45 | <Hixie> | yeah |
| 19:45 | <Hixie> | jgraham: i've changed the :target style to not be yellow too. |
| 19:52 | <IZh> | I'm curious, will ever document title support markup? ;-) I want green window caption. ;-) |
| 20:03 | <Hixie> | IZh: given that document titles are getting less and less used in the UI, i doubt there's much demand to make them harder to implement :-) |
| 20:07 | <jgraham> | Hixie: I think that's a win |
| 20:09 | SamB | is greatly saddened by the disuse of document titles :-( |
| 20:10 | <SamB> | however, it's not bloody likely that they'll be getting any such fancy features |
| 20:11 | <SamB> | the places where they probably still are used -- normal WMs on *nix come to mind -- can't handle anything fancy anyway |
| 20:12 | SamB | sorta feels like it might be nice if stray tags were stripped rather than shown verbatim though |
| 20:17 | <IZh> | One more question. Is it possible to change facicon ob the fly? |
| 20:20 | <SamB> | IZh: well, what happens if you change the relevant link element(s)? |
| 20:21 | <IZh> | SamB: perhaps it will work. |
| 20:31 | <IZh> | is available. And in the case of no connection it will display an error instead of old cached version. I spend lots of time in a waiting for cellular network to appear. Probably some pragmas could force the browsers to display old cached page when they can't fetch a new version instead of showing dumb error. |
| 21:33 | <JonathanNeal> | How are element queries coming along? |
| 22:28 | <TabAtkins> | Hixie: What is FontLoader and what were you using it for? If you just want to load a font via JS, FontFace is constructable. |
| 22:28 | <TabAtkins> | Hixie: There is no way to position the top and left of an element relative to different things at the moment. |
| 22:39 | <Hixie> | TabAtkins: i don't recall. something in HTML. i filed a bug on myself to figure it out. |
| 22:39 | <Hixie> | TabAtkins: re positioning: k. anything on the radar for that? |
| 22:47 | <JonathanNeal> | To whomever it concerns, I have filed my latest element query pleas @ http://discourse.specifiction.org/t/element-queries/26/last |
| 22:54 | <TabAtkins> | Hixie: Nope, nothing right now. I have plans, but no timeline for achieving them. |
| 22:54 | <Hixie> | k |
| 22:56 | <Domenic> | http://gridstylesheets.org/ is a related prolyfill/ideation exercise |
| 22:57 | <Domenic> | i want to try it on a small project and see how i feel afterward |
| 22:57 | <Domenic> | i could easily see it either being "wow this is amazing we must have this" or "meh that really doesn't work in practice, nice try" |
| 23:09 | <JonathanNeal> | Domenic: were you the one who replied to me? |
| 23:10 | <JonathanNeal> | If it was, I appreciate you citing TabAtkins’ blog as the canonical reply. But, at the same time, arrrrr! I had a bunch of links in my post, but discourse doesn’t let me add more than one or two. |
| 23:18 | <zewt> | are clipboard events those sort of broken ancient events that have side-effects when fired from script (like click)? |
| 23:19 | <zewt> | it doesn't seem like they are in testing, but hallvord implied that they are on the list (and he's apparently the editor of the clipboard spec) |
| 23:24 | <JonathanNeal> | Domenic: re: gss, it’s amazing that we can think up entirely different ways to write stylesheets, and its best marketing is still “now you can vertically center something” |
| 23:31 | <gsnedders> | Okay then, to continue my questioning from yesterday: which Chromebook do I want? Given they basically all have 1366x768 displays, I guess there's no point in going for one of the larger ones? AFAICT, the HP Chromebook 11 seems to have the best screen of them, but it does have a now ancient SoC in it… |
| 23:38 | <JonathanNeal> | gsnedders: that sounds all right. I’m very productive on 1440x900. |
| 23:41 | gsnedders | vaguely wonders about selling his tablet |
| 23:41 | <gsnedders> | I just don't use it that much… |
| 23:50 | <JonathanNeal> | gsnedders: i used mine for one project, and my 1 year old found a better use for it, namely the tinkerbell film series. |
| 23:52 | <gsnedders> | All the Chromebooks seem to be somewhat flawed. The HP Chromebook 11 has a wonderful screen, but opinions are mixed on the keyboard, and apparently performance isn't brilliant with a few tabs open… On the other hand, the Dell Chromebook 11 has a less good screen but better everything else… |