| 00:06 | <MikeSmith> | Hixie: Yeah I'm noticing even-more-frequent 408s from bugzilla too, and not just in chrome. I'll raise an actual report for it with the systems team and ask that somebody spend some time trying to reproduce it and troubleshoot it. |
| 02:00 | <MikeSmith> | it is possible to programatically set the validatity state on a particular element? |
| 02:02 | <MikeSmith> | I'd like to make the browser show an invalidity indicator for a particular input area after some other client-side checking completes |
| 02:02 | <Hixie> | yeah, that's what setCustomValidity() is for |
| 02:02 | <MikeSmith> | ah sweet |
| 02:05 | <MikeSmith> | Hixie: do I then need to fire a synthetic "invalid" event at the element, to get the message to appear? |
| 02:06 | <Hixie> | the message appears when the form is submitted, usually |
| 02:06 | <MikeSmith> | ah OK |
| 02:06 | <Hixie> | there's a recent addition form.reportValidity() that can also be used |
| 02:06 | <Hixie> | but i don't know who implements that, if anyone |
| 02:06 | <MikeSmith> | so in this case I'm not actually submitting a form |
| 02:06 | <MikeSmith> | ok |
| 02:06 | <Hixie> | (and :invalid should begin matching immediately) |
| 02:08 | <MikeSmith> | I guess I may need to emulate whatever form.reportValidity() does |
| 02:08 | <Hixie> | why aren't you submitting the form? |
| 02:10 | <MikeSmith> | Hixie: because there's nothing to submit -- it's just executing client-side |
| 02:10 | <MikeSmith> | this is http://w3c-test.org/tools/runner/index.html |
| 02:10 | <Hixie> | i don't mean submit to http necessarily |
| 02:10 | <MikeSmith> | yeah sure |
| 02:10 | <Hixie> | is there a submit button? |
| 02:10 | <MikeSmith> | there's the Start button there |
| 02:11 | <Hixie> | then theres a submission step |
| 02:11 | <MikeSmith> | which causes it to iterate over a list of tests |
| 02:11 | <MikeSmith> | yeah |
| 02:11 | <Hixie> | just make it submit to javascript:submitted() or something |
| 02:11 | <Hixie> | as in action="javascript:submitted()" |
| 02:12 | <MikeSmith> | oh |
| 02:12 | <MikeSmith> | action or formaction? |
| 02:12 | <Hixie> | action if you put it on <form> |
| 02:12 | <Hixie> | formaction if you need to override an action="" from the <form> on the <button> |
| 02:12 | <MikeSmith> | yeah |
| 02:15 | <Hixie> | i have a proposal somewhere for some extension to method="" that's specifically for forms like this |
| 02:15 | <Hixie> | a bit like method=dialog but without even the automatic closure of the dialog |
| 02:15 | <Hixie> | i forget where i mentioned that though... |
| 02:15 | <Hixie> | i never filed a bug for it specifically |
| 02:19 | <Domenic> | Iirc programmatic submission does not trigger validity UI |
| 02:19 | <Domenic> | so reportValidity is awesome but I wish someone implemented it |
| 02:20 | <Domenic> | TabAtkins: Hixie: so generally the plan going forward is that each new element should have its own class, even if it has no unique properties over HTMLElement? |
| 02:26 | <MikeSmith> | hot dog javascript:submitted() works great |
| 02:26 | <MikeSmith> | thanks Hixie |
| 02:28 | <MikeSmith> | hmm maybe I should just call it "started" though |
| 02:31 | <MikeSmith> | someday I should actually get around to learning web programming |
| 02:39 | <MikeSmith> | alternatively, it seems like setCustomValidity() is already pretty well supported, and that's less trouble |
| 02:40 | <Hixie> | Domenic: there's no plan one way or the other there |
| 02:41 | <Hixie> | MikeSmith: setCustomValidity() is something you would use with submission |
| 02:42 | <MikeSmith> | Hixie: yeah if I just make my "Start" button type=submit that should work, right? |
| 02:42 | <Hixie> | yup |
| 02:43 | <MikeSmith> | yeah so I mean that way I don't have to write my own submit thing |
| 02:43 | <Hixie> | ah right |
| 02:44 | <MikeSmith> | which in this case means, less code to get reviewed, and so less for zcorpan to find problems with :-) |
| 02:46 | <MikeSmith> | I find that when things I code need to go to zcorpan for review, minimizing the review surface causes me less embarrassment and time |
| 02:47 | <Hixie> | that's pretty much a given for anyone :-) |
| 04:24 | <zewt> | i really have to wonder who designs the twitter input UI and goes home at the end of the day with a firm good-day-of-work nod |
| 04:25 | <zewt> | re: press down, go to next line. press down again, get a "David Goodman" dropdown because the cursor is on the word "good" |
| 04:59 | <SamB> | zewt: what is this "line" of which you speak |
| 05:00 | <zewt> | text input box |
| 05:02 | SamB | does not think of twitter input as *having* lines |
| 08:53 | <annevk> | Domenic: I think each element having its own class is a requirement if we start exposing constructors, otherwise adding new features to existing elements becomes problematic |
| 10:23 | <aleray> | hi, I have a webpage with several articles. Each article is translated in several languages. what is a sensible markup in this case? |
| 10:25 | <aleray> | example: http://dpaste.com/0HFDBMR/ |
| 10:31 | <annevk> | aleray: use an <article> for each translation with lang=nl and such |
| 10:32 | <annevk> | aleray: or maybe <section> for each translation, |
| 10:32 | <annevk> | aleray: depends a bit on size and such I guess, not sure there's a hard and fast rule |
| 10:50 | <aleray> | annevk, you mean like this? http://dpaste.com/14HHXYD/ |
| 11:14 | <annevk> | aleray: not sure I'd nest <article> like that, it's intended for comments |
| 11:40 | <annevk> | JakeA: you around? |
| 11:53 | <annevk> | What's a good name for Request and URL combined? |
| 11:53 | <annevk> | RequestInfo? |
| 12:33 | <tobie> | annevk: what do you mean by combined? |
| 12:33 | <annevk> | tobie: see http://fetch.spec.whatwg.org/#fetch-api |
| 12:36 | <tobie> | I was going to ask if you were looking for (Request or SVStr) |
| 12:38 | <annevk> | tobie: yeah, a name for that :-) |
| 12:43 | <tobie> | annevk: do you see it more as (Obj or primitive) or as RequestParam? |
| 12:44 | <annevk> | Above I used a single name as fetch() also takes it as argument |
| 12:44 | <annevk> | If I have repeat usage of an or'd item I try to make a name for it |
| 12:45 | <tobie> | Right. Which makes sense. |
| 12:45 | <tobie> | Unrelated, but doesn't the same pattern also make sense for URL? |
| 12:50 | <annevk> | tobie: what do you mean? |
| 12:52 | <tobie> | That new URL() accepts both a SV string and an URL. |
| 12:55 | <annevk> | tobie: oh, URL stringifies |
| 12:56 | <tobie> | annevk: Oh. |
| 12:56 | <tobie> | annevk: where (how?) is that behaviour described. |
| 12:56 | <JakeA> | annevk: sorry, recording a 15 min video took all morning. Catching up… |
| 12:56 | <annevk> | tobie: "stringifier attribute ScalarValueString href;" |
| 12:57 | <tobie> | duh |
| 12:58 | <tobie> | annevk: Would something like GenericRequest capture the intention (it's ugly, though) |
| 12:59 | <JakeA> | annevk: I've always called it just "request", one of the first step is 'upgrading' strings to responses, so haven't seen it as an issue |
| 13:02 | <annevk> | JakeA: the issue is that Request is a thing :-) |
| 13:02 | <annevk> | JakeA: in an hour or so from now I'd like to talk about body/headers if that works |
| 13:02 | <annevk> | tobie: yeah, not really better than Info |
| 13:03 | <JakeA> | annevk: Yeah, I'm free now |
| 13:03 | <annevk> | JakeA: yeah sorry, going out to get a snack |
| 13:03 | <JakeA> | annevk: no worries, got inbox to churn though |
| 13:28 | <tobie> | annevk: what's your plan for headers? More towards a dictionary or raw text with methods like for xhr? |
| 13:50 | <annevk> | ait back |
| 13:50 | <annevk> | tobie: I have no idea |
| 13:51 | <annevk> | tobie: I was hoping other people had ideas, JakeA? |
| 13:51 | <tobie> | worth looking at what JS libs are doing here imho. |
| 13:52 | <jgraham> | Hmm, you can have multiple headers with the same name |
| 13:52 | <jgraham> | So a dictionary doesn't quite work |
| 13:52 | <zewt> | order might matter in some cases too |
| 13:53 | <jgraham> | The standard python thing seems to be a "multidict" which stores a list, but makes access to one of the first or last value simple |
| 13:53 | <jgraham> | http://docs.webob.org/en/latest/reference.html#id3 |
| 13:54 | <zewt> | xhr just flattens multiple values for a header, not sure if that's bad somehow |
| 13:54 | <tobie> | you can return an array in those cases (or in all cases) |
| 13:54 | <jgraham> | http://docs.webob.org/en/latest/#multidict |
| 13:54 | <zewt> | returning an array is annoying when you usually only have one value (and only sometimes returning an array is *really* annoying) |
| 13:54 | <jgraham> | So returning an array in some cases is confusing and returning an array in all cases is user-hostile |
| 13:55 | <JakeA> | agreed |
| 13:55 | <JakeA> | made a "query string to dict" method that always had arrays as keys. It was shite. |
| 13:55 | <zewt> | (a bigger problem with URL query APIs; I hate the ones that return arrays, making my life harder for some other 1% of users) |
| 13:56 | <jgraham> | The 1% that use radio buttons? |
| 13:56 | <jgraham> | Actually I guess that's wrong |
| 13:56 | <annevk> | jgraham: multiple headers with the same name is the same as multiple values for a single name |
| 13:56 | <annevk> | zewt: order only matters on the response and shouldn't in theory |
| 13:56 | <jgraham> | annevk: Yeah, so? |
| 13:57 | <jgraham> | You still have to support it |
| 13:57 | <annevk> | jgraham: no, you can just expose it as a single name with multiple values |
| 13:57 | <JakeA> | http://nodejs.org/api/http.html#http_message_headers node just uses a dict |
| 13:57 | <jgraham> | You mean comma seperated? |
| 13:57 | <jgraham> | I thought the whole point was to avoid the user having to parse things |
| 13:57 | <annevk> | jgraham: that's multiple values |
| 13:57 | <annevk> | jgraham: but it could be an array |
| 13:58 | <zewt> | jgraham: you don't have to support it if it's a new API |
| 13:58 | <jgraham> | annevk: 13:55 < jgraham> So returning an array in some cases is confusing and returning an array in all cases is user-hostile |
| 13:59 | <JakeA> | .get() .getAll()? |
| 13:59 | <JakeA> | :( |
| 13:59 | <jgraham> | Something like that |
| 13:59 | <jgraham> | I would be fine if [] did .get() |
| 14:00 | <zewt> | actually, it should probably just match URL, since it seems like an identical problem |
| 14:00 | <annevk> | what's actually wrong with having to parse the values? |
| 14:00 | <zewt> | (URL queries, that is) |
| 14:00 | <annevk> | splitting on "," if you expect multiple values seems not that bad |
| 14:01 | <jgraham> | It seems terrible |
| 14:01 | <jgraham> | You have to check every time to see if you have a "," in the value and if so split it |
| 14:01 | <zewt> | (splitting on "," then stripping spaces) |
| 14:01 | <jgraham> | Otherwise you get a bogus value |
| 14:02 | <annevk> | jgraham: euhm no? mostly the header name indicates it only has a single value |
| 14:02 | <JakeA> | headers[headerName], vs headers.all which is an array of arrays [[key, val], [key, val], [key, val]] |
| 14:02 | <zewt> | i don't know the use cases, but if a dumb server sends "Content-Type: text/plain" twice in a row because someone did something dumb in PHP, and my code assumes only one value, I'd rather get one arbitrary header value (even if they're different) than "text/plain, text/plain" |
| 14:02 | <JakeA> | You'd use .all if you care about the ordering |
| 14:02 | <JakeA> | & multiple values |
| 14:02 | <zewt> | JakeA: http://url.spec.whatwg.org/#urlsearchparams |
| 14:02 | <JakeA> | headers[headerName] is comma joined |
| 14:03 | <annevk> | zewt: at that point you'd have a security bug in your code |
| 14:03 | <zewt> | annevk: unconvincing |
| 14:04 | <jgraham> | annevk: Having a bug in your code because you expect one value and get more than one seems much more likely than having a bug when the API consistently returns data in the same format for a given call |
| 14:04 | <JakeA> | URLSearchParams works for me. As jgraham says, headers[val] should be the same as headers.get(val) |
| 14:04 | <tobie> | +1 for consistency with URLSearchParams |
| 14:05 | <tobie> | getAll returns an array? |
| 14:06 | <jgraham> | Yeah |
| 14:06 | <tobie> | and so get(foo) === getAll(foo)[0] |
| 14:06 | <annevk> | I wonder if we can make that generic |
| 14:07 | <JakeA> | I'm happy with that |
| 14:07 | <annevk> | But what do we want for the construction side? |
| 14:07 | <JakeA> | Fits nicely with cache.match & matchAll |
| 14:07 | <annevk> | new Request(url, { headers: XXX }) |
| 14:07 | <zewt> | annevk: seems like the only thing query-specific right now is the stringifier |
| 14:07 | <jgraham> | Yeah, I don't really care if get returns [0] or [-1], so consistency with URLSearchParams seems ideal |
| 14:07 | <annevk> | zewt: and the parser |
| 14:07 | <JakeA> | annevk: obj. If you want to do fancy shit, you construct then headers.append |
| 14:07 | <annevk> | URLSearchParams could be a subclass perhaps |
| 14:08 | <annevk> | JakeA: I want Request to be immutable |
| 14:08 | <annevk> | JakeA: but it could be obj or WhateverWeCallTheHeaderThing |
| 14:08 | <jgraham> | annevk: .append to the URLSearchParams-like object I assume |
| 14:08 | <annevk> | Actually, URLSearchParams-like also sucks for keeping Request immutable |
| 14:08 | <JakeA> | hmm, I don't think it should be immutable |
| 14:08 | <tobie> | setter should prop accept a vanilla obj with arrays or strings |
| 14:09 | <zewt> | annevk: it'd just need an immutable base class |
| 14:09 | <annevk> | sounds like a lot of complexity for some headers |
| 14:09 | <JakeA> | annevk: it'd be great to be able to modify requests as they fly through the fetch event (add/remove headers) |
| 14:09 | <zewt> | sounds like a common pattern for data structures |
| 14:10 | <JakeA> | annevk: Without explicitly respondWithing |
| 14:10 | <annevk> | JakeA: Could you clarify the Cache API that it's intended to be available on the main thread in due course and is origin-bound security-wise? That is, the main thread has access to the same data? |
| 14:10 | <JakeA> | annevk: Clarify it in the spec? |
| 14:10 | <annevk> | JakeA: yes |
| 14:11 | <JakeA> | sure, will make a ticket now to remind me |
| 14:16 | <JakeA> | annevk: is this unpossible? https://gist.github.com/jakearchibald/9f556ce0eafc47ba3d6e |
| 14:19 | <annevk> | JakeA: at the moment, yes |
| 14:20 | <annevk> | JakeA: I had assumed we'd not want pages to manipulate the underlying requests so easily; also, it's not entirely clear to me how that would work if the hook for that is that SW returns null |
| 14:21 | <JakeA> | but isn't the request object modified, or is the serviceworker given a copy? |
| 14:22 | <tobie> | JakeA: if you want to keep immutability, what you want is an easy way to duplicate a request with a few modifications. |
| 14:23 | <jgraham> | Why do you want immutability? |
| 14:23 | <JakeA> | ^- that |
| 14:23 | <Ms2ger> | FP |
| 14:24 | <jgraham> | Ms2ger: If you were hoping for first post here, you a a bit late |
| 14:25 | <Ms2ger> | Pah |
| 14:25 | <jgraham> | If you were hoping that javascript was a functional programming language, you're a bit deluded |
| 14:29 | <annevk> | JakeA: I was assuming we'd be passing copies around due to threading |
| 14:30 | <tobie> | seems sensible to design with immutability and later turn mutable if safe to do so, rather than the opposite. |
| 14:31 | <jgraham> | It seems more sensible to ask some implementors about whether immutability is a requirement rather than design an API with artificial limitations |
| 14:32 | <JakeA> | One use-case is resource priorities, being able to tag requests as they come through the fetch event without having to taking over handling the whole request |
| 14:32 | <annevk> | It's not a requirement of course. You can always make it work somehow. |
| 14:33 | <annevk> | But it's not as simple as you make it seem |
| 14:33 | <annevk> | Requests originating from the page are more powerful than we'd like fetch() to handle. But fetch() could still make a restricted copy of course. |
| 14:34 | <jgraham> | Right, but I'm not sure I understand where you think that an immutable object would help. Is there a case when you pass the object into another thread and it is still accessible in both threads? If so, how expensive is a copy? |
| 14:35 | <jgraham> | And could you solve it using a COW design? If so, how hard is that to implement? |
| 14:35 | <annevk> | COW? |
| 14:35 | <jgraham> | Copy On Write |
| 14:36 | <jgraham> | i.e. only make a copy if a mutation occurs |
| 14:41 | <annevk> | jgraham: the problem with mutable is that we have both UA-created Request objects and content-created Request objects |
| 14:41 | <annevk> | jgraham: the former are more involved |
| 14:41 | <JakeA> | Or, give SW a copy, then read bits from it if the SW doesn't call respondWith |
| 14:42 | <annevk> | jgraham: if we allow arbitrary manipulation, there's a whole lot more to reason about |
| 14:42 | <annevk> | JakeA: I guess I would have SW return the request rather than null if we go down that route |
| 14:43 | <jgraham> | annevk: Well the question is whether there are use cases for manipulating the various types of request |
| 14:44 | <JakeA> | annevk: That works |
| 14:44 | <jgraham> | If there aren't any for UA-generated Request objects, they could be immutable. But JakeA seems to have a better idea of the use cases here |
| 14:45 | <jgraham> | Certainly for user-generated Requests, being able to manipulate the request before passing it to fetch seems very useful |
| 14:46 | <JakeA> | jgraham: mostly around resource priorities, giving particular request a higher priority without having to handle the request entirely |
| 14:46 | <annevk> | jgraham: the only case so far was about a UA-generated Request object |
| 14:48 | <annevk> | JakeA: if we give access to such headers, set by the UA, what are the implications for privacy? |
| 14:49 | <annevk> | JakeA: I hadn't actually really thought about exposing Request objects in general for all requests the page makes |
| 14:49 | <JakeA> | annevk: I thought the sensitive headers (such as cookies) were applied after the call into SW |
| 14:49 | <annevk> | JakeA: maybe there's not much badness apart from cookies, which we'll make sure to hide |
| 14:50 | <JakeA> | (I've caught a crazy one https://www.facebook.com/occupyhtml5/posts/1475786125972047) |
| 14:50 | <annevk> | JakeA: currently cookies are set before, at the same time the Authorization header is built based on URL credentials |
| 14:51 | <annevk> | JakeA: it seems like SW would want access to same-origin login data |
| 14:51 | <JakeA> | annevk: but not http-only cookies |
| 14:51 | <annevk> | JakeA: see http://fetch.spec.whatwg.org/#concept-http-fetch |
| 14:51 | <annevk> | JakeA: cookies in general are not exposed so I guess they're not an issue |
| 14:52 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/234 there's also if-none-match and if-modified-since |
| 14:53 | <annevk> | JakeA: do you want to manipulate <body> too? |
| 14:53 | <annevk> | JakeA: given http://fetch.spec.whatwg.org/#request what fields should be mutable? |
| 15:00 | <JakeA> | annevk: anything that wouldn't cause a security issue. Looking now… |
| 15:08 | <JakeA> | annevk: headers, body, mode, omitCredentialsMode? |
| 15:08 | <annevk> | JakeA: so if you set headers it would be a security issue for tainted cross-origin requests |
| 15:09 | <annevk> | JakeA: and changing the mode as a side-effect of setting a header seems very sketchy |
| 15:10 | <annevk> | JakeA: we could throw if the mode is not CORS or same-origin maybe |
| 15:10 | <annevk> | JakeA: and then set a flag to not allow mode to be set after you did such a thing |
| 15:10 | <annevk> | JakeA: but suddenly you're looking at something that's very hard to explain and reason about |
| 15:11 | <JakeA> | annevk: we're already going to set the mode based one headers in the constructors, aren't we? |
| 15:12 | <JakeA> | annevk: we can't allow a GET to another origin with arbitrary headers without a preflight |
| 15:13 | <annevk> | JakeA: my idea was for the constructor to have mode default to CORS |
| 15:13 | <annevk> | JakeA: and throw if you have headers and mode is not CORS or same-origin |
| 15:14 | <JakeA> | annevk: I still want to enable (although it may come later) making an image-like request, that'd be non-cors to other origins |
| 15:14 | <JakeA> | annevk: maybe we throw when setting headers, depending on mode |
| 15:15 | <JakeA> | annevk: …that would be easy as part of the constructor, as mode would be set before headers |
| 15:16 | <annevk> | JakeA: you set them at the same time |
| 15:16 | <annevk> | new Request(..., { headers: ..., mode:"tainted cross-origin" }) |
| 15:17 | <JakeA> | annevk: Yeah, but the algorithm would be "set mode", "set each header, but if a header clashes with the mode, throw" |
| 15:17 | <JakeA> | or vice versa, I guess |
| 15:18 | <annevk> | fair |
| 15:18 | <JakeA> | the same thing would work with mutating, you'd have to lock down mode before adding headers that require cors. But I agree that cors is a sensible default for the constructor |
| 15:19 | <annevk> | JakeA: when would you want to mutate mode? |
| 15:20 | <JakeA> | annevk: I can't think of a reason why not |
| 15:24 | <tobie> | what it UA-generated Request objects were frozen, but constructed ones not? |
| 15:25 | <JakeA> | tobie: what's the benefit? |
| 15:25 | <annevk> | "unexplained magic" |
| 15:26 | <annevk> | (but there'll be some of that anyway) |
| 15:26 | <annevk> | JakeA: should mutating mode throw if there's headers already set? |
| 15:26 | <annevk> | JakeA: how do we know headers are set by the author vs the UA? |
| 15:26 | <JakeA> | annevk: only if the headers are "illegal" given the new mode |
| 15:26 | <annevk> | JakeA: such a gigantic mess |
| 15:30 | <JakeA> | annevk: where do we need to know which headers were set by the author vs UA? |
| 15:30 | <tobie> | JakeA: makes it easier to reason about? |
| 15:30 | <annevk> | JakeA: event.request; which headers can I read, which can I set? can I change .mode? |
| 15:31 | <tobie> | use case for changing mode in that case? |
| 15:31 | <annevk> | JakeA: if a UA has added Last-Event-ID, that's fine, if you do it, it's not |
| 15:32 | <annevk> | JakeA: that is, UA adding Last-Event-ID for EventSource() does not cause a preflight to happen |
| 15:34 | <JakeA> | annevk: I see, so setting mode to cors & back would throw in that case |
| 15:34 | <JakeA> | fair |
| 15:35 | <annevk> | but how do we distinguish? do we keep the UA headers and author headers in a distinct map? |
| 15:36 | <JakeA> | annevk: Does this problem go away if we make mode read-only, but not headers? |
| 15:36 | <annevk> | JakeA: not really |
| 15:37 | <annevk> | JakeA: hmm, maybe as soon as you touch headers mode becomes cors-with-preflight and immutable |
| 15:38 | <JakeA> | annevk: I think if the request is not-cors, and you mess with one of the non-simple methods, it throws or steps up to CORS |
| 15:39 | <JakeA> | stepping up makes more sense I guess |
| 15:40 | <annevk> | Actually, setting mode to same-origin should be fine, it's mostly tainted cross-origin that's dangerous |
| 15:41 | <annevk> | JakeA: https://etherpad.mozilla.org/Request-object-design |
| 15:41 | <JakeA> | annevk: what's the attack (sorry, I'm running out of brain) |
| 15:42 | <JakeA> | annevk: do we need to filter headers or just set the restricted ones after the SW? |
| 15:42 | <annevk> | JakeA: you cannot currently send custom headers to random servers |
| 15:43 | <JakeA> | annevk: right, so setting those headers would change mode, trying to change mode back would throw. It might be weird in the eventsource case you mentioned though |
| 15:46 | <jwatt> | is there any work on a DOM for CSS gradients? |
| 15:46 | <jgraham> | TabAtkins: ^ |
| 15:57 | <annevk> | JakeA: so the main problem with this is that you have now manipulated the request, but the request is still identifying itself as coming from the page |
| 16:13 | <annevk> | JakeA: it would be great if some security guys could look at that etherpad |
| 16:14 | <JakeA> | annevk: I'll deploy the mikewest |
| 16:14 | <annevk> | JakeA: I'll try to fix the draft a bit tomorrow |
| 16:22 | <JakeA> | annevk: when you say restricted header names, do you mean cookie, if-none-match etc? Or do they just get silently overwritten? |
| 16:23 | <annevk> | JakeA: http://fetch.spec.whatwg.org/#concept-forbidden-author-header-names |
| 16:23 | <annevk> | JakeA: if-none-match is typically fair game |
| 16:25 | <JakeA> | annevk: reading it may expose the response, especially the response is limited to a few values |
| 16:25 | <JakeA> | annevk: eg, "yes", "no". You could know the two etags that produces & know the response from the if-none-match header |
| 16:25 | <annevk> | so it's only fair game if mode != tainted |
| 16:26 | <JakeA> | annevk: yeah, that sounds right |
| 16:26 | <annevk> | JakeA: it's a bit unclear how we're layering headers, it might be that some of these need to move to the actual HTTP *network* fetch |
| 16:26 | <annevk> | JakeA: setting them by the UA that is |
| 16:27 | <annevk> | JakeA: although I guess if-none-match you want, since you can use it on your own cache too |
| 17:17 | <JonathanNeal> | If you’re available, would you ask IE about using external SVGs with <use>? https://twitter.com/hashtag/AskIE?src=hash http://css-tricks.com/svg-use-external-source/ |
| 17:29 | <TabAtkins> | jwatt: No; we're planning on a real OM for CSS (not string-based) in the future, but we're waiting for JS Value Objects. |
| 17:44 | <TabAtkins> | Domenic: Yeah, I think that's the plan. Existing places where multiple tags have the same interface (like HTMLHeadingElement) are inconvenient and weird. |
| 17:51 | <annevk> | JonathanNeal: <use> is pretty bad iirc |
| 17:51 | <annevk> | JonathanNeal: seems better to not have it |
| 17:54 | <JonathanNeal> | annevk: It’s a useful element with a bad markup pattern. It’s useful because you can create an SVG spritemap, and because you can style any instance of a sprite like folks do with icon fonts. |
| 17:55 | <TabAtkins> | annevk: <use> is much less bad now that we've nuked the instance tree. |
| 17:55 | <Hixie> | annevk: is the fetch api going to integrate with the Loader stuff at all? |
| 17:57 | <Hixie> | annevk: also, are there any code samples for this api? that's always a good way to sanity check an API |
| 17:58 | <annevk> | Hixie: I think JakeA has some examples, I should probably make some more |
| 17:59 | <annevk> | Hixie: afaict Loader is only for JS modules, I wish those guys talked to us sooner about the whole thing |
| 17:59 | <annevk> | Hixie: I didn't realize how generic that would be |
| 18:00 | <Hixie> | no the thread in es-discuss is very much indicating that the expectation is that all fetches are expected to go through it, as far as i can tell |
| 18:00 | <Hixie> | how about the dependency mechanism, is it intended that you be able to block a fetch on another or anything like that? |
| 18:11 | <jwatt> | is there a way for JS to get the "concrete object size"? |
| 18:12 | <jwatt> | TabAtkins: ok, thanks |
| 18:14 | <Hixie> | jorendorff: yt? |
| 18:15 | <jorendorff> | Hixie: here |
| 18:15 | <Hixie> | jorendorff: so i think i'm gonna try to write a strawman that shows how the ES6 module stuff could be integrated with all the other dependency stuff the web platform has coming down the pipe |
| 18:16 | <jorendorff> | great! |
| 18:16 | <Hixie> | jorendorff: but i'm having great difficulty understanding what ES6 actually says |
| 18:16 | <jorendorff> | understandable |
| 18:16 | <Hixie> | jorendorff: i spoke to arv and he suggested you as one of the best people to brief me on this |
| 18:16 | <Hixie> | jorendorff: is that something you could do? |
| 18:16 | <jorendorff> | happy to |
| 18:16 | <Hixie> | either in person or irc or e-mail or whatever |
| 18:16 | <Hixie> | (i'm in mtv if you want to do it in person) |
| 18:16 | <jorendorff> | yeah, i'm in Tennessee so can't do it in person immediately |
| 18:17 | <jorendorff> | irc's fine, email probably better |
| 18:17 | <jorendorff> | let me send you email to begin |
| 18:17 | <Hixie> | you are awesome |
| 18:17 | <Hixie> | thanks! |
| 18:17 | <jorendorff> | will do in the next 3 hours |
| 18:17 | <Hixie> | ian⊙hc |
| 18:17 | <jorendorff> | ok |
| 18:17 | <Hixie> | fantastic |
| 18:50 | <TabAtkins> | jwatt: There is no JS way to get the concrete object size, no. |
| 18:51 | <jwatt> | TabAtkins: I was asking because I was looking into whether content can make a live gradient editor for gradients with percentage value stops |
| 18:52 | <TabAtkins> | The information necessary for that is all accessible in the page. |
| 18:53 | <TabAtkins> | jwatt: Namely, the concrete object size of a gradient background will just be the background-size, which is either fixed or is the size of one of the layout boxes of the element. |
| 18:54 | <jwatt> | you need the gradient box (which is the concrete object size) to resolve how far along the gradient line px valued stop are |
| 18:54 | <jwatt> | the question is what is the gradient box for a given element |
| 18:55 | <TabAtkins> | Yes, which is calculable as I just described. |
| 18:55 | <jwatt> | how do you get the background-size? |
| 18:56 | <TabAtkins> | By asking for the background-size property? |
| 18:56 | <TabAtkins> | And if it's a keyword value, calculating the correct box from the element, based on width/padding/etc |
| 18:56 | <jwatt> | that could get pretty complicated |
| 18:57 | <TabAtkins> | Yeah, it's not trivial, but neither is it difficult. |
| 18:57 | <jwatt> | I'm not even sure if the background-size is the right thing |
| 18:57 | <TabAtkins> | I'm sure. ^^_ |
| 18:58 | <jwatt> | so it's always sure it's the same as the concrete object size? |
| 18:58 | <TabAtkins> | For an image with no intrinsic dimensions, yes. |
| 18:58 | <jwatt> | an image? |
| 18:58 | <jwatt> | what about a div |
| 19:03 | <jwatt> | calculating the concrete object size of an element may just be a case of "calculate the correct box from the element, based on width/padding/etc" |
| 19:04 | <jwatt> | but in the general case that means basically implementing an entire CSS layout engine taking into account box-sizing, floats, absolute positioning, flex box, etc., etc. |
| 19:05 | <jwatt> | and obviously taking into account siblings, ancestors, etc., since they can all impact the concrete size of the object |
| 19:05 | <jwatt> | unless I'm missing something |
| 19:06 | <jwatt> | so I'd take issue with the statement "neither is it difficult" :) |
| 19:08 | jwatt | will be back later |
| 19:17 | <TabAtkins> | jwatt: You're using terms in ways that don't make sense. |
| 19:17 | <TabAtkins> | An image like a gradient has a concrete object size calculated for it. |
| 19:19 | <TabAtkins> | The inputs to the algo are always the intrinsic dimensions (none, for gradients) and the specified size (for background gradients, the background positioning area, which is calculable from 'background-size' and other properties as needed). |
| 20:35 | <SamB> | TabAtkins: so how do you calculate it in JS then? |
| 20:35 | <TabAtkins> | The way the spec says to, which uses only information accessible via JS. |
| 20:36 | <SamB> | (and how long until some other spec complicates it?) |
| 20:37 | <TabAtkins> | It might get more complicated in the future, yes. |
| 20:42 | <smaug____> | annevk: why does Request in Window context need to have isSynchronous ? |
| 20:44 | <smaug____> | annevk: in other words, I hope we hide the possibility for synchronousness in the main-thread |
| 21:30 | <jorendorff> | Hixie: i kind of suck at this |
| 21:30 | <jorendorff> | still working at it |
| 21:31 | <Hixie> | dude, i'm so thankful that you're doing it at all, you've no idea :-) |