03:25
<fujihiro>
DNS AAAA record of https://whatwg.org/ returns 2607:f298:4:148::a70:f5c3. But this address is unreachable. You can test with http://ipv6-test.com/validate.php
04:18
<MikeSmith>
fujihiro: you should get that info to Hixie when he is around
04:18
<MikeSmith>
fujihiro: I don’t think Hixie can do anything to fix it, because it’s a general Dreamhost issue
04:20
<MikeSmith>
fujihiro: Dreamhost has long had IPv6 issues and they claim to have fixed them but in my experience they continue to have some serious problems.
04:22
<MikeSmith>
fujihiro: so for my local machine, I change my /etc/hosts file to force it to only use IPv4 addresses for whatwg.org domains
04:22
<MikeSmith>
for example:
04:22
<MikeSmith>
75.119.197.251 help.whatwg.org
04:22
<MikeSmith>
75.119.197.251 wiki.whatwg.org
04:22
<MikeSmith>
fe80::1%lo0 help.whatwg.org
04:22
<MikeSmith>
fe80::1%lo0 wiki.whatwg.org
04:32
<fujihiro>
MikeSmith: Thanks for the info. But, is this really difficult problem? If the web server does not support IPv6, this can be solved just by removing AAAA record from DNS.
04:33
<MikeSmith>
fujihiro: true. I’ll ping Hixie about it
04:33
<fujihiro>
MikeSmith: Thanks.
04:34
<MikeSmith>
fujihiro: thanks for the heads-up about it
04:40
<MikeSmith>
fujihiro: so it seems Dreamhost have messed around with the DNS and the best way to get them to fix it is to tweet a message to @DreamHost on twitter https://twitter.com/dreamhost
04:58
<fujihiro>
MikeSmith: OK, I did. Thank you. I'll let you know if they reply to my message.
04:58
<MikeSmith>
fujihiro: super, thanks
10:33
<smaug____>
asking again, does anyone know how to enable shadow DOM in blink?
10:33
<smaug____>
or is that not yet possible?
10:34
<smaug____>
(talking about shadow DOM v1)
10:39
<MikeSmith>
hayato: ⬆
13:41
<nox>
Anyone familiar with https://w3c.github.io/IndexedDB/#steps-for-opening-a-database?
13:42
<nox>
I don't understand the note in step 3.
13:44
<nox>
Step 2 sorry.
13:44
<nox>
The upgrade transaction is started in step 8,
13:45
<nox>
so I don't understand how the note in step 2 can claim that the upgrade transaction will be started immediately.
13:46
<nox>
Oh misread something again, never mind me I'll study a bit more the spec.
13:49
<zcorpan>
Domenic: "The [CEReactions] extended attribute must take no arguments, and must not appear on anything other than an operation, attribute, setter, or deleter. Additionally, it must not appear on readonly attributes, unless the readonly attribute is also annotated with [PutForwards]."
13:49
<zcorpan>
Domenic: should things with PutForwards have it?
13:49
<zcorpan>
Domenic: in particular elm.style
13:51
<nox>
If there exists a database with version = 1 and that I try to open it with version = 2 from two different tabs at once at the same moment, can't there be a race condition where two upgrade transactions are started?
14:19
<Domenic>
zcorpan: yeah, pending a change in decision on https://github.com/w3c/webcomponents/issues/521, elm.style should have it. Did the quoted text confuse things in some way?
15:38
<moo-_->
Any DOM experts here?
15:38
<moo-_->
http://stackoverflow.com/questions/38333118/what-factors-drive-virtual-dom-to-outperform-browser-native-dom
17:20
<kochi>
smaug____: On M53 (canary/dev), Shadow DOM v1 is enabled by default. On M52/51 (beta/stable), you need to turn on "chrome://flags/#enable-experimental-web-platform-features".
17:20
<kochi>
ah, maybe canary is already M54.
17:54
<smaug____>
kochi: aha, perhaps chrome hasn't updated itself on my fedora
18:29
<Domenic>
moo-_-: in general virtual DOM is slower than real DOM
19:19
<jgraham>
My rough understanding is that "it's faster" isn't quite true. It's a technique that will typically prevent you shooting yourself in the foot wrt performance, but it isn't faster than the most optimised DOM code you could write to solve a particular problem.
23:13
<Domenic>
Does anyone have opinions on whether <details>'s toggle event should bubble or not? https://github.com/whatwg/html/issues/1533