| 02:18 | <kochi> | morning, whatwg! |
| 02:36 | <zewt> | i guess |
| 05:05 | <annevk5> | Hmm, nested URL schemes... |
| 05:07 | <SimonSapin> | like git+http: ? |
| 05:21 | <annevk5> | no, like view-source or jar |
| 05:22 | <annevk> | my initial plan was to not support them, but it seems like jar might be liked enough to justify adding either some kind of parser exception or whatever Gecko is doing at the moment |
| 05:24 | <SimonSapin> | annevk: "A relative scheme is a scheme listed in the first column of the following table." Is this table set in stone, or are applications expected to add to it? |
| 05:24 | <annevk> | if it needs to be bigger, the table should be expanded |
| 05:30 | <SimonSapin> | annevk: the git-clone man page lists ssh: git: ftps: rsync: |
| 05:31 | <SimonSapin> | but I don’t expect these to be supported by a browser |
| 05:32 | <annevk> | it's also not necessarily all URL schemes ever, they need to parse in a certain way too |
| 05:33 | <SimonSapin> | also, some Python packaging tools support multiple VCSs by having syntax like git+<URL> or hg+<URL> |
| 05:33 | <annevk> | but we can definitely expand it if there's need, this is just an initial set |
| 05:33 | <SimonSapin> | so you end up with hg+http: git+http: git+ssh: … |
| 05:33 | <SimonSapin> | I’m asking whether we should |
| 05:34 | <SimonSapin> | people are gonna keep inventing crazy schemes for their use |
| 05:34 | <SimonSapin> | should the URL Standard maintain a registry that people ask being added to? |
| 05:35 | <annevk> | oh, that'd be kinda separate |
| 05:35 | <annevk> | yeah, there should be a registry somewhere of what's in use |
| 09:11 | <jgraham> | zcorpan: FWIW I think the correct response to the title of the differences document is "you are wasting my time and the time of everyone on the mailing list. Please stop." |
| 09:11 | <jgraham> | Although perhaps not in quite such a blunt way :) |
| 09:12 | <jgraham> | *discussion on the title of the |
| 09:12 | <zcorpan> | yeah |
| 09:12 | <zcorpan> | or maybe i should stop responding |
| 11:12 | <hsivonen> | Did the HTML WG chartering discussion for which there are no public minutes get minuted Member-confidentially? |
| 11:14 | <gsnedders> | Are charter discussions not normally AB-confidential? |
| 11:18 | <hsivonen> | gsnedders: dunno |
| 11:19 | <hsivonen> | w3cmemes suggested that chartering was discussed at a WG meeting rather than an AB meeting |
| 11:19 | <hsivonen> | I might have misunderstood w3cmemes |
| 11:20 | <gsnedders> | It's often discussed at a WG meeting, but the WG can't do anything but shout at the AB, I believe. |
| 11:30 | <hallvors> | should setRequestHeader() accept input of any length, even very long strings? |
| 11:36 | <jgraham> | Why wouldn't it? |
| 11:38 | <SteveF> | hsivonen: there was some responses to comments on the charter in https://lists.w3.org/Archives/Member/w3c-archive/ |
| 11:45 | <hallvors> | jgraham: assuming implementations have some limitations on how much data they accept, if so perhaps the method should throw when exceeding them or someting..? |
| 12:20 | <zcorpan> | hallvors: that usually falls under the "hardware limitations" clause |
| 12:21 | <zcorpan> | hallvors: (do impls have limitations?) |
| 12:21 | <hallvors> | OK. JS is genetically engineered to not bother about OOM I guess |
| 12:21 | <zcorpan> | right |
| 12:34 | <ambv> | gsnedders: re https://critic.hoppipolla.co.uk/showcomment?chain=153 - this is not an etree test, this is a dom test which was missing before (there were only tests for simpletree in fact). now I test both. |
| 12:35 | <ambv> | I agree with hardcoding {namespace}html, will do that momentarily |
| 12:48 | <gsnedders> | ambv: I mean I'd rather use html5lib.parse("<html>", treebuilder="dom") or so instead of hardcoding dom.TreeBuilder. |
| 12:49 | <gsnedders> | ambv: Because dom.TreeBuilder is really legacy and should be got at through dom.getTreeBuilder(minidom) |
| 12:49 | <ambv> | I changed that to use treebuilders.getTreeBuilder("dom"), is that okay too? |
| 12:49 | <gsnedders> | Yeah, that's fine. |
| 12:50 | <ambv> | also, https://critic.hoppipolla.co.uk/showcomment?chain=152 |
| 12:51 | <gsnedders> | ambv: Responded |
| 12:53 | <gsnedders> | ambv: https://github.com/html5lib/html5lib-python/pull/47 |
| 13:01 | <ambv> | is lxml.etree still limited compared to xml.etree? |
| 13:02 | <gsnedders> | ambv: It handles doctypes entirely differently to xml.etree |
| 13:06 | <ambv> | gsnedders: you should wait with your other pull requests so that you could fill in CHANGES.rst :P |
| 13:07 | <ambv> | I'll help with scraping information from the git logs for older releases |
| 14:10 | <ambv> | jgraham: gsnedders: DjangoCon EU is next week, I would want to make a lightning talk on html5lib 1.0 on it |
| 14:11 | <jgraham> | Nice idea |
| 14:11 | <ambv> | we will need 1.0 to be ready by that time, ideally with a new homepage and docs :> |
| 14:13 | <jgraham> | Hahaha |
| 14:13 | <jgraham> | But seriously… |
| 14:13 | <jgraham> | I think it's a good idea to do a talk whether or not 1.0 is ready |
| 14:13 | <jgraham> | And I think a new homepage and docs are also a good idea |
| 14:14 | <jgraham> | But I don't see us having some beautiful homepage and perfect docs in a week |
| 14:14 | <ambv> | well |
| 14:14 | <ambv> | We don't have to write a book |
| 14:14 | <jgraham> | Actually I don't see us having a beautiful homepage ever, unless someone with some design skills gets involved |
| 14:15 | <ambv> | And a homepage like html5lib.rtfd.org with the default theme (like http://kazoo.readthedocs.org) is totally enough |
| 14:15 | <ambv> | it's nice, standard and looks good |
| 14:16 | <jgraham> | Sure a page on readthedocs.org would be nice |
| 14:16 | <ambv> | this can be done by next week |
| 14:16 | <jgraham> | Yeah, that seems somewhat achiveable |
| 14:16 | <ambv> | AFAIU all the issues gsnedders wanted to close for 1.0 are either closed or a PR is waiting for being merged |
| 14:21 | <annevk> | "WebIDL level 1 is likely to be finished in a few months, with level 2 work ongoing." this would surprise me if actually true |
| 14:37 | <darobin> | annevk: where is that from? |
| 14:37 | <annevk> | darobin: chaals' summary |
| 14:40 | <gsnedders> | ambv: Using Sphinx and then readthedocs was kinda my plan |
| 14:40 | <gsnedders> | ambv: Though I was planning on shipping 1.0 without it :P |
| 14:40 | <gsnedders> | jgraham: Any thoughts on changing the maintainer? |
| 16:09 | <dglazkov> | good morning, Whatwg! |
| 16:35 | <matjas> | “That WhatWG doc sows confusion and should disappear.” — http://twitter.com/awbjs/status/331807099417923585 |
| 16:35 | <matjas> | it disappearing is pretty much the end goal, indeed |
| 16:36 | <matjas> | but the “confusion” part is confusing |
| 16:38 | <Ms2ger> | AFAICT, Allen is a troll |
| 16:39 | <annevk> | Ms2ger, also editor of ES6 |
| 16:39 | <Ms2ger> | Yeah |
| 16:40 | <miketaylr> | isn't IE11 adding __defineGetter__? |
| 16:40 | <miketaylr> | (allegedly) |
| 16:40 | <Ms2ger> | So I also get to blame him for using Word |
| 16:40 | <annevk> | But yeah, that's not a nice thing to say. Especially since he hasn't defined basic things that are part of JS such as <!--, -->, date parsing, etc. |
| 16:40 | <annevk> | Although matjas' document does not define date parsing either thus far. |
| 16:43 | <matjas> | miketaylr: hmm, IE did close my bug reports as WONTFIX |
| 16:43 | <miketaylr> | matjas: http://fremycompany.com/BG/2013/Internet-Explorer-11-9385-new-features-771/ |
| 16:43 | <miketaylr> | of course that's "leaked" or whatever |
| 16:43 | <matjas> | miketaylr: oh wow! interesting |
| 16:43 | <annevk> | matjas, well well, https://twitter.com/awbjs/status/331812114333319170 |
| 16:44 | <annevk> | matjas, there might be hope yet :) |
| 16:44 | <matjas> | annevk: \o/ |
| 16:53 | <matjas> | https://bugs.ecmascript.org/show_bug.cgi?id=1471 now to file bugs for everything else in Web ECMAScript… |
| 16:53 | <annevk> | thanks matjas |
| 16:57 | <matjas> | i wish i could work on this full time for a few weeks or so |
| 17:02 | <annevk> | matjas: how's the teaching going? |
| 17:12 | <matjas> | annevk: it’s both awesome and tiresome |
| 17:18 | <GPHemsley> | Argh, just noticed I never pushed the change to mimesniff I made back in March, which swapped "MIME type" for "media type" |
| 17:18 | <annevk> | why rename that? :/ |
| 17:20 | <GPHemsley> | change goes <- |
| 17:21 | <GPHemsley> | the argument at the time was to leave "media type" for CSS |
| 17:22 | <GPHemsley> | also, just realized that mimesniff is being treated as a "fork" for contribution considerations, meaning github is waiting for changes to merge "upstream" |
| 17:25 | <annevk> | GPHemsley: I'm not following. Leaving media type for CSS is exactly what we want I think. Also, MIME type is way more established within our set of documents. |
| 17:25 | <GPHemsley> | annevk: And I'm saying that's exactly what this commit delivers |
| 17:25 | <GPHemsley> | "media type" was replaced with "MIME type" |
| 17:26 | <annevk> | GPHemsley: maybe I misunderstand the concept 'swapped "MIME type" for "media type"' then. |
| 17:26 | <GPHemsley> | ;) |
| 17:27 | <annevk> | "Give (one thing) and receive something else in exchange." hmm |
| 17:27 | <annevk> | oh well |
| 17:28 | <GPHemsley> | it's ambiguous, I admit |
| 17:28 | <GPHemsley> | but I think we're on the same page now :) |
| 17:30 | <GPHemsley> | annevk: Do you know if platform.html5.org also has any intention of being "upstreamed" to Michael Smith's user repo? (I can include it in my support request if we want it converted to a "normal" repo.) |
| 17:32 | <GPHemsley> | MikeSmith: Oh, ^^ |
| 17:37 | <annevk> | GPHemsley: oh no, it's the new repo |
| 17:38 | <annevk> | GPHemsley: we're all pushing to that one now |
| 17:51 | <MikeSmith> | GPHemsley: what annevk said |
| 18:00 | <GPHemsley> | annevk, MikeSmith: OK, I'll include it in my support request, then. |
| 18:24 | <smaug____> | someone started to write a spec for selection |
| 18:24 | <smaug____> | where might that be |
| 18:25 | <jgraham> | https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selections |
| 18:27 | <jgraham> | This mixed content blocking thing breaks sites :| |
| 18:51 | <manu-db> | For those of you that are interested in browser-based payments - https://manu.sporny.org/2013/browser-payments/ |
| 18:52 | <manu-db> | We're having a call on that spec next week (open to the public) - it would be good to have someone there from Opera, Safari, and Chrome team. |
| 18:54 | <manu-db> | non-HTTPS link: http://manu.sporny.org/2013/browser-payments/ (other one throws up a cert warning) |
| 20:06 | <ambv> | \o/ simpletree is no more. |
| 20:12 | <annevk> | you guys killed it? |
| 20:12 | <annevk> | aw |
| 20:13 | <ambv> | yup, etree is the default now. |
| 20:15 | <gsnedders> | annevk: mwhahaha! |
| 20:15 | <annevk> | gsnedders: heh |
| 20:20 | <gsnedders> | annevk: Speaking of which, I might be at your end of the country sometime in the next month or two. |
| 20:21 | <annevk> | gsnedders: given an opportune time, I might be too :-) |
| 20:21 | <jgraham> | They gave annevk a whole end of the country? |
| 20:21 | <ambv> | gsnedders: I'm updating the change log for stuff merged since 0.95 |
| 20:22 | annevk | is doing this crazy LHR-SFO-LHR-TSA-LHR-NRT-LHR thingie |
| 20:24 | <jgraham> | You're planning a stay with the TSA? |
| 20:24 | <annevk> | it's not just an agency apparently |
| 20:24 | <tantek> | Taiwan? |
| 20:25 | <annevk> | tantek: yeah |
| 20:25 | <tantek> | bummer of a TLA |
| 20:26 | <annevk> | heh |
| 20:28 | <gsnedders> | ambv: Good luck. I was planning on only caring about API changes. :) |
| 20:28 | <ambv> | people are curious |
| 20:32 | <jgraham> | They are? I assume people only read changelogs to find out why stuff broke. Or to learn about new features, perhaps. |
| 20:38 | <ambv> | I'm often curious and nervous if I don't see a change log on a library *before* I update |
| 20:38 | <ambv> | writing mission critical software is no fun |
| 20:44 | <ambv> | gsnedders: https://github.com/html5lib/html5lib-python/blob/master/html5lib/serializer/htmlserializer.py#L9 - this can be removed as well, I presume. |
| 21:00 | <gsnedders> | ambv: You have push access. Go change. :) |
| 21:00 | <ambv> | \o/ |
| 21:01 | <gsnedders> | ambv: In general though, review-then-commit. |
| 21:02 | <ambv> | sure thing, I see that you do that, so I will too, naturally. |
| 21:03 | <ambv> | …but I still don't like Critic. <unsee who="jgraham"/> |
| 21:19 | <heycam> | annevk, "finished" = addressed the open issues; I'm going to try for that few month deadline |
| 21:19 | <annevk> | heycam: I'm missing some context I'm afraid |
| 21:20 | <heycam> | <annevk> "WebIDL level 1 is likely to be finished in a few months, with level 2 work ongoing." this would surprise me if actually true |
| 21:20 | <annevk> | aah |
| 21:20 | <annevk> | well, it's been a few months for a few years now :p |
| 21:20 | <heycam> | yes ;) |
| 21:27 | <annevk> | I kinda thought ES guys were about less magic. But now they're coming up with this concept of a single string to mean either an absolute URLs or module name... |
| 21:56 | GPHemsley | responds to a thread from March about <a download> |
| 22:06 | <gsnedders> | ambv: Is there any decent way to "increment" a string in Python? Like, treating it as a base 0x110000 number? So "a\x00" became "a\x01" and "a\U0010FFFF" became "b\x00"? |
| 22:07 | <gsnedders> | Well, base sys.maxunicode + 1 |
| 22:15 | <jsbell> | gsnedders: I had to implement that in JS last week, oddly enough. |
| 22:18 | <ambv> | gsnedders: |
| 22:18 | <ambv> | >>> import struct |
| 22:18 | <ambv> | >>> b = b'a\x00' |
| 22:18 | <ambv> | >>> new_value = struct.unpack('>q', b.rjust(8, b'\x00'))[0] + 1 |
| 22:18 | <ambv> | >>> struct.pack('>q', new_value).lstrip(b'\x00') |
| 22:18 | <ambv> | b'a\x01' |
| 22:21 | <gsnedders> | ambv: But for Unicode strings? |
| 22:21 | <gsnedders> | Easy in the narrow build case, but wide builds not so much. |
| 22:22 | <ambv> | Let me see but I don' see any method right away. |
| 22:23 | <ambv> | You'd have to find a custom encoding that lends well to bitwise incrementing. Or increment by hand :/ |
| 22:26 | <gsnedders> | jsbell: Come up with anything nice? |
| 22:26 | <jsbell> | my lame JS approach: https://gist.github.com/inexorabletash/5462871 (note: JS has only 16-bit strings) |
| 22:27 | <gsnedders> | jsbell: Yeah, JS makes it easy by having a nice round number of bits. :( |
| 22:29 | <jsbell> | (for the record, it's only used in the context of lexicographical compares of 16-bit code unit sequences, so I can pretend UTF-16 surrogate pairs don't exist) |
| 22:32 | <GPHemsley> | MikeSmith: Just forwarded you an e-mail about GitHub. You need to authorize a change to your local platforms.html5.org repo. |
| 22:41 | <gsnedders> | ambv: Can you rebase/push #49? (Don't use GitHub's PR merge, because needless merge commits.) |
| 22:42 | <ambv> | sure |
| 22:44 | <gsnedders> | ambv: Basically, once review accepted and provided Travis passes, go rebase and push yourself from now on. |
| 22:46 | <GPHemsley> | FTW, mimesniff is now a "normal" repository, rather than a fork |
| 22:53 | <GPHemsley> | annevk: Are you aware that the dom repo as a .DS_Store file? |
| 22:53 | <GPHemsley> | s/as/has/ |
| 22:53 | <odinho> | Those hipsters! |
| 22:53 | <GPHemsley> | xhr too |
| 22:55 | <annevk> | I wasn't, but I can remove that |
| 22:55 | <GPHemsley> | I think I have .DS_Store in my user gitignore file |
| 22:56 | <GPHemsley> | yeah, ~/.gitignore_global |
| 22:57 | <annevk> | platform.html5.org is still a fork |
| 22:58 | <annevk> | what's the deal with that anyway? does it matter? |
| 23:02 | <GPHemsley> | annevk: Yeah, waiting on MikeSmith to authorize a switch; it affects a user's contributions on their profile. |
| 23:03 | <GPHemsley> | annevk: If a repo is a fork, a user won't get credit for it until it gets merged "upstream". |
| 23:03 | <annevk> | GPHemsley: oh, his would become a fork of ours at that point? |
| 23:03 | <GPHemsley> | yeah |
| 23:04 | <annevk> | would easily become our most popular repo then |
| 23:04 | <GPHemsley> | by what measure? |
| 23:04 | <GPHemsley> | oh, forks |
| 23:04 | <GPHemsley> | wow |
| 23:05 | <GPHemsley> | I didn't realize there were so many |
| 23:05 | <GPHemsley> | I wonder how that will play out |
| 23:05 | <GPHemsley> | (most are forks of Mike's repo, rather than WHATWG's) |
| 23:06 | <GPHemsley> | and it doesn't look like anyone else has actually made changes to their forked repos |