00:27 | <MikeSmith> | yippie ki-yay Apple has a new WebKit/Safari evangelist |
00:27 | <MikeSmith> | https://twitter.com/jonathandavis |
00:27 | <MikeSmith> | anybody know him? |
00:37 | <hober> | i do :) |
00:42 | <MikeSmith> | hober! |
00:43 | <MikeSmith> | get him to join here if he can sometimes |
00:43 | <MikeSmith> | anyway, good news that you guys have somebody in the position now |
00:44 | <MikeSmith> | I hope the job has some emphasis on devrel |
00:45 | <MikeSmith> | because it seems like he could end up helping a lot with giving web devs somebody to share their problems with and know that they're being heard |
00:46 | <MikeSmith> | as far as specific issues with making their web apps work well in iOS Safari I mean |
00:47 | <MikeSmith> | anyway it's great news |
00:56 | <hober> | yeah, we're really excited to have him |
01:00 | <MikeSmith> | btw I didn't know xeenon was responsible for evangelism stuff |
01:42 | <MikeSmith> | wow https://twitter.com/emacs/status/572571031447052289 |
01:42 | <MikeSmith> | achivement unlocked there, for w3cmemes |
01:43 | <MikeSmith> | and indirectly for #1 emacs fanboy hober |
02:12 | <MikeSmith> | Domenic: how's jsdom performance these days? |
02:13 | <Domenic> | MikeSmith: pretty good IIRC ... faster than selenium at least, in general. |
02:13 | <MikeSmith> | nice |
02:13 | <MikeSmith> | what parser do you use with it mostly? |
02:13 | <MikeSmith> | parse5? |
02:16 | <Domenic> | yeah parse5 |
02:16 | <Domenic> | we fall back to htmlparser2 if people are in XML mode |
02:16 | <Domenic> | either explicitly or in the magic DWIM mode we try to see if the file ends in .x(ht)ml, the server response comes back with an XML content type, etc. |
02:18 | <MikeSmith> | ok |
02:18 | <MikeSmith> | I don't know htmlparser2 |
02:18 | MikeSmith | looks it up |
02:19 | <MikeSmith> | https://github.com/fb55/htmlparser2/ I guess |
02:21 | <Domenic> | yeah |
02:21 | <Domenic> | it's what we used to use before moving to parse5 |
02:21 | <Domenic> | but it supports xml so we left it around for that case |
02:22 | <Domenic> | a more principled approach to xml would be nice |
02:22 | <Domenic> | but not yet a priority |
02:28 | <MikeSmith> | Domenic: does anybody use https://github.com/aredridel/html5 any more? |
02:29 | <Domenic> | MikeSmith: good question :-/. It's well-loved by its maintainer and so I try to keep support for it active. But I don't know of many people doing so. |
02:30 | <MikeSmith> | Domenic: when I tried it in the past the performance was not great |
02:31 | <MikeSmith> | but it was hard to judge then in part because at that time jsdom perf wasn't great either |
02:31 | <MikeSmith> | that said, it was a long time ago that I last tried |
02:32 | <MikeSmith> | anyway I like Aria |
02:33 | <MikeSmith> | I like to use software by people who both care about making great software but who are also nice enlighted people who seem like they really care about other people |
02:40 | <Domenic> | my thoughts exactly :) |
03:13 | <MikeSmith> | https://twitter.com/mamund/status/572581915456356352 quoting Linus: "We don't break compatibility and we haven't done feature-based releases since basically forever" |
03:13 | <MikeSmith> | sounds like the Web |
05:15 | <JonathanNeal> | Legal question: Are polyfills of CC-BY specs automatically or even forcefully CC-BY? |
05:33 | MikeSmith | looks around the channel for which lawyer here to assign that question to |
05:41 | <Hixie> | JonathanNeal: i am not a lawyer, but, no, there is no relationship between the copyright that a spec is under and its implementation. |
05:46 | <MikeSmith> | Hixie: hey on OSX do you use Terminal or iTerm2 |
05:46 | <Hixie> | terminal |
05:46 | <Hixie> | never heard of iTerm2 |
05:46 | <MikeSmith> | oh |
05:46 | <Hixie> | it's easy to imagine that it'd be better than Terminal |
05:46 | <MikeSmith> | yup |
05:46 | <MikeSmith> | well iTerm2 is way way better |
05:47 | <MikeSmith> | very actively developed by a guy who genuinely cares about making it great |
05:47 | <MikeSmith> | and he makes nightly builds |
05:47 | <MikeSmith> | http://iterm2.com/downloads.html |
05:47 | <Hixie> | though most of my problems with Terminal are to do with basic mac things, like, changing spaces eats your keystrokes and the animation slows at the end, or the annoyance around multiple windows vs multiple tabs |
05:47 | <MikeSmith> | yeah |
05:49 | <MikeSmith> | well an example of a nice feature around that level is the command+/ key in iTerm2 |
05:49 | <Hixie> | nothing on the iterm2 features pages looks compelling to me, though |
05:49 | <Hixie> | what does that do? |
05:49 | <MikeSmith> | it just shows you where your cursor is |
05:49 | <MikeSmith> | but with a very nice UX |
05:49 | <Hixie> | can't say i lose my cursor often :-) |
05:50 | <MikeSmith> | well I do, on OSX |
05:50 | <MikeSmith> | in text editors |
05:50 | <MikeSmith> | specifically in vim |
05:51 | <MikeSmith> | but other places tooーif you use a dark background especially it can be hard to know where your cursor is |
05:51 | <Hixie> | my background is black and my cursor is white |
05:51 | <Hixie> | a big white block |
05:52 | <MikeSmith> | anyway iTerm2 also has a very good way of natively managing multiple tmux windows from a remote ssh session |
05:52 | <Hixie> | (or light blue or something) |
05:52 | <Hixie> | what is there to manage? |
05:52 | <MikeSmith> | well it manages them in way that doesn't require you to do ^B 1 2 3 4 |
05:53 | <MikeSmith> | instead they're just each real windows |
05:53 | <Hixie> | if i wanted them to be distinct windows, i'd just connect to the remote server again :-) |
05:53 | <Hixie> | e.g. right now on this space i have an ssh connection to hixie.ch showing me the screen with my e-mail, and on the next space i have an ssh session to hixie.ch with my emacs screen |
05:53 | <hayato_> | Looks https://labs.w3.org/ is down. Because of that, the specs which use ReSpec aren't rendered properly. Is this a well-known issue? |
05:53 | <MikeSmith> | sure but you also lose ability to use ^B normally |
05:53 | <Hixie> | but they're both the same screen session |
05:54 | <Hixie> | no? |
05:54 | <MikeSmith> | sure |
05:54 | <Hixie> | i can switch internal screen buffers in each of these |
05:54 | <Hixie> | so ^P 2 and now the e-mail window shows my emacs buffer |
05:54 | <Hixie> | ^P^P and we're back to e-mail |
05:54 | <MikeSmith> | yeah sure that's what I normally do too of course |
05:54 | <Hixie> | (i also have a connection to the same screen session on my work desktop) |
05:55 | <MikeSmith> | I'm not totally sold on the idea of native-window management for tmux i'll admit |
05:55 | <MikeSmith> | I guess it's more like I'm impressed that he made it work the way it does |
05:55 | <MikeSmith> | hayato_: not a known issue afaik |
05:56 | <MikeSmith> | hayato_: I'll ping the systems team |
05:56 | <Hixie> | it does sound pretty impressive, technically |
05:56 | <hayato_> | MikeSmith: thanks |
06:05 | <tripu> | Anyone having difficulties with Echidna or spec-generator on labs.w3.org ...? |
06:07 | <tripu> | There isn't anything on https://labs.w3.org/ as such |
06:07 | <tripu> | The tools there are Echidna (the publication system): https://labs.w3.org/echidna/ |
06:07 | <tripu> | ...and an instance of spec-generator (Respec): https://labs.w3.org/spec-generator/ |
06:14 | <hayato_> | tripu: I have the same problem. I've just pinged Mike Smith in this room about that. |
06:14 | <tripu> | What is the issue, hayato_? |
06:14 | <tripu> | Echidna seems up and running |
06:14 | <hayato_> | ReSpec depends on https://labs.w3.org/ |
06:15 | <hayato_> | I guess all specs which use ReSpec aren't rendered correctly. |
06:16 | <tripu> | hayato_: https://labs.w3.org/spec-generator/ isn't working? |
06:16 | <hayato_> | I'm not sure. I am using http://www.w3.org/Tools/respec/respec-w3c-common |
06:17 | <hayato_> | as an instance of ReSpec |
06:17 | <hayato_> | e.g. http://w3c.github.io/webcomponents/spec/shadow/ |
06:18 | <tripu> | http://w3c.github.io/webcomponents/spec/shadow/ looks ok to me, hayato_ |
06:19 | <tripu> | I see that's using http://www.w3.org/Tools/respec/respec-w3c-common , as you say |
06:19 | <tripu> | and that in turn seems to be using https://labs.w3.org/ |
06:19 | <tripu> | which is up |
06:19 | <hayato_> | Table of Contents are not generated. |
06:20 | <tripu> | Although Echidna uses Respec, I'm not very familiar with Respec itself, hayato_ |
06:20 | <tripu> | I think this is a question for darobin |
06:21 | <tripu> | I'll be happy to follow up with him later in the day, hayato_ :) |
06:22 | <hayato_> | I guess the root cause is same. It looks ReSpec of http://www.w3.org/Tools/respec/respec-w3c-common is waiting for time out from https://labs.w3c.org/. |
06:23 | <hayato_> | I guess both depends on the bibrefs from https://labs.w3.org/specrefs/bibrefs?refs=xxxx. |
06:25 | <tripu> | I can look again at this in a few hours, hayato_ -- sorry that I can't right now |
06:28 | <hayato_> | tripu: Never mind. Just talking to myself. :) |
06:39 | <tripu> | I'll look into that again when I'm free, hayato_ :) |
07:51 | <annevk> | Domenic: do you think these cancel threads will drive themselves to a conclusion? |
07:53 | <Domenic> | annevk: I have opinions on that but probably best to wait until tomorrow, gotta sleep now. |
07:54 | <annevk> | Domenic: nn |
09:41 | <darobin> | hayato_: you still around? |
09:42 | <darobin> | hayato_: it looks like the problem you're seeing is not with ReSpec, but instead with another script that you're including |
09:43 | <darobin> | hayato_: autolink.js is blowing up, which seems to stop everything somehow |
09:43 | <darobin> | ah, wait, seeing a timeout now |
09:45 | <darobin> | hayato_: it looks like the biblio proxy service is down, let me see if I can fix that |
09:45 | <darobin> | (there's still a problem with your autolink.js btw) |
09:46 | <annevk> | Domenic: another thing, did we want to change .bodyUsed or not? |
09:49 | <tripu> | Thank you, darobin, wrt ReSpec/Echidna & hayato_ :) |
09:50 | <darobin> | tripu: no worries, I'm a bit surprised that the labs specref thing is down; I thought it was just a proxy to the real service! |
09:50 | <darobin> | (which is up) |
09:50 | <darobin> | I guess we'll see when dom's around |
09:51 | <tripu> | ok darobin |
09:55 | <darobin> | hayato_: the respec parts of your doc are now fixed, but your autolink script is still broken |
10:00 | <hayato_> | darobin: Thanks. biblio seems working now. I've found some dups in my autolink. It's unrelated local minor issues. Thank you for investigating :) |
10:03 | <darobin> | hayato_: the autolink issue isn't about dups, it's a race condition |
10:03 | <darobin> | so maybe you're not seeing it :) |
10:03 | <darobin> | basically there's no guarantee that it runs before ReSpec |
10:04 | <darobin> | and if it doesn't things break |
10:04 | <darobin> | let me fix that for you |
10:05 | <hayato_> | darobin: I remember I encountered such a timing issue. But I don't remember how to manage that... Maybe I didn't fix it. |
10:05 | <darobin> | hayato_: fixing it, don't worry :) |
10:06 | <hayato_> | darobin: you are my hero. |
10:09 | <MikeSmith> | hayato_: darobin is my hero too |
10:09 | <MikeSmith> | we could start a hero club |
10:18 | <darobin> | hayato_: hahaha |
10:18 | <darobin> | hayato_: well, I'm fixing the problem largely by using a feature that's not in the ReSpec docs... so you could say I'm just cleaning up my own mess |
10:19 | <darobin> | I also replaced innerText with textContent, which is what you want there |
10:19 | <darobin> | (innerText is deep magic) |
10:19 | <darobin> | hayato_: https://github.com/w3c/webcomponents/pull/36 |
10:22 | <hayato_> | darobin: I've merged it. Thanks! |
10:22 | <darobin> | hayato_: cool :) |
10:22 | <darobin> | hayato_: I just noticed that you're linking to http://domparsing.spec.whatwg.org/, that spec is gone |
10:27 | <hayato_> | darobin: thanks. Looks domparsing is now at https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html (and http://www.w3.org/TR/DOM-Parsing/), I guess I don't need local Biblio info for DOMPARSING any longer. |
10:28 | <darobin> | hayato_: yeah, you can use [[DOM-PARSING]] |
10:29 | <darobin> | hayato_: also, [[selectors4]] |
10:35 | <hayato_> | darobin: Thanks! I've fixed both. |
10:36 | <darobin> | hayato_: cool, brilliant |
10:36 | <darobin> | I hope you can ship this to Echidna! |
10:46 | <hayato_> | darobin: I've never used Echidna, assuming it's https://github.com/w3c/echidna. I'll have a look. |
10:46 | <darobin> | hayato_: I thought you were trying to get into the automatic publishing thing? |
10:47 | <Ms2ger> | Move to bikeshed already |
10:47 | <darobin> | you don't need to grab the echidna source, but you can sign up to have your draft pushed automatically |
10:47 | <darobin> | Ms2ger: it's the same thing for bikeshed |
10:47 | <Ms2ger> | Yeah |
10:47 | <Ms2ger> | Move to bikeshed already |
10:47 | <Ms2ger> | Respec takes ages to load |
10:49 | <MikeSmith> | boo hoo |
10:49 | <MikeSmith> | that's a feature |
10:49 | <MikeSmith> | it frees you up to do other things while you're waiting |
10:50 | <MikeSmith> | like light up the peace pipe |
11:00 | <MikeSmith> | hsivonen: could we consider a workflow for getting bug fixes into the Java HTML parser code that doesn't involve contributors to all make changes to the affected gecko parts |
11:02 | <MikeSmith> | hsivonen: I know in my case for the two simple patches I have pending I submitted them through Mozilla bugzilla voluntarily. But that's mostly because the upstream code's not in github or somewhere that has a pull-request mechanism of some other means for submitting a patch and have a record of it and some kind of workflow around it |
11:12 | <mrtn_> | the spec [1] says, that the dppx unit are the "dots per ‘px’ unit", but 1 css pixel clearly maps to 4 device pixel for example on a retina display, but the dppx value would be 2 in most (?) browsers - shouldn't it be 4? maybe TabAtkins knows more, as he worked on the spec... [1] http://www.w3.org/TR/css3-values/#resolution |
11:12 | <Ms2ger> | 1 pixel in area or length? |
11:13 | <mrtn_> | i can't find anything that states if it's per area or length, so i just assume it's area... |
11:17 | <mrtn_> | it says "The <resolution> unit represents the size of a single "dot" in a graphical representation by indicating how many of these dots fit in a CSS ‘in’, ‘cm’, or ‘px’." in 1 css pixel fit 4 device pixel in my example, but dppx are 2... |
12:09 | <roc> | per length |
12:56 | <GPHemsley> | Are there any "bad" Unicode characters, where allowing them (or their raw character references) in user input could have adverse effects? |
13:06 | <annevk> | GPHemsley: define "bad", there's a number that allows you leaking out of a line box quite extensively |
13:06 | <GPHemsley> | annevk: Any value of "bad" |
14:19 | <beverloo> | annevk, https://github.com/whatwg/notifications/pull/36 |
14:22 | <annevk> | beverloo: guess we have to wait for TabAtkins to take a look? |
14:23 | <beverloo> | I've peeked around in the bikeshed/widlparser code but can't immediately find what's up |
14:23 | <beverloo> | so yeah, he might know |
14:24 | <beverloo> | widlparser defines a dictionary member like this: |
14:24 | <beverloo> | # [ExtendedAttributes] Type identifier [Default] ";" |
14:25 | <beverloo> | so that's not compatible with webidl and explains the "required" problem |
15:37 | <TabAtkins> | beverloo: Please report these errors on widlparser; plinss is fast at fixing, then I'll pull into Bikeshed. |
15:38 | <TabAtkins> | github.com/plinss/widlparser |
15:39 | <TabAtkins> | mrtn_: The px unit is a linear length, not an area, so a 2x device has 2 pixels per px (but 4 pixels per square px, if that unit ever existed). |
15:43 | <TabAtkins> | beverloo: Oh, I see you not only already reported it, you submitted a PR. ^_^ I'll merge as soon as plinss does, thanks! |
15:57 | <beverloo> | TabAtkins, cool! I haven't found the no-space issue yet, the producer code in widlparser seems to be doing it correctly |
15:57 | <beverloo> | TabAtkins, does bikeshed have its own formatting code for idl? |
16:30 | <TabAtkins> | beverloo: Feel free to just report it; plinss will figure it out. |
16:30 | <beverloo> | TabAtkins, ok! |
16:30 | <TabAtkins> | beverloo: Bikeshed just uses widlparser to handle webidl; it doesn't do anything else besides tweak some attributes. |
16:41 | <mrtn_> | TabAtkins, yeah that makes sense, thank you. btw, liked your talk about Present and Future of CSS Layout! |
16:41 | <TabAtkins> | Thanks! |
17:03 | <jgraham> | So, uh, if I have <div id=1> there is no way to select that by id from css? |
17:06 | <TabAtkins> | jgraham: #\31 |
17:08 | <jgraham> | Not in Firefox at least |
17:09 | <TabAtkins> | Taht's a bug, then. Works in Chrome, and works per spec. |
17:09 | <annevk> | WORKSFORME |
17:09 | <jgraham> | In querySelector? |
17:09 | <jgraham> | I guess I should have made that more clear |
17:10 | <annevk> | jgraham: yes |
17:10 | <annevk> | jgraham: document.querySelector("#\\31") |
17:10 | <TabAtkins> | jgraham: Yes, works. |
17:10 | <jgraham> | Oh, right of course, not enough escaping |
17:10 | <TabAtkins> | But yeah, the double-escaping needed is non-obvious. ^_^ |
17:10 | <annevk> | Just use CSS.escape(id) |
17:10 | <TabAtkins> | Dont' worry, I made the same mistake when I was looking at an example just now. |
17:11 | <annevk> | Although document.querySelector("#" + CSS.escape("1")) is a bit cumbersome to write |
17:11 | <jgraham> | annevk: This is a WebDriver client that doesn't have convenient DOM functions |
17:12 | <jgraham> | Anyway now I know it's actualy possible I can just report it as a bug |
18:19 | <mrtn_> | TabAtkins, there's one thing i wonder about in the responsive images spec, if i use art direction, i may show different pictures, thus need different alt attributes, wouldn't it be good to have an alt attribute on the <source> tag (too)? |
18:22 | <TabAtkins> | mrtn_: Our conclusion is that you really shouldn't be doing things complicated enough to need different alt text, so we aren't going to support it. This might change in the future if it's proven necessary. |
18:24 | <mrtn_> | alright, so this was discussed. i don't need it, just wanted to know... ;) |