| 00:07 | <zewt> | are sandboxed iframes included in a "unit of related similar-origin browsing contexts"? (seems like they are) |
| 00:07 | <zewt> | (tokens like "unit of related similar-origin browsing contexts" remind me of my Netware days) |
| 00:08 | <Hixie> | depends on their origin |
| 00:08 | <zewt> | oh, yeah, missed the distinction between that and "directly reachable browsing contexts" |
| 00:08 | <zewt> | which is probably what I was thinking more of |
| 00:10 | <zewt> | (FWIW "that, through appropriate manipulation of the document.domain attribute, could be made to be the same as other members of the group, but could not be made the same as members of any other group" seems a bit more spec-by-describing-the-result than most of HTML) |
| 00:10 | <Hixie> | yup |
| 00:11 | <Hixie> | spec-by-describing-the-result is the better way to write a spec, if you can do so in a way that describes all the cases |
| 00:11 | <TabAtkins> | Yup, that's what using grammars do, too. (And why using grammars isn't always the right choice for parsing.) |
| 00:11 | <Hixie> | often, though, especially with things like processing inputs, parsing, etc, describing steps results in much less prose than describing results |
| 00:15 | <Hixie> | damnit, i spent all afternoon tracing this one bug, and it's all because i assumed "continue" would skip the loop condition and just jump back to the top |
| 00:15 | <zewt> | it's easily the line in the spec I've had to squint the hardest at to figure out what it's saying to do |
| 00:16 | <Hixie> | yeah... the advantage of writing it that way is that the spec writer doesn't have to do the work :-) |
| 00:16 | <TabAtkins> | Hixie: On a for loop? Yeah, it skips to the top, but then it processes as normal. |
| 00:16 | <Hixie> | TabAtkins: repeat...until loop, but yeah, same deal |
| 00:16 | <TabAtkins> | "continue [to the next iteration]" |
| 00:16 | <TabAtkins> | Ah. |
| 00:16 | <TabAtkins> | do/while loops are just while loops that dont' test their first iteration. |
| 00:16 | <Hixie> | i knew this, i just happened to make two changes at the same time that interacted and didn't think about it |
| 00:16 | <zewt> | repeat until? ... pascal? heh |
| 00:17 | <Hixie> | i miss perl's loop control |
| 00:17 | <Hixie> | perl has awesome loop control |
| 00:17 | <Hixie> | next, last, redo, continue, loop labels... |
| 00:17 | <zewt> | usually if i'm getting annoyed at things like needing to break out multiple levels, i just break stuff into a nested function |
| 00:18 | <zewt> | beyond that the standard mechanics usually work well for me |
| 00:18 | <zewt> | (which I guess is just continue and break) |
| 00:18 | <Hixie> | if your loop body is one line, breaking it into a function makes it way harder to read |
| 00:18 | <zewt> | if my loop body is one line, there aren't multiple levels to break out of |
| 00:19 | <Hixie> | inner loop body |
| 00:19 | <Hixie> | or if you have a complicated nesting of multiple loops |
| 00:19 | <zewt> | i mean taking eg. for(x=0; x < width; ++x) { for(y=0; y < height; ++y) { break 2; } }, making the whole thing a function and just using return |
| 00:20 | <Hixie> | the point being that if your "code" is brief compared to your loop logic, splitting into a function ends up being harder to read than perl-style control |
| 00:21 | <SamB> | zewt: how does turning it into a non-local return help? |
| 00:21 | <zewt> | function() { for(x=0; x < width; ++x) { for(y=0; y < height; ++y) { return; } } } |
| 00:21 | <SamB> | oh |
| 00:21 | <zewt> | exits the whole loop |
| 00:22 | <SamB> | well, that's still no goto |
| 00:22 | <Hixie> | make it three levels of loops where the inner lever has to break out of the inner two but not the third |
| 00:22 | <SamB> | or whatever they have in Pascal |
| 00:22 | <Hixie> | to see what i mean about functions being unclear compared to inline loop control |
| 00:22 | <zewt> | it's a workaround and things like break statements that supply a number of levels to break might be a bit better (i assume perl has something like that), but that's the only loop construct i tend to need a workaround like that for |
| 00:22 | <Hixie> | pascal's as bad as C as far as loop control goes |
| 00:22 | <Hixie> | perl has labeled loops |
| 00:22 | <Hixie> | so you say e.g.: |
| 00:23 | <SamB> | hmm, okay, perl |
| 00:23 | <zewt> | for(z=0; z < 10; ++z) ( (function() { for(x=0; x < width; ++x) { for(y=0; y < height; ++y) { return; } } })(); } |
| 00:23 | <Hixie> | file: while (...) { ...; line: while (...) { ...; next file; } } |
| 00:23 | <zewt> | looks shitty on one line, of course, and it's still a workaround, but it's not terrible |
| 00:23 | <Hixie> | or next line, or redo line, or last file, or whatever |
| 00:23 | <Hixie> | for all the various combinations you might want |
| 00:24 | <Hixie> | (this is one of the few things about perl that's actually a net good, even to readability, imho :-) ) |
| 00:24 | <SamB> | so is JS in the same boat as Python here? |
| 00:25 | <Hixie> | js is like c and company here, i think, right? |
| 00:25 | <Hixie> | dunno what python's loop control looks like |
| 00:25 | <TabAtkins> | You can break a loop using labels in JS, but you can't continue one from a label. |
| 00:25 | <Hixie> | oh, cool, ok |
| 00:26 | <Hixie> | so, in between |
| 00:29 | <SamB> | Python doesn't have labels at all |
| 00:37 | <TabAtkins> | Yeah, Python's annoying in that. They say "don't get yourself into situations where you have to break/continue from multiple loops up", but sometimes it happens and it's the clearest way to write! |
| 00:37 | <TabAtkins> | And having to use flags to simulate the behavior is just dirty. |
| 00:38 | <zewt> | i usually switch to a nested function before using a flag |
| 00:42 | <SamB> | TabAtkins: I know! |
| 00:43 | <zewt> | my current annoyed-at language is C#, where someone who thinks they know better than me tells me how to write code |
| 00:44 | <zewt> | re: prohibiting switch fall-through, because some idiot read a "considered harmful" rant and decided to make my decisions for me |
| 00:45 | <TabAtkins> | Yeah, the case against switch fall-through is against *default* fall-through. |
| 00:45 | <SamB> | yeah, there should be a "fallthrough" statement or something |
| 00:45 | <TabAtkins> | Just changing the default and having some way to indicate that you should fall through is obviously the right way. |
| 00:45 | <SamB> | there is probably only one reason Python does not suffer from the same thing though |
| 00:45 | ChrisMorgan | contests the obviousness of that |
| 00:46 | <zewt> | well, python ... doesn't have switch |
| 00:46 | <ChrisMorgan> | And, for that matter, the truth of it. |
| 00:46 | <SamB> | zewt: yes, that's the reason |
| 00:46 | <TabAtkins> | zewt: Yes. which is also terrible. |
| 00:47 | <TabAtkins> | ChrisMorgan: I'll see your contestation, and raise you all the times I fell through accidentally because I forgot to say "break", and thus had a bug. |
| 00:47 | <TabAtkins> | I *rarely* want to fall-through on a switch. It's common per-switch, but rare per-case, I think. |
| 00:47 | <ChrisMorgan> | TabAtkins: I’m with C♯ on this—forbidding fallthrough altogether is entirely reasonable. |
| 00:47 | <SamB> | ChrisMorgan: you think it should require explicit goto insteaa? |
| 00:47 | <TabAtkins> | That just means duplication. |
| 00:48 | <ChrisMorgan> | SamB: not that either. |
| 00:48 | <zewt> | if i'm trying to do a switch fallthrough, it's for a reason; the language needs to get out of my way unless there's some underlying structural reason why the language can't do it |
| 00:48 | <ChrisMorgan> | TabAtkins: normally there is not actually any basic need for fallthrough in the first place. |
| 00:49 | <SamB> | well, it isn't all THAT much more likely than wanting to goto somewhere else, I guess ... |
| 00:49 | <ChrisMorgan> | zewt: in Rust, or for that matter *any* language with proper pattern matching, fallthrough in `match` branches would make no sense whatsoever. |
| 00:50 | ChrisMorgan | has never felt the slightest pang of remorse or yearning for fallthrough in Rust |
| 00:50 | <SamB> | ChrisMorgan: I hope they have guards though |
| 00:50 | <ChrisMorgan> | SamB: to be sure, to be sure. |
| 00:50 | <ChrisMorgan> | All armed to the teeth! ;-) |
| 00:50 | <SamB> | I mean, conditions for the case matching at all |
| 00:51 | <ChrisMorgan> | To be sure, to be sure. |
| 00:51 | <TabAtkins> | ChrisMorgan: I see your attestation and raise you all the times in the CSS Syntax spec where I'm explicitly doing fall-through in my English-language switch statements. ^_^ |
| 00:52 | <ChrisMorgan> | TabAtkins: I’m not familiar with your specific examples, but most of the ones that I imagine to be of the same nature are “if this is the case, follow these steps”, which does not need to be modelled as fall-through, though that is often one way of doing it (and not the most general, I might add). |
| 00:53 | <ChrisMorgan> | But hey—Swift uses pattern matching, so it *must* be right, huh? |
| 00:53 | <TabAtkins> | ChrisMorgan: No clue what Swift does, so shrug. |
| 00:54 | <TabAtkins> | I'm just talking about switch statements, which are indeed different from pattern matching. |
| 00:54 | <ChrisMorgan> | Back on the topic of labels, the funny thing is that Rust supports labels on its `for` and `loop` loops, but not its `while` loops… a strange omission which I had fun with, https://github.com/mozilla/rust/issues/12643. |
| 00:55 | <ChrisMorgan> | TabAtkins: I can’t speak much of Swift either, but at the theoretical level, switch statements, assuming no fall-through, provide a strict subset of the functionality of pattern matching. |
| 00:56 | <ChrisMorgan> | Anyway, this is probably all moderately off-topic for #whatwg! |
| 00:56 | <TabAtkins> | It's the "subset" part that makes it different. If you're not extracting anything, just doing abbreviated testing (like normal switches do), then fallbacks make more sense, as a disjunction of cases. |
| 00:56 | <TabAtkins> | (Plus the occasional fun bit where you do some preliminary work in some cases and then fallthrough to the base-case to do more work. |
| 00:56 | <TabAtkins> | ) |
| 00:57 | <TabAtkins> | (But that only works if you've only got a single type of prelim work to do, or if your multiple types are chained. If you have multiple parallel types of prelim work to do, you can't model it with fall-through.) |
| 00:59 | <ChrisMorgan> | `switch foo { bar: code1; baz: code2; break; default: code3; }` => `match foo { bar | baz => { if foo == bar { code1 } code2 }, _ => code3 }`. These should have the same performance characteristics when compiled. |
| 01:12 | <TabAtkins> | Is it appropriate to use [SameObject] on an attribute which occasionally swaps out its underlying value? |
| 01:12 | <TabAtkins> | But otherwise always returns the same object? |
| 01:23 | <TabAtkins> | annevk: Do I need to use [Exposed] on events too? Or just normal interfaces? |
| 01:33 | <TabAtkins> | Hixie: Did you mean to make the :target arrow also slightly tilted? |
| 03:04 | <SimonSapin> | TabAtkins: for what it’s worth, I used a lot of pattern matching in rust-cssparser and never missed fall-through |
| 03:04 | <SimonSapin> | (but I do miss pattern matching a lot when going back to Python) |
| 03:06 | <Hixie> | TabAtkins: vaguely |
| 03:16 | <Hixie> | ok i've tried to post this to es-discuss twice now |
| 03:16 | <Hixie> | and i get nothing back and it doesn't go to the list |
| 03:16 | <Hixie> | i'm still subscribed... |
| 03:52 | <hemanth> | jorendorff, If you are around, just posted https://bugs.ecmascript.org/show_bug.cgi?id=2981 |
| 05:19 | <annevk> | TabAtkins: events are normal interfaces |
| 05:20 | <annevk> | Domenic: I mean you want to store these objects some storage API |
| 05:22 | <TabAtkins> | annevk: kk |
| 06:13 | <Domenic> | annevk: yeah, you should generally just read them to the end and store the serialized version, or alternately stream them into a store |
| 06:13 | <annevk> | Hixie: another infographic I'd be interested in is one explaining the relationship of the higher-level object model; how browsing contexts relate to globals, relate to documents, relate to cross-origin Location objects, relate to settings objects, etc. |
| 06:14 | <Hixie> | that would be one hell of an inforgraphic |
| 06:14 | <annevk> | Domenic: my problem is that a developer might want to read data and store the Response |
| 06:14 | <annevk> | Domenic: currently that's not feasible |
| 06:14 | <annevk> | Hixie: yeah :( |
| 06:15 | <annevk> | Hixie: I still find it hard to follow at times what of the various objects I should look at from script and what I can reach from there |
| 06:17 | <Hixie> | annevk: http://junkyard.damowmow.com/542 |
| 06:17 | <Domenic> | annevk: Ah yeah makes sense. Not sure how it would work generally for streams, since e.g. their content can be nondeterministic. (a Response body stream could be the product of the particular time on the server, or of a particular interaction between client and server, for example.) But maybe in this particular case we could define that it reads them to end |
| 06:17 | <Domenic> | at the time of storage, and then when it gets revived from cache it becomes a sort of "constant stream." |
| 06:17 | <Hixie> | HTH |
| 06:18 | <annevk> | Hixie: have a good night :p |
| 06:18 | <Hixie> | :-P |
| 06:19 | <annevk> | Domenic: okay, and if you wanted to read it to inspect it and store the object you'd have to tee it? |
| 06:20 | <Domenic> | annevk: in general yes, if you want to read without consuming you need to tee |
| 06:20 | <annevk> | Domenic: how do you distinguish between an empty stream and a depleted stream? |
| 06:21 | <Domenic> | annevk: good question, might not get this right off the top of my head, but I think: depleted will be "closed" already; empty will start "open" until you try to wait for more data to come in, at which point it becomes "closed" |
| 06:22 | <annevk> | Domenic: ah okay, closed vs open is nice terminology |
| 06:22 | <annevk> | Domenic: I should probably update my abstract stream description in Encoding to use that |
| 06:23 | <Domenic> | And I should probably update the "model" section to have more useful terminology of the sort. Will do at work tomorrow! :) |
| 06:25 | <annevk> | Yay model |
| 06:25 | <krit> | annevk: Hi |
| 06:25 | <annevk> | Yeah we need a model if we want to do this right. Rewrite all the things in terms of that and then slowly open them up to APIs |
| 06:25 | <annevk> | krit: morning |
| 06:26 | <krit> | annevk: Checked and would be available next week. Would you be able to look at SVG sec and have time? |
| 06:27 | <annevk> | krit: yes, let's do it |
| 06:28 | <krit> | annevk: cool. bringing kids to school usually. So am available from 9AM to whatever |
| 06:28 | <annevk> | krit: same here, this is really early for me |
| 06:28 | <krit> | annevk: bringing kids to school? :) |
| 06:28 | <Hixie> | huh |
| 06:29 | <annevk> | krit: I was about to correct that bit |
| 06:29 | <Hixie> | "in select" mode, <select> doesn't check if a select is in scope |
| 06:29 | <Hixie> | i think, per spec, <select>.innerHTML = '<select>' should crash |
| 06:29 | <Hixie> | am i crazy? |
| 06:31 | <annevk> | Hixie: the note "It just gets treated like an end tag." does make it seem like there's a bug there |
| 06:31 | <annevk> | Hixie: although "Pop elements from the stack of open elements until a select element has been popped from the stack." probably does not cause a crash |
| 06:32 | <Hixie> | you pop all the elements, then try to pop the stack when it's empty |
| 06:32 | <Hixie> | it'll either hang or crash or something bad will happen |
| 06:32 | Hixie | fixes the spec |
| 06:33 | <annevk> | Hixie: wouldn't you null-check the stack? |
| 06:33 | <Hixie> | and do what? |
| 06:33 | <Hixie> | i mean normally you shouldn't need to |
| 06:33 | <Hixie> | the parser isn't going to pop all the nodes off |
| 06:35 | <annevk> | Not sure, but e.g. in JavaScript [].pop() doesn't kill you |
| 06:35 | <Hixie> | well sure, in _javascript_ |
| 06:36 | <Hixie> | you can typo your variables names and js isn't going to bat an eye |
| 06:36 | <annevk> | I love that you can write <select></select> with one character less though |
| 06:36 | <annevk> | Didn't know that |
| 06:40 | <Domenic> | annevk: TabAtkins: IMO "await a stable state" is more confusing than "queue a microtask," especially when appearing nearby "queue a task"... |
| 06:41 | <Hixie> | await a stable state makes the spec so much easier to read |
| 06:42 | <Domenic> | disagree |
| 06:43 | <Hixie> | it describes the algorithm as one straightforward algorithm, with the complicated timing details present but not in the way |
| 06:43 | <TabAtkins> | I just did what Hixie told me to do. |
| 06:44 | <annevk> | Hixie: why didn't you group the <dt>s? |
| 06:44 | <Hixie> | ? |
| 06:44 | <annevk> | Hixie: with http://html5.org/r/8667 |
| 06:44 | <Hixie> | context? |
| 06:44 | <Hixie> | they're not identical |
| 06:45 | <annevk> | Ah, parse error |
| 06:45 | <Hixie> | three clauses, three slightly different requirements |
| 06:45 | <Hixie> | ok i can now parse html5lib-tests/tree-construction/tests7.dat tests 1..14 |
| 06:45 | <Hixie> | time for bed |
| 06:45 | <Hixie> | nn |
| 08:28 | <annevk> | So my bank turned ü into ³ |
| 08:33 | <annevk> | Both however have stable positions in single byte encodings |
| 08:33 | <Ms2ger> | How about in ebcdic? |
| 08:42 | <annevk> | Ms2ger: yeah I guess |
| 08:46 | <annevk> | Ms2ger: can't find a code page where that would be the case |
| 09:03 | darobin | wonders if there's a hack to make annevk rich out of this |
| 09:04 | <darobin> | "I'd like to withdraw 99ü, please" |
| 09:06 | <annevk> | Why would http://www.techmania.ch/details.aspx?hersteller=Dell&produkt=EUCORD_CLOF be CHF 27?! |
| 09:06 | <annevk> | darobin: heh |
| 09:08 | <annevk> | It's not even the right cable |
| 10:59 | <krit> | Hixie: All constructors of Path2D seem to have the old name still: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-path2d-withdata |
| 14:46 | <annevk> | So the inconsistent policies between CORS and UA-defined features is annoying. |
| 14:46 | <annevk> | Why can we have Last-Event-ID, Ping-To, and Ping-From without preflight if they are done by the UA, but not if they are done by the developer? |
| 14:47 | <annevk> | These are the only headers that require some kind of separation between developer set headers, and UA set headers |
| 15:58 | <annevk> | hsivonen: did you see Unicode is about to introduce 2800 more code points? |
| 15:58 | <annevk> | JakeA: any insights as to how to best address that? |
| 15:59 | <annevk> | Hixie: you maybe? |
| 16:00 | <MikeSmith> | annevk: what are the new code points? emoji? |
| 16:00 | <MikeSmith> | annevk: you have a link to an announcement or hwatever? |
| 16:00 | <annevk> | MikeSmith: @unicode |
| 16:01 | <MikeSmith> | thanks |
| 16:01 | <annevk> | MikeSmith: no pointer seems to be included |
| 16:01 | <MikeSmith> | yeah |
| 16:02 | <MikeSmith> | annevk: don't UAs already handle most of these? |
| 16:02 | <annevk> | MikeSmith: I guess I should have said new assigned code points or whatever the term is |
| 16:04 | <MikeSmith> | "Duployan shorthand & letters used in Teuthonista & other transcriptional systems" |
| 16:04 | <annevk> | http://www.unicode.org/charts/PDF/Unicode-7.0/ has details it seems |
| 16:05 | MikeSmith | looks |
| 16:05 | <annevk> | It now includes Linear A |
| 16:05 | <annevk> | Lars Thomas can be proud |
| 16:07 | <jgraham> | Linear A, Linear B and Carakan? Awesome |
| 16:07 | <annevk> | Just Linear A |
| 16:07 | <annevk> | Now I wonder about Futhark |
| 16:09 | <jgraham> | Linear B and Carakan are already in Unicode |
| 16:09 | <jgraham> | I think |
| 16:13 | <annevk> | Futhark is too |
| 16:15 | <jgraham> | So we have a full house? |
| 16:17 | <annevk> | I guess we can go shopping |
| 16:39 | <Hixie> | annevk: why would we need to address anything? |
| 16:40 | <annevk> | Hixie: I want to do away with author headers vs headers as it doesn't make much sense if you actually expose the request as an object |
| 16:40 | <annevk> | Hixie: and at that point the only problematic header is Last-Event-ID (and maybe Ping-To and Ping-From) |
| 16:41 | <annevk> | Hixie: as in headers that a spec has set that don't cause a preflight whereas they would if someone set them in some other context |
| 16:42 | <annevk> | Hixie: this becomes icky at the point where you'd add the ability to add headers to an EventSource fetch |
| 16:44 | Hixie | is confused |
| 16:44 | <Hixie> | how is unicode characters related to http headers |
| 16:44 | <Hixie> | i think i missed something |
| 16:45 | <Ms2ger> | Hixie, only temporally in this channel |
| 16:45 | <Ms2ger> | What you're missing is a <hr> between the conversations |
| 16:52 | <annevk> | Hixie: skip the line addressed at hsivonen, it's before that |
| 16:53 | <Hixie> | ah, i see |
| 16:53 | <Hixie> | i don't know why they're the only ones. Seems like their situation would be pretty common. |
| 16:53 | <Hixie> | it's attributes that are harmless when the server sets them, but not harmless when the author sets them. |
| 16:53 | <Hixie> | er |
| 16:53 | <Hixie> | when the client sets them |
| 16:53 | <Hixie> | not server |
| 16:53 | <Hixie> | and headers |
| 16:53 | <Hixie> | not attributes |
| 16:54 | <annevk> | but they're not so restricted that authors can never set them? |
| 16:55 | <Hixie> | right |
| 16:55 | <Hixie> | i mean, if the server wants to use them, and is willing to preflight it, who cares |
| 16:55 | <annevk> | The problem with these is that they're in the middle. Host is client-only. Last-Event-ID however, when set by the client is preflightless. When set by authors comes with a preflight. |
| 16:55 | <Hixie> | right |
| 16:55 | <Hixie> | Host is not something that you could opt into allowing the client to send |
| 16:55 | <annevk> | And if we want to keep that we would need some kind of flag. |
| 16:55 | <Hixie> | since the entire secutity system depends on it |
| 16:56 | <Hixie> | security |
| 16:56 | <annevk> | E.g. what if EventSource starts allowing you to set headers? |
| 16:56 | <annevk> | Maybe I should just assume that it doesn't |
| 16:56 | <Hixie> | i'm neck-deep in the html parser right now, you're not going to get any sympathy from me if you're looking for a way to keep things simple for yourself :-) |
| 16:56 | <annevk> | I'm trying to keep APIs simple for developers |
| 16:57 | <Hixie> | if EventSource lets you set headers, then what? |
| 16:57 | <annevk> | And trying to predict future growth of various APIs and how that would affect the system |
| 16:57 | <Hixie> | i don't see the problem |
| 16:57 | <Hixie> | i'm actually really surprised to hear there's only three headers like this |
| 16:57 | <Hixie> | i'd have thought there'd be more |
| 16:57 | <annevk> | If EventSource lets you set headers the granularity we need is on the level of headers. E.g. a header gets an additional flag about it being set by a spec rather than an author |
| 16:58 | <Hixie> | what spec is this in |
| 16:58 | <Hixie> | i cant' find last-event-id in fetch.spec and xhr.spec |
| 16:58 | <Hixie> | can't |
| 16:58 | <annevk> | It's in your spec |
| 16:58 | <annevk> | You are creating my problems :-) |
| 16:59 | <Hixie> | i don't see anything to do with cors with last-event-id |
| 16:59 | <annevk> | EventSource can do CORS and can include a custom header unlike other headers, Last-Event-ID |
| 16:59 | <Hixie> | in the html spec |
| 16:59 | <annevk> | However, because this header is set by the UA, there's no preflight |
| 17:00 | <annevk> | What Fetch sees is just a Request with a header list attached with Last-Event-ID in it |
| 17:00 | <annevk> | But now it has to know this is UA-set so it won't treat it as not a simple header |
| 17:00 | <annevk> | (As otherwise it would cause a preflight) |
| 17:01 | <Hixie> | what am i missing? |
| 17:01 | <Hixie> | er, ignore last line |
| 17:01 | <Hixie> | hasn't this worked for forever? |
| 17:01 | <Hixie> | i don't understand what's new here that this has suddenly come up |
| 17:02 | <annevk> | Yeah kinda, because I separated author headers and headers set by specs |
| 17:02 | <annevk> | However, that's a silly model and would create an ugly API |
| 17:02 | <annevk> | So I'm trying to come up with something better |
| 17:02 | <rektide> | hi. does anyone know of a way i can smoothly zoom into a page? |
| 17:03 | <rektide> | i spent a day wiring up a nice animated scale() transform |
| 17:04 | <rektide> | i think thinks went wrong when i tried keeping the center of the page as the zoom target by using requestAnimationFrame to adjust the scrollTop() |
| 17:04 | <annevk> | Solutions I see. We add a flag "API lets devs control headers". Set by fetch() and XMLHttpRequest, in all other cases we trust the specs to do the right thing |
| 17:04 | <annevk> | That's 1) |
| 17:04 | <Hixie> | annevk: i don't understand why the api is ugly? |
| 17:04 | <annevk> | 2) We add these headers to simple headers. |
| 17:04 | <rektide> | the scrollTop seems to cause my requestAnimationFrame to only trigger every 33ms |
| 17:05 | <annevk> | 3) We add an additional member to header about whether it's privileged or not |
| 17:05 | <Hixie> | annevk: there's a difference between a header set by the UA, and a header set via an API, right? we already have that in XHR. |
| 17:05 | <rektide> | and i still have some rather sincere jank. anyways, thanks. |
| 17:05 | <Hixie> | annevk: e.g. in XHR the UA sets Host, but the author sets X-Foo via the API |
| 17:05 | <annevk> | Hixie: I checked, XHR doesn't set any headers itself |
| 17:05 | <annevk> | Hixie: no, the network layer sets those headers |
| 17:06 | <annevk> | Hixie: i.e. Fetch, way after the CORS check |
| 17:06 | <Hixie> | sure but that's your problem at the spec level |
| 17:06 | <Hixie> | the author doesn't care about that |
| 17:06 | <Hixie> | from the author's perspective, there's UA-set headers, and author-set headers |
| 17:06 | <Hixie> | this is true in all APIs that let you set headers |
| 17:06 | <annevk> | No, it matters as to what's exposed in service workers |
| 17:07 | <annevk> | E.g. event.request.headers will not contain Host as that is set by the network layer |
| 17:07 | <Hixie> | that's odd |
| 17:07 | <annevk> | It seemed kind of natural to me |
| 17:07 | <Hixie> | but i guess you'd need to exclude some headers for auth |
| 17:07 | <Hixie> | Host is harmless, but others might not be |
| 17:07 | <annevk> | However, Host again would not be a problem either way, as authors cannot set it |
| 17:08 | <SamB> | Hixie: if the header is added by something that hasn't seen the request at all yet, it's obviously not going to be there yet, no? |
| 17:08 | <Hixie> | seems like you'd need a whitelist for what headers to expose |
| 17:08 | <annevk> | Hixie: yeah that is covered too |
| 17:08 | <Hixie> | SamB: i don't understand what you are asking |
| 17:08 | <Hixie> | annevk: is there somewhere i can read to see what service workers see? |
| 17:09 | <annevk> | Hixie: http://fetch.spec.whatwg.org/#fetching |
| 17:09 | <SamB> | I guess Host *could* get added at an earlier layer but seeing as it's mostly there because the GET doesn't mention the hostname ... |
| 17:09 | <annevk> | Hixie: http://fetch.spec.whatwg.org/#concept-http-fetch passes the request into service workers |
| 17:09 | <annevk> | Hixie: in step 8 |
| 17:10 | <Hixie> | (what's "Mixed Content"?) |
| 17:10 | <annevk> | Hixie: https://w3c.github.io/webappsec/specs/mixedcontent/ |
| 17:11 | <annevk> | Those hooks are WIP |
| 17:11 | <Hixie> | oh that kind of mixed content |
| 17:11 | <Hixie> | ok |
| 17:12 | <Hixie> | so https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#request-interface is what the service worker gets? |
| 17:12 | <annevk> | Hixie: http://fetch.spec.whatwg.org/#request is the new idea |
| 17:13 | <rektide> | are there polyfills to host fetch on XHR? or to provide XHR on fetch? |
| 17:14 | <Hixie> | annevk: man, i'm sure glad you're dealing with this and not me |
| 17:14 | <Hixie> | annevk: so the question is basically, which headers to expose there? |
| 17:14 | <rektide> | or against node's http.createClient or mikeal's request? |
| 17:14 | <Hixie> | annevk: or are the headers mutable? |
| 17:15 | <Hixie> | annevk: i think it'd be fine to have some headers be immutable in that API. Doesn't make the API surface particularly hard to understand, and it lets you include things like Host and Cache-Control. |
| 17:15 | <Hixie> | annevk: you could even include auth-related headers, and make them unreadable too |
| 17:16 | <Hixie> | annevk: so that headers would be in three modes: mutable, immutable, protected |
| 17:17 | <annevk> | Hixie: yeah there's some of that for response headers |
| 17:17 | <annevk> | Hixie: the main problem I have right now is the one I mentioned earlier |
| 17:17 | <Hixie> | why does what i described not solve that problem? |
| 17:17 | <annevk> | Fetch (the spec) takes a request which takes a set of a headers |
| 17:18 | <Hixie> | sure. The spec will need to have per-header metadata. |
| 17:18 | <annevk> | Those headers can trigger a preflight |
| 17:19 | <annevk> | Yeah so currently I don't need per-header metadata. The immutable and protected headers can just be lists that are checked on set and get |
| 17:19 | <annevk> | The problem is Last-Event-ID |
| 17:19 | <annevk> | Which triggers a preflight if it wasn't spec-sanctioned |
| 17:19 | <Hixie> | so you add the metadata |
| 17:19 | <Hixie> | what's the problem |
| 17:20 | <Hixie> | i'm really surprised these are the only headers in this mode |
| 17:20 | <annevk> | I think Last-Event-ID is actually the only one, since <a> doesn't do CORS |
| 17:20 | <annevk> | Or maybe <a ping download> does CORS? |
| 17:20 | <Hixie> | seems like e.g. Accept-Charset should be on this list too |
| 17:21 | <annevk> | Accept-Charset is not a header anymore |
| 17:21 | <Hixie> | and DNT |
| 17:21 | <annevk> | DNT is like Host |
| 17:21 | <Hixie> | and User-Agent |
| 17:21 | <annevk> | User-Agent is like Host |
| 17:21 | <Hixie> | how so |
| 17:21 | <Hixie> | i mean, it's on the same list today |
| 17:21 | <annevk> | Hixie: http://fetch.spec.whatwg.org/#forbidden-author-header-name |
| 17:21 | <Hixie> | i'm saying it should be treated like Last-Event-ID |
| 17:22 | <annevk> | No, they are more restricted |
| 17:22 | <Hixie> | if the UA sets it on a UA request, then sure, it shouldn't be mutated |
| 17:22 | <Hixie> | but why would we not allow it to be set on an XHR request, say |
| 17:22 | <annevk> | because we decided we wouldn't back in 2006 |
| 17:23 | <Hixie> | well if that's an argument, then why does the same argument not apply to Last-Event-ID? |
| 17:23 | <annevk> | well I asked you if we should just add Last-Event-Id to that list |
| 17:24 | <Hixie> | right but we decided not to in 200x, right? :-) |
| 17:24 | <Hixie> | adding per-header metadata seems pretty simple to me. |
| 17:24 | <Hixie> | (it's not really per-header, it's more just two lists of headers) |
| 17:25 | <Hixie> | (two lists that browsers probably already have somewhere, to some extent) |
| 17:25 | <Hixie> | (since some attributes are going to be mutable in this API and some aren't, regardless of what we do here) |
| 17:27 | <SamB> | so ... older browsers are going to allow scripts to do whatever they like with those headers, or? |
| 17:27 | <Hixie> | older browsers don't have service workers at all |
| 17:38 | <boogyman> | Hixie: where do I go to report a broken link on the w3.org spec? |
| 17:39 | <boogyman> | Hixie: w3c spec > w3c wiki |
| 17:39 | <Hixie> | on a wiki? just fix it... |
| 17:39 | <boogyman> | I am unaware of what the link is attempting to reference. "checkbox state" |
| 17:40 | <boogyman> | I can make an educated that this may be a reference to the "checked" state, but the phrase is ambiguous. |
| 17:41 | <Hixie> | ah |
| 17:41 | <Hixie> | dunno |
| 17:41 | Hixie | doesn't much care for w3c things |
| 17:49 | <Hixie> | so, anyone know why posts i send to es-discuss might be dropping on the floor? |
| 17:50 | <marcosc_> | Hixie: "use strict"? |
| 17:50 | <marcosc_> | :) |
| 17:50 | <MikeSmith> | heh |
| 18:02 | <Domenic> | Hixie: it finally arrived |
| 18:03 | <annevk> | It can't be a list. Say we put Last-Event-ID on that list. And someone sets it through XMLHttpRequest. How does Fetch know what Last-Event-ID means? |
| 18:04 | <Hixie> | Domenic: i just resent it |
| 18:04 | <Hixie> | Domenic: from a different mail client |
| 18:07 | <JonathanNeal> | Hixie: it’s not like you to resent anything. |
| 18:08 | <SamB> | *groan* |
| 19:12 | <JakeA> | annevk: will catch up tomorrow morning |
| 20:02 | <rektide> | i think i found an approach for zooming content in and out smoothly |
| 20:03 | <rektide> | i tried using requestAnimationFrame to scrollTop(), but that's janky, has some egregious state tracking, and runs half FPS |
| 20:04 | <rektide> | originally i'd thought i needed to dynamically adjust transform-origin, but that would've required it's own janktacular state tracking to keep updating the origin to the center of the page as the user scrolls without shifting |
| 20:05 | <rektide> | guessing the only viable approach is the use translate(), which for some reason hadn't occured to me |
| 20:05 | <caitp> | you will of course report your findings and have them published in a peer-reviewed journal |
| 20:06 | <rektide> | ya'll are welcome to peer review my google+ writeup when it goes up |
| 20:06 | <caitp> | nice |
| 20:08 | <rektide> | i also had to use huge negative margins to trim the zoomed out content's real size down to it's transformed size, which is what made me think the transform-origin was going to be problematic: it'd mean updating those margins as the origin moved. otoh, i only really need to set the transform-origin right before zoom starts, and so long as i can reupdate the origin, re-trim the margins, and set the scrollTop() exactly right, it might not be too bad |
| 20:27 | <zewt> | sometimes you'll get much smoother scrolling with translate3d |
| 20:27 | <TabAtkins> | annevk: Do @font-face rules in documents expose those fonts to other documents in the same window? I didn't think they did, which is why I did document.fonts, but if they are, I can see the argument for shifting to CSS.fonts. |
| 20:28 | <zewt> | depending on what the content is |
| 20:41 | <rektide> | the biggest suck of all is that "zoom" ends up with thousands of millions of results for zooming an image in and out |
| 20:41 | <rektide> | there's absolutely no hope of ever finding any useful information on how to zoom content in or out, which is only slightly bleaker than my outlook for ever getting this right myself by munging carefully with scale() translate(), negative margin, and translate origin |
| 20:42 | <caitp> | to be fair, isn't that usually the client's job? |
| 20:42 | <caitp> | spread fingers apart on the trackpad, notice that text and images scale up |
| 20:43 | <rektide> | it doesn't seem like a use case that the web should be exempt from actually doing |
| 20:43 | <rektide> | just because there is a use case where the browser can do some kind of job at it |
| 20:44 | <caitp> | some people would say the platform already kind of does too much, it's a silly level of scope creep |
| 20:45 | <rektide> | yes, you can't imagine wanting to change the size of a thing, clearly, definitely: should be banned, scope creep. |
| 20:45 | <caitp> | now now, I'm not taking sides in that argument =) |
| 20:46 | <rektide> | scope creep is my weak-sauce hacked out implementations. :( |
| 20:47 | <annevk> | TabAtkins: I suspect with HTML imports they would |
| 20:47 | <TabAtkins> | Ah, hm. Yeah. |
| 22:14 | <Hixie> | man, getting the orientation of the stack of open elements wrong was so dumb |
| 22:15 | <SamB> | Hixie: hmm? |
| 22:15 | <SamB> | oh, you mean in your parser? |
| 22:15 | <Hixie> | when i specced the html parser, i defined a stack which grows downwards |
| 22:15 | <Hixie> | instead of upwards |
| 22:15 | <SamB> | oh |
| 22:15 | <SamB> | oops |
| 22:15 | <Hixie> | so the spec talks about "lower in the stack" meaning further from zero |
| 22:15 | <SamB> | just like on i386 ;-P |
| 22:15 | <Hixie> | heh |
| 22:15 | <Hixie> | it's freaking confusing |
| 22:16 | <Hixie> | but to fix it would be so risky |
| 22:16 | <Hixie> | that i daren't do it |
| 22:16 | <SamB> | maybe change to words that aren't up and down at all |
| 22:16 | <Hixie> | i use all kinds of words |
| 22:16 | <Hixie> | that's why it's risky |
| 22:16 | <Hixie> | e.g. "Let furthest block be the topmost node in the stack of open elements that is lower in the stack than formatting element..." |
| 22:17 | <Hixie> | topmost meaning nearest to index 0, lower meaning with index greater than |
| 22:17 | <Hixie> | assuming a positive-index stack where 0 is the first thing pushed onto it |
| 22:18 | <SamB> | clearly start by wrapping all such text in caution tape ;-P |
| 22:55 | <jamesr_> | redefine the stack to go left-to-right |
| 22:57 | <SamB> | hmm, that's not terribly exotic as directions go |
| 22:57 | <jamesr_> | or north/south? |
| 22:58 | <Philip`> | With C++ std::vector, a stack typically grows from front to back |
| 23:01 | <Philip`> | (Could go with turnwise and widdershins if you want to avoid ambiguity with typical 3D directional terms) |
| 23:03 | jgraham | thinks that the C++ committee and Hixie need to revise the law of universial gravitation |
| 23:03 | <jgraham> | Because their stacks are not going to be stable |
| 23:43 | <Hixie> | holy crap, i implemented the AAA and passed like 10 more tests |