| 00:16 | <Hixie> | hah, call for implementations of websockets |
| 01:51 | <rniwa> | AryehGregor: yt? |
| 02:24 | SamB_MacG5 | wonders why he's seeing hyphens inserted before/after single characters on http://hsivonen.iki.fi/cms/te/ ... |
| 02:28 | SamB_MacG5 | supposes it might help to use the "lang" attribute? |
| 02:48 | <SamB_MacG5> | gah... if I use the multi-page version, I get lousy back-references; if I use the single-page version, I sit there waiting for my browser... |
| 02:49 | SamB_MacG5 | remembers being able to open the multi-page version and have his browser not grind to a halt, wonders what changed |
| 02:49 | <Hixie> | SamB_MacG5: which browser? if you're on a G5 I think I see your problem. :-P |
| 02:50 | <SamB_MacG5> | it has more RAM than any of my other systems... |
| 02:57 | SamB_MacG5 | thinks it's unwise for a web browser with no hyphenation dictionary to try to hyphenate stuff written in latin scripts ... |
| 06:33 | <Hixie> | why is https://www.w3.org/Bugs/Public/show_bug.cgi?id=18223 marked invalid? |
| 06:33 | <Hixie> | am i missing something? |
| 06:34 | <Hixie> | it doesn't have any boilerplate from the editors, suggesting it was misfiled or something? |
| 07:07 | <zcorpan> | Hixie: any advice on translating "flow content" and "phrasing content"? http://forums.whatwg.org/bb3/viewtopic.php?t=5074&p=8102#p8102 |
| 07:09 | <zcorpan> | Hixie: maybe darobin interpreted it as a support forum question? |
| 08:59 | <hsivonen> | anyone want to guess how many requests for different doctype HTML.next will get? |
| 09:04 | <Ms2ger> | No, it makes me sad enough without thinking about that |
| 09:22 | <smaug____> | hsivonen: is HTML.next some W3C thing? |
| 09:22 | <smaug____> | and btw, are you planning to go to TPAC? |
| 09:39 | <zcorpan> | <!doctype html.next> |
| 09:42 | <jgraham> | <!doctype html.next.next> |
| 09:42 | <jgraham> | gets kind of silly |
| 09:43 | <Ms2ger> | <!doctype html.doublenext> |
| 09:44 | <jgraham> | I would take inspiration from functional programming |
| 09:44 | <Ms2ger> | next(<!doctype html>)? |
| 09:44 | <jgraham> | <!doctype applyN(html, next, 2)> |
| 10:10 | <annevk> | for DOMTokenList |
| 10:10 | <annevk> | do we want DOMTokenList.contains("a", "b") as well? |
| 10:10 | <Ms2ger> | What does it mean? |
| 10:10 | <annevk> | with AND semantics |
| 10:11 | <annevk> | I guess I'll leave that for now |
| 10:12 | <Ms2ger> | If someone wants to implement it, I guess |
| 10:12 | <Ms2ger> | Gecko might even be able to in the near future |
| 10:12 | <annevk> | I'm adding arity to add() and remove() now |
| 10:12 | <annevk> | fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=13999 as I think that part of ES6 is ready |
| 10:13 | <Ms2ger> | I believe SM supports the rest thing |
| 10:32 | <annevk> | http://dom.spec.whatwg.org/#domtokenlist |
| 10:33 | <hsivonen> | walmart.ca has a lovely content-type: text/html;UTF-8;charset=UTF-8 |
| 10:36 | <annevk> | should work fine no? |
| 10:37 | <hsivonen> | annevk: yes |
| 10:40 | <annevk> | Is there a way to make https://github.com/whatwg list the repository links as well? (Each repository can have a short description and a link, but for some reason they are only displayed on the repository page.) |
| 10:42 | <miketayl_r> | i don't think github offers that |
| 11:04 | <annevk> | darobin: adding a post-push hook is just as easy |
| 11:04 | <annevk> | darobin: and you get to keep control over the URL, http://url.spec.whatwg.org |
| 11:28 | <hsivonen> | smaug____: it’s a W3C thing. I have TPAC travel booked. |
| 11:28 | <smaug____> | k |
| 11:29 | <smaug____> | I'll be in Lyon the whole week |
| 11:29 | <annevk> | hmm, now I'm somewhat tempted to visit too |
| 11:29 | <annevk> | but I don't really want to attend any meetings |
| 11:30 | <smaug____> | we can pretend to not see you if you're in the meeting room during webapps wg meeting |
| 11:31 | <hsivonen> | the validator is correct here, isn’t it? http://bugzilla.validator.nu/show_bug.cgi?id=943 |
| 11:32 | <annevk> | for now |
| 11:32 | <annevk> | I'm going to make that valid |
| 11:41 | <odinho> | annevk: You can come to TTWF. Or just come down and hang around. Sit in a cafe all day and hang out in breaks and stuff ;P |
| 11:41 | <zcorpan> | annevk: but then we won't be able to use [ and ] to delimit urls!1 |
| 11:47 | <zcorpan> | erratum 3297 for rfc3987 is interesting |
| 11:48 | <zcorpan> | "it's not cool to fix errors in errata if it wasn't an error by the time we published!" |
| 11:48 | <annevk> | odinho: is that in the same time period? |
| 11:48 | <annevk> | zcorpan: oh you |
| 11:51 | <odinho> | annevk: Nah, it's some days before. But anyway it's a reason to travel down :P |
| 11:59 | <darobin> | annevk: sorry, were you replying to something? I'm missing context |
| 11:59 | <darobin> | annevk: there are worse places to visit than Lyon |
| 11:59 | <darobin> | though there are better times of year |
| 11:59 | <darobin> | and TTWF is in Paris right befpre |
| 12:07 | <annevk> | darobin: I was replying to your tweet about spec hosting |
| 12:09 | <annevk> | zcorpan: yeah, the errata system is bullshit |
| 12:10 | <annevk> | I wonder why I keep getting disconnected, oh, maybe it's OS X ML |
| 12:11 | <Ms2ger> | Why not OS HT ML? |
| 12:11 | <annevk> | Why not Zoidberg? |
| 12:11 | <annevk> | not here to debate philosophy |
| 12:13 | <annevk> | it was the OS X update btw |
| 12:13 | <annevk> | on battery power computer sleep was 1h |
| 12:14 | <annevk> | but on adapter it was 15min |
| 12:14 | <annevk> | because Apple |
| 12:14 | <hsivonen> | zcorpan: wow. the IETF is sad. |
| 12:27 | <darobin> | annevk: ah, that document is from tobie actually |
| 12:28 | <tobie> | what did I do again? |
| 12:28 | <annevk> | oh hey, didn't notice tobie was here |
| 12:28 | <darobin> | tobie: annevk was providing some cryptic feedback about your specs@gh document |
| 12:29 | <annevk> | tobie: re your github speccing, all I mentioned was that using a post-push commit hook you can have the same thing, but with control over the URL, e.g. http://url.spec.whatwg.org |
| 12:29 | jgraham | was sort of expecting to get to the end and it to say "inception" |
| 12:29 | <darobin> | annevk: ah, you mean instead of using gh-pages? |
| 12:29 | <annevk> | yeah |
| 12:29 | <darobin> | yes, that's fine, but it does imply that you have somewhere else to host it at |
| 12:29 | <darobin> | imho both are useful |
| 12:29 | <jgraham> | Also, I don't recommend using RSpec (sorry darobin) |
| 12:29 | <annevk> | WHATWG hands out spec.whatwg.org addresses to anyone who wants to spec :) |
| 12:30 | <tobie> | agreed. Seems like we should have two parts to it then. |
| 12:30 | <annevk> | we also have html5.org available if someone fancies that |
| 12:30 | <darobin> | jgraham: I wouldn't recommend using RSpec either, unless you want to write Ruby tests that is |
| 12:30 | <darobin> | but for a spec, ReSpec is the rocking rock in town! |
| 12:30 | <jgraham> | er ReSpec |
| 12:31 | <tobie> | Not really interested in the ReSpec vs something else debate, tbh. Turns out ReSpec makes the gh-pages hosting thing trivial, which I think is kind of cool. |
| 12:31 | <jgraham> | Turns out that two technologies that are inexplicably popular have very similar names |
| 12:31 | <jgraham> | :) |
| 12:31 | <darobin> | I blame Ali G |
| 12:31 | <tobie> | Happy to take pull requests, btw. |
| 12:32 | <tobie> | :P |
| 12:32 | <annevk> | yeah, ReSpec has a bunch of issues |
| 12:32 | <annevk> | http://wiki.whatwg.org/wiki/Howto_spec#Legacy_DOM-style in particular |
| 12:32 | <annevk> | I know it's not enforced |
| 12:32 | <annevk> | but it's used all over |
| 12:33 | <annevk> | e.g. in http://www.w3.org/TR/DOM-Parsing/#extensions-to-the-text-interface |
| 12:33 | <jgraham> | Yeah, it's not ReSpec itself, exactly, but that it seems to encourage bad style |
| 12:33 | <annevk> | the crappy version of http://html5.org/specs/dom-parsing.html |
| 12:34 | <jgraham> | I am happy to believe that ReSpec is super-awesomeness with bad defaults |
| 12:34 | <jgraham> | Unlike RSpec which is just fundamentally wrongheaded |
| 12:35 | <darobin> | as always, I'm happy to take patches :) |
| 12:36 | <annevk> | happy to use Anolis :) |
| 12:36 | <tobie> | I always <3 a good BDD bashing. |
| 12:36 | <darobin> | fwiw the part of ReSpec that implements legacy DOM style is called "webidl-oldschool" — perhaps for a reason :) |
| 12:37 | <annevk> | heh |
| 12:37 | <darobin> | re Anolis it's fine, I just prefer web technology |
| 12:38 | <jgraham> | darobin: That *is* oldskool. The kids these days can't cope unless they have a dedicated app for everything |
| 12:39 | <darobin> | jgraham: I guess it shows my age :) |
| 12:40 | <jgraham> | If Google had a sense of humor they would release an iOS maps app that is just maps.google.com |
| 12:41 | <annevk> | that would actually be better than the situation right now |
| 12:41 | <tobie> | If anyone had a sense of business, they would just wrap maps.google.com with PhoneGap and charge for it. |
| 12:42 | <annevk> | because maps.google.com does not indicate with some flag it can operate independently from Safari |
| 12:43 | <annevk> | sense of business? hah, I'm unemployed and still work |
| 12:44 | <tobie> | yeah, certainly not one of us. |
| 12:44 | <tobie> | the person with a sense of business, that is, not you annevk |
| 12:47 | <annevk> | I see |
| 12:50 | <tobie> | annevk: I'm surprised you were able to make any sense out of my rambling. |
| 12:56 | <Ms2ger> | jgraham, sorry, Apple wouldn't allow it |
| 12:58 | <Ms2ger> | tobie, so about github making it simpler to contribute tests... |
| 12:58 | <Ms2ger> | Do you have actual examples of outside devs submitting tests? |
| 12:59 | <tobie> | Ms2ger: Isn't that what Test The Web Forward is all about? |
| 12:59 | <odinho> | If it hasn't been done before, all the more reason to try to get it. |
| 12:59 | <odinho> | And yeah TTWF FTW |
| 12:59 | <odinho> | WTF as well. Hmm. Funny. |
| 12:59 | <annevk> | WHAT TF, already been done |
| 12:59 | <Ms2ger> | tobie, ttwf? They've been contributing to HG |
| 13:00 | <annevk> | miketaylr: seems only you and @whatwg are excited about add/remove |
| 13:00 | <annevk> | miketaylr: too little too late? :) |
| 13:00 | <tobie> | Well, yes. Where else would they have contributed? |
| 13:01 | <miketaylr> | annevk: probably way too early for the US kids to get excited |
| 13:01 | <miketaylr> | let them have some coffee |
| 13:01 | <annevk> | miketaylr: still in line for that phone? |
| 13:01 | <miketaylr> | heh |
| 13:01 | <annevk> | or maybe that's just the folk that work at Starbucks |
| 13:02 | <Ms2ger> | tobie, did I misunderstand? I thought you had something set up on github |
| 13:02 | <miketaylr> | i'm sure paul_irish will alert his fanbase |
| 13:02 | <annevk> | Ms2ger: for writing specs |
| 13:02 | <annevk> | miketaylr: hard to compete with that |
| 13:02 | <Ms2ger> | Oh, I thought they had something for the ringmark thing too |
| 13:03 | <annevk> | whenever that name falls I think of goatse |
| 13:03 | <annevk> | can't help it |
| 13:06 | <odinho> | annevk: paul_irish or ringmark? |
| 13:06 | <annevk> | dude hahahahah |
| 13:07 | <tobie> | Ms2ger: Ringmark's a Facebook product with a high barrier to contribution (need a PHP server and a full node install, uses a custom test framework, etc). Really don't think it's relevant in this conversation. |
| 13:07 | <Ms2ger> | Oh |
| 13:07 | <Ms2ger> | Then I guess I misunderstood |
| 13:09 | <tobie> | annevk: thanks for the image. |
| 13:16 | <annevk> | lol |
| 13:16 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=11204#c52 |
| 13:21 | <gsnedders> | Ms2ger: Equally, though I believe it is now better, you originally had to support the webkit prefix to do well at Ringmark. |
| 13:22 | <Ms2ger> | I saw a check for window.opera and gave up |
| 13:23 | <gsnedders> | Oh, test262 sniffs for Opera too. It used to make us fail tests. We tried to get it fixed to remove browser sniffing, but instead they just changed the Opera codepath. |
| 13:23 | <gsnedders> | Well, at least it now works regardless of whether you expose window.opera… |
| 13:23 | <zcorpan> | hsivonen: what's the status of regression tests for the validator? |
| 13:24 | <gsnedders> | hsivonen: Did I not see somewhere some meta charset sniffing tests you wrote? Able to release them under the MIT license for html5lib? |
| 14:31 | <miketaylr> | Chad Rampley is having a rough day, it would appear |
| 14:58 | <annevk> | hmm |
| 14:58 | <annevk> | thus far the only must statements in the URL Standard are in the API section |
| 14:58 | <annevk> | I guess that works |
| 14:59 | <annevk> | Would it be weird to name the Creating section Parsing and the "parse" bit "tokenize"? |
| 14:59 | <annevk> | it does a bit more than a typical tokenizer, but otherwise it's fairly close, and "Creating" is odd |
| 15:01 | <Hixie> | wow, we have no way to render the shadow in canvas but not the shape |
| 15:01 | <Hixie> | if you set the shape to transparent, the shadow doesn't render |
| 15:15 | <SamB_MacG5> | Hixie: Oh, I seem to have missed where you asked me "which browser?" last night. I'm using TenFourFox 15 on this machine. |
| 15:16 | <annevk> | I emailed the list instead |
| 15:16 | <annevk> | lets see if that goes any better |
| 15:17 | <SamB_MacG5> | is rendering the shadow without the shape terribly important? |
| 15:31 | <dglazkov> | goodd morning, Whatwg! |
| 15:40 | <jgraham> | Can we video fantasai doing her "How to file a perfect bug report" talk? |
| 15:41 | <jgraham> | Or better yet, can we get a two minute video "How to file a bug report that won't be closed as invalid on sight"? |
| 17:45 | <MadPig> | I still don't get the whole "dropped version number" thing. How is a browser gonna know what to use? Why isn't it <html version="5.0"> or <html version="5.1">? Why can't it make sense? |
| 17:48 | Ms2ger | yawns |
| 17:48 | <Ms2ger> | Because a browser always uses the latest version it implements |
| 17:49 | <dglazkov> | the shuttle flyover! |
| 17:49 | <MadPig> | What? |
| 17:49 | <dglazkov> | yay |
| 17:49 | <MadPig> | Please try to make some sense. |
| 17:54 | <Ms2ger> | Do you know space shuttles? |
| 17:54 | <Ms2ger> | They fly |
| 17:54 | <Ms2ger> | over |
| 17:59 | <TabAtkins> | The flyover was very cool. ^_^ |
| 18:00 | <dglazkov> | http://www.nasa.gov/centers/ames/events/2012/9.20.12_Shuttle_Endeavour.html for context |
| 18:40 | <smaug____> | is Rick Byers ever here ? |
| 18:59 | <Hixie> | Ms2ger: if you get questions about the version number thing, i recommend pointing them to the faq |
| 19:00 | <Hixie> | whatwg.org/faq |
| 19:07 | <Ms2ger> | Yay, a FAQ :) |
| 19:09 | <TabAtkins> | SamB_MacG5: I haven't finished reading through scrollback, so someone may have gotten back to you, but XBL2 was dropped due to lack of implementor interest. It was too complex. |
| 19:09 | <TabAtkins> | SamB_MacG5: We're doing essentially the same thing, but in a saner way, with Web Components. It has impl interest, too - WebKit is the original implementor, and Firefox is getting into it as well. |
| 19:11 | <SamB_MacG5> | yeah, annevk said something along those lines |
| 19:11 | <SamB_MacG5> | (rather more tersely, though) |
| 19:11 | <SamB_MacG5> | (and didn't mention the implementation status of web components) |
| 19:15 | <SamB_MacG5> | TabAtkins: is there a good wiki overview of web components? |
| 19:16 | <Hixie> | TabAtkins: web components has the same level of interest in it now as xbl2 did about 10 years ago... we'll see how long it holds! |
| 19:16 | <TabAtkins> | SamB_MacG5: Not wiki, but we have an explainer document: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html |
| 19:16 | <TabAtkins> | Hixie: Who actually implemented XBL2? |
| 19:16 | <Hixie> | TabAtkins: i have hope, though. dglazkov's approach of splitting it up into smaller problems is solid |
| 19:17 | <Hixie> | TabAtkins: mozilla implemented xbl1, xbl2 is just a recasting of it. |
| 19:17 | <Hixie> | TabAtkins: hyatt had parts of xbl2 implemented in webkit |
| 19:17 | <TabAtkins> | I'll have to trust you on that - from what I understood, XBL2 was significant different from 1. |
| 19:17 | <SamB_MacG5> | Hixie: yes, but was mozilla interested in either implementing both simultaneously, or trying to migrate AMO (and then some) to XBL2? |
| 19:18 | <SamB_MacG5> | I guess AMO *was* probably smaller then, but still... |
| 19:19 | <Hixie> | TabAtkins: well, 1 never had a real spec. xbl2 was an attempt at speccing it and cleaning it up. |
| 19:19 | <Hixie> | SamB_MacG5: everyone was "interested" at one point or another :-) nothing really went anywhere. |
| 19:19 | <Hixie> | SamB_MacG5: hopefully dglazkov's approach will be more successful |
| 19:20 | <Hixie> | (i expect that it will) |
| 19:20 | <dglazkov> | it's all about proper cheerleading |
| 19:20 | <SamB_MacG5> | well, I guess my point is that both of those approaches sound painful, though at least "implement both simultaneously" might have been possible... |
| 19:20 | <dglazkov> | \o/ web components \o/ |
| 19:20 | <SamB_MacG5> | dglazkov: smaller pieces probably also helps? |
| 19:21 | <TabAtkins> | Smaller pieces has been working out extremely well in all our efforts. |
| 19:21 | <dglazkov> | SamB_MacG5: sure. but cheerleading. \o/ |
| 19:21 | <dglazkov> | :) |
| 19:21 | <TabAtkins> | It's also much saner for the platform as a whole, because it means you're much more likely to get something that relies on a minimum of magic. |
| 19:22 | <TabAtkins> | Less magic = easier to implement slight variations in libraries, or to tweak details for yourself. |
| 19:22 | <TabAtkins> | Some of the worst additions to the platform are large dumps, because they tend to have too much interconnected stuff, so you can't tweak any details without reimplementing the whole stack yourself. |
| 19:23 | <dglazkov> | Mozilla is trying to ship parts of it pretty soon, afaik |
| 19:23 | <TabAtkins> | See: CSS layout, which desperately needs some lower-level primitives. |
| 19:25 | <Hixie> | i don't know that i'd agree entirely with that philosophy |
| 19:25 | <TabAtkins> | I know you don't. You're wrong. ^_^ |
| 19:26 | <Hixie> | i know you are, but what am i? :-P |
| 19:26 | <TabAtkins> | Rubber, apparently. |
| 19:29 | <Hixie> | in general, the reason i don't entirely buy into the philisophy you describe is that it relies on a host of very vague and relative concepts like "magic", "easier", "large", "too much", "lower". |
| 19:29 | <Hixie> | i do agree with many of hte conclusions you draw from this philosophy |
| 19:29 | <Hixie> | but i am not comfortable with it as stated |
| 19:30 | <SamB_MacG5> | Hixie: oh, you think he hand-waves too much? |
| 19:30 | <jgraham> | dglazkov: You need to work on your ascii dance shapes if you want adoption. At least throw in some \o\ and /o/ |
| 19:30 | <TabAtkins> | The concepts are vague and arguable, but the philosophy seems to work well in practice, and be useful for arguing with people over what should be native vs libraries vs predefined in terms of native stuff. |
| 19:30 | <dglazkov> | ¯\_(ツ)_/¯ |
| 19:30 | <dglazkov> | ---(ツ)_/¯ |
| 19:31 | <dglazkov> | _/¯(ツ)_/¯ |
| 19:31 | <jgraham> | Now you're just being silly |
| 19:31 | <SamB_MacG5> | anyway, small pieces makes it easier to get somewhere |
| 19:31 | <dglazkov> | _/¯(ツ)--- |
| 19:31 | <dglazkov> | :) |
| 19:31 | <jgraham> | :) |
| 19:31 | <Hixie> | TabAtkins: if it's just meant to be a way to convince people who aren't paying much attention, ok :-) |
| 19:31 | <dglazkov> | if you come to #chromium, you can always as trungl-bot to dance |
| 19:32 | <Hixie> | TabAtkins: but then it's not a philosophy, it's just a... something, there's a word for it, i forget what |
| 19:32 | <TabAtkins> | Hixie: I think it's a reasonable statement of my actual philosophy toward platform additions, but it's also useful as a conversational bludgeon. |
| 19:32 | <Hixie> | TabAtkins: i would be interested in working out what the real philosophy is |
| 19:32 | <Hixie> | "bludgeon" isn't the word i was looking for but it'll do :-P |
| 19:32 | <TabAtkins> | crowbar |
| 19:33 | <TabAtkins> | To pry apart their argument. |
| 19:35 | <dglazkov> | I think slightlyoff's Bedrock post describes the approach pretty well |
| 19:35 | <TabAtkins> | Yes, that's a rather more verbose statement of it. |
| 19:35 | SamB_MacG5 | wonders how hard it would be to make the HTML spec display like the multi-page version, while still keeping a DOM like that of the single-page version |
| 19:35 | SamB_MacG5 | also wonders if this would perform better |
| 19:36 | <TabAtkins> | What do you mean by "display like"? |
| 19:36 | <Hixie> | yeah i _definitely_ don't agree with the principles in /bedrock/ |
| 19:36 | <SamB_MacG5> | TabAtkins: I mean, showing one chunk at a time |
| 19:36 | <SamB_MacG5> | however the multi-page version is chunked |
| 19:37 | <TabAtkins> | SamB_MacG5: Ah, kk. That would help with some performance issues (less things in the rendering structure at once), but not all. |
| 19:39 | <SamB_MacG5> | TabAtkins: Yes, that was my thinking |
| 19:40 | <SamB_MacG5> | I mean, at the very least it the browser wouldn't have to look at the hidden parts of the tree during layout, right? |
| 19:40 | <jgraham> | The problem with philosphy is that it sounds good with highfalutin ideas, but when the real world comes along it tends to fall apart rather quickly |
| 19:40 | <TabAtkins> | Correct. display:none things dont' show up in the render tree at all. |
| 19:41 | <TabAtkins> | jgraham: And yet, it seems to be working out well for us. |
| 19:41 | <Hixie> | i think the problem with /bedrock/ is that it has a faulty initial assumption. e.g. I wouldn't describe the JVM as particularly core to what Java is. |
| 19:41 | <Hixie> | there are "platform" concepts that apply above it -- the language apis, e.g. |
| 19:41 | <jgraham> | TabAtkins: What does? |
| 19:41 | <SamB_MacG5> | and, while there's no *guarantee* that source locality corresponds with address-space locality, it seems likely that it often would? |
| 19:41 | <Hixie> | there are "platform" concepts that apply below it -- the chip's number of processors, cache lines, etc, e.g. |
| 19:41 | <Hixie> | and you don't _need_ a jvm for java anyway |
| 19:42 | <SamB_MacG5> | as long as most of the DOM was left pristine? |
| 19:42 | <Hixie> | and you can write non-java to the jvm |
| 19:42 | <Hixie> | and there are things the jvm can do that java can't |
| 19:42 | <Hixie> | anyway |
| 19:42 | <SamB_MacG5> | you don't need a JVM to use JVM code, for that matter ;-) |
| 19:42 | <TabAtkins> | jgraham: The concept of "specify the minimum amount of magic at the bottom, and then define all the author-useful stuff in terms of that, rather than just defining author-useful things directly with larger amounts of magic". |
| 19:43 | <SamB_MacG5> | I can think of two ways to use JVM code without a JVM |
| 19:43 | <Hixie> | TabAtkins: what is "magic"? |
| 19:43 | <TabAtkins> | When people violate that, authors end up having to reimplement the entire thing from the ground up to make small tweaks. |
| 19:43 | <TabAtkins> | Hixie: Anything you can't do (or can't do performantly) from author-space code. |
| 19:43 | <jgraham> | TabAtkins: Where is that working out for you? |
| 19:43 | <jgraham> | CSS certainly doesn't seem like an example of taht |
| 19:43 | <jgraham> | And web compoents doesn't exist yet |
| 19:43 | <SamB_MacG5> | TabAtkins: that reminds me of Python |
| 19:43 | <TabAtkins> | jgraham: For example, all of our attempts to expand the web platform as part of the Parkour project. |
| 19:44 | <Hixie> | TabAtkins: so in java, everything is magic? |
| 19:44 | <TabAtkins> | Web Components, MDV, etc. |
| 19:44 | <Hixie> | TabAtkins: indeed, in C++, everything is magic? |
| 19:44 | <TabAtkins> | Hixie: Huh? |
| 19:44 | <Hixie> | TabAtkins: i don't understand your definition of "magic" |
| 19:44 | <Ms2ger> | Huh? |
| 19:44 | <jgraham> | SamB_MacG5: Python has *loads* of magic |
| 19:44 | <jgraham> | TabAtkins's definition sounds like C |
| 19:45 | <TabAtkins> | Hixie: Hm, not sure how to restate it. Anything you can't polyfill with reasonable performance is probably magic. |
| 19:45 | <Hixie> | TabAtkins: x86 has instructions that perform stuff that you can't do "performantly" using other instructions, are they magic? |
| 19:45 | <TabAtkins> | The amount of magic is proportional to how much of the stack you need to reimplement to tweak details of it. |
| 19:45 | <SamB_MacG5> | jgraham: I was thinking about how much more of the magic is kept in the Lib/ tree than in the core |
| 19:45 | <TabAtkins> | Hixie: Yes, the lowest-level things are always magic. |
| 19:46 | <Hixie> | you can build non-magic on top of magic? o_O |
| 19:46 | <SamB_MacG5> | (and isn't really magic at all) |
| 19:46 | <TabAtkins> | By definition, yes. |
| 19:46 | <Hixie> | i think a different term would be more helpful here for me to understand what you're trying to argue |
| 19:46 | <SamB_MacG5> | Hixie: never heard of magitek? |
| 19:46 | <TabAtkins> | Perhaps a better term to help your understanding would be "atomic"? |
| 19:46 | <jgraham> | SamB_MacG5: But all the protocols and stuff in python are built-in magic |
| 19:46 | <TabAtkins> | An indivisible piece of functionality? |
| 19:47 | <Hixie> | TabAtkins: i think the problem is that you seem to be assuming that being able to divide functionality is a good thing |
| 19:47 | <TabAtkins> | Something which acts as if it's a bottom layer, rather than being composed of other things. |
| 19:47 | <SamB_MacG5> | the __methods__ are, yes |
| 19:47 | <TabAtkins> | Being able to divide functionality *is* good. It's not an unrestricted good, of course - it often hurts performance. |
| 19:47 | <SamB_MacG5> | otherwise, the protocols are not part of Python |
| 19:47 | <jgraham> | Anyway to me the "bedrock" post sounds like second system syndrome |
| 19:47 | <TabAtkins> | Which is why precomposed versions of things are good - you can optimize them, even though they're not bottom-level. |
| 19:48 | <SamB_MacG5> | they are just applied late-binding |
| 19:48 | <jgraham> | On the other hand, I do think the Web Components project is interesting and potentially useful |
| 19:48 | <Hixie> | TabAtkins: nah, i disagree. it's way more subtle than that. you have to balance api usability, security, performance, efficiency -- all these things lead to finding a balance and does not at all lead to always suggesting that the best API is the one that can be ultimately decomposed. |
| 19:48 | <TabAtkins> | Hixie: The funny thing, we'd argue the opposite. This is an attempt to take an elephantine, feature-laden monstrosity and bake it back down into a number of small, elegant systems. |
| 19:48 | <SamB_MacG5> | TabAtkins: you want small but powerful primitives ("system calls"), from which the rest can be built ("userspace code") |
| 19:49 | <TabAtkins> | Hixie: Of course. I wouldn't argue that decomposability is an absolute good that must be preserved at all costs. |
| 19:49 | <TabAtkins> | But it is *a* good, and one which should not be understated. |
| 19:49 | <jgraham> | If it doesn't follow the trajectory of the last three attempts to do the same thing |
| 19:49 | <Hixie> | TabAtkins: sounds like you are arguing exactly that :-) |
| 19:49 | <TabAtkins> | Hixie: Only because you're attempting to distill an absolutist philosophy from what I'm saying. ^_^ |
| 19:50 | <Hixie> | TabAtkins: i tend to do that when someone just says "you're wrong" :-P |
| 19:50 | <SamB_MacG5> | TabAtkins: with the goal being to have more user-servicable parts |
| 19:50 | <TabAtkins> | I was able to jump straight to that because I've butted heads with you on similar things in the past, where you've dismissed the value of decomposability in what I felt was far too cavalier a fashion. |
| 19:50 | <TabAtkins> | SamB_MacG5: Yes. |
| 19:50 | <Hixie> | TabAtkins: i think it's fine to argue from use cases, and the uses cases might lead to an API based on small components, or they might lead to an "elephantine" API that wraps lots of "magic" into a simple performant API that isn't particularly flexible |
| 19:50 | <Hixie> | TabAtkins: i think it's a mistake to just assume that small components are better though |
| 19:51 | <TabAtkins> | Hixie: My first impulse is always to develop what I want the final API to look like, then look for ways to break it down. Occasionally you can't, and need to stay high-level with hidden functionality. But you usually can, and it's usually a good idea. |
| 19:51 | <jgraham> | (It is also kind of funny that you are arguing this point and rniwa and abarth are insisting that WebKit will never allow APIs with JS<->C++ cycles i.e. will block any attempt to add native-backed js-like APIs to the platform) |
| 19:52 | <abarth> | hi |
| 19:52 | <TabAtkins> | jgraham: That's not contradictory. It just means that we have multiple forces pulling on us. |
| 19:52 | <abarth> | i feel like i'm missing context |
| 19:52 | <jgraham> | TabAtkins: That sounds contradictory to me :) |
| 19:52 | <abarth> | jgraham: there might well be a difference between what TabAtkins wants to design and what we're actually able to build |
| 19:52 | <Hixie> | TabAtkins: i think where we disagree is that you're willing to assume that it's a good idea until proved otherwise, whereas i'm more likely to try to keep the API as simple as possible until decomposition is proved necessary. |
| 19:53 | <jgraham> | abarth: Sure |
| 19:53 | <Hixie> | TabAtkins: which is to say, i prioritise simplicity of the API for the use cases over flexibility of the API for unexpected use cases, and you vice versa. |
| 19:54 | <SamB_MacG5> | Hixie: both are important |
| 19:54 | <Hixie> | SamB_MacG5: yes, though they are often at odds |
| 19:54 | <SamB_MacG5> | which is why APIs tend to have layers |
| 19:56 | <dglazkov> | Hixie: I think you understood the difference wrong. The basic tenet of Bedrock post is that for each feature HTML, you should expect a developer to come by and say: "Hey, that's cool! How do I do the same thing, but slightly differently. How do I do that?" |
| 19:56 | <dglazkov> | remember our debates about whether it's useful to have a progress element auto-orients? |
| 19:56 | <jgraham> | (also making this a point about *DOM* specifically is a bit odd. For example if you were building the web from the ground up you might let developers write custom CSS properties in javascript. But I don't think anyone is proposing that) |
| 19:56 | <SamB_MacG5> | jgraham: hmm ... now you've got me imagining use cases ... |
| 19:57 | <Hixie> | dglazkov: sure, that's another aspect of that post. I think the answer to that question should often be "don't", though, which is another way in which i disagree with slightlyoff a lot :-) |
| 19:57 | <TabAtkins> | abarth: It would probably be good to have you review some of the shadow DOM stuff. ^_^ |
| 19:57 | <SamB_MacG5> | but the implementation would involve a lot of new API |
| 19:57 | <astearns> | jgraham: aren't some polyfills "custom CSS properties in javascript"? |
| 19:57 | <jgraham> | astearns: In some limited sense I guess |
| 19:57 | <dglazkov> | Hixie: don't is the answer you can't give |
| 19:58 | <TabAtkins> | Hixie: Yup, when you say "don't", the usual response is "okay, I'll do it myself in JS and ignore your shitty native stuff". |
| 19:58 | <SamB_MacG5> | hmm, actually, sounds like a nightmare for the CSS WG |
| 19:58 | <abarth> | TabAtkins: happy to look at it |
| 19:58 | <TabAtkins> | abarth: dglazkov would know well what the prickly parts probably are. |
| 19:58 | <Hixie> | dglazkov, TabAtkins: people do bad stuff on the web all the time, but we _certainly_ shouldn't optimise the APIs to help them do so. |
| 19:58 | <jgraham> | But I don't think you can e.g. implement your own display: values in a sensible way that interacts with all the other values |
| 19:59 | <SamB_MacG5> | maybe some kind of user-use namespace for CSS properties, with no support for complicated grammars? |
| 19:59 | <jgraham> | and if you did want do do that I guess you would need to expose a crazy amount of internal state of the layout engine |
| 20:00 | <Hixie> | darobin: what's the context behind https://www.w3.org/Bugs/Public/show_bug.cgi?id=18223 ? i'm confused as to why you marked it invalid without even the boilerplate, is it something you know was filed by mistake or something? |
| 20:00 | <astearns> | jgraham: I agree for some value of "sensible" - you can throw a non-sensible amount of javascript towards creating a bespoke layout mode |
| 20:00 | <jgraham> | And you don't want to do that |
| 20:00 | <jgraham> | So we don't support display:function() {} |
| 20:00 | <dglazkov> | Hixie: re: meter/progress <-- I bet you couldn't foresee these scenarios: http://chemicaloliver.net/internet/styling-the-html5-meter-tag-using-the-shadow-dom/ |
| 20:00 | <jgraham> | astearns: Yeah, but that's faking it |
| 20:00 | <TabAtkins> | Right. I think we should expose better primitives for layout, but exactly how far down we go is an important question. |
| 20:01 | <jgraham> | I mean you run your script after all the native layout has happened |
| 20:01 | <SamB_MacG5> | jgraham: more to the point, layout engines change ... |
| 20:01 | <SamB_MacG5> | or, well, not more |
| 20:01 | <Hixie> | dglazkov: we absolutely considered that use case. That's exactly what XBL2 was intended to allow, and what Web Components will allow |
| 20:01 | <TabAtkins> | jgraham: For example, I have a sketch of adding constraints to abspos that lets you do a *lot* of layout with minimal script interaction. |
| 20:01 | <dglazkov> | Hixie: not if you had that crazy magic with auto-rotation depending on width/height ratio |
| 20:01 | <Hixie> | dglazkov: yes, even with that. |
| 20:02 | <TabAtkins> | Heh, relevant quote from a few minutes ago, on an unrelated G+ comment: |
| 20:02 | <TabAtkins> | That would certainly be useful -- as it is there's an enormous cliff between "I got something simple working in CSS" and "I had to ditch the whole bloody thing and rewrite it by hand because I couldn't get control over one little thing"... |
| 20:02 | <TabAtkins> | ^^^ Quote from Joel Webber |
| 20:02 | <Hixie> | dglazkov: the rotation is implemented by the default binding, so providing a new binding lets you do whatever rotation you want. |
| 20:02 | <astearns> | heh |
| 20:02 | <jgraham> | TabAtkins: But that isn't really the "bedrock" philosphy. You're not allowing users to inject script into the layout lifecycle, or subclass display schemes |
| 20:03 | <SamB_MacG5> | jgraham: you can't provide hooks for *everything* |
| 20:03 | <jgraham> | You're proposing a much more limited set of powers that has the practical advantage of being implemntable |
| 20:03 | <TabAtkins> | jgraham: There's a gradient from "write it in assembly" to "just use this predefined element". |
| 20:03 | <Hixie> | dglazkov: (in fact i would say that's a great example of why the way webkit implemented meter is wrong) |
| 20:03 | <dglazkov> | Hixie: see quote above from Joel. To get rid of auto-rotation, you have _rewrite_the_whole_thing_ |
| 20:03 | <jgraham> | TabAtkins: Hence my point about philosophy quickly crumbling against the rigours of reality |
| 20:03 | <Hixie> | dglazkov: no, you only have to rewrite the rendering. |
| 20:04 | <Hixie> | dglazkov: that's the whole point of web components (specifically, css-bound web components) |
| 20:04 | <TabAtkins> | jgraham: Obviously, the correct answer isn't always "expose the lowest-level thing all the time". However, it *is* correct to seek out the lowest-level thing you can reasonably expose, rather than just stopping once you've created something which solves the use-cases presented. |
| 20:04 | <Hixie> | the lowest-level thing you can _reasonably_ expose _is_ what you're created that solves the use cases presented. :-) |
| 20:04 | <jgraham> | I don't think that's true |
| 20:05 | <jgraham> | Ah, Hixie beat me |
| 20:05 | <jgraham> | It's not like it's *hard* to think of use cases |
| 20:05 | <TabAtkins> | Hixie: That's wrong. There are always use-cases that weren't presented to you. Finding a spanning set of primitives often works better than exactly solving the use-cases you happened to see. |
| 20:05 | <astearns> | I'm with Tab - the use cases presented are almost always the tip of the iceberg |
| 20:05 | <SamB_MacG5> | Hixie: some specs don't expose the thing, though |
| 20:06 | <Hixie> | TabAtkins: as spec editor it is one's job to seek out such use cases |
| 20:06 | <TabAtkins> | *Then* you define things on top of those primitives that exactly solve those use-cases. |
| 20:06 | <SamB_MacG5> | they just use it internally |
| 20:06 | <TabAtkins> | Hixie: As a spec editor who thinks he does his job well, I always find more use-cases after the fact. |
| 20:06 | <jgraham> | But with e.g. Shadow DOM the problem has *never* been lack of use cases |
| 20:06 | <jgraham> | We have known for more than a decade that there were use cases that needed that sort of capability |
| 20:07 | <Hixie> | TabAtkins: in my experience, when i find use cases after the fact, they would rarely have been solved by my taking a more decomposed approach -- because you can't know how to decompose it if you don't know what the use cases are. |
| 20:07 | <SamB_MacG5> | jgraham: well, yeah; the Mozilla sources are full of them ;-) |
| 20:07 | <jgraham> | The problem has always been finding something that is simple enough to get cross-browser implemntations |
| 20:08 | <TabAtkins> | Hixie: Sometimes, sure. However, small tweaks from the existing use-cases are often easy if you did a decomposed approach (because you can more easily slot in the small change you want), and extending the solution later is often easy as well, for the same reason. |
| 20:09 | <jgraham> | So if you want it to succeed, you should prioritise simplicity of implementation over flexibility, subject to the constraint that you still meet (the most significant) use cases |
| 20:09 | <TabAtkins> | I mean, don't decompose too early or too aggressively, because there are always multiple ways to do it, and it can be hard to tell which way is best. But keep it in mind, and as patterns emerge, break ti down. |
| 20:09 | <TabAtkins> | jgraham: Often, breaking things down aids simplicity of implementation, because each piece is simpler. |
| 20:09 | <TabAtkins> | (Though often the total complexity is somewhat higher.) |
| 20:09 | <SamB_MacG5> | I guess you should try to decompose in a way that simplifies implementation? |
| 20:10 | <Hixie> | TabAtkins: sure, you should definitely design features to fit all the use cases, included use cases taht you come up with that are small tweaks of previous ones. |
| 20:10 | <jgraham> | TabAtkins: That doesn't obviously follow |
| 20:10 | <jgraham> | But my main point stands |
| 20:10 | <SamB_MacG5> | it's simpler to make progress in implementing something that's decomposed: |
| 20:11 | <jgraham> | Which is that if I were designing this feature I would be prepared to compromise on flexibility whereever it aided implementability |
| 20:11 | <SamB_MacG5> | you implement a piece that doesn't depend on any pieces you don't have yet |
| 20:11 | <TabAtkins> | SamB_MacG5: Yes, that's often the right thing to do, I think. If you find the cleave points in the implementation, it's usually better for overall performance when you reuse individual bits. |
| 20:11 | <Hixie> | TabAtkins: my point is that you shouldn't prematurely decompose when doing so is _not_ necessary to address use cases, because (a) that makes the API more complicated, (b) it's not necessary (by definition), and (c) it likely doesn't address the unknown use cases, and in fact, can preclude addressing them due to over-designing (it's easier to shift direction later if you haven't over-decomposed) |
| 20:11 | <TabAtkins> | Hixie: I agree with you. I believe we simply disagree on when it's "premature". |
| 20:12 | <TabAtkins> | Based on the types of APIs that we make in Parkour, and the types of APIs that you make in HTML. ^_^ |
| 20:12 | <Hixie> | my definition is easy: you do the minimum necessary to address all the use cases |
| 20:12 | <jgraham> | TabAtkins: Really? e.g. slightlyoff's example of being able to reuse <canvas> to customise drawing of form controls doesn't seem like it would make anything easier or more performant |
| 20:12 | <SamB_MacG5> | Hixie: it could make the API more complicated, sure; but it might make it simpler to understand or implement |
| 20:12 | <jgraham> | (or rahter 2D context, I guess) |
| 20:12 | <Hixie> | SamB_MacG5: ease of implementation is a lower priority than ease of usability (because there's like 4 groups of implementors, and millions of authors.) |
| 20:13 | <SamB_MacG5> | Hixie: but understanding is something the users use |
| 20:13 | <Hixie> | SamB_MacG5: authors |
| 20:13 | <Hixie> | SamB_MacG5: but yes, and simpler APIs tend to be simpler to understand. |
| 20:13 | <TabAtkins> | Hixie: However, implementation often guides you to the correct cleave points for performance. |
| 20:13 | <Hixie> | SamB_MacG5: just compare HTML (high-level composed features) to XBL (very decomposed featureset) :-) |
| 20:14 | <SamB_MacG5> | Hixie: you'll have to excuse me when I say "user" when I mean "programmer"; I hang out in *nix circles ;-) |
| 20:14 | <Hixie> | TabAtkins: decomposition is _definitely_ not the way to get higher performance for hte common case (though it can lead to higher performance for the more unusual cases) |
| 20:15 | <Hixie> | SamB_MacG5: in web circles, user=the reader, author=the programmer, implementor=the browser vendor |
| 20:15 | <TabAtkins> | Yes, I've already stated that. Decomposing can hurt performance, which is why you should also provide precomposed versions that you can black-box optimize. |
| 20:15 | <SamB_MacG5> | anyway, I like legos |
| 20:15 | <Hixie> | TabAtkins: i think we're more or less in agreement, we just tend to apply this all quite differently |
| 20:15 | <TabAtkins> | That's what I've been saying. ^_^ |
| 20:15 | <Hixie> | TabAtkins: and somehow i'm happier with what we have overall than you :-P |
| 20:16 | <Hixie> | anyone understand https://www.w3.org/Bugs/Public/show_bug.cgi?id=17936 ? |
| 20:17 | <jgraham> | Hixie: I understand that it should be resolved INVALID for deviation from the English language as we know it |
| 20:17 | <Hixie> | just a minute, buzz for deviation? |
| 20:17 | <Ms2ger> | ^ |
| 20:17 | <jgraham> | :) |
| 20:18 | <TabAtkins> | How would you write the gerund of "arc"? |
| 20:18 | <Hixie> | man i miss that show |
| 20:18 | <Ms2ger> | It's still on ;) |
| 20:18 | <Hixie> | yeah, but there's no podcast |
| 20:18 | <TabAtkins> | "arcing"? |
| 20:18 | <jgraham> | There is iplayer |
| 20:18 | <Ms2ger> | Yeah |
| 20:18 | <Hixie> | really? |
| 20:18 | <Hixie> | oooh... |
| 20:18 | <Hixie> | i may have to hook myself up a manual podcast |
| 20:18 | <Hixie> | they VERY OCCASIONALLY put it on the comedy of the week podcast |
| 20:18 | <Ms2ger> | "Listen now (3 days left)" |
| 20:18 | <Hixie> | they put the indian one recently on |
| 20:19 | <jgraham> | http://www.bbc.co.uk/programmes/b01mqmsb |
| 20:19 | <Ms2ger> | When they were in India? That's ages ago! :) |
| 20:19 | <Hixie> | yeah, that was a while back |
| 20:19 | <Hixie> | that's the last one they had on though |
| 20:19 | <Hixie> | ("recently" as in "in the past 2 years") |
| 20:20 | <jgraham> | It wasn't *that* long ago |
| 20:20 | SamB_MacG5 | closes that as NEEDSINFO, on the theory that they could get someone to help them with their english |
| 20:20 | SamB_MacG5 | has no idea why he's allowed to do that |
| 20:21 | <jgraham> | FWIW I think the point of the bug was that they want HTML to be simple for distributing textual information or something |
| 20:21 | <SamB_MacG5> | that is certainly a goal |
| 20:22 | <TabAtkins> | And is luckily already met! RESOLVED WORKSFORME |
| 20:22 | <SamB_MacG5> | shouldn't do that unless you can actually understand the message ;-) |
| 20:23 | <TabAtkins> | Yeah, the current resolution is the best one. ^_^ |
| 23:17 | <rniwa> | sicking: yt? |
| 23:17 | <sicking> | rniwa: yup |
| 23:17 | <rniwa> | sicking: hi! |
| 23:18 | <rniwa> | sicking: do you care about interop. of mutation observers in the presence of mutation events? |
| 23:18 | <rniwa> | sicking: in particular, what happens regards to delivering mutation records and the order thereof when mutation event listeners modify DOM. |
| 23:19 | <rniwa> | sicking: as far as we know, mutation events isn't spec'ed in DOM4 so we can't really spec it. |
| 23:19 | <sicking> | rniwa: i personally don't particularly care that much no |
| 23:19 | <rniwa> | sicking: okay. |
| 23:20 | <rniwa> | sicking: i'm a bit worried that some js libraries (notably rich text editors) rely on mutation events |
| 23:20 | <rniwa> | sicking: and other libraries on the same page that use mutation observers might get confused |
| 23:20 | <sicking> | rniwa: i can't speak for Olli, but it seems like that time would be better spent adding code that warns about mutationevents being used and otherwise discouraging people from using them |
| 23:20 | <rniwa> | sicking: but i guess that might be too much of an edge case to worry about :) |
| 23:21 | <rniwa> | sicking: true. |
| 23:21 | <rniwa> | sicking: but there will be some time before all major browsers on desktop & mobile start shipping mutation observers. |
| 23:21 | <sicking> | rniwa: so i take it that you will be adding mutationrecords in reverse order in some cases? |
| 23:21 | <rniwa> | sicking: e.g. Safari hasn't implemented mutation observers yet. |
| 23:21 | <rniwa> | sicking: no. |
| 23:21 | <rniwa> | sicking: we'll be enqueuing earlier sometimes |
| 23:21 | <sicking> | rniwa: Safari for iOS6 apparently has mutationobservers |
| 23:22 | <rniwa> | sicking: it does? |
| 23:22 | <rniwa> | interesting. |
| 23:23 | <sicking> | caniuse doesn't have them, but i read it on the internet so i'm sure it's true :0 |
| 23:23 | <sicking> | :) |
| 23:25 | <rniwa> | sicking: apparently, safari doesn't get the end of task right :( |
| 23:25 | <rniwa> | sicking: so editing case is broken. |
| 23:26 | <sicking> | fabulous :( |
| 23:26 | <rniwa> | oh well… i guess we can file a apple bug. |
| 23:26 | <rniwa> | an* |
| 23:28 | <rniwa> | anyway, thanks. |
| 23:29 | <rniwa> | sicking: fwiw, https://bugs.webkit.org/show_bug.cgi?id=97372 is the relevant bug. |
| 23:52 | <sicking> | rniwa: so i'm still confused as to what you're actually doing? |