| 06:50 | <roc> | hmm, I thought http://wiki.whatwg.org/wiki/Advice_for_people_writing_specs had more in it... |
| 06:56 | <Ms2ger> | http://wiki.whatwg.org/wiki/Howto_spec ? |
| 07:00 | roc | waits for that to load |
| 07:02 | <Ms2ger> | Looks like it's back |
| 07:08 | <roc> | thanks |
| 07:10 | <Ms2ger> | Np |
| 07:19 | <Ms2ger> | zcorpan, the answer to your hg question yesterday was "hg merge", fwiw |
| 07:37 | <kochi> | MikeSmith: ping? |
| 07:38 | <kochi> | Is Mike in US now? |
| 07:38 | <asmodai> | With Opera moving engine and all that, does it mean it will also share more of Chrome's WebDriver setup? |
| 08:19 | <darobin> | the W3C RF policy turns 10 this Sunday |
| 08:55 | <jgraham> | darobin: Planning a party? Will there be jelly and ice cream? |
| 08:56 | <jgraham> | In other news I note that all the "reformists" running for the AB are ex-Microsoft |
| 08:56 | <roc> | hehe |
| 08:57 | <roc> | the deprogramming takes a while, but it is effective |
| 12:31 | <gsnedders> | jgraham, ambv: is there anything for html5lib you want me to do *today*? |
| 12:32 | <ambv> | gsnedders: decide what to do about http://code.google.com/p/html5lib/issues/detail?id=162 |
| 12:32 | <ambv> | it's not moved to GitHub, found it by accident |
| 12:39 | <gsnedders> | ambv: Per myself and jgraham's attitude before, it's not a regression from our last couple of releases so not 1.0 material |
| 12:39 | <gsnedders> | ambv: On the other hand, I won't say no to fixing it. |
| 12:40 | gsnedders | wonders why that isn't moved over |
| 12:42 | <ambv> | gsnedders: you can also convince jgraham to adopt my proposed html5lib logo |
| 12:42 | <ambv> | https://github.com/ambv/html5lib-logo |
| 12:43 | <gsnedders> | I don't have jgraham's on a leash to convince him everything. :) |
| 12:43 | <ambv> | try this: "jgraham: FWIW I find ambv's logo better than no logo." |
| 12:44 | <ambv> | I'm specifically targetting this sad octocat here - https://github.com/html5lib |
| 12:44 | <gsnedders> | ambv: On the other hand, I can just ignore jgraham because I'm an owner of the Github organization. :P |
| 12:48 | <ambv> | :) |
| 12:49 | <ambv> | OTOH, I hate when somebody ignores me. |
| 12:51 | <gsnedders> | Especially since I'm spending a fair bit of time around him in the next week. After that I can more easily ignore him. :P |
| 13:09 | <jgraham> | gsnedders: Tell me why my critic install has decided it can't create directories when trying to fetch from github? |
| 13:09 | <jgraham> | That would be really useful |
| 13:09 | <jgraham> | Because at the moment I am geting like 100 error emails an hour |
| 13:10 | <gsnedders> | jgraham: Perms on the containing directory? |
| 13:10 | <gsnedders> | Dunno. |
| 13:11 | <jgraham> | Well that is the only thing I can think of too |
| 13:11 | <jgraham> | But it looks fine, and I have no idea why it would suddenly change |
| 13:12 | <ambv> | it's probably quietly suggestion migration to GitHub... |
| 13:12 | <ambv> | *suggesting |
| 13:14 | <jgraham> | You think 100 emails an your is quiet? |
| 13:15 | <jgraham> | That kind of insanity might also explain why you think that github reviews are useful :p |
| 13:17 | <Ms2ger> | an your? |
| 13:18 | <jgraham> | *an hour |
| 13:25 | <jgraham> | Oh |
| 13:25 | <jgraham> | hahaha |
| 13:25 | <jgraham> | I have run out of subdirectories |
| 13:25 | <jgraham> | I wonder if they are supposed to get cleaned up |
| 13:30 | <darobin_> | jgraham: not all the reformists are ex-MS, Virginie isn't for instance |
| 13:30 | <darobin_> | also, there is debate as to whether there may be some crypto-reformists in the rest :) |
| 13:41 | <jgraham> | darobin: It's hard to tell from the statements. I was going from tantek's list |
| 13:43 | <hsivonen> | does anyone have a (Member-confidential) link at hand for previous AC rep positions on permissive licensing? |
| 13:57 | <darobin> | hsivonen: well there are the previous votes, and probably some discussions in the ac-forum |
| 13:59 | <darobin> | hsivonen: I'm not sure if those are member-only or team-only: https://www.w3.org/2002/09/wbs/33280/htmllicense2010/results and https://www.w3.org/2002/09/wbs/33280/doclic201105/results |
| 13:59 | <darobin> | note however that some of the positions expressed there have changed |
| 13:59 | <darobin> | more than anything the results indicate confusion when faced with the PSIG license |
| 14:01 | <darobin> | a lot of confusion in fact; I wouldn't put much faith in the results in either direction |
| 14:42 | <ambv> | gsnedders: who owns http://www.ohloh.net/p/html5lib ? |
| 14:43 | <gsnedders> | ambv: I do, seemingly. |
| 14:43 | <ambv> | github it. |
| 14:44 | <ambv> | ungooglecode it. |
| 14:47 | <gsnedders> | ambv: Does Read the Docs just automatically just use README and CHANGES without any further setup? |
| 14:47 | <ambv> | no, but I set it up |
| 14:48 | <Ms2ger> | Looks like http://www.ohloh.net/p/html5lib is suddenly dead |
| 14:48 | <gsnedders> | ambv: Is there no anything in the repo? |
| 14:48 | <gsnedders> | Ms2ger: I renamed it to html5lib-python, though maybe it should just stay as html5lib |
| 14:48 | <ambv> | not finished yet, currently lives at https://github.com/ambv/html5lib-python/tree/doc/doc |
| 14:49 | <gsnedders> | Ah, it comes from your repo. |
| 14:49 | <ambv> | yeah, that's temporary |
| 14:49 | <gsnedders> | ambv: Would rather different section in docs for public API and internal APIs, FWIW |
| 14:49 | <gsnedders> | Hence html5lib.trie wouldn't appear in the public one. |
| 14:50 | <gsnedders> | Obv. the public API is more important. :) |
| 14:50 | <ambv> | sure, this is autogenerated |
| 14:50 | <gsnedders> | Ms2ger: Moved it back to html5lib, albeit with the new name. |
| 14:50 | <ambv> | next up: pruning it and commenting the code in a style that Sphinx understands as well |
| 14:50 | <Ms2ger> | gsnedders, ta |
| 14:51 | <ambv> | and moving the rest of the stuff from the "docs" at Google Code so we can kill it |
| 14:51 | <ambv> | and just leave a link to html5lib.rtfd.org |
| 14:51 | <gsnedders> | ambv: Yeah, getting as much from the docstrings would be nice. |
| 14:51 | <gsnedders> | *as much as possible |
| 14:51 | <gsnedders> | ambv: FWIW, seemingly anyone with an ohloh account can edit the html5lib page. |
| 14:52 | <ambv> | interesting. |
| 14:52 | <ambv> | what do you think about the rtfd.org effort so far? |
| 14:52 | <Ms2ger> | gsnedders, I think that's only as long as nobody claimed to be a manager |
| 14:52 | <gsnedders> | Ms2ger: Indeed. |
| 14:52 | <gsnedders> | Ms2ger: But that's the current state. |
| 14:53 | <ambv> | "User gsnedders does not exist" |
| 14:53 | <gsnedders> | ambv: I think it's a good idea, even if I was planning on doing it post 1.0. :) |
| 14:53 | <gsnedders> | ambv: On rtfd? |
| 14:53 | <gsnedders> | Or what? |
| 14:53 | <ambv> | yeah |
| 14:53 | <gsnedders> | Yes, I have no account. :) |
| 14:53 | <ambv> | I'll add you as a maintainer as well |
| 14:53 | <ambv> | increase the bus factor |
| 14:54 | Ms2ger | throws a bus at ambv |
| 14:54 | <ambv> | hey, that was a PCI bus |
| 14:56 | jgraham | votes himself in as a maintainer |
| 14:57 | <gsnedders> | jgraham: Should we leave you as maintainer in setup.py or not? |
| 14:58 | <jgraham> | gsnedders: I don't really see why not |
| 14:59 | <jgraham> | Seems kind of stupid that it should be a single person |
| 15:01 | <Ms2ger> | "a very low number of source code comments" |
| 15:01 | <jgraham> | I think automated quality analysis tools are kind of dumb |
| 15:02 | <jgraham> | Since they can't actually analyse quality only bad proxies |
| 15:03 | <jgraham> | It's not even that sure that the proxies are correlated with quality |
| 15:04 | <jgraham> | e.g. a high number of comments could indicate a lot of misleading comments, or code that has comments duplicating the functionality, or an over complex codebase |
| 15:04 | <jgraham> | s/functionality/code/ |
| 15:08 | ambv | added jgraham as a maintainer on rtfd.org |
| 15:10 | <hsivonen> | darobin: thanks |
| 15:10 | <jgraham> | ambv: Thanks |
| 15:11 | <ambv> | I'll push the docs to master when everything covered on code.google.com is in |
| 15:12 | <darobin> | hsivonen: if you want to dig more, there's w3c-ac-forum |
| 15:40 | <jgraham> | So sanitising with treewalkers is totally bust, since they have (namespace, name) pairs for attributes rather than just names, like the tokenizer emits |
| 15:40 | <jgraham> | This whole design is a bit dubious |
| 15:40 | Ms2ger | looks for a victim to review https://github.com/w3c/web-platform-tests/pull/95 |
| 15:41 | <jgraham> | Critic says me or annevk or zcorpan. Which isn't quite wrong. Although I would think that odinho should be on that list too. And gsnedders. And probably some others that aren't (ex-)Opera |
| 15:46 | <darobin> | does anyone here know where the people involved in the crazy toolkitchen shims for web components hang out? |
| 15:46 | <jgraham> | The Google offices? |
| 15:46 | <darobin> | heh |
| 15:47 | <darobin> | making their shit work isn't all that straightforward, to say the least |
| 15:47 | <Ms2ger> | odinho, hi :) |
| 15:47 | <ambv> | gsnedders: will we create and maintain 1.0 branch once it's released? ISTM it's possible to end up with 1.0.1 and 1.1.0. that will let us break API compatibility when required. |
| 15:51 | <jgraham> | Ms2ger: Nice tests |
| 15:51 | <Ms2ger> | jgraham, thank you :) |
| 15:53 | <jgraham> | I really wish github didn't have such a merge-happy default workflow :| |
| 15:55 | odinho | currently hiding |
| 15:55 | <Ms2ger> | odinho, oh, jgraham already reviewed |
| 15:55 | <ambv> | jgraham: it's the reason why it's successful. |
| 15:55 | <odinho> | phew |
| 15:56 | <Ms2ger> | odinho, http://i.qkme.me/3qih5c.jpg |
| 15:56 | <odinho> | That was fast. Either I'm very slow or I do it too detailed. I hope it's the last one, and then I should be more lenient :] |
| 15:57 | <gsnedders> | ambv: OTH, I'm trying to get any public API breakage in 1.0 so it doesn't matter. :P |
| 15:57 | <gsnedders> | ambv: Then it's relatively major things that will break lots which I'll call 2.0. We'll see. |
| 15:57 | <gsnedders> | Now, train. |
| 15:58 | <jgraham> | ambv: The reason that github is successful is that it only has default support for integrate-by-merge, not integrate-by-rebase? Interesting theory, please elaborate. |
| 15:58 | <ambv> | gsnedders: without a branch you'll have a hard time managing 1.0.2 and 2.0 at the same time. |
| 15:58 | <odinho> | ofc rebase would change the sha's. |
| 15:58 | <odinho> | But it could possibly have been an option. |
| 16:01 | <jgraham> | odinho: Well these tests followed a pretty clear pattern and were only testing a couple of lines of spec, so it wasn't the hardest review I've ever done |
| 16:03 | <odinho> | jgraham: Okay :] I didn't look much more than scroll through it and think "ouch, lots of lines :P" |
| 16:11 | <ambv> | jgraham: GitHub doesn't ever mention rebasing because it's fragile. They chose the straightforward option: merging. From GH's perspective if the user is interested in squashed commits, he should rebase when creating a pull request. If a project has a strict single-commit-PR policy, it should enforce it with their contributors. |
| 16:12 | <ambv> | This is why I was prepared to rebase my PRs on the go but we cannot use that since it breaks Critic. |
| 16:14 | <jgraham> | Rewriting commits that you already pushed, but pretending that nothing changed is just wrong |
| 16:14 | <jgraham> | But I don't see how rebasing is any more fragile than merging. |
| 16:14 | <ambv> | Excuse me but a merge is just another commit that you can revert. |
| 16:15 | <jgraham> | In either case the trivial case (where your branch is already based on master) is trivial |
| 16:15 | <jgraham> | And other cases require a human that understands what's going on |
| 16:15 | <jgraham> | I don't understand what point you are trying to make |
| 16:16 | <jgraham> | If anything a merge commit is *more* complicated than anything else |
| 16:16 | <jgraham> | Because it makes the history non-linear |
| 16:16 | <jgraham> | which makes it harder to understand |
| 16:16 | <jgraham> | and breaks e.g. git bisect |
| 16:16 | <ambv> | no, it's rebasing which breaks bisect. merge works just fine. |
| 16:17 | <Ms2ger> | Why would rebasing break bisect? |
| 16:17 | <jgraham> | OK, I think we must be talking past each other |
| 16:17 | <jgraham> | Because I don't understand how you can think that rebasing breaks bisect |
| 16:17 | <ambv> | Look. |
| 16:18 | <ambv> | Rebasing recreates history, potentially breaking its chronological order. Merging creates another chronological commit which is just like any other. |
| 16:19 | <jgraham> | Unless you mean that squashing breaks the ability to bisect within the squashed commits. Which is certainly true. But that's a totally different question compared to the method you use to get changes from topic branhces onto master |
| 16:19 | <jgraham> | Chronological of when things were committed on their topic branches seems entirely uninteresting |
| 16:20 | <TabAtkins> | Rebasing rewrites the original, *local* history. Assuming you're not rebasing after pushing, though, the central history was never rewritten, and is always linear and sane. |
| 16:20 | <jgraham> | And merge commits are clearly not like any other |
| 16:20 | <jgraham> | They have multiple parents |
| 16:20 | <jgraham> | So if you try and bisect you have to have some strategy for dealing with the non-linear history |
| 16:21 | <jgraham> | That's *clearly* more complex than the case where master always has a strictly linear history |
| 16:22 | jgraham | wishes there was some way to draw diagrams in IRC |
| 16:22 | <jgraham> | Maybe I could try abusing combining characters to fit it all in one line? :) |
| 16:23 | <Ms2ger> | ,--------, |
| 16:23 | <Ms2ger> | ----< >---- |
| 16:23 | <Ms2ger> | `--------� |
| 16:23 | <jgraham> | Yeah, I guess just drawing the diagram elsewhere and pasting would also work :p |
| 16:23 | <Ms2ger> | :) |
| 16:24 | <Ms2ger> | You could use <svg>...</svg> |
| 16:24 | <ambv> | TabAtkins: sure thing, which is why I think pull requests should be rebased when it makes sense. Specifically, pull requests should not have merge commits of their own. |
| 16:24 | <ambv> | But why would accepting a pull request have to end with a rebase is beyond me. |
| 16:24 | <jgraham> | Not sure that there's an irssi plugin that does svg :) |
| 16:24 | <TabAtkins> | Again, so that the master branch only ever has linear history. |
| 16:26 | <ambv> | TabAtkins: so when you later bisect knowing you had your last good commit on Monday and choose it as the "good", you might be surprised to find out a newer commit sitting *before* it in the linear history. |
| 16:27 | <TabAtkins> | If you're bisecting the master, but basing your memory of when commits happened on your activity in a feature branch, then sure? |
| 16:27 | <Ms2ger> | You mean that a commit can have an earlier timestamp than its parent? |
| 16:27 | Ms2ger | doesn't see the issue |
| 16:27 | <ambv> | Ms2ger: yes. |
| 16:29 | <ambv> | I agree that having many merge commits indicates a problem with your workflow. But avoiding merges at all costs doesn't look reasonable to me. |
| 16:29 | <jgraham> | A - B - C |
| 16:29 | <jgraham> | \ |
| 16:29 | <jgraham> | D - E - F |
| 16:29 | <jgraham> | Original tree |
| 16:29 | <jgraham> | A - B - C - - - M - |
| 16:29 | <jgraham> | \ / |
| 16:29 | <jgraham> | D - E - F |
| 16:29 | <jgraham> | Merge |
| 16:30 | <jgraham> | A - B - C - D' - E' - F' |
| 16:30 | <jgraham> | \ |
| 16:30 | <jgraham> | D - E - F |
| 16:30 | <jgraham> | Rebase |
| 16:30 | <jgraham> | To be clear, those are the two scenarios I'm talking about |
| 16:30 | <Ms2ger> | A - B - C - D' - E' - F' |
| 16:30 | <Ms2ger> | MQ |
| 16:30 | <Ms2ger> | Seems obvious what's simplest! :) |
| 16:31 | <jgraham> | Ms2ger: I think "having terrible support for local branches" is not simplest :p |
| 16:31 | <Ms2ger> | I've never had a need for a local branch |
| 16:32 | <ambv> | hm. |
| 16:32 | <ambv> | jgraham: Please elaborate. |
| 16:37 | <jgraham> | ambv: Well, I don't know what else to say. In the either case, you have a topic branch with 3 commits, whcih we assume are sensible atomic commits and have had all fixup!s squashed out of them. In the merge case, you keep your three original commits in the history, but at the expense of adding a merge commit that bifurcates the master branch and contains some of the information that is part of the patch (how merge conflicts were resolved). In the re |
| 16:42 | <ambv> | I think we violently agree here. Nobody wants "fixup!" commits in the history, nobody wants merge commits from branches which aren't considered long-lasting. The only thing I see we disagree on is "who should rebase" and "when". |
| 16:44 | <jgraham> | I don't want *any* merge commits in the history |
| 16:44 | <ambv> | You will after 1.0 |
| 16:44 | <jgraham> | That wasn't a html5lib related statement |
| 16:44 | <jgraham> | But why? |
| 16:45 | <ambv> | How else can you manage having 1.0.x and 2.0.x simultaneously? |
| 16:45 | <Ms2ger> | Not merge? |
| 16:46 | <jgraham> | I don't see what problem merges would solve there |
| 16:46 | <Ms2ger> | Unless you want a 3.0.x that's a hybrid? |
| 16:46 | <ambv> | git checkout 1.0; hack hack hack; git commit - and then - git checkout 2.0; git merge 1.0; done. |
| 16:47 | <ambv> | your fix is now included in both branches, history is clear about what happened. |
| 16:47 | <ambv> | if you end up copying and pasting your fixes across branches, you might as well start using FTP. |
| 16:48 | <jgraham> | I'm not convinced |
| 16:48 | <jgraham> | It's not clear that you should be developing on a stable branch |
| 16:48 | <jgraham> | It's not clear that all commits from a stable branch should be applied to master |
| 16:48 | <ambv> | You shouldn't do features. But you should do bugfixes on stable branches. |
| 16:49 | <jgraham> | If you have a bugfix that applies to multiple branches cherry-pick is your friend |
| 16:50 | <jgraham> | Trying to merge the two branches just seems like it would create a mess |
| 16:52 | <ambv> | Have you tried? Because clearly cherry-pick is just a glorified copy and paste. |
| 16:52 | <Ms2ger> | Yes and yes |
| 16:53 | <ambv> | For one thing, trying to answer the question "where else is that fix applied?" isn't trivial without merges. |
| 16:54 | <Ms2ger> | It's trivial if you put all that in bugzilla :) |
| 16:55 | <ambv> | and then you switch from code.google.com to GitHub and you're screwed. |
| 16:55 | <jgraham> | A - B - C - D - E - F - G (master) |
| 16:55 | <jgraham> | \ |
| 16:55 | <jgraham> | H - I - J (1.0 branch) |
| 16:55 | <jgraham> | A - B - C - D - E - F - G - M |
| 16:55 | <jgraham> | \ / |
| 16:55 | <jgraham> | H - I - J - - - - - - |
| 16:55 | <jgraham> | Merge |
| 16:55 | <jgraham> | A - B - C - D - E - F - G - J' |
| 16:55 | <jgraham> | \ |
| 16:55 | <jgraham> | H - I - J |
| 16:55 | <jgraham> | cherry-pick |
| 16:55 | <jgraham> | So it looks to me like you end up with a totally unwanted tree if you do what you suggest |
| 16:56 | <Ms2ger> | A dag |
| 16:57 | <jgraham> | And, yes, I have seen a cherry-pick based approach work well enough for releasing complex consumer software |
| 16:58 | <jgraham> | I meant "tree" as-in http://git-scm.com/book/en/Git-Internals-Git-Objects#Tree-Objects |
| 16:58 | <jgraham> | Or perhaps as-in "working tree" |
| 16:59 | <ambv> | Sure thing, it's possible to develop software with both approaches. Pointing to authority is a weak argument so I'll just stick to your example |
| 16:59 | <ambv> | J' is really H with no way of knowing it's the same commit apart from kludges like keeping the message the same or using Bugzilla |
| 17:00 | <jgraham> | J' is really J |
| 17:00 | <jgraham> | And yes, tracking is hard |
| 17:00 | <ambv> | If it applies cleanly. |
| 17:00 | <jgraham> | But at least youu get the right result (i.e. you don't get the unwanted commits H and I in your history) |
| 17:02 | <ambv> | The solution to that is null-merging changes you don't want to see in newer series. Not that common really. Foward merging is quite clean. |
| 17:02 | <jsbell> | I always think of this picture when someone is explaining branching: http://foofighter1111.files.wordpress.com/2012/05/bttfii_2.jpg |
| 17:03 | <jgraham> | jsbell: heh |
| 17:04 | <jgraham> | ambv: What's null-merging, and how does it allow you to end up with a tree equivalent to the rebase one above, but using merges? |
| 17:06 | <jgraham> | Also, if J' doesn't apply cleanly as J then of course you need to change it. But that's true in either case; it's just that in one case the commit holds all the information and in the other it's split over the commit and the merge commit |
| 17:07 | <ambv> | A null-merge is a commit stating two commits as parents but only keeping state from one of them |
| 17:08 | <jgraham> | So you have a reference? google didn't help |
| 17:09 | <jgraham> | (I still don't understand how that would help, since in this case you need history from *part* of one branch and all of the other. Which I think you can only do by splitting two branches into three and having a 1.0.x-and-master branch) |
| 17:18 | <ambv> | jgraham: I can't find any definition. Here's how we use it with Python development: http://hg.python.org/cpython/log?rev=null+merge |
| 17:19 | <ambv> | For instance: http://hg.python.org/cpython/rev/7a45415956b9 -> change baseline: be6bbc9f0561 122d42d5268e current baseline: be6bbc9f0561 |
| 17:36 | <ambv> | So you null merge what you don't want, and then merge what you wanted separately. It's not perfect but it lets us minimize heads. If you apply a bugfix and see that all 3.x branches besides "default" are inactive, your work is done. |
| 17:41 | <ambv> | jgraham: Oh, actually it is documented here - http://docs.python.org/devguide/faq.html#how-do-i-make-a-null-merge |
| 17:46 | <gsnedders> | ambv: I just hope we don't have too much need for bugfix releases. :) |
| 17:46 | <gsnedders> | ambv: Or API changes. :) |
| 17:46 | <ambv> | :) |
| 17:47 | <gsnedders> | ambv: tl;dr: will create a 1.0.x branch when needed, IMO |
| 17:47 | <gsnedders> | :P |
| 17:49 | <ambv> | Sure. We can even do with cherry-picking since the project is small. If only git provided more metadata in the cherry-picked comment, it would be quite attractive. |
| 17:50 | <gsnedders> | Personally, at least, I tend to be very conservative with what goes in bugfix releases. |
| 17:50 | <gsnedders> | So cherry-picking works well. :P |
| 17:52 | <gsnedders> | What's the sdtatus wrt templates in HTML, BTW? |
| 17:52 | <gsnedders> | (People who, like, read the mailing list? :P) |
| 17:52 | <TabAtkins> | The <template> element, you mean? |
| 17:52 | <TabAtkins> | I think it's proceeding okay. |
| 17:53 | <gsnedders> | Is there any intention to move the parser stuff into HTML, I mean. |
| 17:53 | <TabAtkins> | I thought it got moved into the DOM Parsing spec? |
| 17:54 | <gsnedders> | Doesn't appear to have been? |
| 17:54 | <gsnedders> | Ms2ger: ^^ |
| 17:54 | <gsnedders> | TabAtkins: Would be nice to have everything that changes the parse tree in one spec, IMO |
| 17:59 | <Ms2ger> | What? |
| 17:59 | <Ms2ger> | The parser is defined in HTML |
| 18:00 | <Ms2ger> | So that's where extensions should be |
| 18:00 | <gsnedders> | dglazkov: You! |
| 18:01 | <gsnedders> | dglazkov: What's the status of moving parsing HTML templates into the HTML spec? |
| 18:03 | <ambv> | gsnedders: I separated contributing information to CONTRIBUTING.rst so it's picked up by GitHub when somebody creates a pull request. I also expanded it, have a look if it reads right to you: https://github.com/ambv/html5lib-python/blob/contributing/CONTRIBUTING.rst |
| 18:04 | <gsnedders> | ambv: Do we want changelog entries for *everything*? |
| 18:04 | gsnedders | is unconvinced by this approach in general |
| 18:05 | <gsnedders> | Like, as an end-user of a library I tend to primarily want to know what APIs have changed and anything major. |
| 18:06 | <ambv> | I agree. We don't have AUTHORS so the changelog would be where attribution goes. |
| 18:07 | <ambv> | If we introduce AUTHORS, then we can clean up the changelog for every release. |
| 18:07 | <ambv> | The changelog is not so much about "what" but about "why". |
| 18:14 | <ambv> | gsnedders: so, separating AUTHORS. yay or nay? |
| 18:37 | <jgraham> | ambv: Oh I see. Yes I guess that would work, but it seems rather complicated and confusing compared to just cherry-picking |
| 18:38 | <ambv> | I agree both approaches have their good and bad sides ;-) |
| 18:38 | <ambv> | Python uses cherry picking as well between 2.7 and 3.x |
| 18:38 | <jgraham> | I mean it basically amounts to having to explicitly mark every commit that *isn't* on some branch |
| 18:39 | <ambv> | because the 2.7 and 3.x branches diverged so much it would not be feasible to maintain them together |
| 18:42 | <ambv> | jgraham: what do you think about https://github.com/ambv/html5lib-python/blob/contributing/CONTRIBUTING.rst and https://github.com/ambv/html5lib-python/blob/contributing/AUTHORS.rst |
| 18:49 | <manu-db> | TabAtkins: Do you have anyone on the Chrome team that is interested in browser-based payments? |
| 18:50 | <manu-db> | We are looking for a rep from Chrome team to show up to the next Web Payments telecon (we're discussing the Mozilla/FirefoxOS payments API): http://lists.w3.org/Archives/Public/public-webpayments/2013May/0041.html |
| 18:51 | <manu-db> | paul_irish: Previous two lines - if you could get someone from Chrome to show up for the Web Payments telecon discussing Firefox OS' browser-based payment API, that would be great. |
| 18:53 | manu-db | looks around for someone from Opera and the Safari team... hober, know of anyone at Apple that would be interested? |
| 18:55 | <ambv> | gsnedders: jgraham: you guys are from the Opera team, right? ^^^ |
| 18:56 | <Ms2ger> | I guess jgraham might even count as Mobile |
| 18:56 | <odinho> | I have been reading the mailing list, but I'm not on specs any more. |
| 18:56 | <Ms2ger> | odinho, if you like specs, it seems Mozilla is hiring a lot of such people :) |
| 18:57 | <odinho> | Ms2ger: Indeed. I actually flamed Mozilla a bit for having waaay to few spec people at a Firefox OS presentation here in Oslo. And without any relation (I'm quite sure) Moz started hiring lots of spec people after that :-) |
| 18:58 | <Ms2ger> | odinho, I've said it for a long time, but it doesn't seem to have helped much until you came in ;) |
| 18:59 | <Ms2ger> | odinho, sounds like you're the better troll here! |
| 18:59 | <odinho> | Well. They said Mozilla specced XHR, and went on with the "we defend the open web" thing. In front of hundreds of people. |
| 19:00 | <Ms2ger> | Good I wasn't there, I'd have had to boo :) |
| 19:00 | <odinho> | So I said, hello, I'm from Opera, -- and you could see they were going shit-shit-shit :P |
| 19:01 | <Ms2ger> | "... and we specced XHR first." |
| 19:01 | <odinho> | Hehe. :-) |
| 19:14 | <gsnedders> | ambv: Yes. |
| 19:14 | <ambv> | looks nice, didn't notice html5lib had so many contributors |
| 19:14 | <gsnedders> | manu-db: I already prodded people internally, FWIW. |
| 19:15 | <manu-db> | gsnedders: thanks, appreciate that :) - if you want to e-mail me privately to shove somebody specific in the right direction, I'd be willing to do that. :P |
| 19:16 | <manu-db> | gsnedders: currently cc'ing Bruce Lawson on an e-mail about the upcoming browser payments telecon. |
| 19:16 | <ambv> | BBL, possibly in 2 hours |
| 19:29 | <jgraham> | gsnedders: Internal prodding sounds painful |
| 19:48 | <TabAtkins> | manu-db: Yes, yes I do. Talk to esprehn⊙gc |
| 19:53 | <manu-db> | much obliged, TabAtkins :) - I'll ping them. |
| 19:58 | <manu-db> | jgraham: questioning gsnedders prodding methods is grounds for prodding... |
| 21:19 | <esprehn> | manu-db: what time is this telecon? |
| 21:25 | <manu-db> | esprehn: 8am PST |
| 21:28 | <manu-db> | esprehn: Web Payments telecon on browser payment API call details are here: http://lists.w3.org/Archives/Public/public-webpayments/2013May/0041.html |
| 21:34 | <esprehn> | ok, I can make that |
| 21:41 | <annevk> | TabAtkins: so in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20600 are you not concerned with selectors requiring dropping unknown pseudo-elements on the floor and WebKit/Chrome not matching that model? |
| 21:43 | <manu-db> | esprehn: great, glad you'll be able to make it. :) |
| 21:54 | <TabAtkins> | annevk: I'm okay with Selectors changing the required behavior to match what Web Components needs. |
| 21:54 | <annevk> | I still don't see what's wrong with something like ::part(ident) |
| 21:55 | <annevk> | I don't see why we need to deviate from the established selectors model that is. |
| 21:55 | <TabAtkins> | annevk: Nothing wrong with it, except that it's longer than we'd ideally like, and it means that built-in components and author-defined components dont' use the same mechanisms. |
| 21:56 | <annevk> | They don't already... |
| 21:56 | <TabAtkins> | Not with x-, no. But with "starts with -", they would. |
| 21:57 | <annevk> | Why, the ones we'd mint would not start with - |
| 21:57 | <annevk> | And the ones we'd mint would affect the parser of selectors... |
| 21:57 | <TabAtkins> | Depends on if we'd set that as the required pattern or not. ^_^ |
| 21:57 | <annevk> | Well that ship has kinda already sailed with form controls which we're explaining in terms of this... |
| 21:58 | <annevk> | And if you don't think that ship has sailed, they could both use ::part :) |
| 22:00 | <esprehn> | ::part seems pretty weird |
| 22:00 | <TabAtkins> | Form controls currently use a "starts with - and a prefix" pattern. |
| 22:01 | <annevk> | Hmm... http://www.w3.org/TR/css3-ui/#pseudo-elements |
| 22:02 | <TabAtkins> | I think IE might implement ::value. The other three don't exist, but tantek is being stubborn and won't remove them. |
| 22:02 | <TabAtkins> | We also have ::placeholder. |
| 22:03 | <annevk> | I guess I could be okay with ::- but it seems kinda magic... |
| 22:04 | <TabAtkins> | Current element naming is kinda magic, too, since we only require that it has a dash in the name somewhere. |
| 22:05 | <tantek> | TabAtkins - which would you like me to remove? |
| 22:05 | <TabAtkins> | ::choices, ::repeat-index, and ::repeat-item |
| 22:06 | <TabAtkins> | They won't survive CR, I guarantee. |
| 22:06 | <TabAtkins> | So might as well chop them now. |
| 22:06 | <annevk> | TabAtkins: note that there we actively try to avoid clashes between what authors and specs can introduce |
| 22:06 | <TabAtkins> | And xforms is dead. |
| 22:06 | <annevk> | TabAtkins: which is contrary to this ::- proposal |
| 22:06 | <tantek> | TabAtkins - not stubbornness, just haven't edited the draft to do so yet |
| 22:06 | <tantek> | consider them gone |
| 22:06 | <tantek> | they've been at risk for so long |
| 22:06 | <TabAtkins> | tantek: Long-term lack of editting looks like stubbornness from the outside. ^_^ |
| 22:06 | <tantek> | and no-one cares to implement |
| 22:07 | <tantek> | TabAtkins, never ascribe to stubborness what you can ascribe to laziness. |
| 22:07 | <TabAtkins> | tantek: Also: I'm half a bottle of wine in, so I may be a little more abrasive than usual right now. |
| 22:07 | <tantek> | (or intertia) |
| 22:07 | <tantek> | inertia even |
| 22:08 | <tantek> | btw, speaking of removing things, the TV people are still complaining about the impending axing of the nav-* directional properties. |
| 22:08 | <annevk> | heh |
| 22:08 | <TabAtkins> | Produce a browser that someone cares about, and we can talk. |
| 22:08 | <tantek> | btw, even ::value has not shown to be especially well adopted, might punt that to CSS4-UI also |
| 22:08 | <tantek> | hence the note |
| 22:09 | <annevk> | it seems better to nuke those pseudo-elements indeed |
| 22:09 | <tantek> | yeah we'll just keep going to last call maybe |
| 22:09 | <annevk> | and instead of from the perspective of CSS, consider what we need from the perspective of web componentizing form controls |
| 22:09 | <TabAtkins> | I'd keep ::value around until the f2f (and put an agenda item in for it) |
| 22:09 | <a-ja> | aren't ::value and ::placeholder kinda tied together? |
| 22:10 | <TabAtkins> | a-ja: Maybe! |
| 22:10 | <TabAtkins> | Or rather, they *could* be, if we want to take them in that direction. |
| 22:10 | <tantek> | TabAtkins - nah, hence postponing to CSS4-UI rather than outright dropping (unlike the other three) |
| 22:10 | <tantek> | no need to keep it in 3 |
| 22:10 | <tantek> | Tab are you going to be around at I/O? |
| 22:11 | <TabAtkins> | tantek: I'll be in the south bay for I/O. |
| 22:11 | <TabAtkins> | ie. not at i/o. |
| 22:11 | <tantek> | remote i/o |
| 22:16 | <annevk> | DHTML: document.write(); Ajax: XMLHttpRequest; HTML5: CSS3 |
| 22:16 | <annevk> | aah forgot Web 2.0 |
| 22:16 | <annevk> | Web 2.0: SEO |
| 22:16 | <TabAtkins> | web 2.-: jquery |
| 22:30 | <SimonSapin> | TabAtkins: what specifies the case-sensitivity of counter *names*? |
| 22:31 | <SimonSapin> | coundn’t |
| 22:31 | <TabAtkins> | SimonSapin: The fact that they're a user-defined identifier? |
| 22:31 | <SimonSapin> | couldn’t find it in 2.1, or lists 3 |
| 22:31 | <TabAtkins> | I'm probably not invoking the grammar properly right now. |
| 22:31 | <SimonSapin> | hum, ok |
| 22:32 | <SimonSapin> | TabAtkins: yeah, should be <custom-ident> (defined in Values 3) rather than <ident> |
| 22:32 | <TabAtkins> | Yes. |
| 22:35 | <SimonSapin> | TabAtkins: do you have it written somewhere, or should I send this to www-style? |
| 22:35 | <TabAtkins> | No, go ahead and send it to www-style so I'll pick it up when I'm next ready to work on those specs. |
| 22:57 | <annevk> | TabAtkins: are you free Monday? |
| 22:58 | <annevk> | TabAtkins: or maybe Sunday or some such? |
| 22:58 | <nimbu> | annevk: are you still here?! |
| 22:58 | <annevk> | nimbu: uhuh |
| 22:58 | <TabAtkins> | annevk: I'm working with fantasai Monday, but otherwise kinda free. |
| 22:59 | <TabAtkins> | Sunday I'm available in the morning/early afternoon. After that my wife's home. |
| 22:59 | <TabAtkins> | Also: were you on the Google campus this afternoon? |
| 23:00 | <annevk> | TabAtkins: wasn't |
| 23:00 | <annevk> | TabAtkins: Sunday morning would be nice, will ping you around then |
| 23:00 | <hober> | annevk: fyi the hangover helped put me in the right mood for wednesday's dnt meeting, thanks! :) |
| 23:00 | <annevk> | TabAtkins: oh actually, might get tricky too |
| 23:00 | <annevk> | hober: hehehe |
| 23:07 | <zewt> | gar where the heck did blocking sites in google search results go |
