| 00:41 | <jyasskin_> | I'm trying to polyfill a spec that says to "throw a /name/ exception", but it looks like DOMException has no constructors, so Javascript can't implement that algorithm? |
| 00:41 | <jyasskin_> | (https://dom.spec.whatwg.org/#concept-throw) |
| 00:43 | <jyasskin_> | annevk: ^ |
| 06:56 | <annevk> | jyasskin_: I think that's no longer my problem as of today |
| 06:56 | <annevk> | jyasskin_: DOMException moved into IDL |
| 06:58 | <Ms2ger> | http://simonsapin.github.io/wtf-8/ |
| 07:00 | <annevk> | SimonSapin: HTML should probably reference URL for that format |
| 07:08 | <annevk> | Domenic: streams.spec.whatwg.org does not look updated for me |
| 07:08 | <annevk> | Domenic: oh I see now, almost |
| 07:09 | <annevk> | cwilso: should probably do that at some point, although watchPosition would ideally use something like streams or observables |
| 09:08 | <SimonSapin> | mathiasbynens: wow, that was fast :) https://github.com/mathiasbynens/wtf-8 |
| 09:09 | <mathiasbynens> | SimonSapin: nice work there |
| 09:10 | <darobin> | indeed, very nice work SimonSapin |
| 09:10 | <mathiasbynens> | SimonSapin: anything particular you’re using WTF-8 in? |
| 09:11 | <SimonSapin> | mathiasbynens: not yet, but planning to for Windows filenames in the Rust standard library, and probably for all DOM strings in Servo |
| 09:11 | <annevk> | SimonSapin: I don't really understand why it doesn't build on Encoding |
| 09:12 | <SimonSapin> | annevk: Encoding by definition deals in scalar values |
| 09:12 | <SimonSapin> | and making a diff spec seemed brittle |
| 09:13 | <SimonSapin> | mathiasbynens: should I call this wtf-8.js? |
| 09:14 | <annevk> | SimonSapin: also, why not "The WTF encodings" as there appear to be two |
| 09:14 | <annevk> | SimonSapin: I would also expect some kind of indication that these are meant for internal use, not for further propagation of non-utf-8 |
| 09:14 | <annevk> | stuff |
| 09:15 | <SimonSapin> | annevk: maybe, only one is interesting, though. I’ve considered not having the WTF-16 name and call it "potentially ill-formed UTF-16", but that was a bit annoying |
| 09:16 | <SimonSapin> | annevk: I’ve put in "must not be used for interchange", but that could be more prominent (and could use a definition of "interchange") |
| 09:18 | <annevk> | "WTF encodings for internal usage of software that must deal with JavaScript strings" |
| 09:18 | <SimonSapin> | in the title? |
| 09:18 | <annevk> | I guess a subtitle |
| 09:18 | <annevk> | or somewhere high up anyway as that's the takeaway of the entire doc |
| 09:18 | <SimonSapin> | mathiasbynens: http://simonsapin.github.io/wtf-8/#implementations |
| 09:19 | <mathiasbynens> | SimonSapin: cool, thanks |
| 09:19 | <mathiasbynens> | SimonSapin: btw you might as well link to the HTTPS version of your spec (GitHub Pages offers that for free) |
| 09:31 | <Ms2ger> | Hah: http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0021.html |
| 09:32 | <Ms2ger> | Now it's apparently Art's fault that TimBL has refused to make his position public |
| 10:27 | <annevk> | Where did he refuse? |
| 10:27 | <annevk> | http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0024.html does seem somewhat incorrect, but I don't think I've all the facts |
| 10:30 | <darobin> | annevk: I think it is "inaccurate by hearsay" but overall not far from the truth |
| 10:31 | <darobin> | and yes, TimBL didn't refuse to make his position public, he actually hadn't seen where the threads that followed had started from |
| 10:31 | <jgraham> | I think the fact that no one has all the facts here is part of the problem, isn't it? |
| 10:31 | <darobin> | said as much during the TAG meeting yesterday |
| 10:31 | <darobin> | damn right |
| 10:31 | <darobin> | jgraham: that said, a lot of the stuff in question is public, it's just scattered |
| 10:32 | <darobin> | anyway, that latter email is clearly an invitation to figuring out a way W3C and WHATWG can be happy together |
| 10:32 | <darobin> | I'd take it :) |
| 10:32 | <darobin> | but that's just me and my flower power |
| 10:33 | <jgraham> | To me it seems like asking Art to apologise for the fact that he acted on what he believed was the position of the director based on conversations with the director's agents seems a bit unreasonable. But I can't follow this. |
| 10:33 | <annevk> | darobin: well it's our FSA publication which in no way was negotiated with anyone other than with Hixie |
| 10:34 | <annevk> | darobin: I followed a template for it |
| 10:34 | <jgraham> | I'm not sure "disrespectful and childish" has been an opening gambit in many successful negotiations, but maybe I'm wrong |
| 10:34 | <darobin> | annevk: yeah, that's what I meant by "inaccurate by hearsay" |
| 10:34 | <darobin> | I think that Tim is confusing several things going around, notably the work Domenic and I did |
| 10:34 | <annevk> | darobin: I don't see how that title is disrespectful and childish |
| 10:34 | <darobin> | but that's okay, I would focus on the inaccuracies |
| 10:35 | <annevk> | darobin: are there FSA guidelines we did not follow? |
| 10:35 | <darobin> | annevk: then you should talk to Tim about it |
| 10:35 | <darobin> | annevk: I'm not sure about that, I've been meaning to ask IanJ about whether the FSA templates are required or not |
| 10:35 | <annevk> | And I don't think Hixie refused to change the title, he refused to change a single byte of that snapshot |
| 10:35 | <darobin> | because there are FSA templates and they have stylesheets and such |
| 10:36 | <annevk> | I offered that we could make another snapshot to some people, but they didn't really come back to me with anything concrete |
| 10:36 | <darobin> | annevk: actually, Hixie did change the title, which caused other problems because it became a Living Snapshot :) |
| 10:36 | <annevk> | darobin: yeah based on my input and then quickly reverted it |
| 10:36 | <darobin> | annevk: who did you offer to? I wasn't in that loop |
| 10:36 | <annevk> | darobin: I should not have asked |
| 10:37 | <darobin> | annevk: it's okay, I wasn't blaming Hixie over this — or anyone for that matter |
| 10:37 | <darobin> | it was just an amusing side event |
| 10:38 | <jgraham> | So I don't understand why it's a problem to make a new snapshot with a different title, if some people still aren't on board with the whole "implementors don't look at snapshots" thing |
| 10:39 | <darobin> | if theres a way of making a snapshot with a different title, I think it would be great progress |
| 10:39 | <annevk> | I'm not sure I follow your train of thought jgraham |
| 10:39 | <darobin> | and I'm happy to chase down the styling issue |
| 10:40 | <darobin> | annevk: I reckon the primary problem with the title is that it says which people should read the document; whereas it is better to say what the document is and let people decide for themselves |
| 10:40 | <darobin> | i.e. don't work on the assumption that people are stupid |
| 10:40 | <jgraham> | annevk: There is a living standard. There is one snapshot of that which, being a snapshot, can't change. There could be a second snapshot which could be different to the first. Would that solve the problem, or am I missing something? |
| 10:41 | <darobin> | jgraham: it could solve the problems with a few changes, yes |
| 10:41 | <annevk> | jgraham: I don't know, I've been asking people that seemed to have a problem with it and it didn't get very concrete |
| 10:41 | <annevk> | darobin: would something like "URL Standard IPR Snapshot" work? |
| 10:41 | <darobin> | annevk: I can get you something concrete if you're up to working this through |
| 10:41 | <darobin> | I can't make the decision unilaterally, but I can drive the talks inside |
| 10:42 | <darobin> | I'm happy to take that to the right people and get a quick answer |
| 10:42 | <darobin> | the proposal I had was "Immutable Snapshot" |
| 10:42 | <darobin> | annevk: something like this http://darobin.github.io/kadesh/ |
| 10:42 | <darobin> | annevk: note that you can imagine it with the CG style, or perhaps without style |
| 10:43 | <darobin> | (that was initially following the idea of publishing a WD) |
| 10:43 | <annevk> | Yeah, I saw that |
| 10:43 | <jgraham> | I'm not sure an immutable snapshot is an edition |
| 10:43 | <annevk> | I remember disliking several bits but then Domenic told me the whole thing broke down already |
| 10:43 | <darobin> | happy to iterate |
| 10:43 | <darobin> | note: if we're doing an FSA, it's simpler |
| 10:43 | <jgraham> | But I quite like the idea of "URL Spec Immutable Snapshot [date]" |
| 10:43 | <annevk> | I didn't like "Latest published version", "editor's draft" |
| 10:44 | <darobin> | annevk: yeah I know, but again for an FSA draft I can fix that |
| 10:44 | <darobin> | here's what I'll do |
| 10:44 | <annevk> | It's a shame Hixie is asleep |
| 10:44 | <darobin> | you are making encouraging sounds that we could make progress on this |
| 10:44 | <darobin> | I'll take some proposals to those who can make that call |
| 10:45 | <darobin> | and get back to you with some ideas |
| 10:45 | <darobin> | if we can get an FSA draft that people are happy with, that's progress |
| 10:45 | <darobin> | I don't know if it'll be progress enough for the whole HTML reference nightmare, but that's a whole other SNAFU |
| 10:47 | <annevk> | Of course, soon all my URL work will be obsolete: http://lists.w3.org/Archives/Public/public-urispec/2014Oct/ |
| 10:47 | <darobin> | annevk: it's true you're missing LEM formalism. Hackers gonna want some of that. |
| 10:48 | <annevk> | cwilso: in reply to last night, I would be okay with keeping support for callbacks for some time (maybe even two/three years), but I don't see the point in not deprecating them straight away and removing them from the specification |
| 10:49 | <Ms2ger> | darobin, eh, that reference is hardly important |
| 10:49 | <darobin> | Ms2ger: you're telling me? :) |
| 10:50 | <Ms2ger> | darobin, mostly because it's in a document that's hardly important :) |
| 10:50 | <darobin> | Ms2ger: you're telling me? :) |
| 10:50 | <Ms2ger> | darobin, I seem to be! |
| 10:51 | <Ms2ger> | darobin, not sure why, maybe I just like talking to you? |
| 10:51 | <darobin> | Ms2ger: I have no doubt you do sweetie |
| 10:51 | <MikeSmith> | jgraham: as far as Art having just asked based on conversations with the director's agents, I can say, speaking as one of the director's agents, that (a) I never told him anything like that, and he never asked me, and (b) I would think that Art knows me well enough to figure that I was one person he could ask and get a straight answer from, and (c) that if he had asked me I would have told him myself that was in fact not Tim's position at all. |
| 10:52 | <MikeSmith> | jgraham: In hindsight I guess I should have said more to mitigate the shitstorm that Art started, and done more to help let Tim know it was going on. |
| 10:52 | jgraham | takes to referring to MikeSmith as Agent Smith |
| 10:52 | <MikeSmith> | heh |
| 10:54 | <Ms2ger> | In that case... |
| 10:54 | <MikeSmith> | so anyway, Art at least should have chosen his words a lot more carefully, because saying something like "Although I disagree with the Director's position here" was plain bad, given that the only thing he was basing that on was hearsay |
| 10:54 | <mathiasbynens> | Why does @font-face work as expected on https://mathiasbynens.github.io/html-imports-font-face/standalone.html but not on https://mathiasbynens.github.io/html-imports-font-face/example.html? |
| 10:55 | <Ms2ger> | Agent Smith: can you give me a straight and public answer to the question "what is the Director's position on referencing WHATWG standards in W3C documents?" |
| 10:56 | <Ms2ger> | Because I've heard a lot of things that apparently aren't his position, but nothing that is |
| 10:56 | <mathiasbynens> | ^ @font-face doesn’t seem to work from within HTML imports, but I don’t know why |
| 10:56 | <MikeSmith> | and Art bears some responsibility for one of the consequenses of his actions being that other people assumed he actually knew what he was talking about and took his matter-of-factly-worded statements as actual truth and repeated them and acted on them as such |
| 10:57 | <MikeSmith> | Ms2ger: the Director has no blanket policy prohibiting W3C specs from referencing WHATWG specs |
| 10:57 | <Ms2ger> | Interesting |
| 10:57 | <Ms2ger> | Who does? |
| 10:58 | <MikeSmith> | at least the Director has never articulated such a policy to me |
| 10:58 | <Ms2ger> | Ah |
| 10:58 | <Ms2ger> | That's not what you said, then |
| 10:58 | <darobin> | Ms2ger: the references policy basically only grants an automatic "Yes" to things that are W3C Recs, the theory is that everything else is up for director decision |
| 10:58 | <jgraham> | (I would argue that "has no blanket policy" is still a statement on what his position isn't) |
| 10:59 | <Ms2ger> | What jgraham said |
| 10:59 | <darobin> | Ms2ger: the practice is that there are habits and uses that make some references (e.g. IETF) easier to push through than others |
| 10:59 | <MikeSmith> | and understanding that unlike Art I don't claim to actually say what particular positions the Director has |
| 10:59 | <Ms2ger> | "the Director has no blanket policy prohibiting W3C specs from referencing WHATWG specs" |
| 10:59 | <Ms2ger> | How should I read that if not as "actually say what particular positions the Director has"? |
| 11:00 | <MikeSmith> | Ms2ger: if the Director had a policy like the one Art was claiming, you can imagine that I would know |
| 11:00 | <darobin> | Ms2ger: we are working on getting to the point where doing so for the WHATWG would also be pretty usual and natural |
| 11:00 | <annevk> | There's a reference to an obscure book for certain <canvas> algorithms. That never raised an eyeball? |
| 11:00 | <jgraham> | The thing that makes this doubly confusing is that sometimes "the director" doesn't actually mean Tim at all. |
| 11:00 | <annevk> | But oh reference the WHATWG, that's open and public and not a book, must be bad. |
| 11:01 | <darobin> | annevk: you make fair points, but you're not arguing them to the right people there :) |
| 11:01 | <Ms2ger> | MikeSmith, I can imagine that, yes, but I don't care much for discussions based on imagination |
| 11:01 | <darobin> | anyway, I think we can make progress on this, it's not that far away |
| 11:01 | <Ms2ger> | MikeSmith, TimBL doesn't either, reading his email to Art |
| 11:02 | <Ms2ger> | I guess I shouldn't be asking about policies |
| 11:02 | <darobin> | Ms2ger: especially imaginary ones :) |
| 11:03 | <Ms2ger> | My actual question is: "Will the Director allow a specification that references a WHATWG Standard to be published under TR/?" |
| 11:03 | <darobin> | Ms2ger: I can't speak for the Director, but my very strong sense is that this is not far at all from happening |
| 11:03 | <darobin> | or, wait, no |
| 11:03 | <darobin> | under TR: this has already happened |
| 11:04 | <darobin> | as PR/Rec: what I said above about soon |
| 11:04 | <zcorpan> | "Most libraries, including mine, implement RFC3986 and RFC3987 to the letter. And many programs _depend_ on this behavior." |
| 11:04 | <Ms2ger> | darobin, in that case, why did plh change references behind my back? |
| 11:04 | <zcorpan> | is that accurate? |
| 11:04 | <Ms2ger> | zcorpan, [citation needed] on "many", at least |
| 11:05 | <zcorpan> | Ms2ger: what about the first statement? |
| 11:05 | <jgraham> | zcorpan: Seems like something that you could test. Presumably IETF, being a respectable standards organisation, has great testing policies |
| 11:05 | <darobin> | Ms2ger: how so? |
| 11:05 | <Ms2ger> | zcorpan, sorry, s/many/most/ |
| 11:05 | <zcorpan> | Ms2ger: ah |
| 11:06 | darobin | lol at respectable standards organisation |
| 11:07 | <darobin> | I mean seriously have you looked at the bunch of us? at the other people who do standards? how are organisations of such people expected to ever act respectfully? |
| 11:07 | <darobin> | unless there's a theory that says respectful behaviour is emergent in large groups of trolls |
| 11:07 | <jgraham> | darobin++ |
| 11:08 | <jgraham> | Although respectable and respectful are strictly quite different |
| 11:09 | <Ms2ger> | http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0638.html |
| 11:10 | <annevk> | zcorpan: I think there's a lot of software that has the ABNF from URI/IRI imported plus some rules around it |
| 11:10 | <Ms2ger> | If I'm not mistaken, that makes it pretty clear that plh as acting Director had a blanked policy against WHATWG references |
| 11:10 | <annevk> | zcorpan: I don't think that software is used to navigate the web |
| 11:10 | <Ms2ger> | blanket, even |
| 11:11 | <annevk> | zcorpan: a subset of it, perhaps |
| 11:11 | <zcorpan> | annevk: ok |
| 11:13 | <annevk> | Ms2ger: well we just learned that what Art says might not always be correct, so citing Art as proof seems extremely silly |
| 11:14 | <Ms2ger> | That's all we have, isn't it? |
| 11:15 | <Ms2ger> | I've never seen someone who makes the decision actually say what those decisions are based on |
| 11:29 | <MikeSmith> | Ms2ger: that message is old. plh has since then spent tons of time working to get some of the old rules of thumb for normative references liberalized and replaced with something that's actually documented somewhere instead of just being in people's heads |
| 11:29 | <Ms2ger> | That's good to hear |
| 11:36 | <annevk> | Ms2ger: if all you have is advice to jump from a building, would you do it? |
| 11:37 | <rubys> | mezzanine level? |
| 11:38 | <Ms2ger> | Do I get a parachute? |
| 11:43 | <rubys> | plh does not have a blanket policy against referencing WHATWG specs either, nor is he in a position to enforce such. |
| 11:43 | <rubys> | speaking for myself, I believe that the URL standard has the biggest chance of being the first such specification |
| 11:44 | <rubys> | The biggest problem is that it doesn't clearly delineate between stuff that works and is stable and stuff that is broken and a work in progress. |
| 11:44 | <Ms2ger> | Oh course he is in a position to enforce that |
| 11:44 | <Ms2ger> | He has done it |
| 11:45 | <Ms2ger> | Whether he still has such a policy, I don't know |
| 11:45 | <rubys> | I'd suggest that all of the data that you have is second or third hand. |
| 11:46 | <Ms2ger> | Well, I guess so |
| 11:46 | <rubys> | PLH notes that the URL spec fails a number of tests, Art reports that as a blacklist. You accept Art's statements. |
| 11:46 | <rubys> | I suggest that if we focus on the test failures we might very well get a different result. |
| 11:46 | <Ms2ger> | I was talking about http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0638.html |
| 11:47 | <annevk> | rubys: do you have tests for PORTERDUFF? |
| 11:47 | rubys | wonders what PORTERDUFF is |
| 11:47 | <annevk> | a reference |
| 11:47 | <annevk> | BEZIER is even better |
| 11:47 | <annevk> | apparently PORTERDUFF gained a PDF |
| 11:47 | <Ms2ger> | Has anyone ever found a copy of BEZIER? |
| 11:48 | <rubys> | Ms2ger: once again, you are taking a statement by Art on what PLH has done. I'd encourage you not to do that. |
| 11:49 | <Ms2ger> | rubys, I'd love to get a statement from plh one way or the other |
| 11:51 | <rubys> | I talk to PLH frequently. I can say that I don't believe that there is a blanket blacklist. There are a list of issues by specification, and if those issues were to be worked, the results would be different. I believe that the issues with the URL specification can be worked. |
| 11:51 | <Ms2ger> | rubys, sorry, you're a second-hand source |
| 11:51 | <rubys> | yes, I am. |
| 11:53 | <rubys> | What are you looking for? A statement that there isn't a blacklist? Such a statement is easy (as in cheap). |
| 11:54 | <Ms2ger> | A statement that WHATWG Standards can be referenced from W3C publications, and that publications won't be denied or changed based on that alone |
| 11:54 | <Ms2ger> | From someone who actually makes the call |
| 11:54 | <rubys> | That call isn't made by PLH. |
| 11:54 | <Ms2ger> | So you say |
| 11:55 | <Ms2ger> | Last time I checked, the call was made by the Director or acting Director, and plh was acting Director |
| 11:55 | <annevk> | rubys: I left some new comments on your blog btw |
| 11:55 | <annevk> | rubys: was the TLS advice enough to go on? |
| 11:56 | <SimonSapin> | mathiasbynens: Do you want to use wtf-8? How? |
| 11:56 | <rubys> | annevk: I responded to one of them. Your other comment (about tests) was expected. |
| 11:56 | <rubys> | Ms2ger: I've only ever seen Ralph act as acting Director, never PLH. And only on less contentious issues. |
| 11:56 | <SimonSapin> | mathiasbynens: it’s cool that you implemented it, but I don’t want to encourage people to use it where they shouldn’t |
| 11:56 | <Ms2ger> | Anyway, if that's no longer the case, or I misunderstood what I read back then, I assume that means I don't want a comment from plh |
| 11:57 | <annevk> | rubys: I don't see your comment, I made mine just now |
| 11:57 | <annevk> | SimonSapin: you should have given it a less attractive name then |
| 11:57 | <mathiasbynens> | SimonSapin: I don’t, but I had a UTF-8 project that was easy to port to WTF-8, so I figured, why not? |
| 11:58 | <SimonSapin> | annevk: eh |
| 11:59 | <rubys> | annevk: my bad. My comment is posted now. |
| 11:59 | <rubys> | the TLS advice is what I was looking for, but getting my weblog working is higher priority, and even that is lower than other things going on in my life right now :-) |
| 12:00 | <annevk> | fair |
| 12:04 | <annevk> | rubys: hmm yeah, just tried posting something and got an error |
| 12:05 | <rubys> | And nothing in the error log :-( |
| 12:07 | <rubys> | Ah, did find something. Looking further. |
| 12:10 | <rubys> | the error I found was "POST limit exceeded", so you were mis-identified as a spammer :-/ |
| 12:10 | <rubys> | I need to look into that logic, but for now I simply whitelisted you |
| 12:10 | <rubys> | annevk: can you post again? |
| 12:15 | <annevk> | rubys: worked |
| 12:15 | <jgraham> | For the record I think that blocking HTML on referencing URL because implementations fail some of the tests in URL is, to coin a phrase, Fucking Stupid. |
| 12:16 | <annevk> | rubys: it seems weird that if you have a cookie for me and I posted several time successfully, I'm still a spammer |
| 12:16 | <jgraham> | It's also grossly hypocritical since HTML intentionally chose not to look at tests for the parts that would undoubtedly fail. |
| 12:17 | <rubys> | jgraham: can we talk about that a piece at a time? |
| 12:17 | <jgraham> | Sure? |
| 12:18 | <rubys> | you made multiple points. The problem is that URL fails more than a few tests, to the point where entire portions (like file:) don't appear to be based in reality; and as to "chose not to look" we put out a call on what areas we should look at, and did look at those portions. |
| 12:19 | <rubys> | pick one piece, and lets talk further |
| 12:19 | <SimonSapin> | rubys: file URLs are not defined anywhere |
| 12:20 | <SimonSapin> | other than in an obsoleted RFC that basically says "it’s a file" |
| 12:20 | <rubys> | SimonSapin: so those tests are bogus? |
| 12:20 | <jgraham> | I agree that HTML was above board about what it did. That's fine and I don't object to it having done that. |
| 12:20 | <rubys> | SimonSapin: I may not be understanding what you mean by anywhere. Are you saying that the URL Standard doesn't define file URLs? |
| 12:21 | <SimonSapin> | rubys: I don’t know about those tests, but it’s not like there’s a better alternative |
| 12:21 | <jgraham> | But you could easily apply the same standard to URL as HTML ("we look at the results of the tests we think are likely to be interoperable") or to most references ("we don't expect a testsuite or have any requirements on the results of one"). Instead it's being held to a higher standard. |
| 12:22 | <rubys> | "we look at the results of the tests we think are likely to be interoperable" [citation needed]. That is NOT what I said. I said "we put out a call on what areas we should look at, and did look at those portions" |
| 12:23 | <jgraham> | Right, but the areas that we chose not to look at were clearly the ones where we expected most difficulty in getting a testsuite to show "interop" |
| 12:25 | <rubys> | That's was not the intent of the call. If you felt that way, it is unfortunate that you didn't speak up. The intent is to document what works and mark clearly what needs further work. We undoubtedly need to improve, and I'm encouraging the URL standard to do likewise. |
| 12:26 | <rubys> | In fact, I may be willing to personally to contribute to that effort. |
| 12:26 | <annevk> | Hmm, seems David Sheets has already given up on defining an API for URLs before they even started. That doesn't bode well for me getting to work on other problems |
| 12:27 | <rubys> | annevk: indeed. |
| 12:27 | <jgraham> | I don't see why I should speak up. I think that it's a perfectly valid idea to try and ship on a date-based schedule, it's clear that the Process is stacked against trying to achieve that, and I think that skipping some requirements around interoperability in areas where people are going to be adverse to changing their implementations is way less harmful than trying to do surgery to remove those bits from the spec, which was the other possible appro |
| 12:28 | <jgraham> | ... we changed the Process to make this unnecessary, but that also clearly wasn't going to happen. |
| 12:28 | rubys | wonders if jgraham is familiar with the term http://rationalwiki.org/wiki/Gish_Gallop |
| 12:29 | <jgraham> | I am not criticising plan 2014 here. I'm criticising the fact that URL is being held to a different standard than every other reference, or the spec itself, in terms of tests. |
| 12:29 | <annevk> | I should probably have collected less tests for URLs :p |
| 12:30 | <rubys> | and I disagree with that characterization, but I'm having trouble getting a foothold in this discussion given that you I have different understanding of the issue |
| 12:32 | <Ms2ger> | rubys, interesting. To be perfectly clear, are you saying that the URL reference is not held to higher/other standards than other references? |
| 12:33 | <jgraham> | I don't really know what to say. I didn't even consider anything I said about Plan 2014 to be controversial. My point was just the contrast between what was required by HTML and what seems to be required for URL. |
| 12:33 | <rubys> | Ms2ger: would you believe me if I said yes? |
| 12:34 | <Ms2ger> | rubys, if you can back that up, sure |
| 12:34 | <rubys> | jgraham: the HTML spec attempts to identify areas that are soft, and took multiple years before the statements which weren't soft were (mostly) true. The URL spec doesn't make such an attempt, and is less further along. |
| 12:35 | <rubys> | Ms2ger: if the discussion that Anne and I am having on my weblog produces results, I'll be in such a position. |
| 12:35 | <jgraham> | rubys: I agree that URL is less well advanced than HTML. |
| 12:36 | <Ms2ger> | rubys, but the fact that we're talking about this reference and not others seems to suggest that *something* is different, surely? |
| 12:37 | <jgraham> | It's better advanced than other older attempts to specify URLs though. For example it has a testsuite. I'm very concerned that the property of having a testsuite is being held against a spec because that will simply encourage spec editors and other interested parties to not include tests. |
| 12:38 | <rubys> | Ms2ger: part of what is different is people are making unhelpful mis-characterizations, essentially kicking over rocks. |
| 12:39 | <rubys> | if people hadn't done that, I wouldn't be spending my time trying to identify why this case is just like a number of other references, and arguably better; in fact much better |
| 12:40 | <rubys> | that doesn't mean that in the process, I won't be providing feedback on how to make it even better, and in fact, I am starting to do exactly that. |
| 12:41 | <annevk> | There has been never this much scrutiny over normative references. That is what is odd |
| 12:41 | <smaug____> | USVString |
| 12:42 | <smaug____> | that certainly is weird enough |
| 12:42 | <annevk> | heh yes |
| 12:43 | <rubys> | annevk: there may not have been as much public awareness of the scrutiny. And, again, the purposeful kicking over rocks to see what crawls out has indeed invited more scrutiny. |
| 12:43 | <smaug____> | Btw, why does Service worker spec use it? |
| 12:44 | <annevk> | smaug____: for URLs I suspect |
| 12:44 | <annevk> | smaug____: URLs are "lone surrogate safe" |
| 12:45 | <Ms2ger> | Anyway, not sure what exactly you mean about kicking over rocks and who you're accusing of that |
| 12:46 | <darobin> | Ms2ger: FWIW my understanding is that plh only acts as acting director for things that aren't under his purview. Say, RDF and the such. |
| 12:46 | <Ms2ger> | darobin, if you say so |
| 12:49 | <darobin> | I don't think that the URL tests reveal that big a problem to be honest. Looking through the failures, most of them are on pretty horrible things :) |
| 12:49 | <darobin> | there's a point beyond which authors can justifiably be shot |
| 12:50 | <annevk> | rubys: PORTERDUFF and BEZIER are references of <canvas> which apparently are indirect references for HTML, but still normative afaict |
| 12:51 | <darobin> | so, this is lost in the mists of history, but I do believe that at least the PORTERDUFF reference was deemed a problem and investigated as such many, many years ago |
| 12:51 | <darobin> | and it eventually came down to it being pretty much the only reference anyone doing graphics used, and getting patent commitments from the companies that had IP on it |
| 12:51 | <annevk> | for MIMESNIFF it points to an outdated RFC over the WHATWG document that's maintained? |
| 12:51 | gsnedders | has flashbacks to the ASCII citation discussion |
| 12:51 | <darobin> | but don't quote me on that, I was, like, probably still into Guns'N'Roses back then |
| 12:52 | <annevk> | that's quite rich |
| 12:52 | <darobin> | very rich :) |
| 12:52 | <annevk> | It still seems to me that there's a strong anti-WHATWG bias when it comes to references |
| 12:52 | <darobin> | btw, has there been any talk about getting MIMESNIFF rolling again? |
| 12:52 | <annevk> | Rather than any coherent reference strategy that URL is failing |
| 12:52 | <darobin> | annevk: if I tell you we're trying to fix something it's because there's a problem :) |
| 12:53 | <darobin> | that is entirely true |
| 12:53 | <darobin> | hence: fixing |
| 12:56 | <annevk> | There's a normative reference to http://wiki.xiph.org/SkeletonHeaders |
| 12:56 | <annevk> | And to http://www.opensearch.org/Specifications/OpenSearch/1.1#Autodiscovery_in_HTML.2FXHTML |
| 12:57 | <annevk> | And https://publicsuffix.org/ |
| 13:00 | jgraham | imagines darobin with a hair-metal perm. Or a mullet! |
| 13:00 | <darobin> | annevk: please don't make me go over that stuff again |
| 13:04 | <annevk> | It's just, I remember all the fuss over the WHATWG Wiki |
| 13:04 | <annevk> | Did I miss a debate on the xiph.org Wiki? |
| 13:04 | <annevk> | What about publicsuffix's lack of consensus process? |
| 13:05 | <darobin> | jgraham: https://scontent-a.xx.fbcdn.net/hphotos-frc3/v/t1.0-9/228551_18735131056_5573_n.jpg?oh=8d46c54305efb7363f1c2a12c76c726f&oe=54C2F392 |
| 13:06 | <darobin> | annevk: those are all points I have made repeatedly |
| 13:06 | <darobin> | I am glad to see that you are reaching the same conclusions |
| 13:06 | <darobin> | you're missing a few btw |
| 13:07 | <darobin> | I'd love to hear about how ECMA adheres to OpenStand principles (though one could argue TC-39 is different) |
| 13:07 | <darobin> | I'm sure ECMA's hosting of the Tobacco Forum is transparent and for the good of humankind |
| 13:07 | <rubys> | I can confirm that darobin has been making those points, and has been making progress. |
| 13:08 | <annevk> | darobin: hah |
| 13:08 | <annevk> | darobin: what does OpenStand say about making decisions during meetings people can't afford to attend? |
| 13:08 | <annevk> | Actually, it's not even the can't afford to attend bit that's problematic with meetings |
| 13:08 | <darobin> | annevk: that's a valid question, one of the reasons I had toyed with doing "NextStand" back when OpenStand came out |
| 13:09 | <darobin> | but... I suspect that you're preaching to the choir here on all this... |
| 13:09 | <darobin> | I know the unfairness, I'm more interested in fixing the issue |
| 13:10 | <annevk> | Yeah I guess. I'm surprised that almost all of TC39 has come to the conclusions that mailing lists are very bad and F2F is the only way to solve things |
| 13:10 | <annevk> | Which just seems so counter to being inclusive |
| 13:12 | <darobin> | I'm not overly fond of email but replacing that with f2f doesn't strike me as a wonderful idea at all |
| 13:13 | <annevk> | Yeah, I'm fairly happy with GitHub / Bugzilla |
| 13:13 | <annevk> | Not sure about specifiction yet |
| 13:14 | <darobin> | specifiction is more for pre-feature talks; it's less good once you have a concrete proposal to work on |
| 13:14 | <darobin> | I wonder if there's a set up that makes Bugzilla actually run at decent speed |
| 13:14 | <rubys> | Annevk: How happy are you with github? ;-) Would you be open to pull requests? |
| 13:14 | <annevk> | rubys: I've accepted pull requests in the past |
| 13:15 | <rubys> | annevk: excellent! |
| 13:15 | <rubys> | I was unaware of that, and didn't see any recent instances. |
| 13:16 | <annevk> | rubys: https://github.com/whatwg/fetch/commit/7d6d62136c61d538f638479d6beebbdca8d644ee is a fairly recent one |
| 13:16 | <annevk> | (somewhat surprised people still print though) |
| 13:16 | <rubys> | annevk: thanks! |
| 13:20 | <jgraham> | I actually think that GH and BZ are more exclusionary than email, but they do have other advantages |
| 13:21 | <caitp> | because they require a sign up? arguably GH gives a voice to a great deal more people because of its simplicity |
| 13:22 | <jgraham> | Because they fragment discussion making it harder to track everything |
| 13:22 | <caitp> | you say fragment, I say "organize in a readable fashion" :> |
| 13:23 | <caitp> | "harder to track everything" could certainly be improved, but as a communications medium they're both better |
| 13:24 | <jgraham> | AFAICT the main advantage of GH is that people already have accounts, and the main advantage of bugtrackers in general is that you can mark an issue as fixed |
| 13:24 | <jgraham> | It's not that they are intrinsically great environments |
| 13:26 | <annevk> | Well, the discussion stays on a single topic |
| 13:26 | <annevk> | Whereas with mailing lists that is often not the case somehow |
| 13:26 | <annevk> | Or you get several threads on the same topic |
| 13:26 | <annevk> | There's a focus to Bugzilla and GitHub that works rather well |
| 13:27 | <jgraham> | Yeah, that's a fair point |
| 13:36 | <cwilso> | Annevk: planning to keep support for something in products for > a year while removing it from the spec seems like a bad idea. We caused problems for ourselves in web audio that way. Rip off the bandaid one way or another. |
| 13:37 | <annevk> | cwilso: did the Web Audio implementations start telling developers immediately those APIs were deprecated? |
| 13:53 | <darobin> | this was fast https://twitter.com/BrianHallDev/status/518026732478398464 |
| 13:54 | <boogyman> | haha |
| 13:57 | <annevk> | nice |
| 13:57 | <annevk> | was wondering what that was about |
| 13:57 | <cwilso> | annevk: no. Might be an interesting experiment in whether warnings work, but the net problem is code would work on one browser but not newer one following the spec. |
| 13:59 | <rubys> | cwilso: I claim that the problem is worse than that. I see tests that fail in all browsers, and some of those very same tests don't match prior RFCs. |
| 14:00 | <rubys> | goals that Mozilla has for file: URIs (cross-platform consistency) may not be ones that single-platform vendors may share. |
| 14:34 | <annevk> | rubys: we're talking about something else |
| 14:35 | <annevk> | cwilso: sure, but at least you need to give people a heads up, we've had success with that |
| 14:37 | <jgraham> | zcorpan: https://github.com/wooorm/franc seems interesting if you want to do more detailed studies of lang attr correctness |
| 14:38 | <darobin> | wow that's awesome |
| 14:39 | <gsnedders> | jgraham: that actually looks pretty poor at langid tools go |
| 14:39 | <gsnedders> | FYI |
| 14:40 | <jgraham> | gsnedders: Oh I don't doubt you can do better |
| 14:40 | <gsnedders> | AFAICT, it relies on an unweighted list of codepoint trigrams per language (at *least* weight them — but they can't really because their training corpus is hopelessly small) |
| 14:41 | <gsnedders> | (they manage to cover so many languages by having a tiny training corpus per language) |
| 14:41 | <jgraham> | Well I'm happy with "or a similar tool" |
| 14:41 | <jgraham> | It seems better than identifying Spanish using two words |
| 14:42 | <jgraham> | Or whatever unknown technique SteveF_ used |
| 14:43 | <gsnedders> | https://github.com/saffsd/langid.py is what I'd recommend, though the code last I knew was pretty damn messy |
| 14:45 | <jgraham> | Even after you ignore the 1Mb bzipped training data in the main file? :) |
| 14:45 | <gsnedders> | yes |
| 14:46 | <gsnedders> | jgraham: look at all the globals |
| 14:46 | <gsnedders> | jgraham: and cry |
| 14:47 | <jgraham> | anyway what you really want is just to be able to do for (file in files): tree = parse(file); attr = tree.root.attr("lang"); detected = detect(tree.text); update_data(attr, detected) |
| 14:48 | <jgraham> | Doesn't matter too much about the code as long as there's an API that takes a string and returns a language code |
| 14:48 | <gsnedders> | jgraham: somehow need to handle <span lang="en">this is a really silly <span lang="fr">façade</span></span> |
| 14:48 | <jgraham> | "v2" |
| 14:49 | <gsnedders> | jgraham: this is why I'd recommend it, because the API is fine until you need to deal with multiple models at the same time, which is pushing it for most cases |
| 16:07 | <cwilso> | annevk: Of course, you need to give them a heads up. But if you let the old way persist for a long time, it just makes it harder to remove. Best attack: provide a matched pair of monkeypatches (I did this for Web Audio), old->new and new->old, and publicize, and give a relatively short timeframe for removal. |
| 16:08 | <cwilso> | rubys: if tests fail in all browsers, and don't match prior RFCs, then maybe the test is wrong? or the spec? |
| 16:09 | <cwilso> | annevk: no, Web Audio did not start telling devs right away that the APIs were deprecated. It's definitely true that would have helped. (Some of them would have been hard, like changing typing on parameters) |
| 18:05 | <Domenic> | So I missed all the interesting discussion this morning while I was sleeping in |
| 18:06 | <Domenic> | But two things: |
| 18:06 | <Domenic> | 1) file: URLs raaaargh y they suck so much |
| 18:06 | <caitp> | s/file: // |
| 18:06 | <Domenic> | 2) I agree with sentiments that it would be nice if WHATWG specs had better marking up of "this is stable and shipping" vs. "this is agreed upon and we hope implementers will get to it soon" vs. "I am proposing this but people are still debating it" |
| 18:07 | <Domenic> | HTML tries with its browser compat things in the margin |
| 18:07 | <Domenic> | Some CSS specs have test suites in the margin which is cool |
| 18:07 | <Domenic> | But in general nobody has solved this problem that well |
| 18:09 | <Hixie> | i'm updating the HTML spec to use caniuse.com data, btw |
| 18:09 | <Hixie> | this is actively happening right now |
| 18:13 | jgraham | doesn't really know how to feel about test suites in the margin |
| 18:14 | <jgraham> | HTML could trivially have pointers to tests, and with a little effort, some actual results. |
| 18:15 | <jgraham> | But it would be better if we could somehow get a fuzzy sense of "no testsuite / limited testsuite / reasonable testsuite" and "no implementation / some attempt at implementation / good implementation" |
| 18:16 | <jgraham> | Which I think is harder, and might set the wrong incentives |
| 18:16 | <jgraham> | Well anything where we want people to submit tests that will be displayed in a prominent public place sets bad incentives |
| 18:19 | <jgraham> | But yeah, generally the idea of having per-section stability markers is good, and something that we've tried to do multiple times, and something that has never quite been right so far |
| 18:22 | <Domenic> | Hixie: which is really awesome. But doesn't e.g. address navigator.yieldForStorageUpdates() being not only unimplemented and untested, but unwanted :P |
| 18:24 | <jgraham> | Well the right way to address things that are unwanted is to remove them from the spec |
| 18:24 | <jgraham> | Not to leave them there but mark them as unwanted |
| 18:25 | <Domenic> | well HTML has a lot of those :-/ |
| 18:25 | <Domenic> | table sorting also comes to mind |
| 18:30 | <annevk> | 74relide |
| 18:30 | <jgraham> | Domenic: Not clear that's unwanted yet |
| 18:31 | <jgraham> | I understand Google doesn't like it but afaik no one else has provided any feedback yet |
| 18:33 | <Domenic> | jgraham: that should be a clue, no? ;) |
| 18:33 | <TabAtkins> | jgraham: Why are yo uunsure about test suites in the margin? |
| 18:33 | <TabAtkins> | annevk: Time to change your password |
| 18:34 | <jgraham> | Domenic: Lack of feedback doesn't indicate anything much except that it's not at the top of anyone's priority list yet |
| 18:35 | <jgraham> | It might be that it *never* reaches the top of such a list, which would be a problem of course |
| 18:35 | <jgraham> | Anyway this is not that concerning, you just mark that feature as unimplemented and move on |
| 18:36 | <jgraham> | If it stays unimplemented for long enough you remove it |
| 18:36 | <Domenic> | jgraham: fair i guess. but still "no implementer has expressed interest in this; the editor just put it in there" is something that ideally would be called out. |
| 18:37 | <jgraham> | TabAtkins: I'm not too concerned about just listing tests. I'm concerned about listing results, because historically making public displays of results has led to people trying to game the tests rather than trying to improve interop |
| 18:39 | <jgraham> | e.g. withholding good tests, or submitting large numbers of similar, but trivial, tests in areas where they are better than the competition, or doing the minimum to fix tests rather than actually producing good implementations |
| 18:40 | <jgraham> | (Ealy submissions to HTML suffered from the first effect, CSS has had some examples of the second, and basically all the ACID tests led to the third) |
| 18:40 | <jgraham> | *Early |
| 18:43 | <jyasskin_> | annevk: Thanks. And it looks like WebIDL does let users construct a DOMException: http://heycam.github.io/webidl/#es-DOMException-call |
| 18:54 | <Hixie> | jgraham: i'm happy to expose whatever information you think should be exposed. Give me e.g. a JSON file at a fixed URL that I can fetch regularly and use when generating the spec and I'll be all over it. |
| 19:21 | <Jasper> | I know this isn't specifically a WHATWG question -- but has there ever been an idea to decouple <canvas> from its backing store, so we can use an image painted with Canvas2D more than once? |
| 19:22 | <TabAtkins> | Jasper: You can paint a canvas into other canvases, or extract it as a data url and use it in <img>, or (once implementations appear) put the canvas in the document.elementMap and use it in CSS everywhere you want. |
| 19:23 | <Jasper> | TabAtkins, that means me knowing when the other canvas was drawn to and doing a copy |
| 19:23 | <Hixie> | well you know when it was drawn, since you draw it :-) |
| 19:23 | <caitp> | i get what he's saying |
| 19:23 | <caitp> | she? |
| 19:23 | <caitp> | whateva |
| 19:23 | <TabAtkins> | caitp: "They". |
| 19:23 | <caitp> | good point |
| 19:23 | <Jasper> | These are quite large canvases, too, and I'm drawing to a small portion of them. |
| 19:24 | <Hixie> | (the short answer is document.elementMap) |
| 19:24 | <Jasper> | And there's no way to copy only the extents of the painted region. |
| 19:24 | <Hixie> | (as Tab said) |
| 19:24 | <Jasper> | I haven't heard about document.elementMap yet. |
| 19:24 | <Jasper> | Sounds intriguing though |
| 19:27 | <TabAtkins> | It's in CSS Images 4, but nobody implements yet. |
| 19:28 | <TabAtkins> | Firefox has something similar, with slightly different names, which it's based on. |
| 19:29 | <TabAtkins> | And for canvas specifically, webkit has a -webkit-canvas() function, and an API for creating a special "CSS" canvas. |
| 19:29 | <Jasper> | TabAtkins, yeah, I've seen that |
| 19:30 | <Jasper> | I'm also wondering if it's possible to use a Canvas2D as a texture in WebGL. |
| 19:31 | <Jasper> | Ah, it seems I can. |
| 19:31 | <Jasper> | glTexImage2D takes a <canvas>. Nice. |
| 19:54 | <jgraham> | Hixie: Yeah, well I'm hoping that we will get automatic nightly test results at some point. Whether we can fuzz them in a way that produces a kind of vauge "no support / some implementation" annotation might or might not be possible |
| 20:03 | <Hixie> | jgraham: i'm also interested in coverage numbers like you were saying would be good |
| 21:19 | <crankharder> | I added a "Content-Security-Policy-Report-Only" with this value: "default-src 'unsafe-inline' 'unsafe-eval' https: ; report-uri https://www.mydomain.com/csp"; |
| 21:20 | <crankharder> | I'm seeing reports come in for image tags with embedded data, such as: src="data:image/png;base64,iVBORw0KGgoAA....etc" |
| 21:21 | <crankharder> | the intent of this directive was to detect non-ssl resources, which I suppose that ^ is. Is there a way to modify my policy such that it doesn't report for these images? |
| 21:24 | <crankharder> | also, not really sure if that is ontopic in here or not |
| 23:50 | <terinjokes> | what link should I use for Service Workers? /TR/ or the editor's draft? |
| 23:51 | <smaug____> | never tr |
| 23:56 | <tantek> | do or do not, there is no tr |
