| 01:32 | <MikeSmith> | Hixie: yeah, HTTP I think, for the reason annevk gave (so the validator will deal with it at build/startup time) |
| 01:33 | <Hixie> | so the advantage of a persistent connection would be that you could be informed dynamically of any updates, so for example if someone adds a value at validator.nu, the validator.w3.org validator could be updated literally in real time, within milliseconds. |
| 01:38 | <MikeSmith> | right yeah I understand but that would introduce a cost of use needing to check it for each document, rather than just caching at startup and checking that |
| 01:38 | <Hixie> | why? you'd still just cache it |
| 01:38 | <Hixie> | you'd just get notifications for new things to add to the cache |
| 01:38 | <Hixie> | i would expect this to be a very low-bandwidth connection |
| 01:40 | <MikeSmith> | yeah we don't currently have anything similar where we're doing anything in response to notifications |
| 01:41 | <Hixie> | yup |
| 01:41 | <MikeSmith> | but maybe it would make more sense for this case |
| 01:47 | <Hixie> | MikeSmith: i think it would have a couple of advantages. one is that it would reduce confusion from people registering things and not seeing it update. the other is that it would be pretty magical to have the validators in sync even for things that were _just_ registered. |
| 01:48 | <MikeSmith> | yeah I'd be willing to try it that way if Henri thinks it's worth it |
| 01:49 | <Hixie> | i'm writing an e-mail to the list discussing these points, i'm not sure yet about the overall approach, let alone details. it's just an idea so far. |
| 01:49 | <MikeSmith> | ok |
| 01:52 | <Hixie> | do you have any opinions on the vocabularies? like, all the dcterms.* names? |
| 02:00 | <MikeSmith> | my opinion is that there are two many of them and it's not clear to me that there are many applications that actually consume the info |
| 02:10 | <MikeSmith> | Hixie: I think we should avoid encouraging authors to load up their documents with meta names that they don't actually understand nor have any specific consuming application in mind for |
| 02:11 | <MikeSmith> | which I suspect is the case for most of the meta names that authors use now |
| 02:13 | <MikeSmith> | among other problems it results in massive amounts of needless bytes going out over the network all over the place |
| 02:16 | <MikeSmith> | another thing is that in a lot of cases with the wiki currently, people add names that don't actually meet the spec requirements because there actually isn't any spec or documentation for them |
| 02:16 | <Hixie> | yeah |
| 02:16 | <Hixie> | not sure what to do about that |
| 02:17 | <Hixie> | some people clearly do want to use them and know how to use them |
| 02:17 | <Hixie> | e.g. i had several government archival types contact me and talk about this |
| 02:17 | <Hixie> | seems legit that they should be allowed to do it... |
| 02:17 | <Hixie> | not sure how to let them do it unimpeded while helping authors who are wasting their time and resources on it... |
| 02:18 | <MikeSmith> | right |
| 02:20 | <MikeSmith> | I'm nut sure it's such a huge impediment for anybody to, say, go to the WHATWG list and make a case for what they want added |
| 02:20 | <zewt> | pushing change notifications to external clients is pretty well-covered territory, don't need to maintain constant connections or anything wasteful like that |
| 02:24 | <MikeSmith> | Hixie: with the current situation what we have is a de facto review step, where either Henri or I manually review values before adding them to the validator |
| 02:25 | <MikeSmith> | in this case I'm not sure that's a bad thing |
| 02:27 | <Hixie> | MikeSmith: interesting |
| 02:27 | <Hixie> | MikeSmith: bbiab |
| 02:48 | <foolip> | Hixie: fair enough, I'll see if there's support for dropping it in Blink given the usage |
| 06:29 | <MikeSmith> | Hixie: btw Suzanne Bégin contacted me as well a couple days ago about getting access to the wiki to add name=review_date |
| 06:30 | <MikeSmith> | the thing is, we had previously supported name=review_date in the validator but I removed it |
| 06:30 | <MikeSmith> | and the reason I removed it was that there is no spec or documentation for it |
| 06:30 | <MikeSmith> | and there still isn't, as far as I can see |
| 06:33 | <MikeSmith> | she included the details in the message she sent, but she did not include a link to any public document online that provides those same details |
| 06:33 | <MikeSmith> | so it essentially still doesn't meet the spec requirements for registration |
| 06:34 | <MikeSmith> | which is what I have been meaining to write back to her to say |
| 06:35 | <MikeSmith> | I mean, it all looks legit and I understand why it's important to them |
| 06:36 | <MikeSmith> | but they need to, you know, follow all the instructions -- not just part of the instructions |
| 06:37 | <MikeSmith> | so anyway, providing a new registration mechanism and API is not going to fix that problem |
| 06:38 | <MikeSmith> | I mean the problem of people going ahead and registering things without meeting the "provide a link to a spec" problem |
| 06:43 | <MikeSmith> | they do almost always add a URL for the "Link to a specification" column in the wiki. But if you follow those links you find the documents at the other no not actually provide definitions of the name values or how to use them with the meta element in HTML documents. Sometimes that don't even mention anything close at all but are instead just general overview documents that are only marginally related. |
| 07:26 | <MikeSmith> | and even among the legit, documented values that do actually meet the registration requirements in the HTML spec, a lot of them are thing that have use only with some specific niche group |
| 07:29 | <MikeSmith> | I mean they're not values that many people have widespread use for but are instead just for consumption by one single system of some kind somewhere, and some very limited group of people who are using that particular system |
| 07:30 | <MikeSmith> | so I question how much value there is to anybody in having them publicly registered |
| 07:30 | <MikeSmith> | other than just making the validator shut up |
| 07:33 | <MikeSmith> | and other than the limited beenfit of making it possible for that special group of people to catch typos/mispellings in the values |
| 07:35 | <MikeSmith> | but even in that case a coutner-argument is that if there is actually some system/application out there consuming those values, then the authors and users are going to catch the errors when the documents are used with the system |
| 07:36 | <MikeSmith> | dynamically catch the errors during actual use/testing of the documents with the system, as opposed to catching them during static checking with the validator |
| 07:42 | <MikeSmith> | Hixie: another aspect of that is a case like https://github.com/HubSpot/signet/blob/master/README.md#use |
| 07:51 | <MikeSmith> | ... where this guy or group has for some reason created a JavaScript library to "Display links in the console to your Twitter and GitHub sites with icons displayed next to them" |
| 07:52 | <MikeSmith> | and the mechanism that this JS library uses to figure out what to display is, it looks for <meta name="signet:links" content="http://github.com/example, http://twitter.com/example, http://example.com">; in the document |
| 07:54 | <MikeSmith> | and I guess what documentation they have there for it is technically conformant with the spec requirements |
| 07:54 | <MikeSmith> | but IMHO what they are doing is a bad, misguided use meta@name |
| 07:55 | <MikeSmith> | I mean, it's for use with a JS library |
| 07:56 | <MikeSmith> | so why not instead just specify that metadata within a script element instead, or using a data-* attribute |
| 08:21 | Ms2ger | passes MikeSmith a beer |
| 08:23 | MikeSmith | drinkss the beer with a chaser of straight whiskey to wash the beer taste down |
| 08:26 | <darobin> | MikeSmith: I like how you're making that realistic by actually slurring your sss |
| 08:26 | <MikeSmith> | hah |
| 08:27 | <MikeSmith> | yeah just like my life hero George Jones when he sang "White Lightning" |
| 08:31 | <zcorpan> | how should reftests in wpt be written? link together test and ref with a <link> like in csswg? |
| 08:32 | <zcorpan> | jgraham: Ms2ger: ^ |
| 08:33 | <Ms2ger> | Either that, or by calling them foo.html and foo-ref.html or foo_ref.html |
| 08:51 | <zcorpan> | thx |
| 08:57 | <Ms2ger> | jgraham, in serve.py, is the routes variable used for anything? |
| 09:49 | <hsivonen> | annevk-cloud: seen https://wiki.mozilla.org/Gaia/Email/Features#Message_Encodings ? |
| 09:52 | <hsivonen> | also interesting: falling back to UTF-8 instead of windows-1252: https://github.com/mozilla-b2g/gaia-email-libs-and-more/blob/master/data/lib/js-shims/faux-encoding.js#L53 |
| 09:53 | <hsivonen> | annevk-cloud: at least one case where not supporting non-UTF in TextEncoder has lead to more UTF-8 use: https://github.com/mozilla-b2g/gaia-email-libs-and-more/blob/master/data/lib/js-shims/faux-encoding.js#L37 |
| 10:08 | <jgraham> | zcorpan: The <link> thing is preferred because sharing refs is preferred and that's easy to do with the <link> |
| 10:08 | <jgraham> | (it looks, maybe, like lots of the WebVTT tests have the same ref in different files? I didn't check by hand but my harness complains a lot) |
| 10:08 | <zcorpan> | jgraham: yeah ok |
| 10:08 | <zcorpan> | jgraham: possible |
| 10:09 | <Ms2ger> | jgraham, ah, you're here :) |
| 10:10 | <jgraham> | Ms2ger: More or less :) |
| 10:10 | <Ms2ger> | In serve.py, is the routes variable used for anything? |
| 10:10 | <jgraham> | So, uh, I don't see the routes variable being used either. Which makes me wonder how anything works |
| 10:12 | <Ms2ger> | This tends to be the point where you test and nothing works :) |
| 10:12 | <zcorpan> | added an issue to share refs |
| 10:12 | <jgraham> | No, it more or less works because the defaults are designed to be almost the same as the options in that file |
| 10:13 | <jgraham> | Although now the runner is under tools/ I can't really block tools/ |
| 10:13 | <Ms2ger> | Wait, .asis is "as is"? |
| 10:14 | <zcorpan> | yes |
| 10:15 | <Ms2ger> | Sounds like I learned something new today |
| 10:15 | <jgraham> | Yeah it's not supposed to sound like "arses" |
| 10:16 | <jgraham> | Should the runner move, should I not block tools, or should the runner directory be special cased? |
| 10:17 | Ms2ger | looks what's in tools |
| 10:18 | <Ms2ger> | Except a lot of crap |
| 10:19 | <Ms2ger> | jgraham, if you can special case the runner in one line, do that, otherwise leave it open |
| 10:20 | <jgraham> | It's one line, I think |
| 10:24 | <darobin> | agreed |
| 11:14 | <Ms2ger> | jgraham, so were you fixing it? |
| 11:34 | <marcosc__> | annevk-cloud: heh, I always wanted to be in a semicolon discussion :) |
| 11:57 | <jgraham> | Ms2ger: Yeah, but I was doing so on the train |
| 11:58 | <Ms2ger> | Ah |
| 12:04 | <jgraham> | Ms2ger: Have a review |
| 12:05 | <jgraham> | I should hook up manifest.py to the runner frontend so that there is a (Re)generate manifest button. |
| 12:07 | <Ms2ger> | r+, thanks |
| 12:51 | <hsivonen> | awesome. gedit can't deal with emoji in GB18030. |
| 12:54 | <zcorpan> | jgraham: would it make sense to make the argument to step_func_done optional? sometimes i just want to know if i get an event |
| 12:57 | <jgraham> | zcorpan: Yeah, that doesn't sound crazy |
| 12:58 | <jgraham> | Although |
| 12:58 | <jgraham> | Couldn't you just use onevent = test.done? |
| 12:59 | <hsivonen> | having to remember to escape # in data: URLs sure is annoying |
| 13:01 | <zcorpan> | jgraham: that wouldn't have the right this |
| 13:01 | <Ms2ger> | jgraham, is that called with the right this? |
| 13:02 | <zcorpan> | test.done.bind(test) works i guess but seems harder to remember to do correctly compared to test_func_done() |
| 13:02 | <zcorpan> | er test.step_func_done() |
| 13:03 | <Ms2ger> | add_result_callback(function (test) {output.show_status(tests);}); |
| 13:03 | Ms2ger | wonders how that works |
| 13:03 | <jgraham> | Oh right, silly js |
| 13:04 | <jgraham> | Seems kind of tempting just to forcibly bind some of these functions in testharness.js |
| 13:04 | <jgraham> | I wonder if anything would break |
| 13:04 | <jgraham> | But sure, I would accept a patch to make the argument to step_func_done optional |
| 13:06 | <jgraham> | Do we have a standard for the size of reftests? |
| 13:06 | <jgraham> | Alternatively, does anyone know what the blink/webkit standards are? |
| 13:11 | <jgraham> | 800x600 perhaps |
| 13:12 | <Ms2ger> | jmaher would like 600�600 |
| 13:13 | <jgraham> | Yeah |
| 13:17 | <zcorpan> | oh i thought the edit button would make a PR. oh well https://github.com/w3c/testharness.js/commit/58e0b853f4b7c446a66c6b6891709941f0390c41 |
| 13:19 | <jgraham> | I thought it did too |
| 13:19 | <jgraham> | Or made a branch at least |
| 13:22 | <zcorpan> | maybe it commits directly if you're an owner |
| 13:22 | <zcorpan> | or whatever it's called |
| 13:25 | <Ms2ger> | zcorpan, how would you like it if workers tests looked like this? https://pastebin.mozilla.org/4080277 |
| 13:28 | <zcorpan> | Ms2ger: sometimes i want to do some asserts in the worker context and then more asserts in the window context for a given test |
| 13:28 | <Ms2ger> | Pff, you can write those by hand :) |
| 13:29 | <zcorpan> | Ms2ger: i agree that the approach the existing worker tests use sucks, though |
| 13:30 | <Ms2ger> | A little :) |
| 13:34 | <zcorpan> | related is if you want to assert something in a cross-origin iframe |
| 13:36 | <zcorpan> | but maybe that doesn't need to block improving worker-context-only tests |
| 14:06 | <Ms2ger> | jgraham, f? https://github.com/Ms2ger/web-platform-tests/compare/auto-workers https://github.com/Ms2ger/testharness.js/compare/worker-support |
| 14:24 | <jgraham> | Ms2ger: add_start_callback needs to actually conform to the docs rather than the docs changing |
| 14:25 | <Ms2ger> | Output.prototype.init relies on getting the properties, fwiw |
| 14:28 | <jgraham> | Dammit |
| 14:28 | <jgraham> | The problem is that you can't pass them over the postMessage stuff when they involve callbacks |
| 14:29 | <jgraham> | Also, I am not super-happy about hardcoding the -worker suffix in testharness.js |
| 14:29 | <Ms2ger> | Yeah, agreed |
| 14:29 | <Ms2ger> | Just wanted to get something running at first |
| 14:30 | <Ms2ger> | Can any of the properties actually be callbacks? |
| 14:32 | <jgraham> | Yes |
| 14:32 | <jgraham> | The output_docuemnt can be (and it won't clone even if it is not a callback) |
| 14:33 | <Ms2ger> | Yeah, good point |
| 14:33 | <Ms2ger> | Not very likely someone would do that in workers, I guess |
| 14:35 | <jgraham> | Anyway, I think I am happy with the basic approach |
| 14:35 | <jgraham> | But not really with some of the details |
| 14:36 | <Ms2ger> | The details definitely aren't ready :) |
| 14:36 | <jgraham> | OK then it sounds like we are in agreement |
| 14:37 | <Ms2ger> | \o/ |
| 16:09 | <zewt> | python 2.7's https stuff not validating server certificates is bewildering |
| 16:18 | <gsnedders> | zewt: OpenSSL doesn't by default. |
| 16:18 | <gsnedders> | zewt: Because sorting out CA certs is surprisingly hard on Windows. :( |
| 16:25 | <zewt> | i suspect the amount of even-more-insecure https code out there because of that is staggering |
| 16:37 | <gsnedders> | zewt: Browsers are pretty much the only things that check. Because so often verification fails and it's hard to have a nice interactive API to check with the user, if one is involved, what to do. |
| 16:38 | <zewt> | that's nonsense |
| 16:39 | <gsnedders> | On the other hand, it might push more people into actually having CA-signed certificates for things not intended for consumption by web browsers, which really is often the case. |
| 16:40 | <jgraham> | I think requests checks? |
| 16:40 | <gsnedders> | requests is pretty much the only major Python HTTP client to do so. |
| 16:40 | <zewt> | i've never seen an https-based web service that didn't have a signed certificate |
| 16:40 | <gsnedders> | (At least according to what Alex_Gaynor claimed on Twitter. :)) |
| 16:40 | <zewt> | and not checking certificates would be nuts when communicating with a service about a user |
| 16:41 | <gsnedders> | zewt: See /topic |
| 17:11 | <Hixie> | zewt: how would you push prompt notifications to clients potentially behind a firewall without maintaining a TCP connection? |
| 17:43 | <JonathanNeal> | SteveF: did you end up reading http://www.jonathantneal.com/blog/introducing-subhead/ ? |
| 17:47 | <dglazkov> | good morning, Whatwg! |
| 22:39 | <Domenic_> | marcosc: Why don't you feel snapshots is working? It seems like a reasonable model from the outside. |
| 22:40 | <marcosc> | I've not seen anyone republish the specs... they also fall grossly out of date. I |
| 22:40 | <marcosc> | I'm worried people are going to go to the wrong spec |
| 22:40 | <Domenic_> | Hmm. |
| 22:41 | <marcosc> | Domenic_: to see what I mean, just google xmlhttprequest spec |
| 22:41 | <marcosc> | the w3c one comes up first ... and it's from... W3C Working Draft 6 December 2012 |
| 22:41 | <marcosc> | 2012 |
| 22:41 | <marcosc> | !!! |
| 22:41 | <marcosc> | ffs |
| 22:41 | <marcosc> | :( |
| 22:42 | <Domenic_> | right, but that's just a general problem with /TR always sucking :-/ |
| 22:42 | <marcosc> | no, that's the problem with the guys that are supposed to manage the snapshots not republishing |
| 22:42 | <Domenic_> | whether it's WHATWG LS vs. W3C Snapshot or W3C ED vs. W3C Snapshot |
| 22:43 | <marcosc> | TR doesn't have to suck that badly |
| 22:43 | <marcosc> | if the guys that have slapped their names on the spec would do their jobs |
| 22:44 | <Domenic_> | That's true |
| 22:44 | <marcosc> | if they are going to be copypastaing from the WHATWG, they should at least be publishing every 3 month |
| 22:44 | <marcosc> | it can't be that there is 3 people listed on that spec |
| 22:44 | <marcosc> | anyway... that's my concern :) |
| 22:45 | <Domenic_> | well, i'm curious to see where that thread goes :) |
| 22:47 | <marcosc> | Domenic_: I clarified my concern in a follow up |
| 22:48 | <TabAtkins> | What mailing list is this from? |
| 22:49 | <Domenic_> | public-webapps yo |
| 22:49 | <TabAtkins> | ...huh. I saw the very first email with the cfc for heartbeat, but haven't seen anything else. |
| 22:49 | <TabAtkins> | never mind, I'm dumb. |
| 22:49 | <TabAtkins> | I'm just auto-archiving too many things. |