| 09:26 | <Domenic> | So I am debugging whatwg.org build failures (which prevent https://github.com/whatwg/whatwg.org/pull/231 from being merged) |
| 09:26 | <Domenic> | It appears we are pip installing the markdown module without pinning it to a version, and it changed in a backward-incompatible way |
| 09:27 | <Domenic> | I am having some trouble figuring out: where to find a changelog or version history for the markdown module, and how to change the `pip install` command to pin the version. |
| 09:27 | <Domenic> | Python experts appreciated. |
| 09:28 | <Domenic> | OK, the answer to the changelog thing is to use pypi.org instead of pythonhosted.org |
| 09:31 | <Domenic> | OK and the latter is just pip install markdown==2.6.11. I guess I was premature asking for help. |
| 09:49 | <annevk> | Glad you figured that out |
| 09:50 | <annevk> | Also welcome to Europe? |
| 10:36 | <Domenic> | Ya, at the Paris office for this week |
| 10:37 | <Domenic> | annevk: mind reviewing https://github.com/whatwg/whatwg.org/pull/231 now that the build works |
| 11:22 | <hsivonen> | annevk: were pre-java.nio Java encoding canonical names deliberately not added as labels in the Encoding Standard? |
| 11:23 | <hsivonen> | annevk: seems related to the Unicode label mapping problem, since many of them would match if hyphens and underscores were ignored when comparing |
| 11:24 | <hsivonen> | annevk: see the second column at https://docs.oracle.com/javase/1.5.0/docs/guide/intl/encoding.doc.html |
| 11:26 | <zcorpan> | expected rendering, anyone? #block-block-18 select#langlinks{-webkit-appearance:menulist-textfield;-moz-appearance:treeheadersortarrow;appearance:none;background-color:transparent;font-size:9px;height:25px;padding:4px 0 0;width:121px;} |
| 11:34 | <hsivonen> | annevk: I wonder if the email-motivated addition of ms932 as a label for Shift_JIS had the root cause of pre-java.nio Java canonical names |
| 12:05 | <annevk> | hsivonen: the way we did things was looking at the intersection of labels in browsers and that's it |
| 12:06 | <annevk> | hsivonen: it's not entirely clear to me how browsers derived their initial tables, some combination of IANA, experience, and what whoever wrote the code deemed ok |
| 12:16 | <annevk> | hsivonen: I'd not be opposed to adding new labels based on anecdata btw, generally it seems that should be safe here |
| 12:16 | <annevk> | hsivonen: but only if all implementers are on board with such a strategy |
| 12:17 | <MikeSmith> | annevk: is https://rebeccalynndoug-html-multiple-.surge.sh/ non-conforming per the current URL spec? |
| 12:17 | <MikeSmith> | galimatias says: |
| 12:17 | <MikeSmith> | > Invalid host: A label ends with a hyphen-minus ('-'). |
| 12:18 | <annevk> | MikeSmith: no, we set CheckHyphens to false |
| 12:18 | <annevk> | oh wait, conforming |
| 12:19 | <annevk> | MikeSmith: it's currently conforming, but maybe it shouldn't be and we should also use _beStrict_ for CheckHyphens |
| 12:20 | <MikeSmith> | OK |
| 12:20 | <hsivonen> | annevk: thanks. that's what I expected. (I'd be curious to know if ISO8859_1 and the like were part of Opera's rejection of comparison that ignored hyphens and underscores.) |
| 12:22 | <MikeSmith> | annevk: ash I guess the reason galimatias reports an error is because it’s just relying on icu4j (ICU Java library) and is just passing on the error from that |
| 12:23 | <annevk> | hsivonen: I think the only reason was "euc_jp" |
| 12:27 | <hsivonen> | annevk: OK. that's one of the pre-java.nio Java canonical names |
| 12:27 | <annevk> | hsivonen: https://lists.w3.org/Archives/Public/public-whatwg-archive/2009Aug/0077.html |
| 12:28 | <annevk> | I think I remember that being the only case, but it's been a long time |
| 12:36 | <Zegnat> | Can anyone explain why https://html.spec.whatwg.org/multipage/dom.html#inner-text-collection-steps runs step 1 & 2 for nodes that are not being rendered? In what cases would such a list not be empty for a node that isn’t rendered? |
| 12:36 | <Zegnat> | If I understand “being rendered” right, it means a node has no drawing box at all. Which by definition would mean its children have no box at all? (e.g. display:none; can’t be overwritten on a per-child basis.) So shouldn’t all those extra steps just result in empty lists? |
| 12:41 | <annevk> | Zegnat: by the time that algorithm is invoked, the being rendered check for the subtree is already made, right? |
| 12:41 | <annevk> | Zegnat: so presumably something is rendered at that point |
| 12:43 | <Zegnat> | The algorithm only checks if it is being rendered in step 3 though. That is what is confusing me. |
| 12:44 | <Zegnat> | Why go through all the child nodes of something that isn’t being rendered first. I can’t think of a case where any of the childnodes would magically render when their parent does not. |
| 12:46 | <annevk> | Zegnat: when this algorithm is invoked the first time we know the parent is being rendered |
| 12:47 | <annevk> | because of innerText's getter step 1 |
| 12:48 | <Zegnat> | Aah, I think I grasp it now! |
| 12:48 | <Zegnat> | I was too focussed on the nested looping, woops |
| 12:48 | <Zegnat> | Thanks annevk! |
| 13:51 | <zcorpan> | annevk: hmmmm I guess the button element is itself not underlined, but the text-decoration can still propagate into it. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6291 |
| 13:52 | <annevk> | zcorpan: right, if you specify display:inline, I noticed that |
| 13:52 | <annevk> | zcorpan: ooh okay, I might see what you mean |
| 13:53 | <zcorpan> | annevk: I mean it's consistent with replaced elements not being underlined |
| 13:53 | <annevk> | zcorpan: so if image had a box inside it would propagate there too |
| 13:53 | <annevk> | zcorpan: okay |
| 13:53 | <zcorpan> | right |
| 13:54 | <annevk> | zcorpan: but for image that still requires a "I'm no longer replaced" setting when displaying alt (even though that's still somewhat replaced due to a potential impl using contents:attr(alt)? |
| 13:54 | <zcorpan> | yeah it shouldn't be a replaced element when showing alt |
| 19:53 | <lgrahl> | There have been questions about the implementation status of streams in browsers (and perhaps what's planned). (I guess I need to play the middle man since communicating with other WGs seems to be a big no-no for most people in the WebRTC WG...) |
| 20:17 | <Domenic> | lgrahl: implemented everywhere. Firefox is not quite shipped but apparently got unblocked last week. |
| 20:18 | <lgrahl> | Domenic: Ok. I was wondering about Firefox, so that's good to know. Does it also include WritableStream? |
| 20:33 | <Domenic> | lgrahl: not sure, I think they have a patch for that somewhere, but haven't seen movement on it in some time. Probably waiting for a customer :) |
| 20:34 | <lgrahl> | Domenic: And in Chromium? (I kind of figured that this is a chicken egg problem) |
| 20:52 | <Domenic> | lgrahl: all implemented and shipped to stable |
| 21:00 | <lgrahl> | Domenic: Cheers! :) |