| 01:52 | <MikeSmith> | https://twitter.com/qubyte/status/610968768760651776 |
| 01:52 | <MikeSmith> | "Linters are like children... Very naïve, often insightful, and worth taking time and effort to explain things to." |
| 01:54 | <MikeSmith> | gde33: about your "I was curious if there have been proposals for html to get a nice standard outliner" questions at http://krijnhoetmer.nl/irc-logs/whatwg/20150616#l-762 yeah there have been proposals |
| 01:56 | <MikeSmith> | not necessarily for a way to directly render an outline, but at least for a way for Web content to get access to the outline as an object |
| 01:57 | <MikeSmith> | a method to get an outline object in script, either for the whole doc or for a subtree |
| 04:02 | <MikeSmith> | Hixie: I'm going to disable your W3C bugmail briefly while I mass-change some bugs in an uninteresting way |
| 04:40 | <MikeSmith> | Hixie: turned your W3C bugmail back on |
| 04:55 | <annevk> | So Safar when seeing a duplicate @ simply returns failure... |
| 04:56 | <annevk> | I keep writing Safar instead of Safari... |
| 09:36 | <mrflix> | I just ran into this problem: in a web-app UI we want the user to input a timeframe in hours in which to responde to a message. The timeframe should be hours up to 72. We’d love to use input#time but its limited to 24 hours max. Any suggestions where I can suggest a change in the standard? |
| 09:45 | <Ms2ger> | People seriously want to put HTML in WebApps |
| 09:45 | <Ms2ger> | ? |
| 10:05 | <jgraham> | Ms2ger: One group to rule them all |
| 10:06 | <Ms2ger> | Not one I'll touch with a ten-foot pole |
| 10:16 | <annevk> | Rewriting the URL parser is somewhat more work than anticipated |
| 10:49 | <MikeSmith> | annevk: you doing the functional thing? |
| 10:49 | <annevk> | MikeSmith: no, just the rewrite to support relative URLs |
| 10:49 | <MikeSmith> | ah OK |
| 10:49 | <MikeSmith> | yeah had forgotten about that |
| 10:50 | <annevk> | "just" |
| 10:51 | <MikeSmith> | heh |
| 10:51 | <MikeSmith> | I wouldn't think it would be so much work |
| 10:51 | <MikeSmith> | well, relative to other stuff at least |
| 10:51 | <MikeSmith> | (no pun intended) |
| 10:57 | <hsivonen> | annevk: yay unit tests. I found a spec bug in the big5 decoder thanks to a unit test added for a Gecko bug you had filed. |
| 10:57 | <hsivonen> | annevk: I'll file a spec bug |
| 10:58 | <annevk> | yay |
| 11:01 | <annevk> | MikeSmith: hehe |
| 11:01 | <annevk> | MikeSmith: it's a lot of extra conditionals and states |
| 11:01 | <annevk> | MikeSmith: and some reorganizing of existing states |
| 11:10 | <JakeA> | annevk: fetch(request) - if request's redirect flag is set to "manual", do you remember why we set it to follow rather than return a redirect (perhaps with the location header opaque) |
| 11:10 | <hsivonen> | annevk: https://github.com/whatwg/encoding/issues/5 |
| 11:24 | <JakeA> | (will create a github issue) |
| 11:30 | hsivonen | learns that Gecko's encoding converter API is underdocumented, too |
| 11:31 | <hsivonen> | looking forward to seeing a encoding conversion API that isn't underdocumented |
| 11:32 | <annevk> | JakeA: because fetch() does not allow setting it to manual |
| 11:38 | <JakeA> | annevk: https://github.com/whatwg/fetch/issues/66 |
| 12:27 | <JakeA> | annevk: "analyzed" - do you mean by a security team? |
| 12:27 | <annevk> | JakeA: yeah |
| 12:28 | <annevk> | JakeA: last time exposing status was a no-go |
| 12:28 | <annevk> | JakeA: and redirects are a constant source of bugs |
| 12:28 | <annevk> | JakeA: both security and otherwise |
| 12:28 | <JakeA> | annevk: if that's the only objection here, I'll look into it. I thought it was the redirect location that caused the problems rather than just knowing there was a redirect, but I'll dig in |
| 12:29 | <annevk> | JakeA: making them more fragile is not something I'm very happy with |
| 12:29 | <annevk> | JakeA: well that was a issue we found and why the hole was closed |
| 12:29 | <annevk> | JakeA: there might very well be others |
| 12:31 | <JakeA> | annevk: thanks, I'll run it past people. I'm not against making it opaque btw. |
| 12:32 | <JakeA> | But a common pattern is hit url -> not logged in? -> redirect to other origin for login |
| 12:32 | <JakeA> | And we're breaking that |
| 12:32 | <annevk> | JakeA: I think one of the problems is what happens if you store a redirect in the cache |
| 12:33 | <annevk> | JakeA: what happens if you respondWith that redirect in a different context |
| 12:33 | <annevk> | that's all kinds of new vectors |
| 12:33 | <JakeA> | annevk: shouldn't be a problem, should it? Would act the same as if you returned Response.redirect(url) |
| 12:33 | <annevk> | well, except the latter is not privileged |
| 12:34 | <annevk> | and doesn't go to a secret URL |
| 12:35 | <annevk> | e.g. I store that redirect |
| 12:35 | <annevk> | then I create a DELETE request |
| 12:35 | <annevk> | and reply that redirect to that DELETE request |
| 12:35 | <annevk> | that'll fail cross-origin, but same-origin could still be problematic |
| 12:36 | <annevk> | at least, I hope that'll fail cross-origin... |
| 12:38 | <hsivonen> | annevk: It looks like I have push access to whatwg repos. to submit a PR to encoding, should I push a feature branch to the main repo or should I first create a fork under my own account? |
| 12:39 | <annevk> | hsivonen: main repo should be fine |
| 12:39 | <hsivonen> | annevk: ok. thanks |
| 12:39 | <annevk> | hsivonen: that used to trigger the Twitter bot, but it now filters for the master branch |
| 12:55 | <hsivonen> | annevk: OK. I created a PR. |
| 13:00 | <annevk> | hsivonen: thanks! |
| 13:00 | <annevk> | hsivonen: merged and stuff |
| 13:07 | <hsivonen> | annevk: thanks |
| 14:51 | <wanderview> | JakeA: do you have any thoughts on this one? https://github.com/slightlyoff/ServiceWorker/issues/709 |
| 14:51 | <wanderview> | just wondering if I should try to get it in |
| 14:56 | <JoWie> | is that enforce https for new features still a thing? |
| 15:03 | <annevk> | JoWie: yes |
| 15:08 | <JakeA> | wanderview: replied! |
| 15:09 | <wanderview> | thanks! |
| 15:09 | <JoWie> | so would i need a localhost certificate ;) |
| 15:10 | <wanderview> | I'll try to get something implemented soon even though its not completely spec'd |
| 15:10 | <wanderview> | I think localhost should be exempted |
| 15:10 | <MikeSmith> | I think it is already |
| 15:11 | <wanderview> | for SW it is, but this is about adding a new restriction... so nothing is really specified... I don't think this mentions localhost in general: https://w3c.github.io/webappsec/specs/powerfulfeatures/#settings-secure |
| 15:11 | <MikeSmith> | 「Certain origins are always potentially trustworthy. In particular, UAs MUST treat file URLs and URLs with hostnames names equivalent to "localhost" as potentially trustworthy.」 |
| 15:12 | <MikeSmith> | https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy |
| 15:15 | <wanderview> | ah, cool... thanks |
| 15:15 | <annevk> | JoWie: localhost is whitelisted |
| 15:15 | <annevk> | JoWie: did you not read the threads? |
| 15:15 | <JoWie> | i read it a long while back |
| 15:15 | <annevk> | wanderview++ |
| 15:15 | <JoWie> | but i never heard from it afterwards |
| 15:16 | <annevk> | Better start ordering some certificates, or wait until September 14 I guess |
| 15:17 | <JoWie> | i rarely use https because you have to renew them |
| 15:18 | <JoWie> | i just hope i do not accidentally use one of the newer features and then only find out alter i need a cert |
| 15:19 | <JoWie> | or just bug people to modify their whitelist :p |
| 15:21 | <annevk> | JoWie: I recommend doing some reading then, something as basic as HTTP/2 requires it |
| 15:23 | <JoWie> | i thought http 2 had opportunistic ssl |
| 15:34 | <annevk> | Firefox implements that, unfortunately, but fortunately, nobody else does |
| 15:48 | <wanderview> | MikeSmith: annevk: does this address the case of http doc creates https iframe which creates https SharedWorker? seems SharedWorker doesn't have a strict parent to trace back through: https://w3c.github.io/webappsec/specs/powerfulfeatures/#settings-secure |
| 15:50 | <annevk> | wanderview: SharedWorker can have multiple parents... |
| 15:51 | <annevk> | wanderview: I guess using the initial parent or all parents would be an okay solution... |
| 15:51 | <annevk> | wanderview: I'd somewhat prefer all if that's not a major perf issue |
| 15:51 | <annevk> | wanderview: although I guess all is not really an option as that would make it change over time |
| 15:51 | <annevk> | wanderview: probably the one that created the SharedWorker then |
| 15:51 | <wanderview> | annevk: I think the issue with that is it could oscillate between trusted to untrusted to trusted again as docs attach/detach |
| 15:52 | <wanderview> | annevk: I think sicking has requested that SharedWorker not base anything on doc at all, since the docs can change over time |
| 15:52 | <annevk> | so you determine securedness on creation and store that |
| 15:53 | <annevk> | the initial doc can't |
| 15:53 | <wanderview> | annevk: so if something else for that origin has made SharedWorker already... then http doc->https iframe->SharedWorker works... but if nothing else has made the worker yet, then you get the restriction? that will probably be a bit magical for people to understand |
| 15:53 | <annevk> | and I'm okay with docs changing |
| 15:53 | <annevk> | I'm just saying that we set this bit on creation and keep it around until the sharedworker is destroyed |
| 15:54 | <wanderview> | annevk: I understand that... but from the call site in the http doc->https iframe the behavior will be inconsistent |
| 15:54 | <wanderview> | and I guess also lets the GC of SharedWorkers be observed |
| 15:55 | <wanderview> | annevk: I guess I can open an issue in the powerfeatures repo |
| 15:55 | <annevk> | wanderview: maybe sharedworker should simply not work in such a mixed environment? |
| 15:55 | <wanderview> | yea |
| 15:56 | <annevk> | wanderview: that would be the best way out here I think |
| 15:56 | <annevk> | wanderview: require a same-scheme parent chain |
| 15:59 | <wanderview> | annevk: I wrote this: https://github.com/w3c/webappsec/issues/406 |
| 16:04 | <annevk> | https://blog.mozilla.org/luke/2015/06/17/webassembly/ |
| 16:48 | <JonathanNeal> | https://github.com/jonathantneal/postcss-nesting @TabAtkins I hope I got it right. Getting the parent reference to work was a pain. Would you be able to dumb down how @media works for me? The spec doesn’t give an example. |
| 17:29 | <annevk> | "As another example, the mobile Web depends on your browser downloading font resources without checking the CORS headers (as per spec) — we’ve had to change to WebKit behavior in our mobile browsers to make the mobile Web work." |
| 17:29 | <annevk> | http://blogs.windows.com/msedgedev/2015/06/17/building-a-more-interoperable-web-with-microsoft-edge/ |
| 17:29 | <annevk> | Well that's interesting |
| 17:42 | <annevk> | hsivonen: your latest big5 patch still mentions the GitHub issue |
| 17:42 | <annevk> | hsivonen: not a big deal I guess, but you might want to remove that reference locally |
| 17:43 | <Domenic> | meanwhile i feel like there was movement in chrome to try to enforce the cors header. not sure it went anywhere though. |
| 17:45 | <hsivonen> | annevk: I'll remove the reference if I respin the patch or, alternatively, in the encoder patch |
| 17:49 | <annevk> | Domenic: yeah, TabAtkins mentioned that at some point |
| 17:53 | <annevk> | MikeSmith: more URL tests: https://github.com/w3c/web-platform-tests/pull/1909 |
| 17:53 | <annevk> | Sebmaster: ^ |
| 17:54 | <annevk> | The URL Standard just had a major change landed. If you encounter bugs please tell me. It's likely... |
| 17:55 | <Sebmaster> | annevk: havent had time to integrate the changes yet and its kinda late |
| 17:55 | <Sebmaster> | but ill get to it tomorrow |
| 17:55 | <annevk> | Sebmaster: no rush |
| 18:17 | <TabAtkins> | annevk, Domenic: I'll ping Kenji about that again today. |
| 18:18 | <TabAtkins> | JonathanNeal: What needs explaining? |
| 18:21 | <JonathanNeal> | TabAtkins: I’m unsure what happens when @media is nested. |
| 18:23 | <TabAtkins> | The spec doesn't add any new @media nesting abilities |
| 18:25 | <JonathanNeal> | .foo { { @media (min-width: 768px) { /* so this is just gonna fail, right? */ } } |
| 18:26 | <TabAtkins> | Under current specs + Nesting, yeah. |
| 18:27 | <TabAtkins> | You don't need Nesting Block for at-rules anyway. |
| 18:27 | <TabAtkins> | (I'm still considering getting rid of the Nesting Block, and using plain & at the start, or a new @nest rule when it's not at the start.) |
| 18:28 | <TabAtkins> | So for most cases it'd be the same as Sass. |
| 18:29 | <TabAtkins> | Technically, we only need *anything* special to handle the case of a selector starting with a type selector. |
| 18:30 | <TabAtkins> | But I think that's too fine of a distinction to capture directly. The "starts with &" criteria is easier. |
| 19:14 | <JonathanNeal> | TabAtkins: are you thinking of refreshing the syntax? |
| 19:20 | <TabAtkins> | Yeah |
| 19:37 | <JonathanNeal> | How does the new version work, it requires & somewhere before the {? |
| 21:02 | <David17Obbatala> | hola |
| 21:02 | <botie> | niihau, David17Obbatala |
| 21:05 | <David17Obbatala> | niihau botie |
| 23:42 | <MikeSmith> | is this true? https://twitter.com/w3be/status/611306366758727681 (that browsers fall back to UTF-8 for unknown/supported values of charset; e.g., charset=utfX or charset=utf9) |
| 23:42 | MikeSmith | tries Chris Weber's tool at http://www.lookout.net/test/charsets/iana-charset-support/ to see |
| 23:44 | <MikeSmith> | hmm yeah, "utf16" -> UTF-8 |
| 23:45 | <Domenic> | No way... |
| 23:47 | <MikeSmith> | far as I can see |
| 23:48 | <MikeSmith> | hyphens are important :) |
| 23:56 | <Domenic> | I wonder about the header vs. the meta tag |