| 03:36 | <MikeSmith> | https://www.w3.org/community/groups/proposed/#bgsync |
| 03:37 | <MikeSmith> | needs one more person "sponsor" creation of the group |
| 03:38 | <MikeSmith> | anybody know if Josh Karlin uses IRC |
| 05:41 | <MikeSmith> | Hixie: at https://html.spec.whatwg.org/multipage/forms.html#the-select-element you state a requirement that starts out with, "If a select element has a required attribute specified, does not have a multiple attribute specified, and has a display size of 1..." |
| 05:42 | <MikeSmith> | but if the multiple attribute isn't specified the only way to set the display size is by explicitly specifying the "size" attribute |
| 05:45 | <MikeSmith> | oops actually I meant the statement just after that sentence |
| 05:45 | <MikeSmith> | the one that says, "If a select element has a required attribute specified, does not have a multiple attribute specified, and has a display size of 1, then the select element must have a placeholder label option." |
| 05:47 | <MikeSmith> | it seems to me that could more precisely state the requirement explicitly mentioning the "size" attribute instead of indirectly stating it in terms of the abstract "display size" concept |
| 05:48 | <MikeSmith> | so it could be refined to say, "If a select element has a required attribute specified, does not have a multiple attribute specified, and does not have a "sizes" attribute with a value greater than 1, then the select element must have a placeholder label option. |
| 05:58 | <MikeSmith> | filed a bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=28150 |
| 09:27 | <annevk> | MikeSmith: see https://github.com/slightlyoff/BackgroundSync/issues/57 |
| 09:27 | MikeSmith | looks |
| 09:27 | <MikeSmith> | ah ok |
| 09:40 | <MikeSmith> | http://robert.ocallahan.org/2015/03/debugging-gecko-with-reverse-execution.html |
| 09:40 | <MikeSmith> | wow |
| 10:48 | <annevk> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/607#issuecomment-76349858 ping |
| 11:04 | <MikeSmith> | hsivonen: would be good if you could weigh in on https://github.com/validator/validator/pull/48 when have time (relatively minor thing) |
| 11:33 | <darobin> | bah, krijnhoetmer.nl is down! |
| 11:45 | <MikeSmith> | I want my money back |
| 11:45 | <MikeSmith> | darobin: http://logs.glob.uno/?c=freenode%23whatwg remains a live |
| 11:46 | <darobin> | MikeSmith: thanks! I didn't know that one |
| 12:28 | <beverloo> | annevk, cool, thanks |
| 12:28 | <beverloo> | I'll sync the bikeshed version afterwards |
| 12:28 | <annevk> | Ah yeah, forgot about that |
| 12:30 | <beverloo> | no worries, I'd rather not block the spec on that |
| 14:37 | <JakeA> | annevk: on leave at the moment. Not sure I understand the redirect thing. Would it solve the css use case? Where there are redirects that aren't visible to me but I want URLs to be relative to the final url |
| 14:38 | <annevk> | JakeA: why would it not be visible to you though? |
| 14:38 | <annevk> | JakeA: event.request.url != response.url in that case, no? |
| 14:38 | <JakeA> | Correct |
| 14:39 | <JakeA> | annevk: is it safe to give visibility to response.url? I thought there were security issues there |
| 14:40 | <JakeA> | Or was it just intermediate redirect URLs? |
| 14:40 | <annevk> | JakeA: when it's not a redirect it's fine |
| 14:40 | <annevk> | JakeA: and already exposed by XMLHttpRequest |
| 14:40 | <annevk> | (also required if you want to handle e.g. base URL stuff yourself in case of JSON or some such) |
| 14:43 | <JakeA> | annevk: if the SW provides a redirect, does the SW get another fetch event? (I think it's only does that for navigations, but still half asleep) |
| 14:43 | <annevk> | JakeA: it does |
| 14:43 | <annevk> | well should I think |
| 14:43 | <JakeA> | annevk: just navigations or all requests? |
| 14:44 | <annevk> | all |
| 14:44 | <annevk> | see in https://fetch.spec.whatwg.org/#http-fetch step 2 you get the redirect |
| 14:44 | <annevk> | then in step 4 it's handled |
| 14:44 | <annevk> | which causes re-entry |
| 14:44 | <annevk> | so it's all good |
| 14:53 | <JakeA> | annevk: so with the CSS example, id check if the response url is different & instead issue a redirect? I don't like the extra network request or cache lookup that would create. |
| 14:57 | <JakeA> | annevk: what was wrong with useFinalURL? I agree it's a bit ugly, but it works |
| 14:59 | <annevk> | JakeA: less unnecessary primitives |
| 14:59 | <annevk> | JakeA: and yes, redirects are always good to avoid, which is why you should update your code if it creates them... |
| 15:10 | <JakeA> | annevk: they're not always in your control. Check out the font css request at talky.io, the redirect there is the font foundry doing dumb anti-piracy checks. I guess it's not a problem in this exact case because the fonts are datauris |
| 16:27 | <annevk> | JakeA: perhaps we should call it overrideRequestURL |
| 16:27 | <annevk> | JakeA: I'm still a bit skeptic with regards to the savings I have to say |
| 16:27 | <annevk> | wanderview: ^^ |
| 16:28 | <wanderview> | annevk: are you asking me to bikeshed a name? :-) |
| 16:28 | <wanderview> | or is this about forcing the urls to match in the cache |
| 16:28 | <annevk> | please |
| 16:29 | <wanderview> | annevk: I guess I don't really have an opinion other than making it clear its not actually a url... I like starting boolean attributes with "Is" like "IsFinalURL" |
| 16:34 | <annevk> | wanderview: overrideRequestURL has that covered, no? |
| 16:34 | <wanderview> | annevk: what object is this on? |
| 16:34 | <annevk> | wanderview: on response |
| 16:34 | <annevk> | wanderview: as a better name for useFinalURL |
| 16:35 | <annevk> | wanderview: the default is that request's url wins |
| 16:35 | <wanderview> | annevk: it overrides in respondWith()? would it override in Cache as well? |
| 16:35 | <annevk> | wanderview: I'm not sure how it makes sense in the cache |
| 16:35 | <annevk> | yeah hmm |
| 16:35 | <annevk> | JakeA: ^^ |
| 16:35 | <wanderview> | annevk: sorry... in a meeting |
| 16:36 | <annevk> | JakeA: given the other APIs that use Request/Response it does seem better to decouple it somehow |
| 16:36 | <annevk> | JakeA: either require redirects or have a different respondWith |
| 16:36 | <annevk> | JakeA: e.g. repondWith(response, {overrideRequestURL: true}) |
| 16:37 | <JakeA> | annevk: ohh, I like that. I think that's what we were looking for |
| 17:11 | <wanderview> | annevk: does this mean the bool would be removed from Response? |
| 17:14 | <wanderview> | annevk: or it moves to an internal, not-exposed-to-content type flag? |
| 17:16 | <annevk> | wanderview: there's two ways to implement it and the spec will prolly use the flag |
| 17:16 | <wanderview> | annevk: just curious if I should tell people not to write the code to persist the flag to cache |
| 17:16 | <annevk> | wanderview: one way is that SW returns a response and a flag to Fetch, that's the nice way, the other way is that SW annotates response and then returns it, which is the easy way given how Fetch fits together |
| 17:16 | <annevk> | wanderview: yeah, that's not needed with this approach |
| 17:16 | <annevk> | wanderview: unless I'm missing something |
| 17:17 | <wanderview> | good |
| 17:17 | <wanderview> | thanks |
| 17:17 | <wanderview> | I guess I'll wait for the spec text to change before closing the bug |
| 17:17 | <annevk> | wanderview: it seems JakeA agrees so go ahead... |
| 17:18 | <annevk> | wanderview: I can remove the JS property pretty quickly, working on something else now |
| 17:18 | <wanderview> | annevk: k... no rush |
| 17:22 | <annevk> | wanderview: mkay |
| 17:23 | <Krinkle> | Hm.. I'm curious if there's a chance of re-fixing innerHTML under a different name. It seems browsers are resisting spec compliance with regards to newlines for back-compat. We did it with innerText>textContent. Perhaps an htmlContent is in order? |
| 17:23 | <Ms2ger> | No |
| 17:24 | <Krinkle> | e.g. https://code.google.com/p/chromium/issues/detail?id=174829 |
| 17:24 | <Krinkle> | If browsers stay together and resist, the spec might as well be changed back |
| 17:24 | <Ms2ger> | HTML serialization just isn't a priority |
| 17:25 | <Ms2ger> | If you want to get browsers fixed, fixing them yourself is a lot more likely to work than trying to pitch a new redundant feature |
| 17:25 | <Krinkle> | Yeah, we got that after spending 2 years building VisualEditor. Which relies on Content Editable, but due to its instabilities and quirks, have to fallback to innerHTML a fair bit. |
| 17:26 | <Krinkle> | Plain content editable works for one's moms cooking blog, but not Wikipedia. |
| 17:27 | <Krinkle> | (as long as the mom uses a modern browser and write LTR and in Latin characters and uses no special styling or foreign elements.) |
| 17:31 | <MikeSmith> | Krinkle: it sounds like the problem you really want fixed is not with innerHTML but with contenteditable |
| 17:31 | <Krinkle> | MikeSmith: Absolutely. |
| 17:31 | <MikeSmith> | I mean with contenteditable in the abstract |
| 17:31 | <MikeSmith> | in terms of what it rightly should be |
| 17:31 | <MikeSmith> | so you know there's active work going on there |
| 17:31 | <MikeSmith> | I think we talked about that here before |
| 17:32 | <Krinkle> | MikeSmith: We considered going the google-docs route of re-implementing half a browser in JavaScript (e.g. the typical "your cursor is a blinking span"). Which involves having to re-implement text overflow, selection highlights etc. We actually went this route and came quite far. |
| 17:32 | <Krinkle> | But for the benefit of native support for spell check, and IMEs and loads of other things as well as mobile support, we re-started and went with CE. |
| 17:33 | <Krinkle> | Although heavily locked down as it can't be trusted for anything other than a canvas for output and receiving input events. So we have a separate linear data model, and a detached second DOM tree. That is synced with the Content Editable surface. |
| 17:33 | <Krinkle> | It's still in beta, but can be seen here for example: https://www.mediawiki.org/wiki/VisualEditor:Basic_example_worksheet?veaction=edit |
| 17:34 | <Krinkle> | There are a few tangible direct issues in browser we worked around and documented, but the broader issues with CE we never cared to document and just worked around. ITtd be cool to document some of that. |
| 17:35 | <Krinkle> | It seems like CE was one of those features were the spec (as it was 5 years ago anyway) has not received much input based on real-world usage. |
| 17:35 | <Krinkle> | I heard recently there was a call for attention but lost track of that. |
| 17:43 | <MikeSmith> | Krinkle: > But for the benefit of native support for spell check, and IMEs and loads of other things as well as mobile support, we re-started and went with CE. |
| 17:43 | <MikeSmith> | yeah |
| 17:44 | MikeSmith | looks at https://www.mediawiki.org/wiki/VisualEditor:Basic_example_worksheet?veaction=edit |
| 17:45 | <MikeSmith> | this is nice |
| 17:45 | <terinjokes> | going to assume fetch's Body.prototype.blob() is never supposed to throw an exception? |
| 17:45 | <MikeSmith> | Krinkle: you really should get involved with the current Editing work |
| 17:45 | <MikeSmith> | Krinkle: didn't I point you at this stuff the other day? https://github.com/w3c/editing-explainer |
| 17:46 | <MikeSmith> | http://w3c.github.io/editing-explainer/tf-charter.html |
| 17:51 | <Krinkle> | MikeSmith: Aye, I'm spread thin as it is. I'll definitely pass it on this time though. Writing up an internal mail now |
| 17:51 | <Krinkle> | MikeSmith: Are you involved with them? |
| 17:51 | <Krinkle> | that topic/group in particular I mean |
| 18:11 | <MikeSmith> | Krinkle: no I'm not personally |
| 18:11 | <MikeSmith> | not involved with the work on that |
| 18:15 | <annevk> | terinjokes: why would you assume that? |
| 18:15 | <terinjokes> | annevk: it seems very strange for that method to throw, since it could just reject the Promise it should be returning |
| 18:16 | <terinjokes> | but i could be wrong, since the spec doesn't say what to do, which is why i'm asking |
| 18:18 | <annevk> | terinjokes: oh I thought by throw you meant reject the promise |
| 18:18 | <annevk> | terinjokes: which it does |
| 18:18 | <annevk> | terinjokes: as the spec states |
| 18:19 | <terinjokes> | annevk: it only says "Resolve p with a Blob whose contesnts are bytes and type is MIME type." |
| 18:20 | <annevk> | terinjokes: which specification are you reading |
| 18:20 | <terinjokes> | fetch.spec.whatwg.org |
| 18:20 | <annevk> | terinjokes: doesn't step 2 of the algorithm reject? |
| 18:21 | <terinjokes> | only if you used the response already |
| 18:21 | <terinjokes> | i'm in shim land, not in browser land |
| 18:22 | <annevk> | terinjokes: well there's nothing more to it than that |
| 18:23 | <terinjokes> | in i sometime don't have a good way to go from the body type i do have to the body type requested |
| 18:27 | <annevk> | terinjokes: for FormData I guess there are some pieces missing |
| 18:27 | <terinjokes> | FormData -> Blob and FormData -> text |
| 18:28 | <terinjokes> | it can fake it if required |
| 18:33 | <Krinkle> | MikeSmith: Thx, I filed https://phabricator.wikimedia.org/T91781. Also, a more isolated demo: https://wikimedia.github.io/VisualEditor/ |
| 18:33 | <Krinkle> | Without the intergration of the PHP Wikipedia backend. |
| 23:07 | <MikeSmith> | hey Krinkle, looking now |
| 23:07 | <MikeSmith> | me just woke up |
| 23:08 | <Krinkle> | MikeSmith: Timezone? |
| 23:08 | <Krinkle> | Australia? |
| 23:13 | <MikeSmith> | Krinkle: Tokyo |
| 23:14 | <MikeSmith> | Krinkle: wait I can't (re)use my wikipedia account name for a mediawiki.org wiki account? |
| 23:14 | <MikeSmith> | was going to Cc myself on that bug |
| 23:15 | <Krinkle> | MikeSmith: Sure thing. Wikipedia.org accounts are login.wikimedia.org, which is what www.mediawiki.org uses as well |
| 23:15 | <Krinkle> | Should be all connected |
| 23:15 | <MikeSmith> | oh ok |
| 23:15 | <MikeSmith> | cool |
| 23:15 | <Krinkle> | It should even log you in automatically by just visiting mediawiki.org |
| 23:15 | <Krinkle> | logging into Wikipedia sets a central cookie that mediawiki.org routes via as well. |
| 23:16 | <Krinkle> | Then you can OAuth from that to log in to Phabricator (only releases a few weeks ago actually :D) |
| 23:16 | <Krinkle> | We used to have Bugzilla with its own user db |
| 23:16 | <MikeSmith> | nice |
| 23:16 | <MikeSmith> | yeah now I'm authenticated |
| 23:38 | <MikeSmith> | Krinkle: "It would save us an unmeasurable amount of technical debt, performance and interface freedom if we can get some of our use cases to be considered in the creation of a future web standard on this." |
| 23:39 | <Krinkle> | Too much? :P |
| 23:39 | <MikeSmith> | no, it's perfect |
| 23:39 | <MikeSmith> | that's pretty much the sales pitch I always give people for why they should invest time working with others on standards |
| 23:39 | <Krinkle> | You should see some of the hacks we have. Not specifically for CE, but just in general, getting things native just makes so much sense. |
| 23:40 | <MikeSmith> | oh I'd not be surprised |
| 23:40 | <Krinkle> | MikeSmith: Having said that, I heard today a colleague of mine was already aware of this task force but thinks it's not going in the direction we want. |
| 23:40 | <MikeSmith> | I'm sure some of it is pretty gruesome |
| 23:40 | <MikeSmith> | oh |
| 23:41 | <Krinkle> | But I hope that even if we can't control the overal direction, just being around will at least give us a voice for the use cases and bugs. Even if it's not implemented the way we want, having it work a differnet way is better than not having it work at all. |
| 23:41 | <MikeSmith> | well, getting involved makes it possible to make some course correction happen to take it in the direction you want |
| 23:41 | <MikeSmith> | yeah |
| 23:41 | <MikeSmith> | bingo |
| 23:41 | <MikeSmith> | well put |
| 23:41 | <MikeSmith> | that also is true for everybody involved |
| 23:42 | <Krinkle> | MikeSmith: I'm not familiar with the concept of a w3 "task force" however. It seems they don't always get somewhere. What's the position of W3 and Whatwg? Or a better question in its place. Like.. what can I expect? |
| 23:43 | <Krinkle> | I've seen whatwg create new specs (like Fetch) and quite happy with the process. |
| 23:43 | <MikeSmith> | 🎵 you can't always get what you want, but if you try sometime you just mind find... |
| 23:43 | <zewt> | (sometimes, having something not work at all is better than something that half works; half-solutions can stop people from working on real solutions) |
| 23:43 | <Krinkle> | I'm not sure if this will get into a similar process after this, or whether that already started and its now on hiatus as a task force? Basically, how do task forces fit in the bigger picture? |
| 23:44 | <MikeSmith> | the "task force" thing is just a label |
| 23:44 | <MikeSmith> | it's just people |
| 23:44 | <MikeSmith> | it's *always* just people |
| 23:44 | <MikeSmith> | it's sometimes the same people under different labels |
| 23:44 | <zewt> | MikeSmith: heh, it's always annoying when people post to mailing lists with a company name instead of their name |
| 23:45 | <zewt> | (or anywhere) |
| 23:45 | <MikeSmith> | the whatwg vs w3c is often not really relevant, because there's people with a foot in both places. always has been |
| 23:45 | <Krinkle> | zewt: Good point. |
| 23:45 | <MikeSmith> | I was involved with whatwg before I starting working at w3c |
| 23:46 | <MikeSmith> | and in terms of who I do most of my communication with, I talk as much with Hixie and annevk as I do with any colleagues at w3c |
| 23:46 | <MikeSmith> | zewt: yeah |
| 23:47 | <MikeSmith> | zewt: and 100% true too what you said about "sometimes, having something not work at all is better than something that half works; half-solutions can stop people from working on real solutions" |
| 23:47 | <MikeSmith> | so let's not yet again do something half-assed here |
| 23:47 | <MikeSmith> | I think everybody agrees about that, for the Editing stuff |
| 23:47 | <zewt> | (just a general statement, I don't know the specific thing you guys are talking about) |
| 23:48 | <Krinkle> | Yeah, I've seen annevk active on both sides for as long as I can remember. |
| 23:48 | <MikeSmith> | well, contenteditable as it exists today is a good example of a half solution |
| 23:48 | <MikeSmith> | though I guess a lot of people would say it's not even half |
| 23:49 | <MikeSmith> | but it is sorta worse than having nothing at all |
| 23:49 | <Krinkle> | Yeah, believe me, we were not at all attracted to contenteditable at all. But despite all the pains, we went *back* to it. |
| 23:49 | <MikeSmith> | yep |
| 23:49 | <MikeSmith> | like Michael Corleone |
| 23:49 | <Krinkle> | We had our own Google Docs-like system running for a while and it was great. While it's a bigger curve to get anything, after that you have complete control. Whereas with CE, it's a quick start to get basics and then that's the end of it. |
| 23:51 | <zewt> | (the next time I hit shift-delete to cut text to the clipboard and it deletes it without copying because of hardcoded shortcuts by someone who always hits control-x and has never heard of shift-delete -> WW3) |
| 23:51 | <Krinkle> | We had to change our fundamental model of how to represent a character numerous times to support additional languages and scripts. code units, grapheme clusters, and the back again. |
| 23:54 | <MikeSmith> | Krinkle: interesting, about the character model |
| 23:54 | <Krinkle> | MikeSmith: Wikimedia also contributes to Unicode CLDR upstream as our language support is a superset of what the standards define. |
| 23:54 | <Krinkle> | It's a fun "problem" to have. |
| 23:55 | <Krinkle> | our community cares a lot. And many of them are one of few that even represent their language online with the technical know-how to make it work in their language. |
| 23:55 | <MikeSmith> | Krinkle: I bet Richard Ishida from the W3C would love to hear more details about the problems you ran into and how you solved them |
| 23:55 | <MikeSmith> | Richard "Mr. Internationalization" Ishida |
| 23:55 | <MikeSmith> | r12a |
| 23:55 | <Krinkle> | Hehe |
| 23:56 | <Krinkle> | I'm mostly echo-ing what I've learned. I imagine he'll want to talk to David Chan and Roan Kattouw from our team. |
| 23:56 | <Krinkle> | Who are our language expert and data model expert respectively. |
| 23:56 | <MikeSmith> | “many of them are one of few that even represent their language online with the technical know-how to make it work in their language” is really important. You guys are serving a real need there |
| 23:57 | <Krinkle> | Don't have the luxury of off the shelve options often. It's simply never been considered. Especially not open-source. |
| 23:58 | <Krinkle> | The one thing that we were able to use and has been a great help is CSSJanus. An abandoned Google project to flip stylesheets. Before that we manually ported stylesheets, usually meaning that that part of the word got software updates months later. |
| 23:59 | <Krinkle> | Since then forked and renewed by us and volunteers. Now same-day delivery to both and most designers and developers rarely even know it, but everything is mirrored seemlessly. |
| 23:59 | <MikeSmith> | we have a long way to go on thisーon giving all the world's writing systems the ability be used as easily on the Web as the ones we all use ourselves and take for granted |
| 23:59 | <MikeSmith> | I've not heard of CSSJanus. |
| 23:59 | <MikeSmith> | oh wow |