| 00:00 | <TabAtkins> | Your first mistake was the argument of everything that optionally takes a path. |
| 00:00 | <cabanier> | for (x, y) it becomes (x, y. fillrule) |
| 00:00 | <Hixie> | constraining this, is that implementations have already implemented (x, y) and (x, y, fillRule) |
| 00:00 | <cabanier> | yes |
| 00:00 | <Hixie> | so (path, fillRule, x, y) would be ugly |
| 00:00 | <TabAtkins> | Position should, generally, be a unique identifier for the argument. Overloading on argument list length to give different positions different meanings is a bad idea. |
| 00:00 | <Hixie> | but (path, x, y, fillRule) is even worse... |
| 00:00 | <zewt> | optional arguments at the beginning are evil |
| 00:00 | <TabAtkins> | You should have fallen down to options objects earlier. |
| 00:01 | <Hixie> | TabAtkins: too late for that now... |
| 00:01 | <TabAtkins> | zewt: No, optional arguments have their place, when they're truly optional, and are chained-optional (that is, you never want to provide the second optional argument without specifying the first). |
| 00:01 | <cabanier> | I hope those path methods will go away |
| 00:01 | <TabAtkins> | Hixie: Is it? Do we have implementations? |
| 00:01 | <cabanier> | noone implemented them |
| 00:01 | <krit> | Hixie: Blink and WebKit use currentPath to share path objects |
| 00:01 | <zewt> | TabAtkins: ... that's optional arguments at the end |
| 00:01 | <Hixie> | (and i don't generally agree. the first argument of something like this should always be the main thing you're operating on, imho) |
| 00:02 | <krit> | Hixie: you can just set the currentPath with the path you want |
| 00:02 | <krit> | Hixie: and then ask the context |
| 00:02 | <Hixie> | krit: ew |
| 00:02 | <Hixie> | krit: that's even worse :-) |
| 00:02 | <krit> | Hixie: at the moment it is not nice, that is where cabanier's proposal comes in |
| 00:03 | <lecuyer> | TabAtkins: qq about padding-bottom. Is it supposed to be relative to the actual width of the element, or the available width around the element (in the case of max-width)? |
| 00:03 | <krit> | Hixie: for WebKit and Blink, Path is just a storage of Path segments |
| 00:03 | <TabAtkins> | zewt: Yes, if you have optional arguments not at the end, you're doing things wrong. ^_^ |
| 00:03 | <krit> | Hixie: nothing more |
| 00:03 | <TabAtkins> | lecuyer: Whatever the spec says - I dont' remember off the top of my head. |
| 00:03 | <Hixie> | krit: right, same in the spec |
| 00:03 | <zewt> | TabAtkins: ... but i said "optional arguments at the beginning". heh |
| 00:03 | <Hixie> | krit: it's the "currentPath" thing that's ugly :-) |
| 00:03 | <TabAtkins> | zewt: ...I didn't see that part of your comment. Apologies. |
| 00:04 | <zewt> | TabAtkins: option objects and language-level named arguments can complement each other nicely, eg. Python's **args |
| 00:04 | <TabAtkins> | Yes, if you have it. |
| 00:04 | <krit> | Hixie: well, it is more than that |
| 00:04 | <cabanier> | Hixie: currentpath is just an opaque holder of a bunch of path operations |
| 00:04 | <krit> | Hixie: you have path . http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-path-addpathbystrokingpath |
| 00:04 | <TabAtkins> | zewt: It would be nice to pursue, in a future ES version, Pythonic named arguments. |
| 00:04 | krit | hates link replacing |
| 00:04 | <lecuyer> | I've found in implementation it's usually implemented as the latter, but it'd be nice if it wasn't. |
| 00:04 | <TabAtkins> | (though you need a different syntax than Python, as that syntax is already allowed and means something different in JS) |
| 00:05 | <Hixie> | krit: addPathByStrokingPath is just a way to add more path segments |
| 00:05 | <TabAtkins> | lecuyer: Can't change it. |
| 00:05 | <krit> | Hixie: sure, but not always implementable |
| 00:05 | <cabanier> | Hixie: the output of that is undefined |
| 00:06 | <Hixie> | ? |
| 00:06 | <Hixie> | how so |
| 00:06 | <cabanier> | Hixie: probably not what you want |
| 00:06 | <krit> | Hixie: or better there just exist some propritary libs that can do that |
| 00:06 | <Hixie> | the spec defines it in great detail... |
| 00:06 | <lecuyer> | It says in the spec that it's relative to the width of the element, but given that everyone seems to have gotten it wrong I was wondering if they didn't :) |
| 00:06 | <cabanier> | Hixie: as currently defined, the path segments will overlap and caused all sort of drawing issues |
| 00:06 | <krit> | Hixie: you usually don't want to fullfill tasks of graphics libraries in browsers |
| 00:06 | <Hixie> | well, depends what you want, obviously |
| 00:06 | <cabanier> | :-) |
| 00:07 | <cabanier> | I'd expect it to render as if I stroked the path |
| 00:07 | <zewt> | krit: s/you/i/ |
| 00:07 | <Hixie> | well that gets back to the thing we were talking about earlier |
| 00:07 | <Hixie> | which lacks a specification |
| 00:07 | <cabanier> | and not get unpainted areas where the strokes meet |
| 00:07 | <cabanier> | that one is actually spec-able |
| 00:08 | <cabanier> | it's stroking of shapes/combined path which is hard |
| 00:08 | <zewt> | there's quite a lot of "graphics library" tasks in browsers, heh |
| 00:08 | <TabAtkins> | lecuyer: I don't know where you're seeing that it's relative to the width of the element. The CSS 2.1 spec defines percentages in padding to "refer to the width of containing block". |
| 00:08 | <cabanier> | since they don't have a 'start' point any more |
| 00:08 | <krit> | zewt: you as an content author may wish that. I am indeed talking as an implementer |
| 00:08 | <Hixie> | cabanier: everything is spec-able, it just needs to be specced |
| 00:08 | <zewt> | krit: you're a bit late (re: canvas, webgl, css filters) |
| 00:09 | <lecuyer> | TabAtkins: sorry, I must have misread it |
| 00:09 | <krit> | zewt: I don't see the context in your list |
| 00:09 | <cabanier> | Hixie: we *could* spec the planarization algorithm in detail |
| 00:09 | <zewt> | those are all things that overlap with graphics libraries, of course |
| 00:09 | <krit> | right |
| 00:10 | <Hixie> | cabanier: gonna have to if we want it implemented interoperably |
| 00:10 | <zewt> | there are things that are better done in script, of course, but that's a bit more specific than "tasks of graphics libraries" |
| 00:10 | <cabanier> | Hixie: that would be a massive undertaking though. the skia folks can likely provide the algorithm |
| 00:10 | <krit> | zewt: and none of them need path planarization |
| 00:10 | <TabAtkins> | lecuyer: No problem. |
| 00:10 | <Hixie> | cabanier: massive undertakings are what we do |
| 00:11 | <Hixie> | cabanier: that's what distinguishes the web platform from other platforms |
| 00:11 | <cabanier> | Hixie: well, not letting you stroke a union/intersect/xor path will make it a lot easier |
| 00:11 | <cabanier> | Hixie: I need to think a bit more about it |
| 00:12 | <krit> | Hixie: and things like addText require access to font data, which some browsers can't or are not willing to implement (independent of the path planarization discussion of cabanier) |
| 00:13 | <krit> | Hixie: Path planarization is not only very hard to specify, it is also very hard to implement |
| 00:13 | <Hixie> | krit: well, again... :-) |
| 00:13 | <Hixie> | "it |
| 00:13 | <krit> | Hixie: even harder to implement in a interopearable way |
| 00:13 | <Hixie> | er |
| 00:13 | <Hixie> | "it's hard" is not a good argument against doing something :-) |
| 00:13 | <cabanier> | Hixie: very true! |
| 00:14 | <krit> | Hixie: browsers also rely on the path data of the geraphic library |
| 00:14 | <krit> | Hixie: the path data does not reflect what you put into the lib usually |
| 00:14 | <cabanier> | Hixie: it needs to be done somehow. I think the *actual* algorithm doesn't need to be specified. Just how it supposed to work (find intersections, fix winding, remove shared lines, etc) |
| 00:14 | <krit> | Hixie: arc is not an arc in path data but cubic or quadratic curves |
| 00:15 | <Hixie> | cabanier: so long as it's unambiguous under all situations, whether it's defined imperatively or declaratively is just an editorial choice |
| 00:15 | <krit> | cabanier: it just is not really implementable in an interoperable way as long as browsers don't fundamentaly change the way they use Canvas paths |
| 00:15 | <Hixie> | cabanier: i usually do things imperatively because it's easier to reason about whether things are defined unambiguously |
| 00:16 | <krit> | and I don't see any need to lift up path representation to the browser from the graphic library |
| 00:16 | <cabanier> | hixie: yeah. That should be doable. |
| 00:16 | <cabanier> | krit: noone can figure out that an arc became a set of bezier though. There's no access to that |
| 00:16 | <cabanier> | (nor should there be) |
| 00:17 | <krit> | cabanier: that is correct, but this planarization requires it |
| 00:17 | <krit> | cabanier: a requirement from adding paths |
| 00:17 | <cabanier> | krit: don't think so |
| 00:17 | <krit> | cabanier: it does if you want to follow an algorithm |
| 00:17 | <krit> | cabanier: I am not even sure if all path segment primitives are supported by the canvas spec |
| 00:18 | <Hixie> | krit: the algorithms in specs aren't prescriptive of how you implement something |
| 00:18 | <cabanier> | krit: they're all path segments that potentially intersect |
| 00:18 | <krit> | cabanier: that are used by graphics libraries |
| 00:18 | <Hixie> | krit: they're just sample algorithms of black boxes |
| 00:18 | <Hixie> | krit: all that matters is that the inputs and outputs match |
| 00:18 | <Hixie> | krit: for all inputs |
| 00:18 | <krit> | Hixie: true |
| 00:19 | <krit> | Hixie: I care more about performance and interoperability in this case |
| 00:20 | <cabanier> | krit: is performance an issue for the spec? |
| 00:20 | <krit> | Hixie: A different approach where you don't have the access to the path (implementation wise) seems to be less error prone |
| 00:20 | <krit> | cabanier: for sure not, but it is for implementations and authors |
| 00:20 | <cabanier> | krit: yes |
| 00:21 | <Hixie> | krit: not sure what you're arguing, we seem to be in agreement :-) |
| 00:21 | <krit> | Hixie: not when it comes to styled paths |
| 00:22 | <cabanier> | Hixie: I will update my proposal and send it out to the list again |
| 00:22 | <krit> | Hixie: this is what addPathByStrokeingPath makes it cimplicated |
| 00:22 | <cabanier> | krit: that one should be fixed |
| 00:22 | <krit> | cabanier: fixed? |
| 00:22 | <cabanier> | replaced with something else |
| 00:23 | <krit> | cabanier: if you want to have the path along a styled path, it mostly requires path access |
| 00:23 | <krit> | cabanier: (of course not in all cases) |
| 00:23 | <cabanier> | krit: going to dinner now :-) |
| 00:23 | <cabanier> | krit: we can talk about it later |
| 00:23 | <krit> | cabanier: but definitely with pointInPath for instance |
| 00:24 | <Hixie> | krit: i don't have any trouble saying the browsers should have path access |
| 00:24 | <krit> | Hixie: Yes, but this brings the implementation complexity up from the graphic library to the browser |
| 00:24 | <krit> | Hixie: (at least at the moment) |
| 00:24 | <Hixie> | krit: i don't see why we would distinguish between "graphics library" and "browser" |
| 00:25 | <krit> | Hixie: Because implementations (talking about WebKit, Blink and Gecko) build on top of the path handling of the graphic library |
| 00:26 | <Hixie> | krit: so? |
| 00:26 | <Hixie> | krit: the libraries can change... |
| 00:26 | <krit> | Hixie: especially dash array and things like that influence hit testing and all that needs to be integrated when you apply styled paths |
| 00:26 | <krit> | Hixie: sure, as long as they don't, you require browsers to do the job currently done by graphics libraries |
| 00:27 | <Hixie> | krit: again, i don't understand the distinction or why that would be a problem. |
| 00:27 | <Hixie> | krit: that's like saying "browsers will have to do the job of XML parsers" |
| 00:27 | <Hixie> | krit: or "browsers will have to do the job of character encoding libraries" |
| 00:27 | <Hixie> | well, yes |
| 00:27 | <Hixie> | welcome to being a browser |
| 00:27 | <krit> | Hixie: which they don't do either. They rely on libs for that |
| 00:27 | <Hixie> | yeah... no |
| 00:28 | <krit> | Hixie: no for HMTL parser |
| 00:28 | <Hixie> | at least, not off-the-shelf libraries |
| 00:28 | <Hixie> | (then again, as far as i can tell, they all have their own graphics libraries these days too) |
| 00:30 | <krit> | Hixie: the reason why I don't want the browser to do the job is redundancy (the represenation still needs to be done by the graphic library), performance (all the things need to match expectations of authors or they don't use it), interoperability (which is hard to reach on differen starting points the browsers are), implementation complexity (which is hard to maintain and extremely error prone, after all we are browser vendors and no algebra experts) |
| 00:31 | <Hixie> | krit: you keep referring to the graphics library as a separate concept from the browser. it need not be. just view it as one unit of software. |
| 00:32 | <Hixie> | krit: even if implemented in a modular reusable fashion, the graphics "library" can provide exactly the api the browser needs |
| 00:32 | <Hixie> | krit: to do whatever we want it to do |
| 00:32 | <krit> | Hixie: yes of course it doesn't need to be, but it is at the moment for very good reasons |
| 00:33 | <Hixie> | krit: as far as i can tell, all browsers have dedicated graphics libraries under the control of the same development team, not off-the-shelf libraries. |
| 00:33 | <Hixie> | krit: so i disagree |
| 00:34 | <krit> | Hixie: that is not true. So far it is JUST Google that has that |
| 00:34 | <Hixie> | at least google, microsoft, and apple. |
| 00:34 | <krit> | Hixie: Mozilla relies on Cairo/DirectX/maybe Skia, WebKit is based on a lot of graph libs where the browser team does not have influence on the grpahic lib teams. |
| 00:34 | <krit> | Hixie: MS and Apple just in theory :) |
| 00:36 | <Hixie> | i have no problem with the idea that browsers will heavily influence how their graphics engine develops |
| 00:36 | <krit> | Hixie: Google's Chrome/Blink tool is the only team that has direct control on the development of their graphic library |
| 00:37 | <krit> | Hixie: That is ok from the spec author point of view. I am talking from the implementer point of view. |
| 00:38 | <Hixie> | i am too |
| 00:39 | <Hixie> | as implementors, we've taken over the encoding libraries, parsing libraries, all kinds of stuff |
| 00:39 | <Hixie> | UI widget libraries |
| 00:39 | <Hixie> | we've reimplemented accessibility layers |
| 00:39 | <Hixie> | we hook into the OS input layer much higher than most apps |
| 00:39 | <Hixie> | or lower, i guess |
| 00:40 | <Hixie> | graphics is just the next obvious one that will need to be assimilated to get optimal performance |
| 00:40 | <Hixie> | we have our own scripting engines |
| 00:40 | <Hixie> | we have our own memory management routines |
| 00:40 | <Hixie> | we have our own string implementations |
| 01:17 | <TabAtkins> | Ugh, simple bash question. I want to pass all bash function arguments to a python script. How to do? |
| 01:17 | <TabAtkins> | I can easily pass *individual* arguments with $1 or whatever, but can't figure out how to do all of them. |
| 01:18 | <heycam> | "$@" |
| 01:18 | <TabAtkins> | Hah, just now foudn that. |
| 01:18 | <TabAtkins> | Was hidden in one of the google results that didn't look helpful at first glance. |
| 01:18 | <heycam> | searching for shell script syntax is… not an easy thing |
| 01:19 | <TabAtkins> | Indeed. |
| 01:20 | <TabAtkins> | I'm trying to make a python script that can change the shell directory. Looks like best way is to have the script echo the path, and have a bash function cd to that. |
| 01:58 | <krit> | Hixie: I am sorry, I didn't see your reply. Each of these features have been checked for positive and negative effects. And this will continue, even with Paths. In WebKit we had to do this choices multiple times. For SVG we decided to cover the data in the browser to support certain features that are required by SVG 1.1. The Blink investigates in reverse this decision and use the capabilities of the graphic library instead again. (As you noted befor |
| 02:07 | <birtles> | are there any guidelines regarding throwing exceptions from constructors in Web APIs? |
| 02:47 | <cabanier> | Hixie: I agree with your points about the browser vs graphics libraries. |
| 07:17 | <sangwhan_> | I assume no NSS maintainers are in this chat? |
| 07:19 | sangwhan_ | takes that as a yes |
| 07:21 | <Ms2ger> | Doubt it |
| 07:32 | <Ms2ger> | http://w3cmemes.tumblr.com/post/48861166006/does-anyone-want-to-put-their-hand-up-and-help |
| 09:50 | <annevk> | MikeSmith: fwiw, https://wiki.mozilla.org/WebAPI/KeboardIME |
| 11:07 | <MikeSmith> | annevk: thanks |
| 11:07 | MikeSmith | reads |
| 11:08 | <MikeSmith> | annevk: interesting |
| 11:08 | <annevk> | MikeSmith: my rough understanding is that we want an API that allows implementing an IME from scratch |
| 11:08 | <MikeSmith> | hmm |
| 11:08 | <MikeSmith> | so we talked here yesterday about that |
| 11:08 | <MikeSmith> | with James Craig and Dominic Manzonni |
| 11:09 | <MikeSmith> | Dominic Mazzoni |
| 11:09 | <MikeSmith> | my understanding from talking with them is that you're not going to be able to make that accessible |
| 11:10 | <MikeSmith> | they pointed out that e.g., CodeMirror and Cloud9/ACE etc. are not accessible to screen-reader/AT users |
| 11:12 | <annevk> | I guess that would depend on what primitives you expose no? |
| 11:12 | <annevk> | But this is not my area of expertise at all. |
| 11:13 | <annevk> | I just know this is in the works... |
| 11:14 | <MikeSmith> | annevk: ok |
| 11:15 | <MikeSmith> | I see the history of that wiki page shows Yuan Xuleia |
| 11:16 | <MikeSmith> | I would hope that whoever is working it would post feedback or an alternate proposal to public-webapps |
| 11:16 | <MikeSmith> | feedback on the existing IME API draft that's been published |
| 11:18 | <annevk> | Yeah I suggested they do that somewhere |
| 11:18 | <MikeSmith> | k |
| 11:26 | <annevk> | lol |
| 11:27 | <annevk> | The minutes mention dropping keyboard events from DOM3 |
| 11:27 | <annevk> | Which makes sense... but... at what point is someone going to step up and just define the user interaction model already? |
| 11:27 | <annevk> | Is there some kind of benefit to keeping the details and have everyone run in circles? |
| 11:28 | <MikeSmith> | that stuff I've not been following |
| 11:28 | <MikeSmith> | I think I was actually sleeping during that discussion |
| 11:29 | <annevk> | It makes more sense to sleep, since we're not really any further than we were 10 years ago on that subject. |
| 11:30 | <annevk> | And a WebApps WG meeting full of people not interested in doing too much work is not going to change that. |
| 11:34 | <jgraham> | One of the sad truths of life is that it is easy to get money for people to go to meetings and hard to get money for people to do actual work. PAying for 100 people to attend a four day meeting costs the same as employing someone like annevk or Hixie for a year. |
| 11:35 | <smaug____> | annevk: keyevents will not be dropped from DOM3 |
| 11:36 | <smaug____> | it was just discussed |
| 11:36 | <SimonSapin> | annevk: So you’re worth 400 days of work a year :) |
| 11:36 | <smaug____> | and someone mentioned that then the same what happened with D2 would happen with D3 |
| 11:37 | <smaug____> | jgraham: it is hard to find people to write specs |
| 11:37 | <smaug____> | and almost as hard to find people to review specs :) |
| 11:38 | <smaug____> | and someone should write tests too |
| 11:38 | <jgraham> | and someone should review tests :) |
| 11:40 | <Ms2ger> | Fortunately people are happy to implement things |
| 11:41 | <smaug____> | it is easier to find people to implement things |
| 11:41 | <smaug____> | (people should review the specs when implementing them, but that doesn't always or usually happen) |
| 11:42 | <jgraham> | It's not just that |
| 11:42 | <jgraham> | It's that people understand the model of employing people to implement stuff |
| 11:44 | <jgraham> | Or, at least, the benefits of paying people to implement stuff are obvious and short-term |
| 11:44 | <jgraham> | You get more stuff, faster |
| 11:44 | <jgraham> | The benefits of paying people to work on writing specs or tests are less obvious, and suffer more from "tragedy of the commons" effects |
| 11:53 | <hallvors> | is annevk around? |
| 11:59 | <zcorpan> | so we have HTML defining HTMLElement#style, SVG defining SVGElement#style and CSSOM defining ElementCSSInlineStyle#style (which "is implemented by Element objects"), and they're all different |
| 12:00 | <Ms2ger> | Of course |
| 12:01 | <zcorpan> | i guess i should fix ElementCSSInlineStyle#style and make the HTML and SVG specs say (HTML|SVG)Element implements ElementCSSInlineStyle |
| 12:02 | <zcorpan> | wonder why SVG doesn't require CSS support |
| 12:05 | <zcorpan> | what's the right thing when CSS isn't supported? Should .style be absent? or return null? |
| 12:06 | <zcorpan> | absent seems better |
| 12:06 | <Ms2ger> | In that case, I don't think any of the interfaces in cssom should exist |
| 12:06 | <zcorpan> | yeah |
| 12:12 | <SimonSapin> | Doesn’t SVG2 require CSS support? Or did I make that up? |
| 12:17 | <jgraham> | Does SVG2 exist in any meaningful sense? |
| 12:26 | <annevk> | hallvors: am now |
| 12:27 | <hallvors> | great, have a question |
| 12:27 | <hallvors> | I'm looking over the XHR tests, fixing some bugs |
| 12:28 | <hallvors> | main question is: has the spec changed to "fire readystatechange only when readyState actually changes" or not? |
| 12:28 | <hallvors> | I think it has.. and trying to read the processing steps, I can't find any place we don't.. |
| 12:28 | <hallvors> | but it's a bit hard to follow all the steps.. |
| 12:29 | <annevk> | not if abort() sets it to UNSENT |
| 12:29 | <annevk> | but yeah, I remember one event for send() has been removed |
| 12:30 | <hallvors> | so expected outcome of http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/open-open-sync-send.htm and similar tests should be aligned.. |
| 12:31 | <annevk> | https://github.com/whatwg/xhr/commit/15e86b74b03b9bb80186d6edfa8be091d2312522 was over a year ago it seems |
| 12:31 | <hallvors> | Opera (Presto) and Chrome mostly agree with that new model, Firefox doesn't |
| 12:32 | <annevk> | yeah, so says my associated email |
| 12:32 | <hallvors> | Cool, will fix the tests. Only a year late :) |
| 12:32 | <hallvors> | Thanks for confirming ;) |
| 12:32 | <annevk> | great |
| 12:41 | <hallvors> | annevk: if you're still here :) by my reading of the spec (in its current state), this test should do assert_throws : http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/open-url-multi-window-2.htm |
| 12:42 | <hallvors> | (creates XHR from IFRAME window, removes IFRAME from parent before open()) |
| 12:44 | <annevk> | yeah, the document would not be fully active |
| 12:44 | <annevk> | same if you navigate the iframe |
| 12:46 | <annevk> | well, I think that's how it's defined; navigation and multiple browsing contexts is unfortunately still somewhat hairy |
| 12:57 | <zcorpan> | why does http://www.w3.org/TR/SVG2/types.html#InterfaceSVGElement have xmlbase, xmllang, xmlspace? isn't that a bit of layering violation? |
| 12:58 | <Ms2ger> | Poke heycam :) |
| 12:59 | <annevk> | SVG is full of those |
| 12:59 | <annevk> | Ms2ger: nah, please let him focus on IDL stuff |
| 12:59 | <Ms2ger> | Mm |
| 13:00 | <Ms2ger> | Find someone else to poke, then :) |
| 13:00 | <annevk> | Ms2ger? |
| 13:00 | Ms2ger | pokes annevk back |
| 13:01 | <annevk> | should've raised shield |
| 13:28 | <annevk> | So seems like request takes yet another fricking flag :( |
| 13:29 | <annevk> | The "use URL credentials flag" |
| 13:36 | <zcorpan> | i sent an email to www-svg |
| 13:51 | <annevk> | I hope once I've defined all this sometime will point out a way to reduce the flags |
| 13:51 | <annevk> | sometime, someone, either way |
| 13:58 | <hallvors> | hm.. I have no idea what the pass condition for http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/open-url-multi-window-4.htm should be |
| 14:02 | <hallvors> | Firefox, Opera (Presto): terminate request with no further events when IFRAME is removed. Chrome: completes request to readyState=4 but responseText is "" so it's pretty much terminated with an extra event for "DONE" state |
| 14:03 | <hallvors> | annevk: thoughts? |
| 14:07 | <annevk> | hallvors: in a bit |
| 14:07 | <annevk> | like 40min |
| 14:07 | <zcorpan> | ok have a nice weekend guys |
| 14:08 | <hallvors> | annevk: probably won't be here in 40min, could you just post your thoughts here anyway and paste the discussion that occurs in an E-mail to me? ;-) |
| 14:12 | <Ms2ger> | I found a picture for the fetch spec: http://bit.ly/13zyutD |
| 14:41 | <annevk> | hallvors: so I think that should actually just work |
| 14:42 | <annevk> | hallvors: the base URL and everything is established, there's no reason for it to fail if implementations follow the spec (harhar) |
| 16:18 | <matjas> | annevk: i was looking at http://mimesniff.spec.whatwg.org/#determining-the-sniffed-media-type-of-a-resource and figured that Step 5 would apply there, no? |
| 16:19 | <Ms2ger> | WebApps discussing licensing and c/p'ing specs again \o/ |
| 16:19 | <annevk> | matjas: yeah that's the culprit |
| 16:21 | <matjas> | so iOS Safari violates the spec, hence my tweet \o/ glad i looked it up before tweeting (and glad i understood correctly) |
| 16:22 | <annevk> | matjas: I doubt many people got that subtlety though |
| 16:22 | <annevk> | and the guy complaining didn't mention that document |
| 16:22 | <annevk> | so he might not have realized his exact byte sequence for "Content-Type: text/plain" is what causes other browsers not to sniff |
| 16:24 | <annevk> | ah you did |
| 16:42 | <MikeSmith> | hober, divya - so I have a flight out tonight at 23:45 from SFO. So we could meet up from dinner if yall have time |
| 16:45 | <hober> | MikeSmith divya: that might work for me; i'll check with erin |
| 16:47 | <divya> | MikeSmith: YA! |
| 16:47 | <divya> | MikeSmith: hober what time? |
| 16:48 | <divya> | i hav something at 7.30 |
| 16:48 | <hober> | MikeSmith divya: there's also an indieweb meetup of some kind, maybe tantek can fill us in |
| 16:53 | <divya> | hober: can you message me when you know better. i am on and off irc |
| 16:53 | <divya> | MikeSmith: do you have us number? |
| 16:53 | <divya> | MikeSmith: else DM me on twitters |
| 16:54 | <MikeSmith> | divya: +81-80-2387-5995 |
| 16:55 | <annevk> | people reading the logs, you can now bug MikeSmith day and night |
| 16:55 | <divya> | MikeSmith: thnx! |
| 16:55 | <divya> | ahahahahha |
| 16:55 | Ms2ger | fires up his address book |
| 17:13 | <tantek> | hober, MikeSmith see indiewebcamp.com/events |
| 17:22 | <MikeSmith> | tantek: thanks |
| 17:22 | <TabAtkins> | zcorpan: SVG requires CSS support in practice. In 1.1 they were loathe to codify that, but if it's not already in SVG2, it's only because someone hasn't gotten to it yet. |
| 17:22 | <annevk> | morning tantek |
| 17:22 | <annevk> | and morning TabAtkins |
| 17:23 | <TabAtkins> | Yo. |
| 17:23 | <TabAtkins> | annevk: I think you lied to me! |
| 17:23 | <annevk> | autocomplete... |
| 17:23 | <annevk> | TabAtkins: I try |
| 17:23 | <annevk> | TabAtkins: did it work? |
| 17:23 | <TabAtkins> | About Futures not recursively unwrapping. |
| 17:24 | <TabAtkins> | Ie Future.accept(Future.accept(5)).then(console.log) logging "<object Future>" rather than "5". |
| 17:24 | <annevk> | pretty sure that if you do Future.accept(Future.accept(5)).then((x) => alert(x)) will alert a future |
| 17:24 | <TabAtkins> | I find it really hard to follow the spec algorithm, but Domenic (from Promises/A+ standardization fame) asserts that you won't. |
| 17:25 | <annevk> | I think because you confuse Future.accept with Future.accept |
| 17:25 | <annevk> | lol |
| 17:25 | <TabAtkins> | I... I see. |
| 17:25 | <annevk> | Future.resolve with Future.accept |
| 17:25 | <TabAtkins> | Heh. |
| 17:25 | <TabAtkins> | Not that I know of. There's a bunch of "use the resolver's resolve algorithm" sprinkled about that I think means Domenic is right. |
| 17:26 | <annevk> | oh generally futures use resolve, but you can do accept if you want to |
| 17:27 | <TabAtkins> | Yes, of course. The point is whether calling .then() recursively unwraps its calling value. (Or its callback's return value.) |
| 17:27 | <annevk> | then does nothing with the value it's passed |
| 17:27 | <annevk> | it does something with the return value sure |
| 17:27 | <annevk> | but in that thread you guys were discussing Future.resolve |
| 17:28 | <TabAtkins> | Ah, wait, I see the problem. There is one place where you're doing the wrong thing. |
| 17:28 | <TabAtkins> | If the first callback to .then() is omitted, you use the resolver's resolve algorithm instead. That should be the accept algorithm. |
| 17:29 | <TabAtkins> | The signature of the callback should be (a) => (a or Future<a>). The resolve algorithm's signature is (Future<a>) => (Future<a>). You want accept, which is (a) => (Future<a>). |
| 17:29 | <annevk> | ooh, if you omit callbacks |
| 17:29 | <annevk> | hmm |
| 17:29 | <TabAtkins> | (Well, resolve is (a or Future<a>) => (Future<a>).) |
| 17:30 | <TabAtkins> | (Coercing the (a) case into a Future<a>.) |
| 17:32 | <annevk> | so yeah, I guess it makes sense to change that |
| 17:40 | <annevk> | "zero process copyright" if I reorder some of my URL slugs, I hope that changes soon |
| 17:40 | <TabAtkins> | Hm? |
| 17:41 | <annevk> | Oh, someone just asked me about the W3C and URLs so I gave him http://annevankesteren.nl/2013/03/zero http://annevankesteren.nl/2012/11/copyright http://annevankesteren.nl/2012/11/process and then re-ordered the last words a bit |
| 17:42 | <annevk> | I swear, it all makes sense in my head :p |
| 17:43 | <TabAtkins> | Heh. ^_^ |
| 17:53 | <annevk> | jsbell: not defining order of exceptions anno 2013 is sad |
| 17:54 | <annevk> | shame on ReSpec (and Indexed DB) |
| 17:54 | <jsbell> | annevk: Don't blame ReSpec |
| 17:55 | Ms2ger | blames jsbell |
| 17:56 | <jsbell> | :) |
| 17:56 | <annevk> | jsbell: it was one of the reasons initially given, pretty sure if that limitation had not been there it would've been fixed a year ago |
| 17:56 | <Ms2ger> | And the IE team |
| 17:56 | <annevk> | jsbell: Microsoft stalling is of course not helping |
| 17:56 | <annevk> | jsbell: but that's a year later, and well, they always do that |
| 17:57 | <jsbell> | I have my opinions on this one, but it's not a sword I was willing to fall on. |
| 17:57 | <Ms2ger> | Implementing a given order would have taken an order of magnitude less time than the time that has been wasted by the stop energy |
| 17:58 | <jsbell> | Ms2ger: no argument. |
| 17:58 | <jsbell> | Shame not all browsers ship so frequently. :P |
| 17:58 | <Ms2ger> | And to make that even worse, I shall keep beating this dead horse for the rest of the evening! |
| 17:59 | <jsbell> | Ms2ger: make yourself useful and go add Futures to some random spec. ;-) |
| 17:59 | <Ms2ger> | That's annevk's job |
| 18:00 | <annevk> | Ms2ger: dude btw, how did they come to the conclusion DOM Parsing and Serialization was pretty much done?! |
| 18:00 | <Ms2ger> | I was too shocked to reply |
| 18:01 | <annevk> | I see |
| 18:02 | <annevk> | I wonder why tantek attends these support group meetings but refuses to engage in the much more productive support forum discussions. |
| 18:05 | <hober> | hahahaha |
| 18:21 | <tantek> | annevk - in person human to human communications often have higher bandwidth than various support fora and are also a good source of serendipitous 1:1 conversations that can sometimes be orders of magnitude more time-efficient than text media. |
| 18:22 | <tantek> | also, fewer (like very few) crazy armchair-spec-commenters show up in in-person meetings, in contrast to online support fora which are often overwhelmed with them. |
| 18:22 | <TabAtkins> | *forums |
| 18:23 | <Ms2ger> | *fora |
| 18:23 | <TabAtkins> | *This isn't Latin. |
| 18:23 | <TabAtkins> | *And if it was, you're doing it wrong. |
| 18:25 | <annevk> | tantek: I've read the minutes. It looks like a waste of time. |
| 18:25 | <annevk> | "XHR level 1 would be useful" mahahaha |
| 18:25 | <annevk> | It's even wasting my time now |
| 18:30 | <tantek> | annevk - the minutes are, well, a rough approximation, like an outline |
| 18:31 | <tantek> | so yeah - I wouldn't expect them to be much worth your time |
| 18:31 | <tantek> | a lot is communicated in subtle tone of voice, body language etc. that helps set context for the spoken words, only a subset of which are written into the minutes |
| 18:31 | <tantek> | interesting to see who really cares (doesn't care) about what |
| 18:32 | <annevk> | tantek: I've attended the meetings as well in the past. They were generally not worth it. Having focused meetings with a few people works though. |
| 18:32 | <tantek> | focused meetings with a few people do tend to be higher value, no disagreement there |
| 18:32 | <tantek> | interesting thing (which I think got minuted) |
| 18:33 | <tantek> | a set of editors have somewhat threatened to go on strike unless webapps switches to a liberal license |
| 18:33 | <tantek> | so if I can help move that along, the attendance at the meeting will be worth it |
| 18:33 | <tantek> | same reason I'm (likely) running for the AB |
| 18:35 | <annevk> | They'd be welcome here I'm sure |
| 18:35 | <annevk> | I only saw the suggestion from darobin |
| 18:35 | <tantek> | yeah that - from darobin |
| 18:38 | <annevk> | That was quickly followed by Chaals being happy to plagiarise the URL spec |
| 18:42 | <tantek> | annevk - plagiarism is one of the problems I'd like to address at W3C |
| 18:47 | <lecuyer> | TabAtkins: what part of the future spec would resolve(Future<Foo>) return Future<Foo>? It makes sense, I'm just not seeing it. Is that the [[Call]] on `then`? |
| 18:50 | <tantek> | annevk: re: "I've attended the meetings as well in the past. They were generally not worth it." not true at all, I mean just last year, if you hadn't attended HTML/WebApps f2f, we wouldn't have http://w3cmemes.tumblr.com/ |
| 18:50 | <annevk> | lecuyer: if you use resolve it'll return Foo |
| 18:50 | <annevk> | lecuyer: but it seems like there's a bug at the moment |
| 18:50 | <annevk> | tantek: baha :) |
| 18:51 | <tantek> | ;) |
| 18:51 | <jsbell> | This stuff is easy, why aren't we shipping it yet? ;-) |
| 18:52 | <annevk> | jsbell: we're getting close to shipping |
| 18:52 | <lecuyer> | annevk: implementation bugs or spec bugs? |
| 18:52 | <annevk> | spec |
| 18:53 | <tantek> | annevk - shame that http://25.media.tumblr.com/avatar_420f39830dee_128.png is not the first post in w3cmemes |
| 18:54 | <lecuyer> | annevk: are additional prototype implementations welcome to the discussion? |
| 18:55 | <annevk> | lecuyer: don't see why not |
| 18:55 | <divya> | annevk: would your license not make plagarism valid? |
| 18:55 | <divya> | i mean i am not sure why it is a concern if your want your content to be free |
| 18:55 | <annevk> | divya: you're confusing plagiarism with legality |
| 18:56 | <divya> | no i am not talking legal terms at all. |
| 18:56 | <divya> | i thought you want your content to be free. |
| 18:56 | <divya> | but you want credit? |
| 18:56 | <divya> | i dunno |
| 18:57 | <Ms2ger> | divya, nobody's arguing that the W3C is doing something illegal |
| 18:57 | <divya> | Ms2ger: neither am i! |
| 18:57 | <annevk> | The problem with the forks the W3C has done to date is they are not kept up to date and confuse implementers. I'd rather that not happen. Also, forking my work without improving matters is not the reason it's under CC0. |
| 18:57 | <Ms2ger> | divya, only that it's hypocritical |
| 18:57 | <divya> | Ms2ger: ah |
| 18:57 | <divya> | got it. |
| 18:57 | <Ms2ger> | divya, also, unproductive, confusing, and all that |
| 18:57 | <divya> | Ms2ger: yaya got it now. |
| 18:58 | <divya> | but i saw plagarism and got confused. |
| 18:58 | <annevk> | It's under CC0 to spur creativity, not to create confusion. |
| 18:58 | <divya> | all other arguments seem sound to me. |
| 18:59 | <annevk> | Unfortunately I cannot both prevent the W3C from doing stupid stuff while allowing others to do the sane stuff at the same time. Given the choice I'd rather let the W3C do stupid stuff. |
| 19:04 | <tantek> | exactly, just because something is CC0 doesn't make it right to plagiarize |
| 19:04 | <tantek> | plagiarism is unethical, regardless of any license or lack thereof |
| 19:08 | <jsbell> | annevk: http://dom.spec.whatwg.org/#dom-future-any and friends - the append steps reference "resolveCallback" instead of "resolve" and "rejectCallback" instead of "reject" |
| 19:12 | <divya> | ethics is not something worth arguing about |
| 19:13 | <jgraham> | It i true that the meetings are usually the least productive part of TPAC. Coffee breaks: productive. Meals: productive. Evenings in the bar: productive. Meetings: a good time to write tests. |
| 19:13 | <jgraham> | (also the plenary day is typically quite reasonable now) |
| 19:15 | <Ms2ger> | divya, you're not a philosopher? :) |
| 19:15 | <jgraham> | I think the position that "ethics are not something work arguing about" is strongly philosophical |
| 19:16 | <lecuyer> | Ms2ger: Is the real question about whether or not ignoring ethics is itself unethical? |
| 19:17 | <jgraham> | I think it makes divya a moral nihilist |
| 19:20 | <divya> | jgraham: :))))))))))) |
| 19:21 | <divya> | jgraham: you argue my position very well so i think you would be my best representative |
| 19:22 | <divya> | yes i really dont care about morality in the absolute only in terms of the impact of said moral values |
| 19:22 | <jsbell> | annevk: also, in Future.every/some, you might want to be explicit about the index variable being snapshotted for each Function |
| 20:01 | <annevk> | jsbell: fixed |
| 20:48 | <lecuyer> | TabAtkins: any chance of explicit aspect ratios? :) |
| 20:49 | <TabAtkins> | I have a (broken) proposal for it on my blog <http://www.xanthir.com/blog/b4810>;, and I've seen your email, but haven't responded to it yet. |
| 20:51 | <lecuyer> | TabAtkins: I hadn't seen your post, but it's pretty much exactly what I asked for in my email |
| 20:51 | <TabAtkins> | There are some things wrong with my proposal, but I know how to fix them. I just haven't pursued it in a spec yet. |
| 20:52 | <TabAtkins> | I plan to probably put it into the Sizing spec. Dunno whether it'll be this version or the next. |
| 20:58 | <lecuyer> | Awesome, I'm looking forward to it. Would that put it in css4 probably? |
| 20:58 | <lecuyer> | s/css4/sizing level 4/ |
| 21:03 | <TabAtkins> | Yeah, either http://dev.w3.org/csswg/css-sizing/ or the next level of it. |
