| 08:53 | <annevk> | Does anyone know an email client on iOS that only emits text/plain emails? |
| 08:54 | <annevk> | (That doesn't require ssh to use Mutt on some far away server.) |
| 09:23 | <nox> | annevk: Why does NodeIterator need a special pre-remove hook exactly? |
| 09:26 | <nox> | I don't see what it does that couldn't be done with the removing steps. |
| 09:30 | <nox> | What did it make possible that wasn't before? |
| 09:31 | <nox> | annevk: The issue explains what is the change, but doesn't explain why. |
| 09:35 | <annevk> | nox: well, the first step of NodeIterator was sort of broken before |
| 09:36 | <nox> | annevk: How so? |
| 09:37 | <annevk> | nox: hmm, maybe that's okay |
| 09:37 | <annevk> | nox: the other reason is that oldPreviousSibling is going away |
| 09:38 | <nox> | I don't follow. You remove it because it's not useful anymore, but it's not useful anymore because there is now a concept specific to NodeIterator. |
| 09:39 | <annevk> | nox: well, what we had didn't exactly match browsers either |
| 09:39 | <nox> | But it still doesn't match browsers doesn't it? It just matches whatever Blink does. |
| 09:39 | <annevk> | nox: I first want to refine things to more accurately match what browsers do |
| 09:39 | <nox> | And you are not even sure that NodeIterator couldn't work with just removing steps. :/ |
| 09:40 | <annevk> | nox: well this is also roughly what Gecko does, except it does it through a generic mutation observer thingie |
| 09:40 | <annevk> | nox: well I'm sure it can't work if the removing steps no longer include oldPreviousSibling |
| 09:40 | <annevk> | which they won't, since they don't include that in anyone's setup |
| 09:40 | <nox> | annevk: That's circular reasoning IMO. |
| 09:42 | <annevk> | No browser has the setup you advocate... I'm not sure what to tell you |
| 09:42 | <nox> | I don't see how Gecko has the setup with the NodeIterator special hook either. |
| 09:44 | <annevk> | It instead has a far more elaborate synchronous mutation observer setup |
| 09:44 | <annevk> | Which I don't think makes sense to specify |
| 09:45 | <nox> | So you can't say "it's also roughly what Gecko does". |
| 09:46 | <annevk> | nox: Gecko has the same "removing steps" that I plan to have and that Blink also has |
| 09:46 | <nox> | My point is that I could see uses for oldPreviousSibling in the first place, that it allowed NodeIterator to not have its own special snowflake hook, and now it's yet another concept to implement in addition to the other ones. |
| 09:47 | <annevk> | Well ranges are already special, it didn't seem too bad to make NodeIterator special too in that light |
| 09:48 | <annevk> | And focus/blur... |
| 09:48 | <nox> | Well I don't see how ranges could avoid being special, that's a different issue to me. |
| 09:48 | <annevk> | I don't think we actually want to expose oldPreviousSibling precisely because it could mean more stuff starts using it... But we could of course change the contracts around if it's compelling enough |
| 09:49 | <nox> | What is wrong about more stuff using it? |
| 09:49 | <annevk> | It would require browsers to change most of their existing infrastructure. It would also require different hooks for custom elements. And it's not clear whether it's a good idea since so far we haven't needed it. |
| 09:51 | <nox> | I fear the opposite, that more special behaviours will be added when they could have just use oldPreviousSibling. |
| 09:52 | <annevk> | That seems unlikely |
| 09:52 | <annevk> | But if that happens we can revisit |
| 09:52 | <nox> | And you don't need it because you had to rewrite NodeIterator removing steps as its own special thing. |
| 09:54 | <annevk> | Given that NodeIterator didn't use the normal remove hook in all browsers that seemed like fine to me. Also given that ranges were there too. I guess you see things differently, but you're not exactly coming forward with cases that would require oldPreviousSibling... |
| 09:54 | <nox> | annevk: How will you handle "The relevant mutations for an img element are as follows: (…) The element's parent is a picture element and a source element that was a previous sibling is removed."? |
| 09:56 | <nox> | Wouldn't the associated plumbing be in the <source> removing steps? In which case you would just gather all <img> that followed oldPreviousSibling. |
| 09:56 | <annevk> | Presumably in the same way that browsers handle that today? |
| 10:01 | <annevk> | nox: that's an interesting question though |
| 12:11 | <jgraham> | http://www.reuters.com/article/2015/08/08/opera-software-ma-idUSL5N10J09C20150808 |
| 12:58 | <MikeSmith> | jgraham: :( |
| 13:03 | <MikeSmith> | hgl: Shanghai was great. Talked to Dapeng there. My friend Gao Bo did Mandarin interpretation of the presentation I did. That guy's an exceptional translator. |
| 16:40 | <annevk_> | jgraham: everyone did sort of expect that from the new CEO |
| 16:40 | <annevk> | jgraham: being a sales person |
| 16:41 | <annevk> | jgraham: somewhat surprised it took this long, although admittedly I also thought they were going to make it on that advertising stuff for a while |
| 16:53 | <jgraham> | AIUI the adertising stuff is now their biggest source of revenue |
| 16:53 | <jgraham> | Although I did believe the internet rather than actually looking at the financials |
| 16:58 | <jgraham> | The financials do indeed make Opera look like a mobile advertising business with an increasingly vestigial software development arm |
| 19:22 | <Ms2ger> | https://sny.no/2015/08/living |
| 22:13 | <Domenic> | Not bad |
| 22:13 | <Domenic> | Now just to fix these http://www.w3.org/TR/webdriver/#references |
| 22:14 | <Domenic> | I wonder if it's worthwhile pushing for DOM4 to be abandoned now that it has no active editors doing the work of porting |
| 23:14 | <SimonSapin> | How does https://html.spec.whatwg.org/multipage/infrastructure.html#parsed-as-a-css-color-value deal with currentColor? |
| 23:15 | <SimonSapin> | (context: https://github.com/servo/servo/issues/7106#issuecomment-129171059) |