04:11
<wycats>
some people have asked: https://github.com/whatwg/dom/issues/270
04:11
<wycats>
finally posted
04:11
<wycats>
annevk: ^
04:11
<wycats>
if smaug pops around, he was asking about it too
06:09
<MikeSmith>
botie, inform smaug____ wycats: some people have asked: https://github.com/whatwg/dom/issues/270 if smaug pops around, he was asking about it too
06:09
<botie>
will do
06:12
<wycats>
:)
06:12
<wycats>
bedtime for me
07:14
<annevk>
wycats++
08:32
<Ms2ger>
|<html version="5.0">
08:33
<annevk>
Ms2ger: we can pat ourselves on the back for going with half of the idea
08:42
<MikeSmith>
?
08:43
MikeSmith
doesn’t understand that |<html version="5.0"> reference
08:43
<annevk>
MikeSmith: zcorpan tweeted a link about how he came up with <!doctype html>
08:43
<annevk>
MikeSmith: that proposal also contained a proposal for <html version="5.0">
08:44
<MikeSmith>
oh
08:44
<zcorpan>
clearly it was necessary to specify the version... good thing Hixie knew better :-)
08:45
<annevk>
zcorpan: it's also interesting how the doctype bit included justification and the version thing was just like, well, that's always been there
08:46
<zcorpan>
yeah
10:07
<annevk>
zcorpan: https://github.com/whatwg/html/commit/9ac1071abe7fca185604b56b89cb969ea34e39db must have been...
10:08
<annevk>
Somewhat surprised I didn't spot that while reviewing
10:08
<annevk>
Guess I just ignored it as noise
10:09
<annevk>
Which is somewhat disconcerting as that would be a way to comprise the security...
10:50
<kochi>
smaug____ ?
10:51
<kochi>
Can we have a chance to have VC or something to chat about iframe/history thing?
10:53
<smaug____>
kochi: perhaps, though I'm not sure why that would be useful
10:54
<smaug____>
random note, it seems like HTML spec's session history part is rather bogus, not following what implementations do
10:55
<kochi>
smaug____: I just commented on the thread, and hope we could move forward.
10:55
<kochi>
where is it, specifically?
10:56
<smaug____>
though, spec being bogus doesn't affect to this particular issue
10:56
<annevk>
kochi: where is what?
10:56
<kochi>
where is the bogus part of session history?
10:56
<smaug____>
it is wrong in that it uses joint session history for browsing contexts, yet browsers seem to have transaction list of session history entry trees
10:57
<annevk>
that is a lot of words
10:57
<smaug____>
:)
10:58
<smaug____>
annevk: kochi: forwarded you an email about this
10:58
<kochi>
I'm not sure other implementations, but Chrome/Blink stores frame-tree -like history as a node for joint session history.
10:58
<smaug____>
but anyhow, that doesn't affect to the shadow DOM issue
10:59
<smaug____>
I'm hoping Servo folks will help here to fix the issues in the spec
11:00
<kochi>
okay, thanks for forwarding the mail.
11:00
<annevk>
Yeah, I briefly spoke to someone from Servo about this and they seemed happy to file issues
11:01
<annevk>
Just needed a little encouragement
11:01
<annevk>
I think the fact that standards are just like other software projects hasn't entirely hit home just yet
11:05
<kochi>
so the fact is that we haven't come up with a good way to separate the history list, as I wrote in the comment.
11:08
<smaug____>
we could just have a separate session history and not show the shadow history in the UI
11:08
<kochi>
oops, the comment is not posted...?
11:08
<kochi>
okay, posted :)
11:08
<smaug____>
I need to find some food
11:08
<smaug____>
back later
11:09
<kochi>
ooh... I have to go home soon too... talk to you later.
11:09
<zcorpan>
annevk: could the linter maybe fail if new files are added (other than in demos, fonts, images)
11:09
<annevk>
zcorpan: yeah maybe
11:10
<kochi>
for the context, smaug____ and I are talking about https://github.com/w3c/webcomponents/issues/184
11:10
<annevk>
hmm food
11:11
<annevk>
kochi: I'm sorry I don't have more input; I generally agree with smaug____ we should preserve encapsulation since that's a goal, but I don't really know how to achieve it properly here since I don't know enough about session history yet
11:12
<kochi>
annevk: yeah, we are not against having encapsulation, but rather thinking about implementation complexity and breaking user expectation about UI history back/forward.
11:13
<kochi>
history API is broken in the first place, I'd say :)
11:14
<kochi>
but I also have to admit that it is the way how web has worked so far.
11:15
<annevk>
Sure, but if we break the promise of shadow trees the moment you use <iframe>, we might get some issues too down the road
11:24
<kochi>
Yeah, like https://github.com/whatwg/html/issues/763 (link target should not bypass shadow boundary) ideally I'd hope history.go() outside shadow won't disturb shadow trees...
14:42
<annevk>
hsivonen: https://github.com/whatwg/encoding/pulls first two PRs are awaiting review
15:22
<Ms2ger>
hayato, !
15:22
<Ms2ger>
hayato, you broke travis: https://travis-ci.org/w3c/web-platform-tests/builds/138874200
15:43
MikeSmith
notices a typo he made in that lint message
17:14
<tobie>
TabAtkins: just forced Specref to use https for all w3c links. LMK if you bump into issues.
17:19
annevk
is getting pretty close to the point where he can refactor document creation
17:19
<annevk>
Hopefully I won't regress all the things
17:21
<tobie>
annevk: Thinking the same thing about my https upgrade. :)
17:24
<annevk>
tobie: but at least it'll be secure
17:24
<annevk>
tobie: whereas this...
17:24
<tobie>
:D
17:40
<TabAtkins>
tobie: Should be fine; Bikeshed is pretty agnostic about the biblio data. It mostly just cares about the keys, and just spams the url into markup without looking at it.
17:41
<tobie>
TabAtkins: yeah, that was my impression also.
21:15
<smaug____>
hmm, reviews... do webkit or blink (or other large open source project) folks somehow ensure reviewing is spread somewhat evenly between reviewers
21:21
<jsbell>
smaug____: for blink, not via formal process (other than the review tool suggesting potential reviewers randomly from a per-directory OWNERS list). We do end up with review requests piling up on particular reviewers, who are either particularly responsive or the only experts in a part of the codebase. And then we may suggest spreading the work around.