| 05:53 | <zcorpan> | mathiasbynens: did you have a script to normalize scrollTop for html/body without browser sniffing? |
| 05:58 | <matijs> | zcorpan: did you mean https://gist.github.com/dperini/ac3d921d6a08f10fd10e ? |
| 06:00 | <zcorpan> | matijs: looks like what i wanted at least. thanks |
| 06:57 | <estellevw__> | i thought input type=“datetime” was pulled from the spec, but I see it here: https://html.spec.whatwg.org/multipage/forms.html#date-and-time-state-(type=datetime). |
| 06:58 | <mathiasbynens> | zcorpan: https://github.com/mathiasbynens/jquery-smooth-scrolling/blob/fba27f86a6b3a8788d1c1b3aa94a951eb9f087dc/jquery.smoothscroll.js#L4-L21 (jQuery but you get the idea) |
| 06:58 | <mathiasbynens> | matijs: wow, dperini’s is much nicer |
| 06:58 | <estellevw__> | I thought it was removed over a year ago. anyone know the status? |
| 07:00 | <mathiasbynens> | difference: mine is an actual feature test; dperini’s is based on weak inference |
| 07:00 | <zcorpan> | matijs: mathiasbynens: https://github.com/operasoftware/devopera/issues/242 |
| 07:59 | <annevk> | estellevw__: in favor of only having datetime-local? |
| 07:59 | annevk | can't find a bug that has datetime in the description |
| 08:04 | <estellevw__> | I can only find discussions on “non-official” sites that it has been dropped, and browsers don’t support it, but don’t know if WHATWG is or has actively discussed it |
| 08:28 | <annevk> | estellevw__: there has been mailing list discussion about the merits of datetime vs datatime-local |
| 08:28 | <annevk> | estellevw__: and that ideally datetime-local would've been named datetime |
| 08:29 | <annevk> | have been* |
| 08:30 | <estellevw__> | annevk: I believe that was over a year ago. Not sure what the process is for removing stuff from the spec. Trying to determine if it’s a done deal, or it is still being considered. |
| 08:37 | <annevk> | estellevw__: https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F |
| 08:37 | <MikeSmith> | estellevw__: https://lists.w3.org/Archives/Public/public-html/2014Feb/0003.html |
| 08:37 | <estellevw__> | thanks. |
| 08:38 | <estellevw__> | haha, yes, exactly a year ago. |
| 08:38 | <MikeSmith> | and https://www.w3.org/Bugs/Public/show_bug.cgi?id=16959 |
| 08:39 | <MikeSmith> | and https://www.w3.org/Bugs/Public/show_bug.cgi?id=17855 |
| 08:39 | <annevk> | "It was noted that at the F2F that this feature is at risk for 5.0." and it was never resolved? |
| 08:40 | <annevk> | MikeSmith: that latter bug seems mostly about terminology, not about changing controls |
| 08:40 | <MikeSmith> | right, it's a different issue |
| 08:41 | <MikeSmith> | ...I realize now |
| 08:41 | MikeSmith | hunts some more |
| 08:42 | <MikeSmith> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=16960 is the one I was trying to find, I think |
| 08:42 | <MikeSmith> | corresponding whatwg bug is https://www.w3.org/Bugs/Public/show_bug.cgi?id=17856 |
| 08:43 | <MikeSmith> | christ |
| 08:43 | <annevk> | Which defers to a mailing list thread :-) |
| 08:43 | <MikeSmith> | yeah not sure that's it either |
| 08:43 | <MikeSmith> | too many bugs |
| 08:43 | <MikeSmith> | https://github.com/w3c/html/commit/3e5df1ee1aebed37571a23c9b62adc74a92a04b9 |
| 08:43 | <estellevw__> | month and week are also both in the living standards and 5.1 but not in 5.0, but i see no discussion on those being at risk |
| 08:43 | <MikeSmith> | Removing input type="datetime-local" |
| 08:44 | <annevk> | https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0367.html and onwards |
| 08:44 | <annevk> | Wait they removed the useful one? |
| 08:44 | <estellevw__> | hmm, browsers have implement datetime-local but not datetime |
| 08:44 | <annevk> | lol |
| 08:45 | <annevk> | Typical committee decision |
| 08:45 | <MikeSmith> | estellevw__: https://github.com/w3c/html/commit/6ef6eaaad792247c89b2e231e9100d5ff413ad90 "removed input types datetime, datetime-local, week, month" |
| 08:46 | <estellevw__> | thanks. |
| 08:46 | <estellevw__> | https://miketaylr.com/code/input-type-attr.html shows datetime is NOT supported, but datetime-local is |
| 08:47 | <estellevw__> | in blink |
| 08:48 | <MikeSmith> | I think I may have actually been the one who recommended that we drop datetime, datetime-local, week, month from the W3C spec at that time |
| 08:48 | <MikeSmith> | I don't remember |
| 08:48 | <MikeSmith> | maybe darobin will remember better than me, if you want to ask him once he's around |
| 08:50 | <estellevw__> | will do. Thanks. My thought is some of those may have been dropped from 5 and left in 5.1 because they still needed to be better flushed out, like ::selection in CSS being moved from the selectors spec so that the spec can move forward. |
| 08:50 | <estellevw__> | Would like to know if I assuming incorrectly thought |
| 08:50 | <estellevw__> | thanks. |
| 08:59 | <MikeSmith> | estellevw__: I suggest telling your readers to consider the W3C HTML5 Rec just be a snapshot of a subset of what the state of HTML was in October 2014 |
| 09:00 | <MikeSmith> | I think it'd be misleading to lead them to believe they can work from the HTML5 Rec alone as a guide when authoring documents |
| 09:01 | <MikeSmith> | for one thing, even the W3C validator doesn't restrict itself to only what's included in the HTML5 Rec |
| 09:02 | <MikeSmith> | e.g., the validator still considers datetime, datetime-local, week, month to be valid |
| 09:03 | <MikeSmith> | and there was never any decision in the HTML WG to drop them from HTML5 itself. Instead there was just an editorial decision to leave them out of the HTML5 Rec snapshot. |
| 09:05 | <MikeSmith> | as one of the main people responsible for creating all that confusion, I'd be happy to try to help come up with some wording that would hopefully make it all less confusing for readers |
| 09:07 | <MikeSmith> | estellevw__: I think http://www.w3.org/html/landscape/ is a still a good document to refer to for clarification about what the differences are, and a good document to point readers to |
| 09:07 | <MikeSmith> | although I realize it's also not complete |
| 09:08 | <MikeSmith> | hmm I think it's closer than I realized though |
| 09:08 | <MikeSmith> | e.g.,: |
| 09:08 | <MikeSmith> | No input types datetime, datetime-local, week, month in W3C HTML 5.0 (user agent) |
| 09:08 | <MikeSmith> | Insufficient implementation experience at this point. |
| 09:08 | <MikeSmith> | ... is listed there |
| 09:08 | <MikeSmith> | "Insufficient implementation experience at this point." |
| 09:09 | <MikeSmith> | I think Robin did a great job at putting that together |
| 15:12 | <JonathanNeal> | https://dom.spec.whatwg.org/#mutation-method-macro — could this macro ever be exposed as a public method? Would there be a proper name or place for this macro, like ParentNode.mutation? |
| 15:18 | <annevk> | JonathanNeal: not sure we should expose that |
| 15:18 | <annevk> | TabAtkins: any update on bikeshedding DOM? |
| 15:31 | <JonathanNeal> | annevk: We have a set of DOM polyfills that rely on the mutation macro. Inspired by the change from ParentNode.replace to ParentNode.replaceWith, we plan to separate each of the polyfills and let them reference a separate mutation method. Keeping that method private is not a problem, but I want the name to be a semantic as possible. So, I’m trying to |
| 15:31 | <JonathanNeal> | imagine what its name might be were the method public. |
| 15:42 | <annevk> | JonathanNeal: I would imagine it to be a symbol if it were public |
| 15:47 | <caitp> | they might need to target super-legacy browsers with no concept of symbols, though |
| 15:49 | <JonathanNeal> | annevk, caitp: indeed. |
| 15:49 | <annevk> | JonathanNeal: if you keep it private it doesn't seem to matter much |
| 15:50 | <annevk> | JonathanNeal: mutationMacro and just rename it if the DOM changes? |
| 15:50 | <annevk> | JonathanNeal: mutaitonMacro might not be super semantic either, all it's doing is pre-processing the arguments passed |
| 15:53 | <safinaskar> | is living html turing complete? |
| 15:54 | <annevk> | safinaskar: HTML's parser is, yes, due to </script> |
| 15:55 | <safinaskar> | annevk: you mean js? |
| 16:09 | <safinaskar> | okey, what is we disallow inclusion of other languages? is html turing complete? |
| 16:16 | <safinaskar> | :( |
| 16:21 | <caitp> | i mean |
| 16:21 | <caitp> | if you don't include document.write |
| 16:21 | <caitp> | i'm not sure you could call html turing complete |
| 16:23 | <jgraham> | Hmm, how does </script> make the parser turing complete? |
| 16:23 | <caitp> | maybe with html imports you could theoretically create some kind of turing complete program using imports for flow control |
| 16:23 | <caitp> | but you wouldn't really have any other flow control operators, I guess? |
| 16:23 | <jgraham> | Yeah, I'm struggling to see how HTML could be turing complete without imports |
| 16:25 | <jgraham> | (I'm not convinced it is with imports, but it doesn't seem obviously impossible) |
| 16:25 | <jgraham> | Clearly as soon as you can run js, it *is* turning complete |
| 16:25 | <jgraham> | *Turing |
| 16:26 | <caitp> | i think that's what the script tag thing was all about |
| 16:27 | <caitp> | you could write a programme with just <script>document.write()</script> |
| 16:27 | <caitp> | it might not be a very useful programme, but hey |
| 16:30 | <albinowax> | I think CSS comes close |
| 16:36 | <JonathanNeal> | the problem with prollyfills is catching up with us: https://github.com/Financial-Times/polyfill-service/issues/284 |
| 16:36 | <caitp> | http://jsbin.com/cuzatanufa/1/edit?html,output well that was pretty much the best i could come up with |
| 16:37 | <caitp> | I didn't know document.write limited recursion |
| 16:37 | <caitp> | apparently it does |
| 16:39 | <Domenic> | JonathanNeal: seems like your bad for not following semver |
| 16:39 | <Domenic> | JonathanNeal: or rather, financial times's bad |
| 16:48 | <JonathanNeal> | Domenic: I forwarded the recommendation. Thanks for raising the macrotask/microtask issue as well. |
| 16:49 | <annevk> | https://twitter.com/mulambda/status/564824426756472832 \o/ |
| 16:49 | <JonathanNeal> | It relates to a need we have for private methods, such as mutationMacro and whatever-handles-microtasks. |
| 18:11 | <wanderview> | JakeA: I seem to recall a github issue where we were talking about if Cache.add() or Cache.put() would continue even after the SW shuts down... maybe for background sync type stuff... do you remember that? I can't find the issue |
| 18:12 | <wanderview> | JakeA: I just wanted to note that we're probably going to cancel network requests when the SW exits (although we will probably try to keep the SW alive until all the network requests are complete) |
| 19:28 | <JonathanNeal> | Is there any way to simulate the ParentNode object? It equates Document, DocumentFragment, and Element. |
| 19:29 | <caitp> | what do you mean by simulate it |
| 19:33 | <Domenic> | [Document, DocumentFragment, Element].forEach(...) |
| 19:34 | <jsbell> | JonathanNeal: polyfilling the newish DOM functions? https://github.com/inexorabletash/polyfill/blob/master/experimental/dom.js |
| 19:37 | <JonathanNeal> | They were polyfilled long ago, but I’m trying to improve upon then. I want to make each polyfill modular so changing replace with replaceWith doesn’t affect the other methods. It’s also nicer when Chrome requires less methods than all other browsers. |
| 19:37 | <JonathanNeal> | ^ jsbell |
| 19:37 | <JonathanNeal> | Domenic, ok, might as well Document.prototype.thing = DocumentFragment.prototype.thing = Element.prototype.thing then |
| 19:38 | <Domenic> | JonathanNeal: no, that wouldn't be spec compliant, they shouldn't be === |
| 19:40 | <caitp> | as soon as time machines capable of travelling backwards are a thing, someone is going to fix DOM |
| 19:40 | <JonathanNeal> | Domenic: really? Even though they’re all ParentNode? |
| 19:40 | <caitp> | probably not before that, though |
| 19:49 | <Domenic> | JonathanNeal: yes |
| 19:50 | <JonathanNeal> | That is wild. Cause, like, HTMLElement.prototype.remove === Element.prototype.remove |
| 19:51 | <caitp> | but not Document.prototype.remove or DocumentFragment.prototype.remove |
| 19:52 | <JonathanNeal> | Wild. |
| 19:52 | <JonathanNeal> | What is the reason the inheritency doesn’t cross between Document and Element? |
| 19:53 | <caitp> | element does not extend document or vice versa, they're different node types |
| 19:53 | <JonathanNeal> | So that, in theory, ParentNode.prototype.remove === Element.prototype.remove && ParentNode.prototype.remove === Document.prototype.remove && Document.prototype.remove !== Element.prototype.remove |
| 19:54 | <caitp> | well ParentNode isn't a real thing, it's like a macro, its definition gets copied into the interfaces that implement it |
| 19:54 | <caitp> | so when you look at it that way it makes sense |
| 19:55 | <caitp> | it's dumb, but it makes sense |
| 19:55 | <JonathanNeal> | Thanks, caitp. It is dumb, but I’ll do my best to follow it. |
| 20:02 | <JonathanNeal> | Unrelated. What is the name of the thing that cues microtasks in JavaScript? It’s used by MutationObserver and Promise. |
| 20:02 | <JonathanNeal> | In Node, it’s process.nextTick. |
| 20:05 | <jsbell> | JonathanNeal: There's no standardized entry point from script |
| 20:06 | <jsbell> | Some Promise polyfills used MutationObserver :P |
| 20:08 | <JonathanNeal> | Yea. I’m creating a private method to handle microtasks, but I don’t even know what the method or macro or whatever-it-is is called. I might just call it nextTick and use it like nextTick(callback). |
| 20:09 | <Domenic> | it's called enqueueMicrotask |
| 20:10 | <JonathanNeal> | Domenic++ yeaaaaa |
| 20:10 | <Domenic> | there's been some attempt at making "asap" the slang name. Hasn't caught on that much. |
| 20:15 | <hober> | nowish() |
| 20:15 | <hober> | rsn() |
| 20:18 | <JonathanNeal> | Is enqueueMicrotask a private method or a macro or what? |
| 20:20 | <Domenic> | it's a spec-level "abstract operation" |
| 20:20 | <Domenic> | although HTML doesn't call them that or use function-call notation |
| 20:21 | <Domenic> | It's certainly not a method of anything |
| 20:26 | <JonathanNeal> | Domenic: for the purpose of polyfills, it would be best experienced as a method. Thanks, I’ve applied your feedback to my recommendation in FT’s polyfill-service. |
| 20:26 | <Domenic> | JonathanNeal: what object is your polyfill making it a method on? |
| 20:28 | <annevk> | JonathanNeal: what is dump about a mixin? |
| 20:28 | <annevk> | JonathanNeal: if you think we should do something else, please do file a bug |
| 20:28 | <JonathanNeal> | annevk: dump about a mixin? I don’t follow. |
| 20:29 | <annevk> | JonathanNeal: above you called the ParentNode design dumb |
| 20:30 | <caitp> | technically, I called it dumb, and it is --- it's like half-baked trait support without being built on a feature of the language |
| 20:30 | <caitp> | it's not really exposed to the language, so you just have to know a bunch of arbitrary crap to deal with it |
| 20:31 | <caitp> | which is objectively terrible, I mean come on, this isn't news to anybody |
| 20:31 | <caitp> | but you know that filing a bug on it wouldn't be actionable |
| 20:31 | <caitp> | none of this can ever really change |
| 20:31 | <caitp> | so, it's just the way it is |
| 20:33 | <annevk> | There's no native support and the IDL looks a bit clunky, but copying over prototypes is done by JavaScript itself and seems perfectly decent |
| 20:33 | <annevk> | So, I guess I disagree |
| 20:33 | <caitp> | here's the thing |
| 20:33 | <caitp> | suppose your api needs to deal with anything implementing this trait, what do you do? |
| 20:33 | <Domenic> | Yeah, I think objectively terrible is a strong overstatement |
| 20:33 | <caitp> | you're looking at node types, or the constructor property |
| 20:33 | <caitp> | or instanceof |
| 20:34 | <caitp> | and this means you're dealing with things that don't really matter |
| 20:34 | <caitp> | best case would be if (!this implements Trait) throw TypeError(); |
| 20:34 | <caitp> | or something |
| 20:35 | <caitp> | but instead you have to dig up idl and figure out everything that implements the trait, and how to identify those things |
| 20:35 | <caitp> | that's all kind of awful, like it's not a good scene, it's just that everyone has been stuck with it for so long that it will probably never become not-bad |
| 20:37 | <annevk> | caitp: it's not a trait, it's a mixin |
| 20:37 | <caitp> | it's basically a trait |
| 20:37 | <caitp> | it would be better if it were a trait |
| 20:37 | <JonathanNeal> | annevk: i concurred with caitp that it is dumb — but what more can I do but sigh? If it already works this way, “fixing” it would involve changing aka breaking the way it worked before, so would filing a bug be anything more than futile? |
| 20:37 | <annevk> | well you can keep calling it that, but I don't think there's anything that supports that |
| 20:38 | <caitp> | the only difference between a trait and a mixin, is that you can tell if something implements a trait |
| 20:38 | <annevk> | sure |
| 20:38 | <caitp> | which is simpler, and more scalable |
| 20:38 | <annevk> | IDL does not have traits, just mixins |
| 20:38 | <caitp> | thus objectively better and more correct |
| 20:39 | <annevk> | I don't really see how it would be simpler |
| 20:40 | <annevk> | JonathanNeal: I don't think much of this is implemented so dunno |
| 20:40 | <caitp> | traits -> you have a single thing that you need to be aware of: "does X implement T or not" |
| 20:40 | <caitp> | mixins -> you have N things you need to be aware of |
| 20:40 | <JonathanNeal> | Domenic: re: what object is your polyfill making it a method on? No object, it would be a private method within a closure, exposed only to polyfills. |
| 20:40 | <Domenic> | JonathanNeal: all methods are on objects... do you mean it's a function then? |
| 20:41 | <caitp> | 1 is fewer than N, thus mixins are simpler |
| 20:41 | <JonathanNeal> | As in all var’d and function’d things? Yes. |
| 20:41 | <caitp> | er |
| 20:41 | <caitp> | traits are |
| 20:41 | <caitp> | I totally got that ass-backwards in that last line :> |
| 20:42 | <annevk> | I think in this case mixins are simpler since all these methods delegate to generics anyway |
| 20:42 | <annevk> | If we designed things from the ground up it might be different of course |
| 20:42 | <JonathanNeal> | Domenic: the living example would be https://github.com/Financial-Times/polyfill-service/blob/feature/enqueueMicrotask/polyfills/enqueueMicrotask/polyfill.MutationObserver.js |
| 20:42 | <Domenic> | JonathanNeal: yeah, that's definitely not a method. |
| 20:42 | <annevk> | Well, not might, if we did it today things definitely would be a lot different :-) |
| 20:43 | <caitp> | well, it's possible that we will have traits some day, and webidl could be rewritten to make these partial interfaces traits, and it could still easily be backwards compatible |
| 20:43 | <caitp> | but that's just blocked on so many things that it's just as likely to never happen |
| 20:43 | <annevk> | I don't see how these particular methods would benefit from being traits |
| 20:44 | <annevk> | They're generic, like Array methods |
| 20:44 | <caitp> | it's not really about the implementation |
| 20:44 | <Domenic> | annevk: that's not quite accurate; array methods don't do brand checks, whereas these do. |
| 20:44 | <caitp> | it's about being able to easily identify things that have them, don't have them, or should have them |
| 20:45 | <caitp> | if a polyifller just needed to extend a trait, that would be pretty awesome |
| 20:45 | <annevk> | Domenic: fair |
| 20:45 | <caitp> | typing is hard |
| 20:46 | <annevk> | caitp: also fair |
| 20:46 | <annevk> | https://github.com/whatwg/streams/commit/06143f8bb8b92381fcce5f1f4f2d6fe10b64d087 Domenic++ |
| 20:47 | <Domenic> | ^_^ |
| 20:47 | <annevk> | Domenic: have you discussed Streams with sicking lately? Seems he still has the 4 objects vs constructing some kind of pipe concern |
| 20:48 | <Domenic> | annevk: we had a bit of a discussion in the bug, I don't think he responded to the point |
| 20:48 | <annevk> | ah right |
| 20:49 | <Domenic> | This is interesting http://www.do-not-panic.com/2014/02/developer-certificate-of-origin.html more lightweight than a CLA but seemingly just as good |
| 20:51 | annevk | read CA and got confused |
| 20:52 | <annevk> | "certificate" and "origin" did not help |
| 20:52 | <Domenic> | hahaha |
| 20:56 | <Domenic> | more http://lwn.net/Articles/592503/ |