02:30
<MikeSmith>
my Canary on OS X is failing to update for the last couple days. Wondering if others are having the same problem
02:31
<MikeSmith>
normally I would just give up and build it from sources, but I have XCode7 installed, and that currently breaks clang compiling of the blink code all over the place
04:02
<caitp>
MikeSmith: that sounds like the issue of not having the OSX 10.10 sdk, probably
04:03
<caitp>
but no, not having that issue here
07:55
<MikeSmith>
caitp: yeah I've since re-tried the build and it actually ran to completion and I've got a new Chromium binary so I'm all good now
07:57
<MikeSmith>
I had basically been away for an entire week, til today, so I guess all the fixes got made in the mean time
07:59
<MikeSmith>
caitp: for historical interest, https://code.google.com/p/chromium/issues/detail?id=517914 (resolved Oct 13)
08:29
<philipj>
annevk: do you know how arangana of File API fame is? https://github.com/w3c/FileAPI/commit/613b4d5b679cc651184275d784c1d74e078c3fdf
08:29
<annevk>
philipj: I suspect Arun
08:30
<philipj>
annevk: https://github.com/arunranga that is?
08:30
<annevk>
philipj: yes
08:30
<philipj>
ok, thanks!
08:33
<philipj>
annevk: the context is https://github.com/w3c/webrtc-pc/issues/324#issuecomment-148652950
09:00
<MikeSmith>
philipj: Arun is a wonderfully reasonable and responsive guy. He's even around on this channel sometimes.
09:02
<MikeSmith>
And he is somewhat actively contributing recently to discussion on some new spec proposal (though I forget right now which one), so I know he is around
09:02
<MikeSmith>
at least he was a week or so ago before I took my golf vacation
10:26
<gsnedders>
Is microdata essentially entirely dead now?
10:27
<gsnedders>
oh, it's just gone from the W3C spec?
10:27
<jgraham>
The API is dead
10:27
<jgraham>
The markup is less dead
10:34
<gsnedders>
Given everything that supports microdata also supports RDFa, as far as I can tell, and some things *only* support RDFa, it seems dubious to me as to why I should use it.
10:35
<jgraham>
So that you don't have to use RDFa?
10:35
<jgraham>
I mean that's the value proposition
10:35
<jgraham>
If you don't think that's valuable then you aren't going to like it
10:35
<gsnedders>
RDFa really isn't that bad if you use a simple subset, though…
10:36
<gsnedders>
esp. now RDFa Lite is supported everywhere
10:36
<jgraham>
Shrug
10:37
<gsnedders>
I agree the full thing is implementation hell, but the reality is that it's supported everywhere and microdata isn't.
10:37
<jgraham>
They all solve a problem I have never had
10:37
<gsnedders>
(the problem in question here is "getting 'Rich Snippets' on Google search")
10:37
<gsnedders>
And "reasonable auto-link descriptions on Facebook"
10:37
<gsnedders>
And things along this line.
10:50
<gsnedders>
oh god
10:51
<gsnedders>
ended up looking at the *full* RDFa spec
10:51
<gsnedders>
I'm so lost.
10:51
<gsnedders>
And I'm someone who's done a fair bit with RDF previously…
11:51
<annevk>
That's why we have Microdata
14:01
<smaug____>
annevk: "Apply the URL parser to url, with base as the base URL, with encoding as the encoding." means what
14:02
<smaug____>
is it about "basic URL parser"in https://url.spec.whatwg.org/#concept-basic-url-parser ?
14:02
<smaug____>
or something else
14:02
<smaug____>
hmm, maybe not, since HTML spec uses both "URL parser" and "basic URL parser"
14:03
<smaug____>
and " basic URL parser" takes and input, and url and base are optionals
14:04
<gsnedders>
smaug____: https://url.spec.whatwg.org/#url-parsing
14:05
<smaug____>
hmm, it takes input
14:05
<smaug____>
I guess "url" maps to that "input"
14:06
<gsnedders>
yeah
14:36
<annevk>
smaug____: is URL parser not xref'd?
14:46
<smaug____>
I didn't see a link
14:47
<smaug____>
there was a link to "basic URL parser"
14:54
<annevk>
smaug____: anyway, URL parser is https://url.spec.whatwg.org/#concept-url-parser
14:54
<annevk>
smaug____: which takes a url, base URL, and an encoding
14:55
<smaug____>
it takes "input"
14:55
<smaug____>
but something else is passing "url"
14:55
<smaug____>
so that was just a bit misleading, silly me
14:56
<annevk>
smaug____: I see, still need to update HTML a bit around URL handling
14:56
smaug____
almost understands how push/replaceState should behave per spec ;)
14:56
<Ms2ger>
How about you write a couple hundred tests? :)
15:08
<annevk>
Ms2ger: what is the frameURI business in https://github.com/w3c/web-platform-tests/blob/master/html/browsers/origin/cross-origin-objects/win-documentdomain.html?
15:10
<Ms2ger>
No clue
15:12
<annevk>
"Addressed Ms2ger's review comments."
15:12
<annevk>
hmm
15:13
<annevk>
Ms2ger: https://critic.hoppipolla.co.uk/r/2116
15:13
<annevk>
I don't understand assigning window.frames in https://github.com/w3c/web-platform-tests/blob/master/html/browsers/origin/cross-origin-objects/frame.html either
15:14
<Ms2ger>
Ask bholley?
15:14
<Ms2ger>
Or bz
15:16
<annevk>
I guess I have to :-/
15:16
<annevk>
I already have some outstanding questions
15:16
<annevk>
This is a bit hard
18:07
<Domenic>
So the correct type for representing timestamps is unsigned long long?
18:07
<TabAtkins>
Isn't it DOMTimestamp
18:07
<TabAtkins>
?
18:07
<Domenic>
I think that is changing to be offset from page load?
18:08
<Domenic>
No, I am wrong
18:08
<gsnedders>
https://dom.spec.whatwg.org/#interface-htmlcollection has what I'd expect to be a link to "Elements" at the start of the note… and it's not xref'd
18:10
<TabAtkins>
Yeah, the Elements definition is written in pseudo-ES6/IDL, rather than actual WebIDL, so it's not auto-marked-up by Bikeshed, and Anne hasn't manually marked it up.
18:10
<gsnedders>
well you guys suck!
18:35
<TabAtkins>
Ugh, I still hate the "in parallel, do..." construction. Every time I see it, it looks like it's telling me to shard out the nested operations in parallel.
19:03
<Domenic>
Anyone have examples of APIs that use an abbreviation as their first word in a method or property?
19:03
<Domenic>
So far all I've found is document.URL
19:04
<Domenic>
OK, document.fgColor, bgColor
19:04
<Domenic>
cssElementMap
19:04
<Domenic>
I conclude lowercase
19:05
<Domenic>
Nobody seems to implement cssElementMap, we should probably kill that
19:33
<annevk>
Domenic: yes, lowercase for properties
20:10
<bholley>
annevk: let's talk here
20:10
<bholley>
annevk: what do you mean 'corresponds to'?
20:10
<bholley>
annevk: do you mean 'describes'?
20:11
<bholley>
annevk: or do you mean 'is an object in the scope of'
20:11
<annevk>
bholley: hmm, I guess it describes the active document
20:11
<bholley>
annevk: exactly
20:11
<annevk>
bholley: which could be cross-origin
20:11
<bholley>
annevk: that's the weird thing about location
20:11
<bholley>
annevk: which is why same-origin Location objects still need security checks
20:11
<bholley>
annevk: because you might not be the active document
20:11
<bholley>
annevk: but that's distinct from how we handle cross-origin objects
20:12
<annevk>
bholley: is the only difference the prototype stuff and expandos and some things around enumerability?
20:12
<bholley>
annevk: difference between what and what?
20:13
<annevk>
bholley: between same-origin Location object describing "cross-origin active document" and cross-origin Location object
20:13
<bholley>
annevk: they are different "concepts"
20:13
<bholley>
annevk: which might be confusing you
20:13
<bholley>
annevk: the "concept" is not "the URL of the browsing context"
20:13
<bholley>
annevk: the "concept" is "the Location interface associated with a given Window"
20:14
<bholley>
annevk: which, for bizarre reasons, doesn't necessarily describe that window
20:14
<bholley>
annevk: but for our purposes, two Location objects that describe the same browsing context are totally distinct
20:14
<bholley>
annevk: this is web-observable, FWIW
20:15
<bholley>
annevk: grab xoIframe.contentWindow.location, navigate it to something else, grab the location again
20:15
<bholley>
annevk: they're two different objects
20:15
<annevk>
sure, Location objects are minted per Document
20:15
<bholley>
right
20:16
<bholley>
annevk: and you can only read the information if the associated Document is same-origin _and_ the Document's BC's active Document is same-origin
20:16
<bholley>
as in, we take a union of the two security restrictions
20:17
<annevk>
makes sense
20:18
<annevk>
the "concept" thing is a bit weird, since the cross-origin wrapper will forward behavior and at that point we basically expect that behavior to be JavaScript-object-like
20:18
<annevk>
or something JavaScript can call into
20:19
<bholley>
annevk: please don't spec this in terms of wrappers
20:20
<annevk>
bholley: html5-cross-origin-objects is basically a description of proxy objects
20:20
<annevk>
bholley: I guess I shouldn't use the word wrapper for proxy, but in mind they're somewhat interchangeable
21:49
<nox>
annevk: The URL spec says: "A URLSearchParams object’s update steps are to set url object’s url’s query …" and "A URLSearchParams object has an associated url object, which is initially null.",
21:50
<nox>
annevk: but it also says "A URL object has an associated url (a URL) and query object (a URLSearchParams object)."
21:50
<nox>
So, can URLSearchParams' "url object" be something else than an instance of the interface named URL?
23:50
<rniwa>
Domenic: yt?
23:50
<rniwa>
annevk: yt?