| 01:33 | <Domenic> | annevk: I sometimes use the assign feature as a sort of needsinfo, but it's meh |
| 02:36 | <MikeSmith> | botie, inform beverloo A comment from you at https://github.com/whatwg/notifications/issues/46 would be welcome. |
| 02:36 | <botie> | will do |
| 06:19 | <annevk> | Hixie: can we raise the cc limit for the WHATWG list? |
| 06:19 | <annevk> | Hixie: I keep hitting the limit |
| 06:22 | <MikeSmith> | annevk: did you see https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0099.html (Testing W3C's HTTPS setup)? |
| 06:22 | <annevk> | MikeSmith: did |
| 06:22 | <MikeSmith> | k |
| 06:23 | <annevk> | MikeSmith: but didn't really want to modify my setup |
| 06:23 | <MikeSmith> | ah OK |
| 06:24 | <MikeSmith> | well I've been trying it for a while and found a few problems (mostly just redirect loops) and systeam has fixed them all quickly |
| 06:24 | <MikeSmith> | so, progress |
| 06:26 | <MikeSmith> | but I've not been checking very carefully yet for mixed-content problems (to see if the Content-Security-Policy: upgrade-insecure-requests header is working as expected) |
| 06:34 | <annevk> | That only works in Chrome I think |
| 09:01 | <annevk> | philipj++ for editing help with Fullscreen |
| 09:02 | <annevk> | "fullscreen element" as concept refactoring is simplifying a ton of stuff |
| 09:02 | <philipj> | :) |
| 09:02 | <philipj> | let me know when it's settled down and I'll take another pass |
| 09:08 | <annevk> | philipj: do you know why collect ancestors looks top layers with only a single element? |
| 09:08 | <annevk> | philipj: should that also change to just looking for ancestor documents with a non-null fullscreen element? |
| 09:17 | <philipj> | annevk: yeah, I'm not sure why it's like that, what did it say before the top layer refactoring? |
| 09:17 | <annevk> | philipj: before it says fullscreen element stack with one element |
| 09:18 | <philipj> | oh, so I suppose the equivalent would be documents where the top layer stack has only on element with the fullscreen flag? |
| 09:18 | <annevk> | philipj: the top layer thing made it worse, it should just say single element that has its fullscreen flag set I suppose |
| 09:18 | <annevk> | philipj: yeah, changing it to that |
| 09:18 | <philipj> | if I'm not mistaken, this is all about exiting multiple levels of iframes when appropriate |
| 09:18 | <annevk> | philipj: yeah, was just thinking that too |
| 09:19 | <annevk> | ta |
| 09:19 | <philipj> | np |
| 09:34 | <philipj> | annevk: the note "HTML defines the exact conditions under which the fullscreen enabled flag ..." should probably be moved up one step |
| 09:36 | <annevk> | yes |
| 10:13 | <Ms2ger> | !summon TabAtkins |
| 10:52 | <philipj> | annevk: I've gone through the whole diff of recent changes and everything looks good now except for the open issues |
| 10:53 | <philipj> | probably would find more bugs if implementing though :) |
| 10:54 | <Ms2ger> | So go forth and implement :) |
| 11:42 | <MikeSmith> | annevk: CSP upgrade-insecure-requests just landed in gecko trunk, right? |
| 12:26 | <botie> | beverloo, at 2015-07-13 02:36 UTC, MikeSmith said: A comment from you at https://github.com/whatwg/notifications/issues/46 would be welcome. |
| 12:27 | <MikeSmith> | beverloo: I see you already commented there in the time since I left that message for you originally |
| 12:29 | <beverloo> | MikeSmith, no problem :) Thanks for pinging! |
| 12:33 | <MikeSmith> | beverloo: thanks for you comments and info |
| 13:11 | <TabAtkins> | Ms2ger: pong |
| 13:12 | <Ms2ger> | TabAtkins, a question about selectors, if you have a moment |
| 13:13 | <TabAtkins> | That's why I ponged |
| 13:14 | <Ms2ger> | Should :first-child etc. match an element a. without a parent node; b. whose parent is a Document; c. whose parent is a DocumentFragment; d. whose parent is an Element |
| 13:14 | <Ms2ger> | d. is obviously "yes", but I have no idea about the others |
| 13:14 | <Ms2ger> | Especially since selectors-3 and -4 seem to disagree |
| 13:15 | <TabAtkins> | S4 has the right answer. Let me review real quick. |
| 13:17 | <TabAtkins> | Yeah, :first-child/etc only care about relative position among siblings. Parent (or lack of) doesn't matter. |
| 13:19 | <Ms2ger> | How would you feel about adding a note near the definition or to the Changes section to point out the change is intentional? |
| 13:19 | <TabAtkins> | That's fine with me. Send email, as I won't be into the office for several hours yet? |
| 13:20 | <Ms2ger> | Sure |
| 13:37 | <Ms2ger> | Oh, I was going to cc the list |
| 13:38 | <Ms2ger> | Eh |
| 14:23 | <annevk> | MikeSmith: seems like it, got an email earlier anyway |
| 14:51 | <annevk> | JakeA: regarding no-cors CSS, https://bugzilla.mozilla.org/show_bug.cgi?id=1180145#c3 is our current thinking |
| 14:51 | <annevk> | JakeA: well, I guess it's mine, but I think the security people agree |
| 15:02 | <webzen> | hi |
| 15:03 | <webzen> | Can anyone give me some info on how es6 modules will be built and assembled on es6 browsers without using browserify or such ? |
| 15:04 | <webzen> | high level |
| 15:04 | <annevk> | webzen: there's an idea for <script type=module src=module.js> |
| 15:05 | <annevk> | webzen: https://whatwg.github.io/loader/ and its repo have some of the details for an even bigger plan |
| 15:06 | <webzen> | i tried to read that already but it was too low level. So with main.js containing import module1 from "./imports/module1"; |
| 15:06 | <webzen> | how would the client get to the files on the server |
| 15:06 | <webzen> | to traverse the tree |
| 15:06 | <webzen> | of dependencies |
| 15:07 | <annevk> | client being? |
| 15:07 | <ondras> | well by using a regular http request that is normally used to fetch scripts |
| 15:07 | <webzen> | client being a es6 browser in the future. and i start with <script src="build/js/main.js"></script> |
| 15:07 | <webzen> | but main.js only has import module1 from "./imports/module1"; |
| 15:08 | <ondras> | right. its dependencies will be fetched, analyzed, their dependencies fetched, analyzed, .... |
| 15:08 | <ondras> | and once the whole tree is statically analyzed, the code is finally run |
| 15:08 | <annevk> | it's not exactly defined how the translation happens and whether from "..." is a URL or some identifier |
| 15:08 | <webzen> | so the es6 browsers will make more requests ? |
| 15:08 | <webzen> | currently i have all my js in one file to reduce requests |
| 15:08 | <ondras> | if you serve your code in X files, X requests will be made |
| 15:08 | <webzen> | won't that be expensive ? |
| 15:08 | <annevk> | yeah, but not with HTTP/2 |
| 15:09 | <ondras> | also you can pack your multiple ES6 modules into one |
| 15:09 | <annevk> | ondras: not anymore |
| 15:09 | <ondras> | annevk: I mean the System.register API |
| 15:09 | <annevk> | ondras: there's no syntax for inline modules |
| 15:09 | <ondras> | babel --modules=system or somth |
| 15:09 | <webzen> | ondras: i'm saying without babel |
| 15:09 | <ondras> | okay |
| 15:09 | <webzen> | in es6 browsers |
| 15:09 | <ondras> | http2 then |
| 15:09 | <ondras> | or multiple requests |
| 15:10 | <webzen> | is HTTP/2 in current browsers or is that future thing |
| 15:10 | <ondras> | http://caniuse.com/#feat=http2 |
| 15:11 | <webzen> | so it's already in the current browsers |
| 15:13 | <webzen> | annevk: so are there any es6 browsers with this loader yet ? |
| 15:13 | <webzen> | thanks ondras |
| 15:13 | <annevk> | nope |
| 15:14 | <annevk> | I've been thinking about poking at it, but haven't made the time yet |
| 15:14 | <webzen> | so currently i'm using babel but in the future i'll just be able to use the es6 browsers and they will handle assembling the modules |
| 15:14 | <webzen> | ? |
| 15:14 | <webzen> | or is my thinking wrong |
| 15:15 | <annevk> | sounds about right, you might need some tweaks here and there I guess, depends a bit on the final details |
| 15:15 | <webzen> | i just don't want to write code that will fail in the future |
| 15:16 | <webzen> | since i'm going to be writing es6 code |
| 15:20 | <webzen> | so to be clear, in the future es6 browsers they will be able to run the dependency from the client side by making multiple calls to build the file before running it yes ? |
| 15:26 | <annevk> | TabAtkins: can you roll https://github.com/plinss/widlparser/commit/43f0d6be64741642dd8ea9f6847dfec0ad3afb14 into bikeshed? |
| 15:27 | <webzen> | annevk: can you please affirm or correct my statement please ? |
| 15:28 | <annevk> | webzen: it's not entirely clear to me what that statement means |
| 15:28 | <webzen> | meaning i won't need babel or such |
| 15:28 | <annevk> | webzen: well yes, that's the intent |
| 15:28 | <webzen> | the browsers will handle the module assembling |
| 15:29 | <annevk> | yup |
| 15:29 | <webzen> | ok thanks so much |
| 15:29 | <webzen> | that's very helpful |
| 15:29 | <annevk> | and in some future future the module can be some WebAssembly code |
| 15:29 | <webzen> | i'll be playing guitar then :-) |
| 15:30 | <webzen> | WebAssembly is a thing ? |
| 15:30 | <annevk> | it's a thing: https://github.com/WebAssembly |
| 15:30 | <webzen> | oh dear |
| 15:31 | <TabAtkins> | annevk: Will do so shortly. |
| 15:31 | <webzen> | so i'll be able to start over with WebAssembly and forget all I know :-) |
| 15:32 | <webzen> | thanks again ! |
| 15:34 | <TabAtkins> | Well, you'll be able to start over with whatever languages compile into WebAssembly. You won't write it directly, any more than you write asm.JS directly. |
| 15:36 | <caitp> | so, is wasm supposed to have enough type info and static knowledge of the program available to eg. bypass expensive optimization processes at runtime? |
| 15:36 | <caitp> | it would be pretty cool if it just plugged into ionmonkey/tf right away |
| 15:37 | <caitp> | since i guess you'd hope clang would do the LICM and constant folding and operator reduction and etc |
| 15:38 | <JakeA> | annevk: is your analysis at https://github.com/whatwg/fetch/issues/66#issuecomment-118638144 how it works now, or how a solution could work |
| 15:38 | <JakeA> | annevk: is your analysis at https://github.com/whatwg/fetch/issues/66#issuecomment-118638144 how it works now, or how a solution could work? |
| 15:38 | <annevk> | caitp: we're planning on making use of IDL to bypass a bunch of IDL stuff |
| 15:39 | <annevk> | JakeA: 'we should just expose it as a "redirect" (new type of response, identical to opaque except for its type and exposure of url as that is identical to the request url)' and what follows is a proposal |
| 15:42 | <JakeA> | (sorry for the repeated message, got caught in the netsplit) |
| 15:42 | <JakeA> | annevk: "If you then get back an opaque response you know that a redirect happened." - that's not what happens now though |
| 15:42 | <JakeA> | You get a non-opaque response back for the final non-redirect resource |
| 15:43 | <JakeA> | Since fetch(event.request) changes the mode of the request |
| 15:45 | <annevk> | JakeA: no it doesn't? |
| 15:46 | <JakeA> | annevk: hmm, I'm getting confused then https://fetch.spec.whatwg.org/#request-class "If request's redirect mode is "manual", set it to "follow"." |
| 15:47 | <annevk> | JakeA: oh, changes the redirect mode? |
| 15:47 | <annevk> | JakeA: right, we'd stop doing that |
| 15:47 | <JakeA> | annevk: ah, yes, sorry wasn't specific enough. Yeah, that's why I was asking if that line was you clarifying the current behaviour or a proposed behaviour. It's the latter, got it |
| 15:48 | <annevk> | it's the proposed behavior for redirect mode "manual", still not super helpful since you don't actually know where the redirect will go, but at least a little bit |
| 16:10 | <TabAtkins> | caitp: wasm starts with asm.js, basically, just in a binary format. It'll grow optimizations and features as it goes. |
| 16:25 | <annevk_> | TabAtkins: that bug is one of the reasons for migrating to GitHub, would be hard to WONTFIX |
| 16:26 | <TabAtkins> | Why is it hard? |
| 16:27 | <annevk> | TabAtkins: it'll just get reopened |
| 16:27 | <annevk> | TabAtkins: a11y concern does seem like something that needs addressing one way or another |
| 16:27 | <TabAtkins> | You can just... close it again. What's special about Bugzilla that makes it reopenable? |
| 16:28 | <TabAtkins> | Yeah, have an open bug on Bikeshed for that. Just need to modify the CSSWG and WHATWG stylesheets to handle it. |
| 16:28 | <TabAtkins> | (So they dont' double-generate "Warning", etc. |
| 16:28 | <TabAtkins> | ) |
| 16:29 | <annevk> | TabAtkins: feel free to WONTFIX and see what happens |
| 16:29 | <TabAtkins> | I'm not responsibel for the spec, so shrug. |
| 16:29 | <annevk> | TabAtkins: I wonder who they think will fix that bug anyway, with berjon leaving the W3C |
| 16:30 | <annevk> | And also, berjon made a vague promise of only subsetting, not forking |
| 16:32 | <TabAtkins> | Worth the paper it wasn't printed on, obvs. |
| 16:33 | <jgraham> | Oh did darobin leave? |
| 16:33 | <TabAtkins> | Did, or will soon, I forget. Working... I forget where. |
| 16:33 | <TabAtkins> | Somewhere cool. |
| 16:33 | <annevk> | NYC |
| 16:33 | <TabAtkins> | Yeah, def NY, just forget what company. |
| 16:35 | <annevk> | https://twitter.com/robinberjon/status/616565633539571712 |
| 16:38 | <jgraham> | Presumably the Watson and Crick photo is an example of using someone else's data to make your discovery ;) |
| 16:39 | <TabAtkins> | jgraham: Context? |
| 16:39 | <botie> | Context is https://github.com/validator/validator/issues/61 |
| 16:39 | <TabAtkins> | That's... incorrect, botie. |
| 16:39 | <botie> | TabAtkins: i'm not following you... |
| 16:39 | <jgraham> | TabAtkins: http://www.standardanalytics.io/ |
| 16:40 | <TabAtkins> | ah |
| 16:41 | <Ms2ger> | .io, of course |
| 16:46 | <annevk> | "JSON-LD and RDFa" |
| 17:58 | <izhak> | Hi, guys! How do I import svg file with filters into html for use in css ? |
| 18:05 | <TabAtkins> | izhak: Just point to them with url() as usual. |
| 18:05 | <TabAtkins> | They're just images. |
| 18:06 | <izhak> | TabAtkins: I'm trying this: filter: url(./filters.svg#mtshadow); |
| 18:07 | <TabAtkins> | Oh, you're trying to get an SVG *filter* into CSS. |
| 18:07 | <TabAtkins> | Still, that's supposed to work, per spec. |
| 18:07 | <TabAtkins> | http://dev.w3.org/FXTF/filters-1/#typedef-url |
| 18:08 | <izhak> | TabAtkins: yes. And currently I'm working with a local files (file:///). In firefox 39 when I click to that url in firebugs css console, it opens the svg file with filters. But filters refuse to apply... |
| 18:09 | <TabAtkins> | Hm, per caniuse.com, that should work. |
| 18:10 | <TabAtkins> | It's possible you need to flip the layout.css.filters.enabled flag? |
| 18:11 | <izhak> | Actually svg filters work when I open for example this: http://bl.ocks.org/cpbotha/5200394 |
| 18:13 | <TabAtkins> | Yes, that's creating an inline SVG element. |
| 18:14 | <wanderview> | JakeA: if disk space is running low and an origin has its storage purged... is there anything in SW spec or chrome impl to run the SW install event again? |
| 18:14 | <izhak> | TabAtkins: What I do is copy the external html for svg tag in this example (using firebug), paste it to filters.svg and then refer to it as I showed. |
| 18:15 | <izhak> | I apply it to rect element, and it just disappears. |
| 18:15 | <TabAtkins> | If you view the filters.svg file, do you see the rect with shadows? |
| 18:17 | <izhak> | oops.. firefox opens it like a xml file.. looks like I forgot to add xmlns and version |
| 18:17 | <TabAtkins> | You don't need version, just xmlns |
| 18:18 | <TabAtkins> | (We're hoping to remove that requirement.) |
| 18:18 | <tantek> | xmlns lol |
| 18:18 | <TabAtkins> | tantek: indeed |
| 18:18 | <izhak> | TabAtkins: great it works now, thank you:) |
| 18:19 | <TabAtkins> | np |
| 18:23 | <JakeA> | wanderview: I don't think so, wouldn't that just fill up space again? |
| 18:24 | <wanderview> | JakeA: the problem is if the SW thinks its still installed... but its Cache was deleted out from under it... it may not try to re-populate without another install event |
| 18:24 | <wanderview> | this may be a gecko problem, though |
| 18:31 | <TabAtkins> | annevk: I'm confused about your questions about "the font API" and "such a CSS resource". Are you under the impression that Font Loading does something with CSS files? |
| 18:34 | <annevk> | TabAtkins: is that not where it gets the FontFace stuff from? |
| 18:34 | <TabAtkins> | Stylesheets create FontFace objects, yeah. |
| 18:34 | <annevk> | right, and no-cors stylesheets shouldn't have their FontFace objects exposed, most likely |
| 18:34 | <TabAtkins> | Ah... Hm. |
| 18:34 | <annevk> | because that violates SOP |
| 18:37 | <TabAtkins> | Yeah, I suppose so. I'll open a thread on www-style notifying people, and make the change. |
| 18:42 | <TabAtkins> | What's the right term to link for "CORS-enabled"? |
| 18:43 | <Krinkle> | JakeA: Do you know what the expected behaviour is with SW caching with regards to quota? See my comment at https://phabricator.wikimedia.org/T66721#1350485 for context. |
| 18:44 | <JakeA> | wanderview: yeah, I don't think we should be dropping part of an origin's storage |
| 18:44 | <JakeA> | wanderview: if we drop the cache or IDB, we should drop the SW too |
| 18:45 | <wanderview> | JakeA: yea, we should treat the registration as part of the origin storage... right now we have it in a separate non-origin-specific db |
| 18:45 | <wanderview> | the scripts live in origin storage though |
| 18:45 | <JakeA> | Krinkle: the cache uses the same origin storage as idb |
| 18:46 | <TabAtkins> | Ugh, this makes things complicated. I need to include them in the source, but flag them so they're invisible to any query methods that aren't called by a blessed caller. |
| 19:04 | <izhak> | Guys, is it possible to apply perspective transformation to a svg group? |
| 19:05 | <TabAtkins> | Yes, but iirc you need to use the transform property, not the transform attribute. (3d transforms are part of CSS, and not accepted in the SVG attribute) |
| 19:07 | <izhak> | Cool, thanks! |
| 19:12 | <TabAtkins> | heycam|away: Just hitting you with an explicit ping, I just posted https://lists.w3.org/Archives/Public/www-style/2015Jul/0150.html about FontFace objects from a cors-tainted stylesheet. |
| 20:37 | <annevk> | TabAtkins: CORS-tainted is not a thing |
| 20:37 | <annevk> | TabAtkins: simplest would be to simply filter out those FontFace objects I think |
| 20:38 | <TabAtkins> | annevk: Not really. It means that, for example, calling document.fonts.load("some-font-in-the-co-sheet 10px") will confusingly return a promise for an empty array of fonts. |
| 20:38 | <TabAtkins> | Despite actually kicking off loads. |
| 20:39 | <annevk> | That would make it observable |
| 20:39 | <TabAtkins> | And I still need the ability for the impl to use these algos and receive the "real" set. |
| 20:39 | <TabAtkins> | Loading behavior is already trivially observable via timing channels. |
| 20:39 | <TabAtkins> | If you know the font name, you can test for loaded status. |
| 20:39 | <annevk> | How? |
| 20:40 | <TabAtkins> | ...the same way you measure whether a font is loaded today? |
| 20:40 | <TabAtkins> | Create an inline element styled with the font you want to measure, and a font you already know has loaded as a fallback. Poll its width; when it changes, the first font has loaded. |
| 20:41 | <annevk> | Ah yeah |
| 20:41 | <TabAtkins> | (Ideally your fallback is a constructed font with weird metrics, very tiny or very big, so it's impossible to confuse your algo if the first font is already loaded.) |
| 20:41 | <TabAtkins> | So exposing load status of fonts you know by name isn't a further leak. |
| 20:43 | <TabAtkins> | Exposing the number of fonts in a tainted stylesheet, and the load status of those mystery fonts, is somewhat more information than is available today, but I have a slightly more complex proposal that addresses that, too. At worst, it only exposes whether the stylesheet contains *any* fonts, but I might be able to spec it such that that's plugged too. |
| 20:43 | <annevk> | Yeah, that proposal seemed okayish |
| 20:44 | <annevk> | Hopefully we can get bz to take a look |
| 20:44 | <TabAtkins> | Which? #2 in the email, or #3 in the next? |
| 20:44 | <annevk> | #3 |
| 20:45 | <annevk> | Anyway, thanks for tackling this switfly |
| 20:45 | <TabAtkins> | np |
| 20:45 | <boogyman> | is there some reason why exposing loading/loaded fonts is an issue? |
| 20:45 | <TabAtkins> | And thanks for prompting me to do the refactor necessary to fix the dom Bikeshed error. ^_^ |
| 20:45 | <annevk> | And reach out to bz somehow I guess, not sure who else would be good to review this |
| 20:45 | <TabAtkins> | boogyman: It's more information than is exposed today. |
| 20:46 | <TabAtkins> | annevk: Already pinged heycam, about to ping our internal people. |
| 20:46 | <TabAtkins> | Tho that's just font implementors, not security people. |
| 20:46 | <boogyman> | but is that extra info a bad thing? what can someone really do with it? |
| 20:47 | <TabAtkins> | who knows? That's why we limit cross-origin data in the first place. |
| 20:48 | <TabAtkins> | It's often difficult to construct specific attack scenarios until they happen, so a blanket prohibition is often warranted. |
| 20:48 | <boogyman> | ah, I missed the CORS mention |
| 20:51 | <annevk> | Indeed, it's the combinatory explosion thing why we need to keep SOP as tight as it is now |
| 20:51 | <annevk> | Even security groups such as WebAppSec seem eager to break it :-( |
| 20:58 | <roc> | :-) |
| 20:58 | <annevk> | roc: rebel |
| 21:00 | <annevk> | nn |
| 21:39 | <jgraham> | So… why can't I find where the spec says what to do when you try to navigate and end up with a network error of some sort? |
| 23:04 | <Domenic> | Can dispatching an event (from spec) throw an error? |
| 23:04 | <Domenic> | Probably not... |
| 23:15 | <smaug____> | Domenic: it can if the event is already being dispatched |
| 23:15 | <smaug____> | (or if the event isn't initialized ) |
| 23:16 | <smaug____> | oh, perhaps "from spec" means, implementation dispatching events |
| 23:16 | <Domenic> | smaug____: OK, but author listeners throwing doesn't need to be handled by specs that do "dispatch event" |
| 23:21 | <caitp> | do multiple event listeners ever happen in the same turn? |
| 23:22 | <TabAtkins> | No. |
| 23:23 | <caitp> | just trying to think of a situation where it would matter if the authors listener threw |
| 23:24 | <Domenic> | Of course they do... |
| 23:24 | <Domenic> | dispatchEvent() will fire them all, for one |
| 23:24 | <Domenic> | And queuing a task to fire an event from some other spec will call all of them, certainly. |
| 23:25 | <Domenic> | Right, OK, there's a try { call listener } catch (e) { reportException(e); } in the spec. https://dom.spec.whatwg.org/#concept-event-listener-invoke |
| 23:29 | <caitp> | i dunno man, the web is too complicated. no idea how you can ever tell if some change might break something unless it's really obvious |
| 23:30 | <caitp> | even for less complicated systems, it's really hard to tell if anyone ever depends on some subtle thing that might change between versions |