| 00:07 | <Hixie> | so many ways to design an iterator |
| 06:14 | <tyoshino__> | zewt: sorry. i didn't mean replacing all the use cases of Blob. Use cases where stream fits, stream would play the role instead of Blob. Like Domenic_'s examples, we could have elements to work as WritableStream and pipe to it from some source |
| 06:14 | <tyoshino__> | elements, video, audio, etc. |
| 06:39 | <tyoshino__> | Corrected on the bug |
| 09:20 | <annevk> | https://twitter.com/hober/status/430907579061915648 hahaha |
| 09:24 | <yoav> | zcorpan: I'm adding the essence of http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2795 as a Blink layout test, if you're cool with it |
| 09:25 | <zcorpan> | yoav: no need to ask for permission to write tests :-) |
| 09:26 | <zcorpan> | or to steal my tests |
| 09:54 | <yoav> | zcorpan: awesome! |
| 10:39 | <annevk> | Hixie: I agree with you with respect to frozen |
| 10:39 | <annevk> | Hixie: frozen has the wrong semantic, you want immutable |
| 10:39 | <annevk> | Hixie: the inability to mutate the array, but the ability to add expandos |
| 10:40 | <annevk> | Hixie: of course that doesn't really exist |
| 10:42 | <jgraham> | If only there were people working on the platform who could make it exist |
| 10:46 | <darobin> | jgraham++ # funny |
| 10:52 | <annevk> | I think sicking's idea is that by using frozen, we can more easily switch to immutable later. Whereas if they are not frozen, we cannot switch to immutable later. |
| 11:13 | <MikeSmith> | I guess I shouldn't admit I don't know what frozen is |
| 11:23 | <SteveF> | MikeSmith: its a movie http://en.wikipedia.org/wiki/Frozen_%282013_film%29 |
| 11:28 | <jgraham> | Hmm, nice to know that shadow-DOM is stilll a trainwreck |
| 11:30 | MikeSmith | wonders if smaug e-mailed blink-dev yet |
| 12:01 | <zcorpan> | https://github.com/bholley/web-platform-tests/compare/submission;bholley isn't actually a pull request yet, is it? i can't find it listed in w3c/web-platform-tests PRs |
| 12:11 | <jgraham> | zcorpan: No |
| 12:13 | <jgraham> | I think this is the wrong hour to ask bholley if he meant it to be |
| 12:23 | <zcorpan> | i commented in the bug so he'll see it at the right hour i hope :-) |
| 12:36 | <jgraham> | Look like interesting tests, but I want to make comments ;) |
| 12:45 | <zcorpan> | hsivonen: MikeSmith: does v.nu not support <foreignObject>? |
| 12:46 | <MikeSmith> | zcorpan: it's meant to |
| 12:48 | <MikeSmith> | zcorpan: test document? |
| 12:50 | <zcorpan> | MikeSmith: <!DOCTYPE html><title>x</title><svg><foreignobject></foreignobject></svg> |
| 12:52 | <zcorpan> | foreignObject has a weird content model per spec. is it intentional that any element in the svg namespace is allowed? |
| 12:56 | <MikeSmith> | foreignObject should only allow <math>, <html>, <body>, or flow content |
| 12:56 | <MikeSmith> | zcorpan: <!DOCTYPE html><title>x</title><svg><switch><foreignobject></foreignobject></switch></svg> |
| 12:58 | <MikeSmith> | is foreignobject now allowed outside of switch? |
| 12:58 | <zcorpan> | switch huh |
| 12:58 | <zcorpan> | MikeSmith: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#svg-0 seems to ban <html> and <body> |
| 12:58 | MikeSmith | looks |
| 12:58 | <MikeSmith> | oh |
| 12:59 | <zcorpan> | MikeSmith: and http://www.w3.org/TR/SVG11/struct.html#SVGElement seems to allow foreignObject as child of svg |
| 12:59 | <MikeSmith> | I wonder if that was added later. Anyway, I can fix that |
| 12:59 | <MikeSmith> | zcorpan: hmm yeah |
| 12:59 | <zcorpan> | maybe first edition didn't |
| 13:00 | <MikeSmith> | yeah I think probably so |
| 13:00 | <MikeSmith> | anyway I can fix that too |
| 13:00 | <zcorpan> | cool |
| 13:01 | <MikeSmith> | "This appendix summarizes the changes from the previous publication of SVG 1.1 Second Edition" |
| 13:02 | <MikeSmith> | hey geniuses how about listing the changes sinces actual 1.1 |
| 13:03 | <MikeSmith> | http://www.w3.org/TR/2010/WD-SVG11-20100622/changes.html#WholeDocument |
| 13:03 | <MikeSmith> | zcorpan: have to go all the way back to that WD to figure out what they actually changed |
| 13:03 | <MikeSmith> | "The content models of container elements were changed to allow ‘foreignObject’ children. Previously, according to the DTD, ‘foreignObject’ was allowed only as the child of a ‘switch’." |
| 13:04 | <MikeSmith> | whatever "container elements" is |
| 13:05 | <zcorpan> | http://www.w3.org/TR/SVG11/intro.html#TermContainerElement |
| 13:05 | <MikeSmith> | ok |
| 13:06 | <zcorpan> | is there a plan with svg2? |
| 13:06 | zcorpan | finds http://www.w3.org/TR/SVG2/changes.html#extend |
| 13:29 | <hsivonen> | MikeSmith: surely we don't want to allow <body> in <foreignObject> in text/html |
| 13:30 | <hsivonen> | zcorpan: but yeah, v.nu is supposed to support <foreignObject> |
| 13:30 | <hsivonen> | zcorpan: I might have made stuff up here, because the specs didn't make sense. |
| 13:30 | <hsivonen> | zcorpan: it's been a while. can't recall |
| 13:31 | <zcorpan> | hsivonen: appears like it does but follows and old svg 1.1 spec and made up content model for html or something (probably predates html spec's rules) |
| 13:32 | <hsivonen> | zcorpan: quite possible |
| 13:39 | <MikeSmith> | hsivonen: working on it now |
| 13:39 | <MikeSmith> | we inherited that schema from the SVG WG |
| 13:39 | <MikeSmith> | and I am finding now that it in some ways it doesn't actually even follow the original SVG 1.1 spec |
| 13:40 | <MikeSmith> | for example, it says SVG.glyph.content = SVG.Description.class*, SVG.glyph.class* |
| 13:40 | <MikeSmith> | so glyph if it had "description" elements, would need to have them before any other elements |
| 13:41 | <MikeSmith> | but the 1.1 spec says the child elements can be in any order |
| 13:53 | annevk | wonders what https://twitter.com/RobbertAtWork/status/429271270052872193 was about |
| 13:53 | annevk | finds it to work fine |
| 14:05 | <MikeSmith> | zcorpan: foreignObject changes fixed and pushed to http://validator.w3.org/nu/ |
| 14:05 | <MikeSmith> | thanks |
| 14:05 | <MikeSmith> | http://validator.w3.org/nu/?doc=data:text/html;charset=utf-8,<!DOCTYPE html><title>x</title><svg><foreignobject height width></foreignobject></svg> |
| 14:07 | <MikeSmith> | we really need some SVG-in-HTML test documents for wpt conformance-checkers/ |
| 14:08 | <zcorpan> | MikeSmith: <svg><foreignobject width height><svg></svg></foreignobject></svg> "Error: Element svg is missing a required instance of child element foreignObject. " ? |
| 14:08 | <MikeSmith> | hmm |
| 14:08 | <MikeSmith> | um dunno |
| 14:08 | MikeSmith | looks back at schema |
| 14:09 | zcorpan | -> train |
| 14:12 | <MikeSmith> | whoops forgot the "*" (zero or more) |
| 14:14 | <MikeSmith> | see what I said before about having test documents.. |
| 14:35 | <zcorpan> | MikeSmith: how do i enable XML parser? |
| 14:36 | <zcorpan> | file upload maybe |
| 14:36 | <MikeSmith> | zcorpan: mime type |
| 14:36 | <MikeSmith> | or .xhtml file upload |
| 14:37 | <MikeSmith> | zcorpan: data: URL |
| 14:37 | <MikeSmith> | zcorpan: fixed the "Error: Element svg is missing a required instance of child element foreignObject. " |
| 14:37 | <MikeSmith> | and pushed it |
| 14:38 | <zcorpan> | MikeSmith: i meant from textarea input |
| 14:38 | <zcorpan> | nice |
| 14:39 | <MikeSmith> | zcorpan: yeah can't do with for textarea any more at http://validator.w3.org/nu/ |
| 14:40 | <MikeSmith> | experimenting with dropping most of those XML-related options |
| 14:40 | <MikeSmith> | or really pretty much all the options except the "Show x" options |
| 14:42 | <annevk> | Reasons for Fetch to know about Document: referrer, Origin?, tasks, CSP |
| 14:43 | <annevk> | Reasons for Fetch to not know about Document: CSP (if allowed to be manipulated through script), only works in specification land |
| 14:43 | <gsnedders> | I read that as French, not Fetch. |
| 14:47 | <annevk> | JakeA: you around? |
| 14:47 | <JakeA> | Yep! |
| 14:47 | <annevk> | JakeA: do you remember when, from the perspective of the service worker, you want to do URL rewrites? |
| 14:48 | <annevk> | JakeA: i.e. the request is for /a, and you reply with /b and don't want a redirect to happen and want URLs in /b to be resolved with /a as base? |
| 14:49 | <JakeA> | If you respondWith anything, the browser sees it as a response to the request url |
| 14:49 | <annevk> | JakeA: it seems to me we could always do a conceptual redirect if there's a mismatch between request URL and response URL and if you don't want that redirect you'd rewrite the response URL to match the request URL |
| 14:50 | <annevk> | JakeA: so if the request was for /a and you have a response from /b and you don't want the browser to redirect you'd do response.url = "/a" first |
| 14:51 | annevk | is trying to define response's url |
| 14:51 | <JakeA> | I'm trying to remember why that wasn't ok… |
| 14:51 | <JakeA> | If it is ok, then it's the right thing to do |
| 14:52 | <JakeA> | Does it reveal redirect info in a way we don't want? |
| 14:53 | <annevk> | No, that would be impossible. I guess the weird case is the navigate/popup/child scenario as redirecting there could affect the service worker in use |
| 14:54 | <annevk> | At which point you probably would not want to use the given response? |
| 14:55 | JakeA | is flip flopping |
| 14:56 | <JakeA> | Maybe rewrite is the best thing to do, as it most closely resembles the serverside model |
| 14:56 | <JakeA> | "For the request url, here is your response" |
| 15:08 | <annevk> | JakeA: okay, rewrite meaning the page would never know about it? |
| 15:09 | <annevk> | JakeA: e.g. XHR's responseURL (to be added, hence these questions) would return "/a"? |
| 15:10 | <annevk> | JakeA: the main problem there is that sometimes you do want redirect to be followed, e.g. for a CSS resource it seems unlikely you ever wanted to rewrite it |
| 15:10 | <annevk> | JakeA: because then all subresources might end up having the wrong URL fetched |
| 15:12 | <JakeA> | annevk: yeah, I feel like we've swapped sides on this. I argued for this because of CSS on the last day of the meeting, Jonas talked me round. |
| 15:12 | <JakeA> | annevk: But yeah, it makes sense for CSS, but not so much for pages |
| 15:13 | <JakeA> | annevk: Eg, if I was delivering /static/page-shell.html in place of / |
| 15:14 | <annevk> | JakeA: even in that case if /static/page-shell.html had <img src=logo.png> you could be in trouble |
| 15:14 | <annevk> | JakeA: though I agree you do not want a redirect there, that'd look ugly |
| 15:14 | <annevk> | JakeA: so you should probably have absolute-path-relative URLs |
| 15:15 | <annevk> | http://url.spec.whatwg.org/#concept-absolute-path-relative-url |
| 15:15 | <JakeA> | Agreed |
| 15:15 | <annevk> | zcorpan: encoding="text/html" reads so weird |
| 15:16 | <zcorpan> | annevk: yeah |
| 15:16 | <JakeA> | Could be a problem if the shell was served from a CDN, but I don't know how common that would be |
| 15:16 | <annevk> | JakeA: mkay, rewrite-always makes sense if we advice people to use absolute-path-relative URLs |
| 15:16 | <annevk> | JakeA: do we allow CORS filtered responses as top-level? |
| 15:16 | <annevk> | JakeA: I guess we might as well |
| 15:16 | <JakeA> | Also, what happens if the reponseUrl isn't set, is the request url substituted in? |
| 15:17 | <JakeA> | annevk: Yeah, I don't see why not. Doesn't seem insecure. |
| 15:17 | <annevk> | JakeA: so Fetch will determine the response's URL solely based on the last request URL |
| 15:17 | <JakeA> | Guess it's only opaque ones that cause issues |
| 15:18 | <annevk> | JakeA: so I think within the context of responseWith() the url property of the Response object is not relevant |
| 15:19 | <annevk> | JakeA: Response.url is only relevant for fetch() and maybe caches |
| 15:19 | <JakeA> | Yeah, although it's used for CSP right? |
| 15:19 | <JakeA> | (btw, I'm really jetlagged so sorry for slow thinking) |
| 15:20 | <annevk> | Nah, this is great |
| 15:21 | <annevk> | Given Document -> Fetch -> Service Worker -> Network, CSP should only govern the last arrow I suppose |
| 15:21 | <annevk> | So if the service worker gets a Response object or creates one itself it's already trusted at that point from the CSP perspective |
| 15:22 | <JakeA> | Doesn't that circumvent a lot of the CSP stuff? Eg, I lose the ability to say "scripts can come from domain x, css can come from domain y" |
| 15:23 | <MikeSmith> | hsivonen: yeah dunno why the vnu schema had allowed body in there before. anyway it's fixed now |
| 15:24 | <JakeA> | Although if an attacker gets to create a serviceworker on the origin, the castle's walls are completely down anyway |
| 15:32 | <annevk> | JakeA: the moment you put a service worker in the middle you can no longer really control that I think |
| 15:33 | <annevk> | JakeA: e.g. the service worker could take the bytes of a response from domain y and serve it up as a fresh response to a fetch for a script |
| 15:33 | <JakeA> | annevk: Only if it non-opaue, but if the script is an attacker's script, they can control that |
| 15:34 | <JakeA> | yeah, makes sense |
| 15:34 | <JakeA> | opaque* |
| 15:34 | <annevk> | JakeA: we could make service workers CSP-opt-in maybe |
| 15:34 | <annevk> | JakeA: given how big of a foot gun they might be to you |
| 15:34 | <annevk> | JakeA: but that kinda sucks |
| 15:35 | <JakeA> | annevk: Setting content-type was a huge barrier to entry for appcache |
| 15:36 | <JakeA> | Requiring serviceworkers to be on the same origin feels good enough |
| 15:36 | <annevk> | But yeah, service workers make the whole fetch purpose/context discussion that CSP is having kind of irrelevant |
| 15:37 | <annevk> | I'll write an email to the CSP guys I guess. I wish I was a bit further today. Such a slow day |
| 15:38 | <JakeA> | I've managed about 3 paragraphs of a blog post |
| 17:06 | <dglazkov> | good mornign, Whatwg! |
| 17:25 | <Ms2ger> | Hey dglazkov! |
| 17:25 | <Ms2ger> | If you want to ship all this stuff soon, there'd better be a test suite ;) |
| 17:39 | <jgraham> | (and a spec :p) |
| 17:50 | <m4nu> | Anyone know what the best way to discover the final URL is after a bunch of redirects have been followed by XMLHttpRequest? Is there a solution to this problem yet? |
| 17:57 | <hober> | annevk: re: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2798 i'm surprised to see .children on DocumentFragment in Gecko |
| 17:57 | <hober> | annevk: i would have expected you to write http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2799 |
| 17:57 | <hober> | annevk: (which works in both webkit and gecko) |
| 17:58 | <Ms2ger> | It's on ParentNode? |
| 17:59 | <annevk> | hober: http://dom.spec.whatwg.org/#parentnode |
| 17:59 | <annevk> | hober: however, I always forget what the non-children one is called, didn't even realize I was operating on a DocumentFragment :-) |
| 18:00 | <annevk> | hober: please don't tell my employer I don't know what I'm doing |
| 18:01 | <hober> | heh |
| 18:02 | <hober> | i must have missed it when HTMLCollection things got added to DocumentFragment |
| 18:02 | <hober> | do we really want to have more HTMLCollections? |
| 18:02 | <Ms2ger> | It's the same HTMLCollection as before |
| 18:08 | <hsivonen> | MikeSmith: thanks |
| 18:10 | <hober> | tracked down the relevant bug, thanks |
| 18:46 | <TabAtkins> | zcorpan: It's not really *intentional* to allow CSS escapes in srcset, but doing anything less would require defining my own private tokenizer. |
| 18:46 | <TabAtkins> | Or defining a full parsing algorithm, which seems like overkill. |
| 18:47 | <Hixie> | i wonder what i was smoking when i wrote "This specification does not define any processing for elements in SVG fragments that are not in the HTML namespace; they are considered neither conforming nor non-conforming from the perspective of this specification." |
| 18:48 | <Hixie> | that's completely meaningless |
| 18:50 | <jgraham> | It depends if SVG fragments is well defined |
| 18:51 | <jgraham> | If an SVG fragment was, say, a subtree consisting of all nodes with a common ancestor that is the SVG element in the SVG namespace, it would seeem to make sense |
| 18:53 | <Hixie> | jgraham: it adds no conformance statements, despite sounding like it does, and it doesn't point the reader to any conformance statements, and it doesn't give the implications of conformance statements, nor give best practices... |
| 18:53 | <Hixie> | in other news, anyone know where MathML defines its content models? MikeSmith maybe? |
| 18:53 | <MikeSmith> | yeah |
| 18:54 | <MikeSmith> | but if you're asking about annotation-xml they don't define it |
| 18:54 | <MikeSmith> | you have to :) |
| 18:54 | <Hixie> | i was asking about <mi>, mainly |
| 18:54 | <MikeSmith> | ok |
| 18:55 | <Hixie> | (the idea being to see how they phrased that, so i could remain somewhat consistent) |
| 18:55 | <Hixie> | (for a-xml) |
| 18:55 | <MikeSmith> | ah cool |
| 18:55 | <MikeSmith> | man you fast |
| 18:55 | <MikeSmith> | http://www.w3.org/TR/MathML3/chapter3.html#presm.mi |
| 18:56 | <jgraham> | Hixie: The first part seems like a statement of fact |
| 18:56 | <MikeSmith> | is where I'm looking myself now |
| 18:56 | <MikeSmith> | ... and they don't say it there, I see |
| 18:56 | <Hixie> | jgraham: it's definitely trying to be a statement of fact, but not a useful one, is what i'm saying :_) |
| 18:56 | <MikeSmith> | I guess you probably already looked there. I'll dig further |
| 18:56 | <Hixie> | MikeSmith: i was expecting them to have a DTD or something |
| 18:57 | <MikeSmith> | they have a RelaxNG schema |
| 18:58 | <MikeSmith> | but I think there's prose somewhere in teh spec |
| 18:58 | <MikeSmith> | I hope so at least |
| 18:59 | <Hixie> | did we just make up the fact that <mi> can contain HTML phrasing elements from whole cloth? |
| 18:59 | <MikeSmith> | um um |
| 18:59 | <MikeSmith> | I seem to remember I filed an HTML spec bug about it a long time agao |
| 19:00 | <MikeSmith> | and I also asked the Math WG bout it |
| 19:00 | <Hixie> | we list mi, mo, mn, ms, and mtext as "MathML text integration points" |
| 19:00 | <Hixie> | which means they can receive HTML nodes |
| 19:00 | <Hixie> | but i can't find anything that actually says the content model for those allows anything but text, mglyph, and the other mathml text stuff |
| 19:00 | <MikeSmith> | yeah I remember we actually discseed it |
| 19:03 | <Hixie> | bummer, my blame records aren't precached for the edits around there |
| 19:03 | Hixie | sets up some more blame caches |
| 19:05 | <MikeSmith> | Hixie: I raised https://www.w3.org/Bugs/Public/show_bug.cgi?id=9859 back when, but you wontfixed it |
| 19:05 | MikeSmith | keeps looking |
| 19:07 | <Hixie> | that bug is a great example of why i don't actually mark a bug WONTFIX when i wontfix it, but leave it open for people to argue back for a while :-) |
| 19:07 | <Hixie> | don't any more, i mean |
| 19:08 | <Hixie> | i'm not really sure i understand that bug though |
| 19:08 | <MikeSmith> | that bug kinda diverged from teh description |
| 19:08 | <MikeSmith> | Hixie: http://www.w3.org/TR/MathML3/chapter6.html#world-int-combine-other is what you want I think |
| 19:09 | <MikeSmith> | well hmm not much there either |
| 19:09 | <Hixie> | yeah i think my wontfix is for the original description, and it makes sense relative to that (you don't have to ban things that aren't allowed in the content model, by definition) |
| 19:10 | <MikeSmith> | yeah |
| 19:11 | <MikeSmith> | "When designing a compound document format in which MathML is included in a larger document type, the designer may extend the content model of MathML to allow additional elements." is the main relevant part I guess |
| 19:12 | <MikeSmith> | before it said, "In the lax schema profile, elements from non-MathML namespaces are allowed in token elements, but not in other elements" |
| 19:12 | <MikeSmith> | where "token elements" = mi, mo, mn, ms, and mtext |
| 19:14 | <Hixie> | aha! excellent, that's exactly what we need |
| 19:14 | <MikeSmith> | cool |
| 19:15 | <MikeSmith> | (sorry it took me so long to find it -- it's been a while since we had those discussions) |
| 19:15 | <Hixie> | oh no worries, i couldn't find it either! |
| 19:17 | <MikeSmith> | yeah actually I remember not how painful it was to try to find anything in that spec |
| 19:19 | <Hixie> | do we have to say anything about annotation-xml's encoding attribute? or just say that if it contains html, it must be flow content? |
| 19:25 | <Hixie> | MikeSmith: ok, check what i just checked in, reopen the bug if it's no good. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24526 |
| 19:26 | <Hixie> | heycam|away: ping |
| 19:26 | MikeSmith | looks at commmit |
| 19:28 | <MikeSmith> | Hixie: Thanks -- looks great as-is to me. I don't think we need to say anything explicit in the HTML spec about annotation-xml's encoding attribute but I'll ping David Carlisle to confirm. |
| 19:29 | <Hixie> | k. |
| 19:29 | <Hixie> | thanks! |
| 19:29 | <MikeSmith> | cheers |
| 19:29 | MikeSmith | goes off to fiddle this into the validator code |
| 21:02 | <heycam> | Hixie, pong |
| 21:03 | <heycam> | and good morning |
| 21:03 | <Hixie> | hey |
| 21:03 | <Hixie> | you following the Window/Location security thing? |
| 21:04 | <heycam> | I have seen the comments come in but not read them |
| 21:04 | <heycam> | is it time for me to read them now? :) |
| 21:06 | <Hixie> | well, probably not |
| 21:06 | <Hixie> | but |
| 21:06 | <Hixie> | i was thinking about how to do this |
| 21:06 | <Hixie> | and it is probably going to end up being best partly done in WebIDL |
| 21:06 | <Hixie> | so i wanted to give you a heads-up |
| 21:06 | <bholley> | Hixie: who is the abarth/bholley/travis equivalent at WebKit? |
| 21:07 | <Hixie> | bholley: no idea, but hober would know |
| 21:07 | <bholley> | hober: ^ |
| 21:07 | <Hixie> | abarth and eseidel might know also |
| 21:08 | <heycam> | Hixie, ok well let me know when it's figured out what bits should be on the Web IDL side |
| 21:08 | <Hixie> | heycam: basically cross-origin Window and Location objects are gonna behave very differently than same-origin Window and Location objects. so i was thinking maybe the way to spec this is to have two actual separate interfaces, a Window and a WindowCrossOrigin, where the second has some sort of [CrossOriginObjectFor=Window] attribute or some such |
| 21:08 | <abarth> | bholley: what expertise exactly are you looking for? |
| 21:08 | <abarth> | JS bindings? |
| 21:08 | <Hixie> | heycam: and then webidl would take care of killing the prototype, making things act frozen, returning the right Function objects, etc |
| 21:08 | <bholley> | abarth: I'm just wondering who we want to get feedback from on the Window/Location stuff |
| 21:09 | <Hixie> | heycam: anyway, i'll let you know when it's ready, we're still trying to get people on board at this point |
| 21:09 | <heycam> | Hixie, ok |
| 21:09 | <abarth> | bholley: I'd ask sam wenig |
| 21:09 | <abarth> | he might be a manager now and direct you to someone else |
| 21:09 | <bholley> | abarth: do you have his email? |
| 21:09 | <abarth> | but he's a good person to start with |
| 21:09 | <abarth> | yeah |
| 21:10 | <abarth> | http://trac.webkit.org/search?q=sam%40webkit.org&noquickjump=1&changeset=on&wiki=on |
| 21:11 | <bholley> | abarth: great, thanks |
| 21:53 | <hober> | he's also in #whatwg |
| 21:53 | hober | summons weinig |
| 22:17 | <Hixie> | bholley: re your mail, as per my comments with heycam earlier, i think most of the details will hopefully end up specced in WebIDL, and HTML will just have to have its 900+ mentions of Window and Location updated to return the right objects |
| 22:17 | <Hixie> | heycam: in the meantime, https://etherpad.mozilla.org/html5-cross-origin-objects is the current thinking |
| 22:17 | <bholley> | Hixie: sgtm |
| 22:17 | <bholley> | Hixie: I forgot to CC heycam - did you forward, or should I? |
| 22:18 | <Hixie> | feel free to |
| 22:18 | <heycam> | thx |
| 23:01 | <jgraham> | bholley: Did you mean your push to web-platform-tests to be a pull request? Because you didn't create one |
| 23:01 | <bholley> | jgraham: no, I'm waiting until we sort out the spec |
| 23:02 | <bholley> | jgraham: I wasn't sure about the branch naming convention - did I make it look like I wanted it to be a PR? |
| 23:02 | <jgraham> | bholley: I think you put submissions/ in the name, which kind of suggests a PR |
| 23:03 | <bholley> | jgraham: yeah, ok. I was just quickly following the instructions for adding tests |
| 23:03 | <bholley> | but makes sense |
| 23:03 | <jgraham> | BTW since we are using critic for review it is better to create a PR early and add an issue stating that you are waiting for spec feedback |
| 23:03 | <jgraham> | You don't need a mozilla-style complete patch before submitting for review |
| 23:04 | <jgraham> | (that doesn't mean *right now* is best of course, just that push early, push often is a good rule) |
| 23:09 | <bholley> | ok, I'll look into that after the initial round of feedback |
| 23:38 | <zewt> | things pages should not be able to do: prevent pasting text into forms. |
| 23:38 | <TabAtkins> | Hostile password entry? |
| 23:39 | <zewt> | pages that want to coerce you into typing your email address or password or whatever twice |
| 23:40 | <Hixie> | i always just bring up the dom inspector and nuke the relevant attributes |
| 23:40 | <TabAtkins> | Yeah, me too. |
| 23:40 | <zewt> | my normal (non-development) browser is firefox, and its inspector is too cumbersome to bother with |
| 23:41 | <TabAtkins> | I have a solution to that. |
| 23:41 | <zewt> | the main reason I don't switch to chrome for general usage is lack of vertical tabs |
| 23:42 | <TabAtkins> | Ah, kk. |
| 23:42 | <TabAtkins> | Yeah, you're screwed then. |
| 23:42 | <zewt> | which I really, seriously don't understand--horizontal tabs are pretty unusable |
| 23:43 | <TabAtkins> | If you use a lot of tabs. |
| 23:43 | <zewt> | if you have a list of horizontal things, you stack them vertically |
| 23:43 | <TabAtkins> | Switch to only using a few. |
| 23:43 | <zewt> | i'm not going to reengineer how I use browsers to suit chrome's crippled ui, heh |
| 23:43 | <TabAtkins> | LifeHacks® |
| 23:44 | <JosephSilber> | When a parent |
| 23:45 | <JosephSilber> | When a parent's height depends on it's children, you can't use percentage heights for the children. |
| 23:45 | <TabAtkins> | Yes. |
| 23:45 | <zewt> | i tend to switch to chrome when doing a search, because switching browsers is faster than using firefox's dog-slow address bar search, heh |
| 23:45 | <JosephSilber> | What if the parent's height isn't fixed, but it doesn't depend on its children. |
| 23:45 | <TabAtkins> | Example? |
| 23:46 | <JosephSilber> | an absolutely positioned parent |
| 23:46 | <JosephSilber> | all corners set to 0 |
| 23:46 | <Hixie> | wtf is a vertical tab in this context? |
| 23:47 | <zewt> | browser tab bar with tabs vertical, not horizontal |
| 23:47 | <TabAtkins> | JosephSilber: Then it's fixed for those purposes. |
| 23:48 | <TabAtkins> | The relevant term is "definite" versus "indefinite": http://dev.w3.org/csswg/css-sizing/#definite |
| 23:48 | <TabAtkins> | Percentage width/heights can resolve against definite parent width/heights. |
| 23:49 | <TabAtkins> | In terms of abspos, though, if you set top and bottom, then height is *implicitly* set as well. Same with left/right/width - setting any two to a definite value implicitly sets the third to a definite value as well. |
| 23:50 | <JosephSilber> | TabAtkins: see this? stretches in ff, but not in chrome: http://codepen.io/anon/pen/qItFp |
| 23:51 | <TabAtkins> | JosephSilber: Is this related to what we were just discussing? |
| 23:51 | <TabAtkins> | I see an abspos, but no percentages on its children. |
| 23:51 | <JosephSilber> | TabAtkins: It is. I've solved it for my project using min-height. This is just me trying to understand what's supposed to happen according to the spec |
| 23:52 | <JosephSilber> | .box has a min-height: 100% |
| 23:52 | <TabAtkins> | This case is too busy for me to figure out. It needs to be reduced pretty badly. |
| 23:52 | <JosephSilber> | ...I meant that I solved it with min-content... |
| 23:53 | <JosephSilber> | ok. I'll try stripping stuff out and report back |
| 23:55 | <zewt> | (https://zewt.org/~glenn/tabs.png <- that) |
| 23:56 | <zewt> | (usually with 30-40 tabs, of course, not 9) |
| 23:59 | <JosephSilber> | TabAtkins: ok. so I got it down to this: http://codepen.io/anon/pen/qItFp |
