| 00:26 | <gsnedders> | Bah, coming up with a good title for a Stack Overflow question of "my mod_rewrite rules don't do what I want" is hard. :( |
| 02:03 | GPHemsley | wonders if there was an incident recently |
| 07:57 | <mathiasbynens> | Hixie: why are `minlength` & `maxlength` specced to count 16-bit code units rather than code points? https://html.spec.whatwg.org/multipage/forms.html#attr-fe-maxlength |
| 08:09 | <annevk> | mathiasbynens: that's what implementations do iirc |
| 08:09 | <annevk> | mathiasbynens: although I think WebKit might not, there was some discussion about it |
| 08:10 | <mathiasbynens> | annevk: isn’t `minlength` “new”? hmm, even then i guess consistency with `maxlength` is worth something |
| 08:11 | <annevk> | yeah, that's why |
| 08:11 | <annevk> | it's unclear why you'd count code points though |
| 08:11 | <annevk> | bytes would make some sense historically |
| 12:28 | <mathiasbynens> | yeah, almost anything other than 16-bit code units would make more sense :) |
| 12:28 | <mathiasbynens> | but… topic |
| 12:46 | <smaug____> | is Brian Kardell ever on irc? |
| 12:58 | <MikeSmith> | smaug____: no, Brian isn't usually aroun on IRC |
| 12:58 | <MikeSmith> | or maybe never |
| 12:58 | <MikeSmith> | can't recall if I ever remember chatting with him on IRC anywhere |
| 12:59 | <smaug____> | k |
| 12:59 | smaug____ | sends email |
| 13:06 | <smaug____> | ...saying nothing new |
| 13:35 | <annevk> | smaug____: I hope that we can finish custom elements as a standalone thing first, but it might make sense to figure out how to better support encapsulation in shadow DOM |
| 13:43 | <annevk> | https://twitter.com/IgorZIJ/status/561902586631303168 SoundScript is some kind of asm.js competitor? |
| 13:50 | <smaug____> | annevk: yup |
| 13:50 | <smaug____> | to the earlier comment |
| 13:50 | <smaug____> | hmm, what is SoundScript |
| 13:50 | <smaug____> | sounds like some audio handling thingie |
| 13:50 | <smaug____> | but probably isn't |
| 13:50 | <annevk> | smaug____: only one browser shipped so far... |
| 13:51 | <annevk> | smaug____: from the surrounding tweets and the dslomov commenting I'm pretty sure it's not about audio |
| 13:51 | <annevk> | s/the dslomov/dslomov/ |
| 14:20 | <caitp> | annevk: was there any attempt to add progress notifications to fetch? seems unfinished :( |
| 14:30 | <MikeSmith> | RSConf looks like a fun event https://twitter.com/182debrin/status/561811081564131328/photo/1 |
| 14:33 | <MikeSmith> | apparently some people are starting to use the term HTML6 non-ironically https://twitter.com/hashtag/html6?src=hash |
| 14:34 | <caitp> | HTML2016 � |
| 14:36 | <jgraham> | MikeSmith: Yeah I was having my own personal WTF moment about that |
| 14:37 | <jgraham> | and then I saw http://t.co/sLHt8HjjFp and my head exploded |
| 14:37 | <gsnedders> | oooh, HTML6 again! |
| 14:38 | <caitp> | wow jgraham |
| 14:39 | <jgraham> | http://joostvanmeeteren.info/informatics/introduction_to_html6.html |
| 14:39 | <caitp> | on the bright side at least the zombies didn't win |
| 14:39 | darobin | discreetly purchases xhtml3.com |
| 14:42 | <MikeSmith> | for lots more wtf see http://www.realcombiz.com/2014/10/the-expected-specifications-of-html6.html |
| 14:42 | <MikeSmith> | which appears to be a re-blog of something from somewhere else maybe |
| 14:42 | <MikeSmith> | but regardless it's .. baffling |
| 14:43 | <MikeSmith> | "With HTML6, we’re going to have namespace elements like: <html:media type=”video”>, <html:title>." |
| 14:43 | <MikeSmith> | is that coming from some trollish thing that people are taking seriously? |
| 14:44 | <gsnedders> | It seems to be from http://html6spec.com? |
| 14:44 | <caitp> | as long as it prevents another zombie apocalypse, it's all good, bring on the namespaces |
| 14:46 | <jgraham> | http://xahlee.info/comp/html6.html is exciting |
| 14:46 | <jgraham> | In the future you will need a custom keyboard layout just to type HTML |
| 14:47 | <caitp> | such a modest proposal |
| 14:48 | <MikeSmith> | gsnedders: ah |
| 14:50 | <MikeSmith> | jgraham: oh man the Questions ＆ Answers part of http://xahlee.info/comp/html6.html is solid gold |
| 14:53 | <MikeSmith> | anyway you can type 「 and 」 easily from a Japanese IME, so as long as we'll be requiring authors to use a Japanese IME we might as well go all the way and use Japanese for all the element names and attribute names |
| 14:54 | <caitp> | that would probably make a lot of people very happy and encourage a lot of people to become web developers |
| 14:54 | <darobin> | with judicious Kanji we might be able to make every single element and attribute name single-character |
| 14:54 | <MikeSmith> | oh wait I see even the parens are not parens they're LEFT/RIGHT TORTOISE SHELL BRACKET |
| 14:55 | <darobin> | I mean talk about terse |
| 14:55 | <darobin> | it's so terse it's torterse |
| 14:55 | <MikeSmith> | darobin: yeah |
| 14:55 | <MikeSmith> | hahah |
| 14:55 | <annevk> | caitp: that's because it's not finished |
| 14:56 | <Ms2ger> | darobin, anything you want to say before I close https://github.com/w3c/web-platform-tests/issues/1484 ? |
| 14:56 | <annevk> | caitp: I recommend studying https://github.com/yutakahirano/fetch-with-streams/ for the tentative plan |
| 14:56 | <MikeSmith> | of course the logical place we're going to end up here is don't use kanji for element/attribute names but go all the way and just use emoji |
| 14:56 | <darobin> | Ms2ger: I should probably look at it, but if you really want to close it I can't say I care that much |
| 14:56 | <Ms2ger> | OK |
| 14:57 | <darobin> | I'm disappointed that it hasn't addressed the custom elements issue simply through use of the astral plane |
| 14:57 | <MikeSmith> | annevk: speaking of Streams, has anybody started to implement it in gecko yet |
| 14:57 | <MikeSmith> | and if so is there a tracking bug |
| 14:57 | <darobin> | emoji is sure to attract a lot of people to coding |
| 14:57 | <annevk> | MikeSmith: not that I know of |
| 14:57 | <MikeSmith> | ok |
| 14:58 | <annevk> | MikeSmith: might be a good idea to file a tracking bug |
| 14:58 | <MikeSmith> | ok will do a right now |
| 14:58 | <annevk> | ta |
| 14:59 | <caitp> | annevk is it problematic that blink might ship it early then, in case it needs to change more fundamentally? |
| 14:59 | <annevk> | caitp: streams? |
| 14:59 | <caitp> | fetch |
| 14:59 | <annevk> | caitp: oh, I did not mean not finished in that way |
| 15:00 | <annevk> | caitp: the way fetch() is designed right now seems as close to perfect as we could get without streams; and the design does not preclude adding them later |
| 15:02 | <MikeSmith> | annevk: what component for Streams? DOM or JavaScript Engine or ...? |
| 15:02 | MikeSmith | looks around for smaug too |
| 15:02 | <annevk> | MikeSmith: heh |
| 15:02 | <caitp> | i dunno, the example looks kinda sub-optimal :( |
| 15:02 | <annevk> | MikeSmith: both DOM and JavaScript :/ |
| 15:02 | <MikeSmith> | yeah |
| 15:02 | <annevk> | caitp: what example? |
| 15:02 | <caitp> | on the github page you linked |
| 15:03 | <annevk> | caitp: that's mostly the streams API, no? |
| 15:04 | <caitp> | sure, but it doesn't really look very good, as an api, it doesn't really integrate well with promises |
| 15:05 | <caitp> | the subscription model doesn't fit well there |
| 15:05 | <caitp> | ehhh it's awkawrd |
| 15:05 | <annevk> | So did we change subjects from whether fetch() is shippable to whether streams is done? |
| 15:05 | <caitp> | i think when it comes to fetch they're sort of tied, no? |
| 15:06 | <annevk> | Currently fetch() doesn't expose streams, so no |
| 15:06 | <MikeSmith> | annevk: file https://bugzilla.mozilla.org/show_bug.cgi?id=1128959 |
| 15:06 | <MikeSmith> | *filed |
| 15:06 | <caitp> | if it ships now, people start using it, and then in m44 or m56 they start exposing streams, that seems potentially bad |
| 15:07 | <MikeSmith> | annevk: I put it under DOM: Core & HTML |
| 15:07 | <MikeSmith> | I'll wait for smaug to move it out to the JavaScript component :) |
| 15:08 | <annevk> | caitp: you might be on to something, but this is not very concrete |
| 15:08 | <annevk> | MikeSmith: cool, next time just put it in "DOM", the subcomponents are rather useless |
| 15:08 | <MikeSmith> | oh |
| 15:08 | <MikeSmith> | ok |
| 15:08 | <Ms2ger> | Well, DOM vs DOM: C&H at least |
| 15:09 | <caitp> | okay, so lets say right now, i'm used to my promise being resolved when the request completes, because that's just how it is since there's no way to subscribe to progress notifications or explicitly ask for streaming |
| 15:09 | <caitp> | then all of a sudden, it starts being resolved very early before everything is done |
| 15:09 | <caitp> | the response isn't what i expect it to be |
| 15:09 | <caitp> | and, i haven't explicitly subscribed to streaming anywhere |
| 15:10 | <caitp> | just doesn't seem right |
| 15:10 | <MikeSmith> | Ms2ger: annevk the Component Description for "DOM" doesn't provide such great guidance to bug submittors: 「For bugs in DOM support which do not fit into any other DOM Component. This is the right component for issues with <base href=""> and xml:base. 」 |
| 15:11 | <Ms2ger> | It hasn't been updated in a long time |
| 15:11 | <annevk> | caitp: that part is not going to change, the promise resolving once all headers are in is exactly the right primitive to expose |
| 15:12 | <annevk> | MikeSmith: yeah, bothers me too |
| 15:12 | <annevk> | MikeSmith: I wonder if I put effort into getting it right whether that would pay off |
| 15:12 | <MikeSmith> | probably not worth it |
| 15:15 | <Domenic> | regarding streams/fetch/progress, JakeA put something together a week ago which I tidied up a bit, results in https://gist.github.com/domenic/440db8eac99c5b41bf95 |
| 15:15 | <MikeSmith> | I doubt there are many people who just wander in and submit any bugs under components in the Core product to begin with and read the component descriptions anyway |
| 15:27 | <MikeSmith> | Domenic: do you know if there's a chromium/blink tracking bug for the Streams implementation |
| 15:28 | <MikeSmith> | I found other chromium bugs related to it but nothing for it itself |
| 15:35 | <MikeSmith> | the guy who wrote http://www.infoworld.com/article/2873543/html5/10-proposals-for-a-better-html6.html seems to be a time traveler from the past; e.g., "HTML6 proposal No. 2: Browser-sizing of imagery" is basically describing the <picture> element |
| 15:36 | <MikeSmith> | but his next-most-recent article is "PHP vs. Node.js: An epic battle for developer mind share" so maybe he's actually from another dimension |
| 15:37 | <MikeSmith> | "PHP and JavaScript, two partners who once ruled the Internet together" |
| 15:37 | <MikeSmith> | "Where PHP wins: SQL" |
| 15:50 | <annevk> | MikeSmith: hah |
| 15:53 | <MikeSmith> | annevk: about whatever SoundScript is, https://docs.google.com/presentation/d/1803sMhKjZEOSpsShfC7K7O4sl6ZltWXyQ4ego1BN-kM/edit#slide=id.g6e9e9d944_2_344 |
| 15:54 | <MikeSmith> | is "use stricter" already a real thing being discussed |
| 15:56 | <gsnedders> | MikeSmith: no |
| 16:05 | <caitp> | it didn't really seem like a competitor to asm.js to me, because it didn't seem like it would make a real target language. but it could allow optimizing compilers to cheat a bit, possibly removing mapcheck bailouts and stuff like that? dunno too much about it though |
| 16:05 | <MikeSmith> | gsnedders: ok well hopefully Dmitry will get around to writing about this soon somewhere else |
| 16:05 | <MikeSmith> | lomov |
| 16:07 | <gsnedders> | MikeSmith: :) |
| 16:08 | <gsnedders> | caitp: depends how you handle the boundary between typed and untyped code, and how often you cross it |
| 16:09 | <caitp> | well it would be like, mapcheck failure -> throw, rather than deopt |
| 16:09 | <caitp> | or something like that |
| 16:09 | <caitp> | I have no idea :) |
| 16:10 | <MikeSmith> | from whence are you all discerning the details about the proposal? |
| 16:10 | <MikeSmith> | from those slides or some other writeup? |
| 16:11 | <caitp> | I don't have much info on it, it was talked about a few weeks ago, but no writeup or anything that I saw |
| 16:11 | <MikeSmith> | ah OK |
| 16:11 | <MikeSmith> | well from the slides I can't tell how much of it is just describing how V8 already works vs what's being proposed |
| 16:12 | <gsnedders> | caitp: as soon as you have the check you've lost, throwing or deopt doesn't matter |
| 16:12 | <caitp> | gsnedders, not necessarily |
| 16:13 | <caitp> | i mean the end result is you don't want to crash the browser, so somewhere along the way you need some sanitization |
| 16:14 | <caitp> | some of that might be able to happen statically |
| 16:14 | <caitp> | if it can't happen statically, you might only need to perform checks when crossing from untyped code into typed code |
| 16:15 | <caitp> | but yeah the whole thing is pretty fuzzy to me :p |
| 16:15 | <caitp> | i'm sure there will be more info as it becomes available |
| 16:16 | <gsnedders> | caitp: most of it can't happen statically because you don't have the level of detail needed in any sane type system, because you need to know object layouts to be useful |
| 16:16 | <gsnedders> | caitp: boundary checks typically end up frequent enough the gain is pretty small |
| 16:16 | <caitp> | we'll see |
| 16:17 | <gsnedders> | (Hack with only a very small perf gain for FB, simply because boundary checks were so frequent. Yes, it got better over time, but it's still not a particularly big perf gain AIUI. The big gain is statically asserting correctness properties of the codebase.) |
| 16:18 | <caitp> | that's certainly a big one |
| 16:18 | <gsnedders> | I'm not saying there aren't good reasons to add more of a type system to ES, and I think it'll happen, but you can get the correctness gains through gradual typing by and large, and without introducing another mode. |
| 16:19 | <caitp> | I have so little info on it, and I can't read cyrillic writing so it's hard to get much out of the presentation :p |
| 16:21 | <Domenic> | apparently you can't get perf gains out of a non-sound type system, so it is much less interesting to VM implementers |
| 16:21 | <Domenic> | My main impression of SaneScript is that, like Dart, it is a language designed with VM implementers as the highest good in the priority of constituencies. |
| 16:22 | <Domenic> | slides/TC39 notes should be public soon |
| 16:22 | <caitp> | i assume they've already lifted the lid on it if they're talking about it at rsconf |
| 16:23 | <gsnedders> | Domenic: pretty much |
| 16:35 | <MikeSmith> | Domenic: I'd hope your impression isn't correct but I guess I won't be surprised if it is |
| 16:36 | <MikeSmith> | but even the value proposition for asm.js doesn't seem like the greatest if you try to describe it |
| 16:36 | <Domenic> | yeah languages which are designed with VM implementers in mind do have good value as a compilation target. |
| 16:36 | <MikeSmith> | "The solution for people who want/like to write things in C++" |
| 16:46 | <caitp> | i still didn't really get the "compilation target" vibe from the new language modes |
| 16:46 | <caitp> | if that's what it sounded like at tc39 i'll take your word for it |
| 16:48 | <annevk> | "use stricter+types" wow |
| 16:48 | <annevk> | MikeSmith: it's Dmitry and Dimitri |
| 16:49 | <Domenic> | caitp: that's definitely not the intent, but I think it will be the effect. |
| 16:49 | <Domenic> | I *did* get the "these are the parts of JS we don't like optimizing" vibe |
| 16:50 | <annevk> | MikeSmith: heh, I stopped reading those slides due to the Russian, guess I should have persisted |
| 16:53 | <annevk> | Domenic: is "SoundScript" from the slides "SaneScript"? |
| 16:53 | <caitp> | different language modes |
| 16:53 | <Domenic> | Nah, SoundScript is a sound type system, and in theory could be separate from SaneScript |
| 16:54 | <annevk> | Ah, makes sense |
| 16:55 | <annevk> | Looking forward to the details |
| 17:00 | <MikeSmith> | I hope there's not really a trend as far as (mis)prioritization of things that lend themselves to optimization over ... just making things work well |
| 17:01 | <MikeSmith> | or even just prioritization of performance over all else |
| 17:02 | <caitp> | mobile users might be pretty keen on having their js-heavy applications work fast, and maybe yield more time to the cpu instead of doing background (or worse, serial) optimization |
| 17:03 | <MikeSmith> | well we are coming up on 5 years since that V8 "move DOM attributes to prototype chain" bug was first opened |
| 17:03 | <caitp> | yeah but isn't that more of a problem for developers rather than users |
| 17:03 | <caitp> | grandma doesn't care about that she just wants her email |
| 17:03 | <MikeSmith> | meanwhile all other JS engines implemented it per-spec years ago -- performantly |
| 17:04 | <Domenic> | Yeah the biggest takeaway re: SaneScript/SoundScript I think is that the V8 team working on JavaScript proper is going to be smaller again :( |
| 17:05 | <MikeSmith> | I think the fact that the V8 developers can't implement "move DOM attributes to prototype chain" performantly is because they've already over-optimized in such a way that their design prevents it |
| 17:05 | <Ms2ger> | Don't worry, SM will beat them so hard they'll have to :) |
| 17:05 | <Domenic> | Ms2ger: that's my hope :) |
| 17:05 | <caitp> | domenic i'm guessing that's more the compiler people doing that, and probably not until TF is actually fast |
| 17:05 | <gsnedders> | To be fair, I think a lot of the problem is that there are a lot of people in Google who want to write a new language VM rather than V8. idk. |
| 17:05 | <Domenic> | gsnedders: yep, feels cyclical... first dart, now this. |
| 17:06 | <gsnedders> | Along with requirements for the team all to be in one place, which drives some (many?) Googlers away. |
| 17:06 | <MikeSmith> | that's really sad if true |
| 17:06 | <MikeSmith> | somebody remind me what product managers are for |
| 17:06 | <caitp> | I don't think they're all in california or germany <_< |
| 17:06 | <caitp> | just most |
| 17:06 | <caitp> | >_- |
| 17:06 | <gsnedders> | (i.e., anyone who wanted to stay in Aarhus ended up working on Dart, more or less.) |
| 17:07 | <gsnedders> | I don't think anyone of the original Aarhus team was allowed to keep working on V8? |
| 17:07 | <gsnedders> | When it mostly moved to Munich? |
| 17:08 | <gsnedders> | AFAICT your options were: a) stay in Aarhus and work on Dart; b) move to Munich and keep working on V8; c) stay in Aarhus and move to working on something totally unrelated. |
| 17:08 | <gsnedders> | Which doesn't seem like the best management of the V8 project. |
| 17:10 | <MikeSmith> | there's management of the V8 project? |
| 17:11 | <Domenic> | gsnedders: I don't think that's an accurate history... |
| 17:12 | <caitp> | there wouldn't be much point paying for expensive campuses in different countries if you couldn't dig up peoples families to relocate them |
| 17:17 | <gsnedders> | Domenic: it's how I've always understood it, from what I've been told |
| 17:18 | <Domenic> | gsnedders: from what I've been told everyone in Aarhus wanted to move with Lars to Dart and then the V8 team had to rebuild from scratch. The initial people interested in doing so worked in Munich and built a team there. |
| 17:20 | <Ms2ger> | Sounds like "everyone realized how much technical debt they'd built up" |
| 17:22 | <gsnedders> | Domenic: I had the impression that one or two people in Aarhus would've rather stayed with V8, but couldn't move. idk. |
| 17:22 | <gsnedders> | Domenic: certainly, yes, the majority chose to move with Lars |
| 17:33 | <caitp> | is that the story behind TF? |
| 17:33 | <caitp> | i guess that makes sense |
| 17:39 | <annevk> | Domenic: it seems somewhat inevitable some kind of VM thing emerges in the end with all the compile-to-JS stuff going on, but maybe not |
| 17:40 | <annevk> | Domenic: that stream-based progress example does require an awful lot of code compared to the equivalent with XMLHttpRequest |
| 17:40 | <annevk> | Domenic: I guess the abstractions come later... |
| 17:44 | <caitp> | async fetch(url, options) -> Promise vs fetchStream(url, options) -> Stream, imho |
| 17:47 | <Domenic> | I think the Promise<Response> where response.body is a Stream is the better model. |
| 17:48 | <caitp> | then it's a 2-step process |
| 17:48 | <Domenic> | yep |
| 17:48 | <caitp> | I think the fact that it's a 2-step process makes it kind of unattractive :( |
| 18:11 | <Domenic> | caitp: I doubt you want to start reading from the body of a 404. Seems good to have a step in between. |
| 18:11 | <caitp> | why do you doubt that? web browsers do it |
| 18:12 | <caitp> | an abstraction in a framework might also want to |
| 18:12 | <Domenic> | Sure, then the framework can write a function |
| 18:13 | <caitp> | i mean yeah other people can write the abstractions for you, but it seems like the exposed API should be pretty good to begin with |
| 18:16 | <Domenic> | I think it is |
| 18:19 | <annevk> | caitp: a web browser needs to inspect response headers before processing the body |
| 18:20 | <annevk> | caitp: every somewhat-non-trivial HTTP API will have to do that |
| 18:26 | <caitp-> | which is great, but it still makes for a pretty awful api |
| 18:38 | <annevk> | well, I guess we'll disagree on that |
| 19:12 | <bkardell> | smaug: http://krijnhoetmer.nl/irc-logs/whatwg/20150203#l-289 |
| 19:13 | <bkardell> | no, it's blocked at work, but occasionally he checks the logs :) |
| 19:29 | <JonathanNeal> | If it’s not too intrusive … would you circumvent ad blocking software for a client? Let me know @ https://docs.google.com/forms/d/1OxPpj8ZbM1oTBS8iG4MkGNQ7tq7EEeMltEJ5tUpAmUk/viewform or to help spread the poll @ https://twitter.com/jon_neal/status/562682942682841088 |
| 19:29 | <JonathanNeal> | s/too intrusive/too intrusive to ask |
| 21:29 | <jgraham> | JonathanNeal: Didn't you ask that before? :p |
| 21:32 | <JonathanNeal> | jgraham: yea, and by asking again, I got another 20 entries. Now, I feel like I have a comfortable sample size. |
| 21:33 | <jgraham> | JonathanNeal: By which you mean "a reassuringly large, but nevertheless hugely biased, sample", right? :p |
| 21:35 | <JonathanNeal> | jgraham: How is it hugely biased? And how would I get it not to be? |
| 21:35 | <jgraham> | It's hugely biased because it's self-selecting |
| 21:35 | <jgraham> | Only people who are interested in the answer bother to reply |
| 21:36 | <JonathanNeal> | I’m surprised it’s not so one-sided then https://docs.google.com/spreadsheets/d/1bSl8xyrrQ34AFcUszHBXn8riLjVpxwFUwdcetDqoTDI |
| 21:37 | <jgraham> | Right, but you don't know how one-sided it is compared to the true population |
| 21:37 | <jgraham> | e.g. if you get 50/50 and the underlying population is 90/10 then you still didn't collect useful data |
| 21:38 | <JonathanNeal> | jgraham: is there a way to better collect useful data? Are there such statistics already available to me? |
| 21:39 | <jgraham> | I don't know how to collect useful data here, unless you have some way of reaching a largely uniform sample of the population you are interested in |
| 21:44 | <JonathanNeal> | jgraham: would you find the reasons listed as being useful information? I found some of them very insightful, and some of them better than I am at articulating one point of view or the other. |
| 21:46 | <jgraham> | Yeah, so *reasons* seem like they are more useful independent of the actual yes/no answers |