00:05
<MikeSmith>
jgraham: wow when even he can't tell from the specs what's supposed to be allowed, the specs are pretty bad
00:05
<MikeSmith>
Daniel Stenberg I mean
00:06
<jgraham>
Yeah
00:24
GPHemsley
wonders if "initial MIME type" and "final MIME type" would be clearer than "supplied MIME type" and "sniffed MIME type", respectively.
00:24
<zewt>
cool, another CORS header for everyone to copy and paste blindly into their server
00:25
<zewt>
(heh)
00:26
<TabAtkins>
GPHemsley: initial/final sound good. supplied/sniffed sound like they're both inputs into an algorithm that'll spit out a final one.
00:26
<TabAtkins>
Or mix 'em up, supplied/final.
00:26
<GPHemsley>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28094
00:27
<GPHemsley>
Could that be what's in play here?
00:27
<TabAtkins>
GPHemsley: Ah, no, in that bug, it's that the phrase "the X is the Y" is unclear - the directionality of the implication isn't obvious.
00:27
<TabAtkins>
I try to be explicit and say "set X to Y"
00:28
<TabAtkins>
Or similar.
00:28
<GPHemsley>
oh, interesting
00:28
<GPHemsley>
leave a comment to that effect?
00:28
<TabAtkins>
Doing so.
00:28
<GPHemsley>
thanks
00:32
<GPHemsley>
TabAtkins: Any insight into the first two quotes?
00:32
<tantek>
why not specified mime type and computed mime type? 1/2 ;)
00:32
<TabAtkins>
No, I don't know about the first two lines. Those seem fine to me.
00:33
<GPHemsley>
tantek: s/specified/supplied/ ?
00:33
<GPHemsley>
I like that
00:33
<GPHemsley>
supplied and computed
00:33
<GPHemsley>
I never liked sniffed
00:34
<tantek>
agreed. use of "sniff" always smelled a bit funny to me.
00:34
GPHemsley
wonders what has changed out from under him since the last time the spec was updated
00:34
<zewt>
igi smelled
00:34
<GPHemsley>
:P
00:35
<TabAtkins>
/kick #whatwg tantek Puns too terrible.
00:37
<GPHemsley>
was there some change to the infrastructure, or should I be able to build like I always have?
00:38
<TabAtkins>
You can try it and see?
00:39
<GPHemsley>
I suppose :)
00:39
<GPHemsley>
looks like it should be OK, as long as I don't update anything
00:54
<MikeSmith>
it seems like this "Waiting for available socket" thing in Chrome can't be caused by hitting a system-level limit in OSX, because when it happens with some particular URL, I can open up that same page in Firefox or Safari with no problem
00:58
<GPHemsley>
"X is Y" means "X == Y"
00:58
<GPHemsley>
"set X to Y" means "X = Y"
00:58
GPHemsley
puts that in the style guide
01:08
<TabAtkins>
GPHemsley: Yeah, that's right.
01:33
<zewt>
MikeSmith: don't know the particular issue, but you could have per-process (maybe per process tree?) limits
01:37
<GPHemsley>
Feedback welcome: https://wiki.whatwg.org/wiki/Specs/style#Equality
01:37
<GPHemsley>
TabAtkins: ^
01:38
<TabAtkins>
Looks good.
01:39
<TabAtkins>
GPHemsley: Do you know the source of the "inverse map" term?
01:40
<TabAtkins>
That's definitely not my expected name for a map where each key can have multiple values.
01:40
<GPHemsley>
TabAtkins: Likely me and/or Wikipedia
01:40
<GPHemsley>
TabAtkins: Feel free to check the logs :P
01:43
<GPHemsley>
nevermind, I'll do it
01:44
<GPHemsley>
6 Nov 2013
01:44
<GPHemsley>
SimonSapin was involved
01:45
<GPHemsley>
http://logs.glob.uno/?c=freenode%23whatwg&s=6+Nov+2013&e=6+Nov+2013&h=inverse+map#c838129
01:46
<TabAtkins>
Okay. ^_^
01:47
<GPHemsley>
yay data!
01:47
<TabAtkins>
Oh wait, I see. "inverse map" is actually more restrictive than anything in the platform; that really is the correct term in that case. I was thinking it was basically equivalent to multimap, but it's not.
01:48
<GPHemsley>
:)
01:50
<GPHemsley>
[ For a keyed collection of values, use "inverse map" when there can be more than one value per key and only one key per value ]
01:53
<GPHemsley>
hmm... I suppose that means that, if there are no orphans, the number of values is always greater than or equal to the number of keys
01:53
GPHemsley
wanders off
01:55
GPHemsley
returns briefly to alert Hixie to the terminology change in mimesniff
01:56
<Hixie>
file a bug
01:56
<Hixie>
:-)
01:58
<MikeSmith>
zewt: ah ok
03:12
<MikeSmith>
Hixie: have you got any ideas on how we want to deal with document conformance for documents that contain custom elements
03:13
<MikeSmith>
I mean both spec-wise and for conformance checkers
03:13
<MikeSmith>
as far as the validator we could of course trivially just make it ignore any element names that contain hyphens
03:15
<MikeSmith>
but the downside of that is we'd lose the ability to help people catch cases where they mistyped an element name by putting a stray hyphen into it
03:15
<MikeSmith>
though I think that's probably a very rare mistake to make
03:15
<MikeSmith>
and if they did that for a non-void element, they'd have to make that same mistake twice
03:16
<MikeSmith>
because otherwise the validator would at least emit an error about finding an end tag for an element that's not open
03:19
<MikeSmith>
but the bigger downside is that trivally ignoring any element with a hyphen in its name would also mean any of its child elements also get ignored by the validator
03:23
<Domenic>
My suggestion: Output a list of hyphen-containing elements, highlight somehow any that differ by one or two characters, especially if one of the different-by-one's only occurs once or twice.
03:26
<MikeSmith>
Domenic: OK yeah that would help
03:27
<MikeSmith>
but we still would have the problem that the validator can't do any checking of the child content of a custom element without knowing or assuming what type of content the element's meant to have
03:28
<MikeSmith>
I guess one way to deal with that could be to just try any child element as a div as a far as validation of its child content goes
03:29
<MikeSmith>
but then some custome elements might be meant for use inline, as phrasing content
03:31
<Domenic>
Hmm yeah seems not possible to solve without external metadata
03:32
<Domenic>
Which would require custom element authors to be people who want to give thought to validation constraints :/
03:34
<MikeSmith>
yup
03:34
<MikeSmith>
which isn't practical
03:36
<MikeSmith>
but short of external metadata I could have the validator try to heuristically determine what kind of content the custom element is
03:37
<MikeSmith>
e.g., a simple case is, if the custom element is itself a descendant of an element that can only contain phrasing content
03:37
<MikeSmith>
e.g., a <p> element
03:37
<MikeSmith>
then in that case we can assume that the custom element can also only contain phrasing content
03:38
<MikeSmith>
and implementation-wise I could just have the validator treat it the same as a <span> I guess
03:38
<MikeSmith>
in other words, we just make the content model of all custom elements be "transparent"
03:39
<Hixie>
fundamentally, no, i have no idea.
03:39
<Hixie>
i mean that's what DTDs were to SGML
03:39
<Hixie>
and that failed
04:04
<Domenic>
You could imagine a "custom elements validator config"
04:04
<Domenic>
It could be very simple, starting with one line or so for each element
04:04
<Domenic>
And could become sharable
04:04
<Domenic>
Or people could end up just inputting it into a textbox alongside their HTML content
04:04
<Domenic>
and maintaining it in a .txt file they use
04:05
<Hixie>
this isn't new technology. xml schemas, dtds, relaxng, they're all elaborate ways to do this
04:05
<Hixie>
and they all basically uniformally fail in a web enviroment
04:05
<MikeSmith>
Domenic: right, something like that may be what we end up needing in the long run
04:05
<Hixie>
i mean this really is exactly what we're doing here. we're making in possible for people to use a meta language to make a new vocabulary
04:05
<Hixie>
this is exactly what sgml was, and xml later.
04:06
<MikeSmith>
Hixie: I'm not sure you're completely right about those existing schema languages having ways to do this
04:06
<MikeSmith>
certainly Relaxg
04:06
<Hixie>
i don't mean specifically define a vocabulary for custom elements in html
04:07
<Hixie>
i mean the class of problems of "describe validation criteria for a vocabulary in a metalanguage"
04:07
<MikeSmith>
ok
04:08
<MikeSmith>
well I think the problem with most existing schema approaches for validation is that they're all grammar-based
04:08
<MikeSmith>
so they by default say nothing is allowed anywhere
04:08
<MikeSmith>
it's like Deny: *
04:09
<MikeSmith>
and they all require you to them explicitly define what's allowed where
04:10
<MikeSmith>
the other approaches like schematron that are assertion-based do the opposite Allow:* way of saying everything's allowed everywhere
04:11
<Domenic>
I think my approach is predicated on my guess that those approaches failed because of usabilty issues
04:11
<MikeSmith>
anyway for better or worse the validator at its core is a grammar-based checker so we're stuck with that limitation until we come up with something better to replace it
04:11
<Hixie>
i think these approaches failed because most people don't care to define constraints for their vocabularies.
04:11
<MikeSmith>
bingo
04:11
<MikeSmith>
in the past very few people had any need to
04:12
<Domenic>
Whereas something like "contains only: phrasing content" or "contains only: [x-menuitem]" --- with nothing else --- might succeed, at least in the domain of people who care enough about validation to lug around the metadata
04:12
<MikeSmith>
but I think custom elements changes that
04:13
<MikeSmith>
Domenic: yeah I think what you've described would need to be limited to some very simple limited easy to grok expression language
06:44
<annevk>
jgraham: left a reply, URL Standard has all the answers, but when you start looking at RFCs... yeah
10:23
<annevk>
JakeA: DOM === (!JavaScript && !<canvas>)
10:24
<JakeA>
annevk: haha, perfect!
10:25
<Ms2ger>
I'm having issues with my HTML5 DOM HTTP
12:32
<jgraham>
annevk: Do we know how common xml:base is?
12:51
<annevk>
jgraham: foolip has been counting it I think
12:52
<annevk>
philipj that is, these days
12:52
<jgraham>
Oh, he changed nicks
12:53
<jgraham>
(thinking about it more, I don't really care that much for the problem I had in mind)
12:53
<jgraham>
(so don't worry)
12:55
<GPHemsley>
Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28100
12:56
<annevk>
jgraham: see https://code.google.com/p/chromium/issues/detail?id=341854 for progress on removing xml:base
12:57
<annevk>
jgraham: https://bugzilla.mozilla.org/show_bug.cgi?id=903372 is still awaiting a volunteer
13:30
<hemanth>
How do I import a reserved/key word? Something like import { 'return' } as identity from 'fj-maybe'; does not work...
13:31
<hemanth>
fj-maybe does: export default { 'return' (value) {return value;} }
13:49
<philipj>
annevk, jgraham, it's more convenient to be philipj in #blink, so...
13:50
<philipj>
so the xml:base counter isn't for the presence of the attribute but just when it has an observable effect in Blink
13:50
<philipj>
https://www.chromestatus.com/metrics/feature/timeline/popularity/580
13:51
<philipj>
https://www.chromestatus.com/metrics/feature/timeline/popularity/681 is for the reflected attribute in SVG
13:52
<annevk>
looks great
13:52
<annevk>
but it also seems that in Chrome it has barely any effect at all
13:52
<annevk>
that's not true for Gecko though since no other browser does it...
13:53
<philipj>
annevk: note that the SVG counter (681) hasn't reached stable yet, but I'm quite optimistic
13:53
<jgraham>
philipj: On an entirely different topic, I needinfo'd you on a bug about wpt media test source selection. I hope you don't mind
13:54
<philipj>
jgraham: yep, I saw that, and don't mind :)
13:54
<philipj>
I also have a philipj⊙oc account in your Bugzilla, not sure why I have two
13:55
<jgraham>
Ah, foolip is a more unique search string ;)
13:58
<philipj>
yes it is :)
14:03
<philipj>
jgraham: I've replied to your needsinfo bug
14:03
<jgraham>
philipj: Thanks!
14:03
<philipj>
I like this needsinfo system BTW
14:04
<Ms2ger>
MikeSmith bugged systeam about that, I wonder what happened
14:04
<jgraham>
Yeah, it seems to work quite well
14:05
<Ms2ger>
philipj, you can get accounts merged, fwiw... You need to file a bug somewhere
14:05
<MikeSmith>
I got a reply on the needsinfo thing—basically a "maybe"—so at least they didn't reject it yet
14:06
<MikeSmith>
I need to get back to them and continue to lobby for it
14:32
<Ms2ger>
MikeSmith, any chance you can get a big banner on http://www.w3.org/TR/Window/?
14:32
<MikeSmith>
Ms2ger: yeah
14:33
<MikeSmith>
got a page I can copy the banner from?
15:02
<Ms2ger>
MikeSmith, http://www.w3.org/TR/CSS1/ maybe
15:05
MikeSmith
looks
15:06
<Ms2ger>
MikeSmith, or redirect to html.s.w.o ;)
15:11
<MikeSmith>
Ms2ger: would that I could 😄
15:11
<Ms2ger>
MikeSmith, or, hell, the fork
15:23
<philipj>
Ms2ger: will a bug just anywhere do the trick? ;)
15:25
<Ms2ger>
<glob> Ms2ger, bugzilla.mozilla.org :: administration
15:25
<Ms2ger>
<glob> Ms2ger, we'll need a comment from both accounts
15:42
<MikeSmith>
Ms2ger: done
15:43
<Ms2ger>
MikeSmith, yay, advanced 8 years :)
15:43
<MikeSmith>
hahah
16:19
<annevk>
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0414.html :-(
16:20
<annevk>
I don't even know where to start if I wanted to reply to that
16:56
<Domenic>
Yeah :(
16:56
<Domenic>
we talked about this at TAG f2f
16:56
<Domenic>
linked data software apparently isn't aware of redirects or canonicalization or anything like it
16:56
<Domenic>
just uses URLs as long guids
17:00
<annevk>
That doesn't seem problematic
17:00
<annevk>
They should just have additional logic for fetching resources if they actually plan on doing that
17:01
<annevk>
Also, there's owl:sameAs... They just need to invest some work in integrity and such
17:01
<Domenic>
agreed
17:03
<annevk>
Does anyone know what other browsers call what Gecko calls "load group"? The thing that's sort of responsible for keeping track of all fetches within an environment?
17:24
<jamesr___>
what's an "environment"?
17:24
<jamesr___>
a tab?
17:38
<annevk>
jamesr___: window or worker
17:38
<annevk>
jamesr___: anything with a global object
18:51
<jsbell>
Offhand, anyone know why the WebSocket constructor uses DOMString[] instead of sequence<DOMString> ?
19:00
<jgraham>
jsbell: No, but I wonder if you know anything about the server configuration for the blink service worker tests :)
19:00
<jsbell>
jgraham: not as much as I wish I knew, but I can try and get answers for you
19:02
<jgraham>
jsbell: I'm trying to work out what to map the various servers to e.g. 127.0.0.1:8000, etc. It wasn't immediately clear (without trying too hard) what relationship each was intended to have with the main server (different post, different host, etc.)
19:04
<jsbell>
jgraham: ah yes.... "intended" will be difficult w/o context. Generally it's just to get different origins, and it may be author's whim whether to vary host or port. Let me quick skim any docs we have to see if there's guidance...
19:04
<jgraham>
Oh dammit these tests have changed since I forked them :(
19:07
<jsbell>
jgraham: http://www.chromium.org/developers/testing/webkit-layout-tests#TOC-Tests-that-use-a-HTTP-Server says more... but I had never even heard of "pending tests" until now, digging...
19:07
<jgraham>
It would be nice to coordinate with the people actually writing the tests here. I guess I could just email them…
19:08
<jsbell>
jgraham: service workers specifically, right?
19:08
<jgraham>
jsbell: Yeah
19:08
<jgraham>
jsbell: That page is helful, thanks
19:08
<jgraham>
*helpful
19:14
<jsbell>
jgraham: I'm pinging the GOOG SW folks to see what the best way to coordinate with you would be. We've got some tracking cr bugs, we could spin up an issue on the SW github, etc.
19:19
<jsbell>
jgraham: so far as I can tell by looking at our apache config, that page is a lie; we use 8000, 8080, and 8443, not the other ports.
19:25
<jgraham>
jsbell: Awesome, thanks!
19:26
<jgraham>
annevk: What's the easiest way to tell if a string a an absolute url?
19:26
<jsbell>
jgraham: and from a random sampling, it appears to just be up to the test author to chose between varying host or port to get a different origin. Apart from security/origin tests, which try both, of course.
19:44
<wanderview>
JakeA: can we go ahead and remove scriptCaches
19:44
<wanderview>
?
19:48
<wanderview>
having a writable Cache that under-pins the ServiceWorker seems a bit dangerous... and we have no method to mark a Cache object read only currently
19:49
<wanderview>
I'm asking baku not to expose scriptCache in gecko for now
19:55
<jsbell>
wanderview: no plans to implement it any time soon in blink, either
19:55
<wanderview>
thanks... good to know
19:58
<wanderview>
jsbell: updated https://github.com/slightlyoff/ServiceWorker/issues/473
21:18
<jamesr___>
annevk: there's the thing that drives the spinner, which may be similar
21:43
<jsbell>
jgraham: also http://www.chromium.org/blink/serviceworker/testing - apart from host/port config and the py/php thing, if there's anything we're doing "weird" in our tests that's going to make upstreaming them more difficult, let me know and we can fix that doc and update our tests.
21:49
<jgraham>
jsbell: Thanks!