| 00:07 | <TabAtkins> | If I got kicked for writing long emails, I'd have a problem. |
| 00:08 | <Philip`> | Think of the problems that readers would be saved from, though |
| 01:30 | <weinig> | Hixie: I have kind of a dumb question, but I am having trouble finding the answer in the spec |
| 01:30 | <weinig> | Hixie: are <script> tags in innerHTML and insertAdjacentHTML supposed to run? |
| 01:32 | <TabAtkins> | Pretty sure, yes. |
| 01:32 | <weinig> | TabAtkins: pretty sure it should run the scripts? |
| 01:33 | <weinig> | neither Firefox nor WebKit seem to |
| 01:33 | <TabAtkins> | I think so, at least. But I could easily be wrong. |
| 01:33 | <TabAtkins> | And I can't point you to a yay/nay in the spec. |
| 01:33 | <weinig> | that is my problem :( |
| 01:34 | Philip` | tries to follow the behaviour of the parser-inserted flag in the spec |
| 01:34 | Philip` | fails |
| 01:34 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/images/parsing-model-overview.svg looks weird and broken in Opera |
| 01:39 | <roc> | yes, looks like an Opera bug ... someone probably forgot to start a new path when drawing the marker |
| 01:49 | <Hixie> | wirepair: it's defined, but it's a bit subtle. The answer is no for innerHTML, and I forget for insertAdjacentHTML. |
| 01:49 | <Hixie> | er |
| 01:49 | <Hixie> | weinig: ^ |
| 01:49 | <Hixie> | sorry wirepair |
| 01:49 | <weinig> | thanks |
| 01:50 | <weinig> | they both say similar things about inserting the document fragment into the document |
| 01:50 | <Hixie> | gotta go right now, but if you can't work it out and need an answer, ping me again in a bit :-) |
| 01:50 | <weinig> | ok, thanks |
| 06:41 | <hsivonen> | whoa: https://twitter.com/#!/joehewitt/status/117017829861113857 |
| 06:42 | <hsivonen> | https://twitter.com/#!/joehewitt/status/117017571320016897 |
| 06:43 | <Hixie> | man, i can never understand what people are saying on twitter |
| 06:49 | <roc> | /on twitter/ |
| 08:40 | <Kellen`> | hsivonen: another recommendation for validator.nu: error codes in JSON output so that users can catch and report errors consistently if the message texts change |
| 08:42 | <hsivonen> | Kellen`: yeah, well, that would require having the capability to propagate codes. it's currently SAX ErrorHandler-based |
| 08:43 | <hsivonen> | Hixie: he seems to be saying that SemWeb stuff becomes more important when browsers diminish |
| 08:43 | <hsivonen> | (diminish in the sense that native iOS apps take over) |
| 08:59 | <Kellen`> | hsivonen: okay, that makes sense. thanks |
| 09:17 | <Ms2ger> | "Authors should not, but may" |
| 09:27 | <MikeSmith> | Kellen`: fwiw, the W3C systems team has also ask for error IDs, for localization purposes |
| 09:27 | <MikeSmith> | I told them the same thing that hsivonen told you |
| 09:28 | <MikeSmith> | but they've told me they are planning on trying to add them, and contributing a patch |
| 09:28 | <MikeSmith> | I don't quite know how they plan to do it, but I think they have someone assigned to work on it |
| 09:29 | <Kellen`> | MikeSmith: you could use a properties file for all the error strings and do the localization on output from the webservice |
| 09:29 | <MikeSmith> | yeah |
| 09:29 | <Kellen`> | messy, but it'd achieve the purpose |
| 09:29 | <MikeSmith> | I think hsivonen discusses that approach in his thesis, actually |
| 09:30 | <Kellen`> | haven't read it yet, ha |
| 09:30 | <MikeSmith> | it's a good read |
| 09:30 | <MikeSmith> | http://hsivonen.iki.fi/thesis/html5-conformance-checker.xhtml |
| 09:30 | <MikeSmith> | though some of the code has changed considerably since the time when he wrote that |
| 09:31 | <MikeSmith> | for one thing, I think he wrote it before he implemented the validator.nu conforming HTML5 parser |
| 09:32 | <MikeSmith> | http://hsivonen.iki.fi/thesis/html5-conformance-checker.xhtml#localizability |
| 09:32 | <MikeSmith> | that part discusses the error messages |
| 09:33 | <MikeSmith> | and "reverse templating" |
| 09:33 | <Kellen`> | thanks, yeah that was exactly what i was thinking |
| 09:34 | <Kellen`> | i'm using the parser internally so the localization doesn't matter so much, but it'd be nice not to have to update my code if the messages change ever so slightly |
| 09:34 | <MikeSmith> | yeah |
| 09:46 | <zcorpan> | Ms2ger: so the spec has three different rfc2119 keywords for the same thing. "must not use foo" "should not use foo" "may use foo (and ignore other requirements)" |
| 11:26 | <robnyman_> | Testing out HTML5 Forms and setCustomValidity("Any message I want") |
| 11:26 | <robnyman_> | WHen I try to combine that check oninput with checkValidity, it is always invalid |
| 11:27 | <robnyman_> | Shouldn't checkValidity still resort to the built-in validation even do I use setCustomValidity? |
| 11:28 | <robnyman_> | An example can be seen at http://jsfiddle.net/mathias/htsLW/ |
| 11:29 | <robnyman_> | Basically, after any input and the usage of setCustomValidity, checkValidity always returns false |
| 11:30 | <Rik`> | robnyman_: yes, you need to do setCustomValidity('') |
| 11:31 | <Rik`> | oh that's what you do |
| 11:32 | <robnyman_> | Rik`: Yep. I think doing my own check and setting setCustomValidity would work. But checkValidity seems broken if you use it in conjunction with setCustomValidity |
| 11:33 | <robnyman_> | Which really makes it harder if I have to roll my own validation algorithm just because I use setCustomValidity to have my own message in the web browser's native UI |
| 11:35 | <Rik`> | there's no real check in your logic here |
| 11:35 | <robnyman_> | In what sense? |
| 11:35 | <robnyman_> | It checks validity for every input |
| 11:37 | <Rik`> | we have the x-moz-errormessage attribute to change the messag |
| 11:38 | <robnyman_> | Rik`: I know, but that doesn't seem to be standardized nor do I have any other option to make it work cross browser |
| 11:39 | <robnyman_> | So I'm trying to figure out if setCustomValidity should cancel out checkValidity completey, or if there is something wrong in the implementations |
| 11:39 | <Rik`> | then we need to standardize it maybe ? :) |
| 11:39 | <robnyman_> | Rik`: Oh, definitely! |
| 11:49 | <robnyman_> | A combination of resetting setCustomValditiy on input and using setCustomValidity for the invalid event is the only way I can make it work |
| 11:49 | <robnyman_> | http://jsfiddle.net/SNysL/2/ |
| 11:50 | <robnyman_> | And removing a message by an empty string, BTW - shouldn't it be another method, like removeCustomAbility? |
| 12:07 | <hsivonen> | does anyone happen to remember which fires first: the last progress event for XHR or the DOMContentLoaded on responseXML? |
| 13:34 | <zcorpan> | thanks AryehGregor for updating atob |
| 13:48 | <MikeSmith> | anybody know if a PHP class can have multiple constructors? |
| 13:48 | <MikeSmith> | with different signatures |
| 13:48 | MikeSmith | googles |
| 14:27 | <hsivonen> | is XHR Level 2 part of HTML5? :-) |
| 15:54 | <hober> | TabAtkins: you really should have resolved one of those as "everyone's a porc porc" |
| 15:55 | <hober> | TabAtkins: totally missed the humor window there :) |
| 16:57 | <wilhelm> | This might be of interest to some of you: http://lists.w3.org/Archives/Public/public-test-infra/2011JulSep/0031.html |
| 17:03 | <AryehGregor> | wilhelm, sounds awesome if people actually attend. Do you know who else is coming? |
| 17:03 | <AryehGregor> | Presumably Google, if it's at Google headquarters . . . |
| 17:04 | <wilhelm> | AryehGregor: Yes. Google, Mozilla, Opera and Microsoft have shown interest. Pending actual signups. (c: |
| 17:04 | <wilhelm> | I haven't heard back from Apple. |
| 17:04 | <AryehGregor> | Nice. |
| 17:04 | <AryehGregor> | There are quite a lot of tests floating around at this point that browsers should all be running. |
| 17:05 | <AryehGregor> | Although this reminds me, I need to give some people a poke (and/or stab) about my reflection tests again. |
| 17:05 | <AryehGregor> | They seem to be moldering indefinitely in submission/. |
| 17:05 | <wilhelm> | TabAtkins (and possibly others - you guys need to figure that out :) will attend from Google. I have also invited Simon Stewart separately (Google too, but from the WebDriver project). |
| 17:06 | AryehGregor | isn't really part of "you guys" when it comes to Google |
| 17:06 | AryehGregor | justs happens to receive money from them for some reason |
| 17:06 | <wilhelm> | Yes. And I know several browser vendors, Opera included, have large numbers of unreleased tests. |
| 17:06 | <wilhelm> | They should be released, in formats all the other browser vendors can use. (c: |
| 17:06 | <AryehGregor> | Well, it can't be "several" when there are only two notable browser vendors whose rendering engines are closed-source. |
| 17:07 | <AryehGregor> | I somehow doubt Mozilla or anyone from WebKit has many secret tests. |
| 17:07 | <AryehGregor> | They have lots that other browsers can't straightforwardly use as it stands, though. |
| 17:07 | <gsnedders> | AryehGregor: Apple do, certainly. |
| 17:07 | <AryehGregor> | Really? For testing the rendering engine and not just the browser UI and such? |
| 17:08 | <wilhelm> | Eh, yes, that could have been phrased better. Not all the publicly available tests have been submitted to working groups, using sensible frameworks and formats. (c: |
| 17:08 | <gsnedders> | For testing the rendering engine. They can't have copies of Gmail and the like publicly, for example. |
| 17:08 | <AryehGregor> | Like, tests that are going to fail when people do WebKit checkins but the people who do the checkin won't notice for who knows how long because the WebKit buildbots don't run the tests? |
| 17:09 | <gsnedders> | AryehGregor: Potentionally yes. |
| 17:09 | <AryehGregor> | I thought copies of things like Gmail are useless because they change way too rapidly and are way too complicated, so that you're best off just waiting for user reports. |
| 17:10 | <AryehGregor> | I guess user reports aren't as helpful when you have a Safari-style release schedule instead of a Chrome/Firefox schedule with bajillions of beta testers. |
| 17:10 | <gsnedders> | AryehGregor: Whether it's for performance testing or regression testing is a good question, but they certainly have copies of major sites and the like. |
| 17:10 | <AryehGregor> | Interesting. |
| 17:10 | <AryehGregor> | Not really relevant to standards, though. |
| 17:10 | <gsnedders> | No, but who knows what other tests they have privately/ |
| 17:10 | <gsnedders> | *? |
| 17:12 | <gsnedders> | AryehGregor: But yeah, the more serious point is the majority of tests vendors have isn't really in any form useful to any other vendor. |
| 17:12 | <wilhelm> | Also, tests requring some sort of user interaction is an unsolved problem. I think every browser vendor is doing something slightly different, if they are automating such things at all. |
| 17:16 | <AryehGregor> | Yeah, I could really use that for my editing tests. |
| 17:17 | <wilhelm> | I think some mutation of WebDriver is the solution. Which is why I've invited Simon Stewart (and why the basic WebDriver API will be specced and standarized in the tools WG). |
| 17:18 | <AryehGregor> | Makes sense. |
| 17:19 | <wilhelm> | We use the Watir API at Opera (which is built on top of the more verbose WebDriver API). |
| 17:19 | <gsnedders> | AIUI Google are using WebDriver too for Chrome |
| 17:21 | <wilhelm> | Yep, with a slightly different flavour. (c: |
| 17:26 | <gsnedders> | Python bindings? |
| 17:28 | <wilhelm> | I've been told Mozilla uses the Python bindings. |
| 17:29 | <gsnedders> | Don't they all work with each other, if only by the remote protocol? |
| 17:32 | <wilhelm> | They do. But it would be nice to have a test suite in one language, not part Java, part Ruby, part Python, part .NET. (c: |
| 17:33 | <gsnedders> | Well, yes :) |
| 17:33 | <AryehGregor> | Surely we'd want it all JavaScript. |
| 17:33 | <wilhelm> | 927? :P |
| 17:36 | <gsnedders> | AryehGregor: When nobody uses that today? |
| 17:37 | <AryehGregor> | gsnedders, nobody but Opera uses the W3C test formats at all today, that I'm aware of. |
| 17:37 | <gsnedders> | AryehGregor: And would require a different WebDriver impl for each JS engine, if people cared about that? |
| 17:37 | <AryehGregor> | Isn't WebDriver something people want to implement in browsers anyway? Or am I confusing it with something else? |
| 17:37 | <gsnedders> | AryehGregor: I believe WebKit run some. |
| 17:37 | <AryehGregor> | Oh, I am. |
| 17:37 | <gsnedders> | AryehGregor: You need something to control the web browser, and something that exposes an API to control it with. |
| 17:37 | Philip` | thinks standardising on languages sounds like a pretty futile exercise, since everyone has their own favourites and not enough motivation to use a different one |
| 17:38 | <AryehGregor> | We need to use JS for the tests anyway. We should avoid using any other language if it's not strictly necessary. |
| 17:38 | <wilhelm> | That something that controls the browser must be outside the browser. |
| 17:38 | <Philip`> | (Better to design a system that can cope with diversity, rather than trying to get rid of all diversity) |
| 17:38 | <AryehGregor> | Yeah, granted. |
| 17:38 | <AryehGregor> | I was thinking WebDriver was something else. |
| 17:38 | <AryehGregor> | Philip`, diversity is bad if you expect the same people to maintain all the code. |
| 17:39 | <gsnedders> | AryehGregor: But what JS engine? What host object API do you use to impl the code to control the browser? |
| 17:39 | <AryehGregor> | I know that MediaWiki has a small part (texvc) written in OCaml that's bitrotted for years because the only language all the devs know is PHP. |
| 17:39 | <AryehGregor> | gsnedders, it shouldn't matter, right? JS is standard! :) |
| 17:39 | <gsnedders> | AryehGregor: How could you communicate with a browser through JS, though? |
| 17:40 | <wilhelm> | gsnedders: Actually, if someone did write JS bindings for WebDriver, it would magically work in all browsers. |
| 17:40 | <gsnedders> | wilhelm: Using the remote API? |
| 17:40 | <Philip`> | AryehGregor: If it's meant to integrate with browser developers' testing systems (getting tests from them and giving other tests to them), then the relevant people are not all the same people |
| 17:40 | <wilhelm> | gsnedders: By simply mapping the JS function calls to the WebDriver API calls. |
| 17:41 | <wilhelm> | All the business logic is one level below. |
| 17:41 | <Philip`> | OCaml is unusually obscure compared to PHP/Python/Perl/Ruby/JS/etc |
| 17:41 | <gsnedders> | wilhelm: But how would it call the WebDriver API? |
| 17:41 | <wilhelm> | If someone would be willing to make that investment, this might be a possible solution. |
| 17:42 | <wilhelm> | gsnedders: Eh. Andreas would know. (c: |
| 17:42 | wilhelm | is a dump user in this particular case. |
| 17:42 | <wilhelm> | eh, dumb |
| 17:42 | <gsnedders> | wilhelm: I mean, the only way I can think is to use the remote API, hence communicating over HTTP. |
| 17:42 | <wilhelm> | Yes, I think that's what the different bindings use. |
| 17:42 | <AryehGregor> | I should clarify that the tests themselves should be entirely in JS. |
| 17:43 | <AryehGregor> | If there's some browser- and/or OS-specific framework that's not in JS that only a few people have to understand, that's okay. |
| 17:44 | <gsnedders> | AryehGregor: Running in each browser in some privilaged mode? |
| 17:44 | <gsnedders> | The aim of the WebDriver approach is to run tests in the normal executation mode. |
| 17:45 | <gsnedders> | If you want to use WebDriver within JS, it may as well be from a JS shell, which means managing to implement WebDriver host objects. |
| 17:45 | gsnedders | is most unclear what people are proposing here |
| 17:45 | <ryanmunger> | hi all |
| 17:45 | <ryanmunger> | found our about this room by reading jeremy keith's masterpiece "HTML5 for web designers" |
| 17:46 | <AryehGregor> | You've caught us. |
| 17:46 | <AryehGregor> | This is where we all lurk and conspire. |
| 17:46 | <AryehGregor> | Hi. |
| 17:46 | <ryanmunger> | excellent! |
| 17:47 | <jarib> | wilhelm, gsnedders: there has been some work on a pure JS WebDriver http://selenium.googlecode.com/svn/trunk/javascript/webdriver-jsapi/ |
| 17:47 | <ryanmunger> | i am excited to start using the new strucrural elements, as well as microformats! |
| 17:47 | <jarib> | not sure how it works exactly |
| 17:48 | <ryanmunger> | the only thing that is strange about html5 is the fact that we can have like 10 <h1> tags on the same page |
| 17:48 | <ryanmunger> | how does google and other search engines view that at the moment? |
| 17:48 | <jarib> | but a JS client could potentially use the existing wire protocol (which is JSON/HTTP) |
| 17:49 | <wilhelm> | jarib: Interesting. Is the project alive? |
| 17:50 | <jarib> | wilhelm: the dev doing most of the work has been out for a while due to an injury, so not at the moment. |
| 17:51 | <gsnedders> | jarib: Right, that's what I was guessing. So it could run in one browser and potentionally control another. |
| 17:51 | <jarib> | yep |
| 17:52 | <gsnedders> | Would likely require XHR2, though, as to communicate with the wire protocol |
| 17:53 | <wilhelm> | Running it in a second browser would be suboptimal for completely automated testing, though. |
| 17:54 | <gsnedders> | Yes. Though it'd be interesting to see how running it in the same browser would affect testing. |
| 17:54 | <wilhelm> | “Interesting”. (c: |
| 17:55 | <gsnedders> | "Well, I hope it won't crash and burn." |
| 17:56 | <AryehGregor> | ryanmunger, mostly here we're excited about the boring matter of writing standards and tests clear enough that browsers actually interoperate in practice. What search engines do is something that a) probably we don't know, and b) we don't care about so much. |
| 17:57 | <ryanmunger> | gotcha |
| 17:57 | <AryehGregor> | Nearly all the active people here are either browser implementers, or spec and/or test writers. |
| 17:57 | <AryehGregor> | Search engines not so much. |
| 17:58 | <AryehGregor> | They use nonstandard heuristics, generally, so not our lookout. We define theoretical semantics and they'll probably support it if they see enough authors using it. |
| 17:58 | <ryanmunger> | wthank you for the clarification |
| 17:58 | <ryanmunger> | i will do my best to keep up |
| 17:58 | <AryehGregor> | Except they'll probably support some variant that better reflects what people actually use, and not follow the standard. |
| 17:58 | <AryehGregor> | So whatever. |
| 17:58 | <ryanmunger> | which follows the whole "pave the cowpaths" model, right? |
| 17:59 | <AryehGregor> | Something like that, yeah. |
| 17:59 | <wilhelm> | It predates any formal model, but yes. (c: |
| 17:59 | <AryehGregor> | Although in our case we try to pave them, search engines are maybe more likely to just use them as-is. |
| 17:59 | <ryanmunger> | i guess a healthy medium of "formal model" and "using what is already being used" would be a good approach... |
| 17:59 | <AryehGregor> | We try to adapt existing browser behavior to be sane enough that we can standardize it without crying ourselves to sleep at night. |
| 18:00 | <ryanmunger> | :) |
| 18:00 | <AryehGregor> | As opposed to matching it exactly. |
| 18:00 | <AryehGregor> | (except when we have to) |
| 18:00 | <ryanmunger> | exciting |
| 18:00 | <wilhelm> | There's a lot of the crying-ourselves-to-sleep. |
| 18:00 | <wilhelm> | I suppose that too can be exciting. :P |
| 18:00 | <ryanmunger> | well, this is a little off topic, but someone needs to tell firefox to find a better way to update their browser |
| 18:01 | <ryanmunger> | since everytime i do, it breaks every plugin i have installed |
| 18:01 | <AryehGregor> | Yeah, I think they know that. |
| 18:01 | <AryehGregor> | They're kind of trapped by the fact that they're adopting this rapid-release thing so late in the game. |
| 18:01 | <ryanmunger> | i can see them using the "update it behind the scenes" model that chrome uses |
| 18:01 | <AryehGregor> | Chrome did it from day one and so they made sure their extension APIs were stable. |
| 18:01 | <ryanmunger> | yeah |
| 18:01 | <ryanmunger> | does anyone develop in chrome, here? |
| 18:01 | <AryehGregor> | Firefox has way deeper extension APIs, so they can't keep them stable, so extensions have to sometimes break on release. |
| 18:01 | <ryanmunger> | i am thinking about making that jump |
| 18:02 | <AryehGregor> | There are a few Chrome developers who hang out here, yeah. |
| 18:02 | <ryanmunger> | i am more of a 60% designer, 40% front end dev |
| 18:02 | <AryehGregor> | We've got at least one or two regular visitors from every major browser except IE. |
| 18:02 | <ryanmunger> | sounds like firefox needs to standardize their plugins? |
| 18:02 | <AryehGregor> | They can't without breaking all of them for good. |
| 18:03 | <AryehGregor> | They're trying to get people to move to Jetpacks, which are more like Chrome extensions and won't break on upgrade (hopefully). |
| 18:03 | <AryehGregor> | And also can be installed without a browser restart, I think. |
| 18:03 | <AryehGregor> | Anyway, that's something they know about and are thinking about, yeah. |
| 18:03 | <ryanmunger> | it will be interesting to see what the future holds in terms of making firefox plugins future proof |
| 18:04 | <ryanmunger> | i feel like it's the wordpress days, when you would update wordpress and your entire site would break |
| 18:04 | <AryehGregor> | Extensions are also holding back Firefox from moving to a multi-process model. |
| 18:04 | <ryanmunger> | i do like that about chrome, as well |
| 18:04 | <ryanmunger> | the mpm |
| 18:04 | <AryehGregor> | ("extensions" and "plugins" are different things for non-IE browsers, by the way -- plugins are things like Flash or Java that use the NPAPI and work cross-browser, extensions are browser-specific) |
| 18:05 | <ryanmunger> | my bad :) |
| 18:05 | <ryanmunger> | still learning the nomen clature |
| 18:06 | <ryanmunger> | all right. time to get back to work. i will be here absorbing a lot of the chatter going on in here |
| 18:06 | <ryanmunger> | thanks for clarifying some things |
| 18:08 | Philip` | hopes ryanmunger is sufficiently absorbent and won't overflow with the chatter |
| 18:09 | <ryanmunger> | well, i definitely feel like the dumbest guy in the room :) |
| 18:09 | <ryanmunger> | but i hope to change that by just taking it all in |
| 18:09 | <AryehGregor> | That's how most of us started. |
| 18:09 | <ryanmunger> | is there a fair share of front end devs in here? |
| 18:10 | <AryehGregor> | No, basically none. |
| 18:10 | <AryehGregor> | Some of us have experience as front-end devs, though. |
| 18:10 | <Philip`> | You could read the last million lines of chat log to catch up with where we are now, if you want |
| 18:10 | <ryanmunger> | lol |
| 18:10 | <AryehGregor> | Well, I guess Philip` is primarily a front-end dev of some kind. |
| 18:10 | <AryehGregor> | I'm a MediaWiki developer, but have been inactive in that for a year or two, since I moved mostly to standards stuff. |
| 18:10 | <Philip`> | I'm not a dev at all :-) |
| 18:11 | <AryehGregor> | What are you? |
| 18:11 | <AryehGregor> | I'm curious. |
| 18:11 | <zewt> | educated guess: human male |
| 18:11 | <Philip`> | An almost-ex PhD student, I suppose |
| 18:11 | <ryanmunger> | what is anyone in this industry anymore? ;D |
| 18:11 | <ryanmunger> | font end user experience standards based designer with an emphasis in usability? |
| 18:11 | <ryanmunger> | :) |
| 18:12 | <ryanmunger> | the terms get so crazy |
| 18:12 | <AryehGregor> | Are you writing a dissertation in anthropology on the social structure of web standards development, or do you have some personal involvement in the web? |
| 18:12 | <ryanmunger> | "we're all designers" |
| 18:12 | <AryehGregor> | . . . Other than as a user. |
| 18:14 | <Philip`> | It's not about anything web-related (it's a few layers further down the stack); I just got involved in HTML5 stuff a while ago since canvas was fun but broken, and then hung around for no particular reason |
| 18:15 | <AryehGregor> | Makes sense. |
| 18:15 | <ryanmunger> | ah, canvas |
| 18:15 | <AryehGregor> | You've mentioned something about game development, no? |
| 18:15 | <ryanmunger> | that thing that adobe will use to create their browser based version of photoshop in the next 10 years :) |
| 18:15 | <zewt> | i'd put money against that :P |
| 18:15 | <zewt> | (for a real value of "photoshop" and not "HalfBakedWebPhotoshop") |
| 18:16 | <ryanmunger> | do you think canvas is capable of something like that, though? |
| 18:16 | <Philip`> | AryehGregor: That's another hobby which I started a while ago and then failed to give up on :-) |
| 18:16 | <ryanmunger> | some open source version that will blow photoshop out of the water? |
| 18:16 | <wilhelm> | ryanmunger: I'll be a front end dev in … two and a half months! :P |
| 18:16 | <AryehGregor> | ryanmunger, if you're sufficiently masochistic, the current web platform is enough to write an OS from scratch. |
| 18:16 | <ryanmunger> | (that is NOT GIMP) |
| 18:16 | <AryehGregor> | Which people have more or less done. |
| 18:16 | <wilhelm> | After seven years on the Other Side. |
| 18:17 | <ryanmunger> | awesome, wilhelm |
| 18:17 | <AryehGregor> | By writing JS VMs and such. |
| 18:17 | Philip` | supposes he needs to figure out what to do in real life, after finishing PhDing |
| 18:17 | <zewt> | it's capable of pieces of it (the webgl side of "canvas", anyway, not so much the 2d side), but i have my doubts of web app APIs will ever fully displace native ones |
| 18:17 | <ryanmunger> | html, css and javascript seem like a pretty powerful combo right now |
| 18:17 | <zewt> | but i'll help as I can to get them to come as close as possible :P |
| 18:18 | <ryanmunger> | maybe in 1996 people thought it would be impossible to drag a map around in your web browser? |
| 18:18 | <zewt> | ryanmunger: here's a random piece https://zewt.org/curves :P |
| 18:18 | <zewt> | ("url" won't work anymore; need to load a local file) |
| 18:19 | <Philip`> | ryanmunger: There was probably a Java applet that could drag maps :-) |
| 18:19 | <Philip`> | (and that would take thirty seconds to start up and would randomly hang your browser) |
| 18:19 | <ryanmunger> | okay..."plug in free" |
| 18:20 | <zewt> | in 1996 we didn't have enough experience with the web to make any kind of meaningful predictions :P |
| 18:20 | <ryanmunger> | hha |
| 18:20 | <zewt> | now we have quite a bit of experience |
| 18:20 | <ryanmunger> | too busy using the <blink> tag |
| 18:21 | <zewt> | https://zewt.org/~glenn/gross.html |
| 18:22 | <ryanmunger> | lol |
| 18:22 | <ryanmunger> | love it |
| 18:22 | <ryanmunger> | love that snippet of js you wrote |
| 18:22 | <zewt> | the revival of blink, not so much? heh |
| 18:23 | <zewt> | i did name it appropriately |
| 18:23 | <zewt> | gross. |
| 18:23 | <ryanmunger> | :D |
| 18:23 | <ryanmunger> | blunk |
| 18:23 | <ryanmunger> | i'm trying to get a real hold on microformats today |
| 18:23 | <ryanmunger> | def exciting stuff |
| 18:31 | <AryehGregor> | zewt, web APIs will never fully displace native ones in the same sense as scripting will never fully displace C, and for that matter C will never fully displace assembly. It's plausible that at some point, most programmers will only really know web APIs. |
| 18:32 | AryehGregor | never realized that <style> had a .disabled IDL attribute, dang |
| 18:32 | AryehGregor | has some code where he inserts and removes /* */ using regex :( |
| 18:32 | <AryehGregor> | zewt, also, you can probably do that declaratively these days with CSS animations! |
| 18:41 | <zewt> | AryehGregor: not really the right analogy |
| 18:41 | <zewt> | scripting won't displace C because it'll never be as fast as C; the reasons web apis won't display native APIs are different |
| 18:41 | <zewt> | (that's one of them, to be sure, but not the biggest) |
| 18:42 | <AryehGregor> | C to assembly is a better analogy. Assembly will never disappear because there are some things C can't do, but you'll only find it used for niche things. |
| 18:42 | <AryehGregor> | Web APIs can be as fast as native ones with NaCl. |
| 18:43 | <AryehGregor> | If the Chrome OS concept takes off, which I suspect it will as web APIs become more powerful, then most developers won't be able to develop for anything but the web platform, if they want to target devices like Chrome OS. |
| 18:43 | <zewt> | the need for web apis to be cross-platform (meaning, in most cases, lowest-common-denominator), and the need in most cases for them to be safe enough to run untrusted code on (this at least could be improved, and hopefully will) |
| 18:43 | <gsnedders> | AryehGregor: That depends how much Google tries to standardize it's platform |
| 18:43 | <gsnedders> | zewt: Also, stuff like LuaJIT2 gets pretty impressive performance |
| 18:43 | <gsnedders> | In general not as quick as C, but not massively far off |
| 18:44 | <gsnedders> | (How you deal with SSE and the like from a high-level langauge is a good question, though) |
| 18:44 | <zewt> | "not far off" for JIT tends to mean things like "only four times slower" |
| 18:44 | <zewt> | well, SSE is even hard in C, which is why most native-code developers still drop to assembly for it |
| 18:45 | <gsnedders> | zewt: pure maths stuff it's quicker than C for, often |
| 18:45 | <zewt> | (intrinsics, even when they work, are still inherently platform-specific) |
| 18:45 | <gsnedders> | Which JS has little hope of reaching. |
| 18:45 | <zewt> | (intrinsically platform-specific? heh) |
| 18:45 | <gsnedders> | (with the single int/double type, and overflow checks it needs, etc) |
| 18:46 | <zewt> | but performance is only a part of the equation; i was thinking in terms of APIs |
| 19:11 | <AryehGregor> | jgraham, my reflection tests are still broken and I don't know why. It must have been a change in testharness.js, because I never changed the tests themselves without testing the change. See, e.g., http://aryeh.name/tests-root/tests/submission/AryehGregor/reflection/reflection-forms.html |
| 19:16 | <AryehGregor> | Or the w3.org URL if you like: http://dvcs.w3.org/hg/html/raw-file/tip/tests/submission/AryehGregor/reflection/reflection-forms.html |
| 19:16 | <AryehGregor> | The tests seem to run, but they don't output. |
| 19:17 | <AryehGregor> | Wait, now it seems to work? |
| 19:17 | <AryehGregor> | Hmm . . . |
| 19:18 | <AryehGregor> | This is what breaks it: document.body.innerHTML += "something"; |
| 19:19 | <AryehGregor> | Not sure why that would do it, but it's obviously bad for perf and such anyway. |
| 19:19 | <AryehGregor> | Hmm, maybe because it causes an expected element to vanish. |
| 19:23 | <AryehGregor> | jgraham, okay, I fixed it, never mind. |
| 19:23 | <AryehGregor> | Is there some place I can file bugs about testharness, though? |
| 19:28 | <AryehGregor> | . . . I'm pretty sure this template stuff is responsible for massive slowdowns in rendering the test output. |
| 19:29 | <AryehGregor> | IMO, you should just use string concatenation to make the HTML for the output table and assign it all to the table at once. |
| 19:29 | AryehGregor | experiments with that |
| 19:41 | <TabAtkins> | AryehGregor: I have significant experience as a front-end dev, though I'm now mostly a spec author. |
| 19:41 | <AryehGregor> | TabAtkins, right, I thought of you when I said that. |
| 19:41 | <TabAtkins> | Ah, kk. |
| 19:41 | <AryehGregor> | But you don't currently work as a front-end author. |
| 19:42 | TabAtkins | misses a lot of conversation in the mornings now that he works from home until lunch. |
| 19:42 | <TabAtkins> | True. |
| 19:42 | <TabAtkins> | hober: Oh man, you're right. There's still time! |
| 19:49 | <AryehGregor> | jgraham, this patch makes my one-page reflection tests in your framework take about five minutes to run in Firefox instead of eight: http://pastebin.com/kbfWk6RH |
| 19:49 | <AryehGregor> | If you don't count blank lines and comments, it removes three lines of code net. |
| 19:50 | <AryehGregor> | And uses only basic DOM stuff instead of templates, so it's much easier to understand. |
| 19:50 | <AryehGregor> | Can I push it? :) |
| 19:52 | <AryehGregor> | Hmm, it seems to make no difference to Chrome. |
| 19:52 | AryehGregor | isn't 100% sure about his Firefox results' validity, but thinks it's worth it just based on code simplicity |
| 20:00 | <TabAtkins> | ...I just not realized there was actually a man named "Haskell Curry". |
| 20:00 | <TabAtkins> | That feels like finding someone named "Javascript Memoize". |
| 20:00 | <jgraham> | TabAtkins: You previously did realise? |
| 20:00 | <TabAtkins> | s/not/now/, pedant. |
| 20:01 | <jgraham> | AryehGregor: (reading backscroll) |
| 20:12 | <jgraham> | TabAtkins: Given form, I'm surprised no one at Opera has named their kids Haskell yet (as far as I know) |
| 20:17 | <jgraham> | AryehGregor: I am not a big fan of random escape_html functions with weird edge cases living in the middle of the code |
| 20:17 | <jgraham> | It feels too much like bad experiences with PHP |
| 20:18 | <AryehGregor> | jgraham, granted. What do you suggest instead? |
| 20:18 | <AryehGregor> | Do you have a problem with the general idea? |
| 20:19 | <jgraham> | Well it would be interesting to know what is slow. Maybe the templating stuff can stay (although I grant that it is complex) but can build a string for innerHTML rather than doing DOM operations |
| 20:20 | <AryehGregor> | What use is the templating stuff? It just adds complexity. It's not like it makes the code any shorter. |
| 20:22 | <jgraham> | Well I think it is shorter than doing all the DOM operations by hand would be. Or at least less complex |
| 20:22 | <AryehGregor> | It's longer in this case. |
| 20:22 | <AryehGregor> | Look at the diffstat, then count the added/removed lines that are blank or comments. |
| 20:23 | <AryehGregor> | That's even including the addition of my escape_html function. |
| 20:23 | <jgraham> | Well yeah, but you're not doing dom operations, you're doing unsafe string manipulation |
| 20:23 | <AryehGregor> | That's the point, yes. It's much faster for large inputs. Also, why do you say "unsafe"? |
| 20:24 | <AryehGregor> | I mean, clearly they're unsafe if misused, but in this case it's pretty easy to see that it's safe (I think). |
| 20:24 | <AryehGregor> | Also, it's not like we're super-worried here about XSS in the test cases. |
| 20:25 | <jgraham> | Well yeah, but the point is that in general it's not safe |
| 20:25 | <jgraham> | No, I'm not worried about XSS |
| 20:25 | <AryehGregor> | It is if you escape properly. |
| 20:25 | <AryehGregor> | It's also much, much shorter and easier to understand. |
| 20:25 | <jgraham> | But it is tiresome if we start getting issues where adding the wrong kind of character to the test name causes weird brokenness |
| 20:25 | <AryehGregor> | And I strongly suspect it's faster, at least in Gecko, although I didn't do multiple runs to verify. |
| 20:26 | <jgraham> | Which I have seen in similar systems |
| 20:26 | <jgraham> | I can easily believe that it is faster |
| 20:26 | <AryehGregor> | Faster is a big issue when you have tens of thousands of tests on a page. |
| 20:26 | <AryehGregor> | Most of the time is spent rendering the results, not running the actual tests. |
| 20:26 | <AryehGregor> | That's bad. |
| 20:27 | <jgraham> | Yes, I can see that is a problem. Having tens of thousands of tests on a page wasn't a design goal |
| 20:27 | <AryehGregor> | Well, in Firefox that's true. Chrome seems to spend most of the time running them, but still an appreciable amount of time rendering them. |
| 20:27 | <jgraham> | s/Having/Supporting/ |
| 20:27 | <jgraham> | So it's not supported well |
| 20:29 | <AryehGregor> | I guess it might make sense for me to just split the tests up as much as necessary. |
| 20:34 | <jgraham> | I also had to change a bunch of createElements to createElementNS to keep the SVG people happy. Possibly innerHTML would upset them (although I don't recall the exact problem we were trying to solve) |
| 20:38 | <shepazu> | jgraham: what would upset the SVG people about innerHTML (besides the unfortunate name)? |
| 20:49 | <AryehGregor> | It occurs to me that if we tested all of HTML5 at the same level of depth I like to write tests, the full test suite would take weeks to run. |
| 20:49 | <AryehGregor> | Oh well. |
| 20:49 | <jgraham> | shepazu: Depending on it in testharness.js given that it doesn't work on SVG elements yet |
| 20:49 | <AryehGregor> | It should parallelize nicely. |
| 20:49 | <jgraham> | AryehGregor: ACID4! |
| 20:49 | <jgraham> | It will require proper dedication to get a result ;) |
| 20:49 | <AryehGregor> | We should make ACID4 be a giant comprehensive test suite that takes weeks to run? |
| 20:49 | <AryehGregor> | Sounds good to me. |
| 20:49 | <jgraham> | Yeah :) |
| 20:51 | <Hixie> | heh |
| 20:57 | <shepazu> | jgraham: what would need to happen for innerHTML to work on SVG? |
| 20:57 | <jgraham> | shepazu: Not much. |
| 20:58 | <jgraham> | shepazu: I think it is in DOM4 already. Implementations just need to actually implement it |
| 20:58 | <jgraham> | But it's not really that hard since they already do it for (X)HTML |
| 21:05 | <jamesr> | AryehGregor: parallelization of tests is very handy, although basically impossible to do in a browser-based harness |
| 21:06 | <AryehGregor> | jamesr, why isn't it trivial in a browser-based harness? |
| 21:06 | <AryehGregor> | If you have separate test pages. |
| 21:06 | <AryehGregor> | Just parallelize across the pages. |
| 21:06 | <mkanat> | AryehGregor: Imagine you have a million tests. |
| 21:06 | <mkanat> | AryehGregor: And you want to run 300 at once. |
| 21:06 | <jamesr> | maybe you could open up a test run page in a bunch of (isolated) tabs and have some central broker shard the tests out |
| 21:07 | <AryehGregor> | Sure. |
| 21:07 | <mkanat> | jamesr: Like with postMessage? |
| 21:07 | <jgraham> | Why not just use multiple browser instances |
| 21:07 | <jgraham> | On multiple physical machines |
| 21:07 | <mkanat> | jgraham: That would be even better, then you'd run out of RAM after opening just three. |
| 21:07 | <AryehGregor> | Or do it by some unit (e.g., directory) that's large enough that you can just spawn a new tab for each one without load balancing. |
| 21:07 | <mkanat> | jgraham: That would indeed solve the problem, physical machines. |
| 21:07 | <mkanat> | jgraham: And it was my original thought as well. |
| 21:08 | <jgraham> | If the tests are anything like efficient you can't parallelise well in one browser instance simply because you quickly use up all the avaliable CPU |
| 21:08 | <jgraham> | Also working out what happened when something crashes becomes tricky |
| 21:08 | <mkanat> | jgraham: Well, not all browser tests would be CPU-intensive. |
| 21:09 | <AryehGregor> | Almost all will be. |
| 21:09 | <AryehGregor> | I mean, they don't *have* to be. |
| 21:09 | <jamesr> | what else would they be? |
| 21:09 | <mkanat> | jamesr: GPU, RAM. |
| 21:09 | <jgraham> | GPU sure |
| 21:09 | <mkanat> | jamesr: And some few (storage) would be I/O bound. |
| 21:09 | <jgraham> | RAM not so much |
| 21:09 | <jamesr> | memory-bound is the same as cpu-bound |
| 21:09 | <jamesr> | if you're really blocked on memory bandwidth |
| 21:09 | <mkanat> | jamesr: Memory-speed bound, sure. |
| 21:09 | <AryehGregor> | You could conceivably have tests that require large delays to be inserted for some reason. |
| 21:10 | <jamesr> | storage tests shouldn't be I/O bound unless the implementation is pretty bad |
| 21:10 | <AryehGregor> | Or I/O, yeah, or GPU. |
| 21:10 | <mkanat> | jamesr: No, I do agree with you that in my imaginary world, most HTML tests are CPU-bound. |
| 21:10 | <jgraham> | Tests that require large delays are not uncommon |
| 21:10 | <mkanat> | AryehGregor: setTimeout. |
| 21:10 | <jgraham> | If you are testing networking code, for example |
| 21:10 | <mkanat> | AryehGregor: I mean, that test would involve a delay. |
| 21:10 | <jamesr> | network bound is reasonable |
| 21:10 | <AryehGregor> | Yes, but that's a tiny minority of tests. |
| 21:10 | <jgraham> | But anyway, parallelising across multiple browsers makes all of this rather easy to deal with |
| 21:10 | <AryehGregor> | I mean setTimeout. |
| 21:10 | <mkanat> | Well, but if you were testing network code, I'd probably test against localhost. |
| 21:10 | <AryehGregor> | Network, maybe not. |
| 21:10 | <mkanat> | AryehGregor: Yeah, agreed that it's a small minority. |
| 21:11 | <AryehGregor> | But who cares? Just spawn significantly more instances than you have CPUs. |
| 21:11 | <mkanat> | jgraham: Agreed. |
| 21:11 | <AryehGregor> | Let the OS scheduler work it out. |
| 21:12 | <mkanat> | Hixie: MS and other vendors have actually written a bunch of somewhat-comprehensive spec tests for some specs, right? |
| 21:12 | <jgraham> | (the other advantage is that running multiple tests at the same time on the same machine can cause problems) |
| 21:12 | <jgraham> | (e.g. timeouts due to resource starvation) |
| 21:12 | <jgraham> | mkanat: fairly comprehensive testsuites for some features exist, yes |
| 22:56 | <michaelw> | hi! in the html5 spec, Sec. 4.3.1 (script elements), is "already started" the same flag as in 3.17.1 "already executed"? |
| 22:58 | <Hixie> | mkanat: probably, i'm not the one to ask on that front |
| 22:58 | <Hixie> | michaelw: no |
| 22:58 | <Hixie> | michaelw: though one may be a typo... |
| 22:58 | <Hixie> | michaelw: looking now |
| 22:58 | <Hixie> | i can't find any mention of "already executed" |
| 22:58 | <Hixie> | the <Script> flags are all defined in http://www.whatwg.org/specs/web-apps/current-work/complete.html#already-started |
| 22:59 | <Hixie> | michaelw: i can't work out to what you are referring to w.r.t 3.17.1 |
| 22:59 | <michaelw> | oh drat, I might have looked at an outdated spec! |
| 22:59 | <Hixie> | michaelw: are you looking at the current spec? |
| 22:59 | <Hixie> | whatwg.org/html or whatwg.org/c |
| 22:59 | <Hixie> | don't look at anything else if you want to avoid outdated specs :-) |
| 23:00 | <Hixie> | and definitely don't look at anytihing with /TR/ in the url |
| 23:00 | <michaelw> | ok, thanks. sorry for the noise |
| 23:00 | <Hixie> | np |
| 23:02 | <michaelw> | another question, in 4.2.7 a UA can "give up" on a stylesheet that is blocking scripts. What does that mean exactly? |
| 23:03 | <Hixie> | pretty much exactly what it sounds like |
| 23:03 | <michaelw> | the way it reads to me right now is that a UA doesn't have to block... |
| 23:04 | <Hixie> | that is correct |
| 23:05 | <michaelw> | Hixie: this sort of begs the question why this is mentioned then at all |
| 23:05 | <Hixie> | i can add some clarifying text explaining why giving up early is a bad idea |
| 23:07 | <michaelw> | Hixie: yes, please. |
| 23:07 | <Hixie> | k. remind me in 5 minutes :-) |
| 23:07 | <Hixie> | or file a bug |
| 23:07 | <Hixie> | (a bug will take more months) |
| 23:07 | michaelw | sets a timer |
| 23:17 | <michaelw> | Hixie: here's your reminder about adding some explanation to 4.2.7 why giving up on stylesheets immediately (and only waiting for them at the styling phase) is bad |
| 23:17 | <Hixie> | thanks |
| 23:18 | <Hixie> | that was perfect timing |
| 23:23 | <Hixie> | ok i added a paragraph after the "give up" one |
| 23:23 | <Hixie> | michaelw: should be up in a few seconds for your review |
| 23:26 | <michaelw> | Hixie: okay, waiting for it |
| 23:27 | <Hixie> | should be up |
| 23:28 | <Hixie> | (checked in) |
| 23:31 | <michaelw> | Hixie: got it, thanks |
| 23:40 | <Hixie> | julian is funny |
| 23:42 | <Hixie> | funnier still though is the people who still argue with him! |
