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! |