| 03:07 | <mnot> | annevk: you about? |
| 03:33 | <JonathanNeal> | Could the CSS Color Module be used to invert a color? My usecase is styling `::selection`and wanting the color to be the inverse of the background. |
| 03:40 | <caitp> | https://drafts.csswg.org/css-color/ has some comments about that, so it sounds like probably not yet |
| 03:40 | <caitp> | i mean, in current implementations, no, maybe some day |
| 04:41 | <caitp> | annevk: I was going to say, it would be really handy if the full markup was generated from markdown or something, so that it's easier to read the blame |
| 04:41 | <annevk> | caitp: HTML is hard to read? |
| 04:41 | <caitp> | yeah, when the bulk of it is not the actual text content |
| 04:42 | <annevk> | I guess |
| 04:42 | <annevk> | I don't really have the bandwidth to convert specs to markdown though while retaining all the same features |
| 04:43 | <caitp> | yeah, but somewhere out there there's a college kid learning python or node or something that needs something to work on |
| 05:06 | <annevk> | caitp: oh, so the whitespace is the problem for these "bearer" tokens? Not e.g., 0x02 bytes? |
| 05:07 | <caitp> | well the problem is that they're programmatically building the header, and OAUTH wants it to be "Bearer<whitespace>SomeThing", I guess |
| 05:07 | <caitp> | and they historically haven't had to make sure the value is non-empty |
| 05:07 | <caitp> | so, they don't |
| 06:09 | <annevk> | if we had to preserve whitespace there that actually violates HTTP semantics |
| 06:09 | <annevk> | that would be something |
| 08:23 | <annevk> | I'm having a hard time understanding why SharedWorker has both URL and name, when they're required to match anyway |
| 08:25 | <zcorpan> | annevk: isn't it to be able to start a separate instance of a shared worker? |
| 08:27 | <annevk> | zcorpan: ah okay |
| 08:28 | <annevk> | zcorpan: do you know why empty string name and non-empty string are handled differently in the constructor? |
| 08:28 | <annevk> | zcorpan: I don't understand why non-empty string doesn't check the URL straight away too and instead throws an exception later on for it... |
| 08:31 | <annevk> | I guess name has to be sole key |
| 08:32 | <annevk> | And when name is empty, the constructor URL is the key |
| 08:33 | <zcorpan> | annevk: step 6 makes a difference there, but i don't know if it is intentional to not throw in that mode |
| 08:35 | <annevk> | zcorpan: afaict Firefox just keys on both constructor url and name |
| 08:35 | <annevk> | zcorpan: and therefore never reaches 7.1 |
| 08:36 | <annevk> | zcorpan: I guess it depends on whether you want names to be unique or not, but it seems empty string is already not unique |
| 08:36 | <zcorpan> | ok. i don't know why the spec is as it is |
| 08:36 | <annevk> | Chrome does do this per spec though |
| 08:50 | <zcorpan> | annevk: certainly for the purpose to just be able to start a separate instance of a shared worker, there is no need for URLMismatchError |
| 08:51 | <annevk> | The only reason I can imagine is that you want non-empty string names to be unique |
| 08:51 | <annevk> | I don't think that's particularly great design |
| 08:55 | <annevk> | zcorpan: any idea who from Chromium we can convince that this should be changed? |
| 09:32 | <zcorpan> | annevk: sof implemented workers in presto. otherwise dunno; maybe someone from https://code.google.com/p/chromium/issues/detail?id=327256 |
| 09:59 | <Ms2ger> | annevk, so you can still detect whether a cross-origin file is well-formed JS by calling importScripts? Does <script> already expose that? |
| 10:03 | <annevk> | Ms2ger: hmm, I think <script> calls report the exception in that case which ends up on the Window object |
| 10:04 | <Ms2ger> | Seems plausible |
| 10:04 | <annevk> | Ms2ger: actually, I'm not sure how importScripts() ever ends up there given that it too uses "create a script" which already reports the errors |
| 10:05 | <annevk> | Ms2ger: I'm mainly concerned about the "ok status" leak, but that was already present... |
| 10:08 | <annevk> | Ms2ger: ah, it gets there because it also starts running the script |
| 10:12 | <annevk> | Added some thoughts to the PR on potential further improvements |
| 11:01 | <annevk> | wanderview: so you asked at some point whether fragments need to be preserved, it seems workers preserve them |
| 11:05 | <annevk> | So much churn :-( |
| 11:37 | <JonathanNeal> | TabAtkins: a usecase for inverting a color is styling `::selection`and wanting the text color to be the inverse of the background. https://drafts.csswg.org/css-color/ |
| 11:41 | <frewsxcv> | <font size=2>hello</font> |
| 11:41 | <frewsxcv> | What should the computed font size for that be? |
| 11:45 | <zcorpan> | sigh, free pascal installer refuses to install. it says i need xcode and command line tools, which i have installed |
| 11:49 | <zcorpan> | or hmm, maybe command line tools thing failed |
| 12:05 | <jgraham> | zcorpan: You might need to accept the license agreement |
| 12:08 | <zcorpan> | jgraham: i managed to download and install the command line tools from developer.apple.com |
| 12:08 | <jgraham> | OK |
| 12:09 | <jgraham> | The usual problem with Xcode is that you need to actually start it and accept a license agreement before the command line parts work |
| 12:14 | <zcorpan> | ok. i had started it so it was some other problem :-) |
| 12:16 | <Ms2ger> | frewsxcv, there's something in HTML for that |
| 12:40 | <wanderview> | annevk: you're saying you want Request to preserve fragments? JakeA does this mean Cache API needs to preserve request fragments? |
| 12:47 | <frewsxcv> | Ms2ger: right. The html spec specifies which absolute String they map to, like xx-large. Do you know where it's specified bow that String gets turned into a scale ratio? |
| 12:49 | <Ms2ger> | There's a table at https://drafts.csswg.org/css-fonts/#font-size-prop |
| 12:51 | <frewsxcv> | So I saw that table. Though it appears blink and Gecko don't follow it. I guess I'll just look at their source |
| 12:55 | <frewsxcv> | for example, <font size=2> with gecko results in font-size == 13px. whereas 8/9 * 16 = 14.2222222222222 |
| 12:56 | <frewsxcv> | i also find it strange how both gecko and blink have nice whole numbers for pixels. maybe pixels aren't allowed to be decimal and they round? |
| 12:56 | <Ms2ger> | frewsxcv, they have tables for small base font sizes |
| 12:57 | <frewsxcv> | they == blink+gecko ? |
| 12:58 | <Ms2ger> | I'm pretty sure Gecko does, and probably Blink too |
| 12:58 | <frewsxcv> | does that go against the spec? |
| 12:58 | <JakeA> | wanderview: annevk: hm, I'd be surprised to see them in the request url… where is it they surface in works? |
| 12:59 | <JakeA> | workers* |
| 12:59 | <Ms2ger> | Yeah |
| 13:53 | <annevk> | JakeA: self.location |
| 13:53 | <annevk> | wanderview: guess so |
| 13:55 | <wanderview> | annevk: does this have to effect the script visible Request object? seems self.location could pull from the inner request url |
| 13:55 | <annevk> | frewsxcv: nah, the spec just calls it guidelines |
| 13:56 | <annevk> | wanderview: yeah we could Request alone still, seems a tad weird perhaps since it has an effect on workers (of sorts) |
| 13:57 | <wanderview> | annevk: I think workers are weird for letting fragments be a thing in their script location |
| 13:59 | <frewsxcv> | annevk: so should there not be any tests in web-platform-tests for this since it's pretty much a guideline? |
| 14:02 | <Ms2ger> | frewsxcv, if browsers agree, I guess we should just spec and test it |
| 14:02 | <Ms2ger> | ("just") |
| 14:03 | <frewsxcv> | what do you mean by 'spec it'? |
| 14:03 | <frewsxcv> | add it to the spec? |
| 14:04 | <Ms2ger> | Yes |
| 14:44 | <annevk> | wanderview: I don't disagree, but not sure it's worth fixing it |
| 14:45 | <annevk> | wanderview: and I guess you could use it for something |
| 14:45 | <annevk> | But having both fragments and names to play with as keying mechanisms seems a bit much |
| 14:48 | <wanderview> | annevk: JakeA: it would really be nice to have a convenient way to construct a new Request from an old Request and an overriding url |
| 14:48 | <annevk> | wanderview: hmm |
| 14:51 | <wanderview> | maybe thats not my problem |
| 14:56 | <annevk> | wanderview: I guess we could offer that at some point |
| 14:56 | <wanderview> | annevk: I've just seen a couple pieces of code that need to do that and get it wrong |
| 14:57 | <wanderview> | forget to propagate something like body or headers or a new field that was added to Request |
| 14:57 | <annevk> | wanderview: I see, file an issue? |
| 14:57 | <wanderview> | ok |
| 15:00 | <wanderview> | annevk: https://github.com/whatwg/fetch/issues/129 |
| 15:04 | <JakeA> | wanderview: could it be new Request(url, oldRequest)? |
| 15:05 | <wanderview> | JakeA: that would work for me |
| 15:05 | <wanderview> | its unclear to me if some contents of the Request should not be propagated... type, destination, unsafe-request flag, etc |
| 15:05 | <JakeA> | Does that not already work? |
| 15:05 | <JakeA> | ahh ok |
| 15:05 | <wanderview> | JakeA: the second arg of Request constructor is RequestInit... a dictionary |
| 15:06 | <wanderview> | JakeA: which works for most thing... but not propagating the body |
| 15:06 | <JakeA> | Ahh fair enough |
| 15:06 | <wanderview> | JakeA: although maybe that would work after streams land? |
| 15:07 | <JakeA> | wanderview: Once .body is fully known, it could be made to work I guess |
| 15:09 | <wanderview> | I don't know why I forgot Request could be passed as the dictionary |
| 15:19 | <wanderview> | JakeA: I guess maybe this code wants to override the url and like one or two other fields.... |
| 15:20 | <JakeA> | wanderview: I guess you want something to turn a request into a mutable requestInit type of thing |
| 15:20 | <wanderview> | yea |
| 15:21 | <wanderview> | I guess script can do that anyway |
| 18:03 | <ccardona-work> | Good morning/afternoon/evening WHATWG crew o/ |
| 19:33 | <Krinkle> | JakeA: Do you reckon the outcome of "Aborting a fetch" / cancellable promise/task etc. will be one that is polyfillable? I can't wait to be able to use it in all browsers, today. This comes up like every 48 hours in my job. And gets worked around in horrendous hurtful and counter-intuitive ways. |
| 19:34 | <Domenic> | Krinkle: if you are willing to re-build fetch + promises from scratch then yes. |
| 19:34 | <Domenic> | (both are doable, on top of XHR and nothing, respectively.) |
| 19:34 | <Krinkle> | yeah. |
| 19:35 | <Krinkle> | I could just pick one of the ideas there and have "something", but I do have the discipline to wait a bit longer so that I'm not betting on the approach that didn't make it and have to re-educate everyone when we change things again. |
| 19:35 | <Krinkle> | the while .then() loses .abort() with ajax is the main driver here. |
| 19:36 | <Krinkle> | whole* |
| 19:36 | <Domenic> | What "whole .then() loses .abort() with ajax"? |
| 19:36 | <Krinkle> | Global singletons keeping track of of XHRs etc. it's just unmaintainable and prone to error. |
| 19:37 | <Krinkle> | Domenic: A common pattern is to abort requests based on user input. Either from debouncing or otherwise. But further in processing, every then() later, you lose the original .abort from the initial jQuery promise that had .abort tacked on. |
| 19:37 | <Domenic> | I thought we were talking about fetch, not jQuery. |
| 19:38 | <Krinkle> | Yes |
| 19:38 | <Krinkle> | It's all part of an endless pyramid of problems and concerns |
| 19:38 | <Krinkle> | whatever pattern we settle on here, will be one we can re-use elsewhere as a logical unit of how to deal with this |
| 19:38 | <Krinkle> | API wise, not implementation wise |
| 19:39 | <Krinkle> | We can apply it to our library that deals with internal API requests (which uses ajax() internally) |
| 19:41 | <Krinkle> | e.g. mw.Api#getCategories -> mw.Api#getPageInfo -> jQuery.ajax; Then consumer UI code calls getCategories() and needs a way to .abort / cancel / ignore / ensure it won't ever callback. |
| 19:42 | <Domenic> | How would you feel about an approach where you pass a cancelation toekn to getCategories, which passes it to getPageInfo, which passes it to, well, fetch, not jQuery.ajax. |
| 19:44 | <Krinkle> | I can't say I'm very keen on such interface. It feels unnecessarily formal and overhead. |
| 19:45 | <Krinkle> | But if that's the way it will be, I'm okay with that. I'll become part of how we use fetch() and a familiar behaviour and pattern we'll encounter anyway, so might as well use that in our library. |
| 19:46 | <Krinkle> | At this point I've lost any and all preferences or pleasantry, I'm too eager to just have an answer. |
| 19:46 | <Krinkle> | In another month or so we'll probably just pick an approach and abstract it a bit so we can easily switch to fetch() internally. |
| 19:50 | <Krinkle> | The chain-aware ness seems achievable |
| 19:51 | <Krinkle> | Though I agree with JakeA that this only works when strictly chaining. |
| 19:51 | <Krinkle> | When passing on a promise received by closure instead of then(), there is no longer that explicit link, not until the code executes. |
| 19:51 | <Krinkle> | RE: There's a bunch of good ideas there but I do have the discipline to hold off a little longer to avoid having to enter a paradigm shift when the eventual apparoach |
| 19:51 | <Krinkle> | * RE: https://github.com/whatwg/fetch/issues/27#issuecomment-92929061 |
| 19:58 | <annevk> | Krinkle: I'm mostly being patient too, waiting for Domenic and JakeA to come up with something |
| 19:58 | <Domenic> | We're having a mini cancelable promises summit next Monday before TC39 |
| 19:58 | <annevk> | Krinkle: doesn't seem worth it to add something to the specification now since whatever we add we'll have to live with for a long time |
| 19:58 | <Domenic> | The biggest issue in my mind right now is that the ref-counting CancelablePromise subclass approach doesn't work with async functions |
| 19:59 | <Domenic> | So we want to noodle on that for a bit |
| 19:59 | <Krinkle> | Domenic: Hm.. because await is an implicit then? |
| 19:59 | <annevk> | So, https://github.com/w3c/charter-html/issues/112 |
| 20:00 | <annevk> | Anyone opinions? |
| 20:00 | <Domenic> | Krinkle: because async functions always return Promises, not CancelablePromises. |
| 20:00 | <annevk> | I'm sort of at the point where I would just like this to stop, but it seems that's unrealistic at least for a while longer... |
| 20:00 | <Domenic> | annevk: My opinion is they should stop copying their specs. |
| 20:00 | <Domenic> | s/their/the |
| 20:01 | <Domenic> | But dbaron basically blew that out of the water by asking for text saying "we plan to copy." |
| 20:01 | <annevk> | Yeah... I normally agree with dbaron but I'm torn on this one |
| 20:01 | <Domenic> | Whatever, they don't have enough editors to copy things anyway. I plan to ignore it. |
| 20:02 | <Domenic> | bbiab meeting |
| 20:02 | <annevk> | If they had done a decent job of copying in the past I would be more sympathetic, but most things just end up being a disaster |
| 20:02 | <annevk> | In fact, pretty sure that's all |
| 20:04 | <dbaron> | you're welcome to suggest alternatives |
| 20:04 | <dbaron> | I tend to think that asking the W3C to not have a spec for HTML probably won't go over very well, though. |
| 20:06 | <Domenic> | This is interesting https://stackoverflow.com/questions/32656594/domcontentloaded-blocks-page-loading |
| 20:11 | <annevk> | dbaron: well, it's true that it hasn't worked so far |
| 20:12 | <dbaron> | I meant "won't be well received" when I said "won't go over very well" |
| 20:13 | <MikeSmith> | the W3C organizationally cannot force the WG to publish a spec for HTML or anything else. Especially if the members of the WG don't support doing it |
| 20:14 | <MikeSmith> | the fact that the charter puts a spec in the scope of the WG does not mean that the group is obligated to actually publish that spec |
| 20:14 | <annevk> | dbaron: I guess I'm not really sure what to say, I've made many suggestions to Jeff over the years, but it usually comes down to no compromise from their side. I think I'm at the same point Hixie and Domenic are at, that caring is probably not really worth the effort. |
| 20:15 | <annevk> | Domenic: that follows pretty straightforwardly from the event loop section of the spec |
| 20:15 | <Domenic> | annevk: well, Chrome requiring two rAFs is at least strange. |
| 20:16 | <Domenic> | I guess update the rendering does happen after run the task though |
| 20:16 | <annevk> | Domenic: oh, I missed that |
| 20:18 | <Domenic> | Also, am I reading this right? The event loop section implies update the rendering more often than 60 times per second? |
| 20:18 | <MikeSmith> | annevk: "straightforwardly" there reminds of the job about the two mathematicians who argue about some point for hours and in the end one of them changes his position and says oh yeah it's "obvious" that what that other has been asserting is in fact right |
| 20:18 | <MikeSmith> | s/job/joke/ |
| 20:18 | <annevk> | MikeSmith: well, isn't it? :-P |
| 20:19 | <MikeSmith> | yes! 😆 (says the mathematician in me after 3 hours of reading) |
| 20:20 | <annevk> | Domenic: it allows for it, see 8.3 for why it's not required |
| 20:20 | <annevk> | Domenic: and that makes sense, e.g., I believe VR would like 120 Hz if not more |
| 20:21 | <Domenic> | Ah, missed 8.3 |
| 21:40 | <jamesr> | many displays are not 60Hz |
| 21:40 | <jamesr> | some are slower, some are faster |
| 21:41 | <jamesr> | when a browser actually renders stuff is pretty much 100% unspecified |
| 22:12 | <MikeSmith> | in GitHub lingo, what is the term for the repo from which a network of other repos have been forked? |
| 22:12 | <MikeSmith> | Source repo? |
| 22:12 | <MikeSmith> | Base? |
| 22:13 | <MikeSmith> | Upstream.. Original |
| 22:14 | <MikeSmith> | I guess I will just use "Origin" |
| 22:22 | <nox> | gsnedders: Did you take a look at https://github.com/html5lib/html5lib-tests/pull/69? |
| 23:56 | <Krinkle> | Hm.. DOMContentLoaded blocking paint is kind of neat in my opinion. It gives clients a chance to modify things without FOUC-y behaviour (e.g. hide elements based on cookies). However I assume this is only the case on small and/or unbuffered pages. Because iirc Chrome can (should) do first paint earlier if it received enough html content. |