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... ;)