| 00:31 | <Hixie> | anything any implementors need resolving soon? |
| 00:33 | <Hixie> | i guess i'll go back to last in first out |
| 00:38 | <wilhelm> | Hixie: I'll have some minor comments and a whitelist for register*Handler() next week (I'm technically on vacation this week :), but no rush. Our implementation (and soon-to-be-published test suite) is done, and disagrees with Firefox on a couple of points. |
| 00:38 | <gsnedders> | wilhelm: You're on vacation? Oh. :) |
| 00:39 | <wilhelm> | … Yes. |
| 00:52 | <AryehGregor> | The_8472, something like <div align=right> aligns all descendant blocks too, to arbitrary levels of nesting. |
| 00:53 | <The_8472> | AryehGregor, use selectors |
| 00:53 | <The_8472> | div * ... |
| 00:54 | <AryehGregor> | The_8472, I don't think the effect is fully expressible using selectors either. At least, the HTML5 spec uses prose to define it, not selectors. |
| 00:54 | <AryehGregor> | But it doesn't help me anyway, because I'm writing an execCommand() spec, and execCommand() has to output only inline style. |
| 00:54 | <AryehGregor> | (Example of difference: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22width%3A20em%3Bborder%3A1px%20solid%20blue%22%3E%0A%3Cdiv%20align%3Dright%3E%3Cdiv%20style%3D%22width%3A2em%3Bborder%3A1px%20solid%20black%22%3Eabc%3C%2Fdiv%3Edefghi%3C%2Fdiv%3E%0A%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22width%3A20em%3Bborder%3A1px%20solid%20blue%22%3E%0A%3Cdiv%20style%3D%22text-align%3A%20right%3B%20margin-lef |
| 00:54 | <AryehGregor> | t%3Aauto%22%3E%3Cdiv%20style%3D%22width%3A2em%3Bborder%3A1px%20solid%20black%22%3Eabc%3C%2Fdiv%3Edefghi%3C%2Fdiv%3E%0A%3C%2Fdiv%3E) |
| 00:54 | <The_8472> | err... yeah |
| 00:55 | <AryehGregor> | (should have saved it and gotten a numeric URL) |
| 00:55 | <AryehGregor> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1012 |
| 00:56 | <The_8472> | whose brilliant idea was it to bring those things that have already been deprecated back to html5? |
| 00:56 | <jamesr> | protip: spec authors can't deprecate things! |
| 00:57 | <The_8472> | but everyone except legacy people moved on to css |
| 00:57 | <The_8472> | so why support it |
| 00:59 | <AryehGregor> | The_8472, browsers have to support it. |
| 00:59 | <AryehGregor> | Otherwise old web pages break. |
| 00:59 | <Hixie> | wilhelm: cool, i look forward to the feedback. not sure i can do anything on the spec on that until we've shipped something and tested it, really. |
| 00:59 | <The_8472> | but not for *new* standards |
| 00:59 | <AryehGregor> | So HTML5 tells browsers how to support it to render webpages correctly. |
| 00:59 | <AryehGregor> | Which new standards were you thinking of? |
| 00:59 | <The_8472> | html5 |
| 00:59 | <AryehGregor> | HTML5 is meant to tell browsers how they have to behave to process all conten.t |
| 00:59 | <AryehGregor> | content. |
| 00:59 | <gsnedders> | The_8472: Browsers don't want different rendering modes for each version of HTML. |
| 00:59 | <The_8472> | if you want old pages... use html4 |
| 00:59 | <AryehGregor> | Browsers process old content the same as new content. |
| 00:59 | <Hixie> | html doesn't allow align="" |
| 00:59 | <AryehGregor> | They don't want to have to write separate code, and anyway, it would just break when people copy-paste HTML. |
| 01:00 | <gsnedders> | The_8472: Browsers want to have as few modes as possible. |
| 01:00 | <Hixie> | but it does say what should happen in browsers if authors ignore the spec |
| 01:00 | <The_8472> | which means there is a "well-defined" behavior that you can suddenly use |
| 01:00 | <The_8472> | good job |
| 01:01 | <AryehGregor> | Previously, there was also a basically well-defined behavior, just no one documented it, so browsers had to reverse-engineer it. |
| 01:02 | <AryehGregor> | And any differences in behavior contributed to lock-in. |
| 01:02 | <AryehGregor> | Because it meant authors would write pages for browsers with the most market share and ignore the others. |
| 01:02 | <AryehGregor> | So it would only work in the biggest browsers, and not work in others. |
| 01:02 | <The_8472> | and everyone did it differently, things broke, providing incentive to actually write standards-compliant markup |
| 01:02 | <AryehGregor> | It never provided enough incentive to make a big difference. |
| 01:03 | <AryehGregor> | Browsers were mostly interoperable in practice. |
| 01:03 | <The_8472> | then things didn't break enough |
| 01:03 | <AryehGregor> | Great, so feel free to write a browser where 90% of web pages break. |
| 01:03 | <AryehGregor> | See how well it does, get back to us on that one. |
| 01:03 | <AryehGregor> | Browsers can't get away with breaking pages, because then people stop using that browser. |
| 01:03 | <Hixie> | The_8472: sorry dude, but we're not going to break cnn.com |
| 01:03 | <AryehGregor> | Or don't upgrade. |
| 01:03 | <AryehGregor> | We don't have a choice here, these features have to be supported in real-world browsers if they want people to actually use them. |
| 01:04 | <The_8472> | div align=...? |
| 01:04 | <AryehGregor> | Given that, the least evil by far is if it's clearly documented how they work, so that browsers behave the same way. Then browsers can compete on things they can actually improve, like performance and usability. |
| 01:04 | <AryehGregor> | Yes. |
| 01:04 | <The_8472> | that wasn't even standard iirc |
| 01:05 | <AryehGregor> | Line 256 on http://www.cnn.com/: <div align="center"><div id="cnn_maincntnr"> <!-- this is where the breaking news CSI code will go --> |
| 01:05 | <Hixie> | doesn't matter what was standard |
| 01:05 | <Hixie> | matters what people use |
| 01:05 | <wilhelm> | The_8472: You can't win that way. If you write a web site that breaks in a certain browser, the users blame you. If you write a web browser that breaks certain sites, the users blame you and switch to a different browser. (c: |
| 01:05 | The_8472 | sighs |
| 01:05 | <AryehGregor> | Actually, it was part of HTML 4.01: http://www.w3.org/TR/html401/struct/global.html#h-7.5.4 |
| 01:05 | <AryehGregor> | But that's neither here nor there. |
| 01:06 | <AryehGregor> | Maybe it would be great if we could rewrite everything and get rid of all the legacy cruft, but browsers can't do that. |
| 01:06 | <AryehGregor> | So we have to live with it, forever. |
| 01:06 | <AryehGregor> | Nobody likes it, but that doesn't mean anyone can change it. |
| 01:06 | <wilhelm> | For several decades, at least. Some of the old cruft is actually disappearing. Very, very slowly. |
| 01:07 | <AryehGregor> | Although FWIW, HTML's align attributes (and <center>, same deal) are among the things that CSS still really doesn't do as well. |
| 01:07 | <AryehGregor> | Stick something in <center> and everything's centered, no way to do that with CSS. |
| 01:07 | <AryehGregor> | But I'm off for the night, bye. |
| 01:08 | <The_8472> | well, flexboxes get close |
| 01:08 | <The_8472> | but hey, until that's supported everywhere years will pass |
| 01:10 | <Hixie> | wilhelm: it's my intent that the spec be usable in 1000 years to write a browser that renders pages from the mid 90s |
| 01:10 | <Hixie> | wilhelm: so i don't plan to ever remove anything from the implementation section so long as any significant number of pages ever used it |
| 01:11 | <The_8472> | madness |
| 01:12 | <wilhelm> | Oh, it's madness. And the only reasonable option here. (c; |
| 01:12 | <Hixie> | yeah, see the /topic |
| 01:12 | <The_8472> | also, the complexity will just increase over time |
| 01:12 | <Hixie> | we're well aware that it's crazy :-) |
| 01:12 | <wilhelm> | Either you are mad when you start working on browsers, or you turn mad along the way. |
| 01:12 | <Hixie> | well yeah, even if we never add anything bad to the platform, it'll get more complicated over time |
| 01:13 | <Hixie> | how could anything like the web ever get _simpler_ over time? |
| 01:13 | <The_8472> | by removing obsolete things of course |
| 01:14 | <Hixie> | if we never added anything bad, there'd be nothing obsolete |
| 01:14 | <The_8472> | you know, like we don't have watering places for horse carriages anymore |
| 01:14 | <Hixie> | you think transport now is simpler than when we had horses?! |
| 01:14 | <Hixie> | have you _seen_ the state of transport these days?! |
| 01:14 | <The_8472> | a car is easier to assemble than a horse |
| 01:14 | <Hixie> | ok i'm going to go back to work now |
| 01:14 | <The_8472> | ^^ |
| 01:15 | <The_8472> | have you ever tried to build a horse from scratch? |
| 01:18 | <wilhelm> | Hixie: I suppose “any significant number” are the keywords here. Are <layer>, <plaintext>, <multicol>, <blink> or <marquee> deliberately missing from the spec? (c: |
| 01:18 | <wilhelm> | The latter should probably defined. |
| 01:18 | <Philip`> | The_8472: Creating new horses is so easy that even horses can do it |
| 01:18 | <Hixie> | wilhelm: <blink>, <marquee>, and <plaintext> aren't missing |
| 01:19 | <Hixie> | wilhelm: <layer> and <multicol> were not used sufficiently to matter for archeologists |
| 01:19 | <wilhelm> | Oh, I'm just blind, then. (c: |
| 01:19 | <Hixie> | <marquee> has its own huge section |
| 01:19 | <Philip`> | <layer> is used loads |
| 01:19 | <Philip`> | See e.g. http://www.imdb.com/ |
| 01:19 | <wilhelm> | Ah, there it is. Good, good. |
| 01:20 | <wilhelm> | It's widely used in several Asian countries still. |
| 01:20 | <Hixie> | <layer> is not used in a way that requires more support from browsers than what hte HTML spec requires |
| 01:23 | <The_8472> | Philip`, still missing the point. even if todays system is more complex we still removed obsolete parts |
| 01:25 | <The_8472> | there even are govt incentives to replace old cars (at least here there are) |
| 01:28 | <wilhelm> | A government! Now, that would be useful on the Web. And horrible. And impossible. (c: |
| 01:30 | The_8472 | puts that on his evil overlord to-do list. require all citizens to run modern browsers. so they can all read my proclamations with the proper layout |
| 01:33 | <Hixie> | if we could enforce behaviour, this would be far easier... |
| 01:35 | <wilhelm> | Indeed. Threats of violence (and the proper tools to carry out said threats) is probably the only way to force everyone to actually do what the spec says. (c: |
| 01:36 | <wilhelm> | On the other hand, we'd be missing out in other areas. I have reluctantly accepted that the Web really is a case of “worse is better”. |
| 01:40 | <The_8472> | sometimes it seems like it's someone is trying to specify an operating system down to every library before it's even implemented. |
| 01:40 | <The_8472> | and where nobody trusts a user |
| 01:43 | <Hixie> | we write the spec usually after it's implemented |
| 01:43 | <Hixie> | that's why it's ugly :-) |
| 05:52 | <cgcardona> | nice work https://sites.google.com/site/webrtc/ :) |
| 05:52 | <cgcardona> | stokage |
| 07:45 | <hsivonen> | Hixie: Validator.nu allows the rel values in the spec and the rel values in this (currently one-item) table: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions |
| 07:55 | <hsivonen> | Hixie: I suppose in principle I should make V.nu allow all rel values that have the right columns on the entire page, but only that table currently has the right columns |
| 08:57 | <zcorpan> | so has it been figured out yet which things in the DOM turn null to "null" and which turn null to ""? |
| 08:59 | <Ms2ger> | All turn into "" now, I guess |
| 09:00 | <zcorpan> | we implemented that and it broke stuff |
| 09:00 | <Ms2ger> | Hah |
| 09:00 | <zcorpan> | or i'm not sure what it broke but we have a bug about it being wrong |
| 09:01 | <Ms2ger> | Anything that needs changing in DOM Core? |
| 09:01 | <zcorpan> | i'll have to figure it out |
| 09:02 | <zcorpan> | seems we want methods to give "null" and attributes to give "" ? |
| 09:03 | <zcorpan> | Ms2ger: is CDATASection needed for compat? |
| 09:03 | <Ms2ger> | I'm actually not sure where that will end up |
| 09:29 | <hendry> | does anyone have opinions on "BrowserMark" http://browsermark.rightware.com/browsermark/ they want to share? |
| 09:50 | <Onderhond> | Hey guys, got a question about data- attributes |
| 09:50 | <Onderhond> | http://dev.w3.org/html5/spec/Overview.html#embedding-custom-non-visible-data-with-the-data-attributes |
| 09:51 | <Onderhond> | The spec states: These attributes are not intended for use by software that is independent of the site that uses the attributes. |
| 09:51 | <Onderhond> | But it fails to explain why exactly this requirement was added |
| 09:51 | <Onderhond> | Any ideas? |
| 09:54 | <Ms2ger> | To avoid it being used by microformat-style specs |
| 09:55 | <Ms2ger> | Their point is to always be reserved for the page author, and the author shouldn't need to bother about conflicts |
| 10:29 | <jgraham> | Any opinions on what http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1013 should log? I think true, [object HTMLImageElement], undefined, but no browser agrees with me |
| 10:29 | <jgraham> | So I could be misreading WebIDL |
| 10:51 | <Onderhond> | Ms2ger: thanks for the reply. |
| 10:52 | <Onderhond> | So is there something that _can_ be used to inform external script of data that is not relevant to the user (and shouldn't be added to the content of the html?) |
| 11:04 | <jgraham> | AryehGregor: Really your reflection tests would be more useful if they weren't set up to all fail |
| 11:05 | <jgraham> | Or, if you like, if they seperated out the different possible reasons for failure into different tests |
| 11:32 | <mikekelly> | is it a lot of work to introduce @rel for iframe elements |
| 11:32 | <mikekelly> | ? |
| 12:45 | <hsivonen> | Interesting how instead of saying "here's a spec and one Open Source implementation", http://sites.google.com/site/webrtc/reference is so clear on the intention that there's a bunch of code that you put in your browser |
| 12:47 | <aho> | is there any way to do string concatenation inside attr() or url()? |
| 12:48 | <aho> | calc() doesn't seem to allow it... mh |
| 12:53 | <ako> | e.g. attr(data-foo, url)... what if i don't always want to repeat the whole url in those data attributes? what if i want to make that url partially depending on media queries (without resorting to multiple different data attributes of which each one specifies the whole url)? |
| 12:54 | <Ms2ger> | That isn't implemented anywhere, is it? |
| 12:54 | <ako> | content:attr(data-bla, url) works in opera |
| 12:54 | <ako> | (yes, even without before or after) |
| 12:55 | <ako> | http://nicolasgallagher.com/responsive-images-using-css3/ |
| 13:02 | <aho> | so... i need to wait for variables if i want something like that? |
| 13:03 | <aho> | heh. i often wish css were a real programming language. |
| 13:04 | <aho> | don't like doing layouts with floats? write your own layout manager or pick one from github :> |
| 13:04 | <Ms2ger> | Make sure Bert Bos doesn't hear that :) |
| 13:10 | <hsivonen> | I find it interesting that when both validator.w3.org and validator.nu link to the meta name and rel registries and say they are wikis, people rather file bugs asking for stuff to be registered than edit the wikis themselves |
| 13:12 | <hsivonen> | Hixie: requiring registrations to have a spec URL is a great filter against bogus stuff, btw |
| 13:12 | <hsivonen> | where bogus is either something someone just made up and no one cares to implement or stuff that's used by cargo cult but no one has proof anyone implements |
| 13:23 | MikeSmith | only now comes around to realizing that the cause of the can't-submit-feedback-form-because-no-JS problem is in the "boilerplate" files used to generate the W3C copies of the upstream spec content |
| 13:23 | <Philip`> | hsivonen: Maybe people want the confirmation of an authority agreeing with them - if they edit the page themselves with no discussion or approval then it doesn't feel proper |
| 13:24 | <MikeSmith> | Ms2ger: I will fix the boilerplate now, and that'll fix the problem with the webstorage spec and everywhere, after Hixie pushes again |
| 13:24 | <Ms2ger> | Ta |
| 13:25 | <Ms2ger> | And btw, I made anolis generate the trailing slashes you added to the DOM Core WD once and for all |
| 13:30 | <hsivonen> | Philip`: it's more likely that authorities will disagree, so seeking approval seems like a bad strategy if you want your gunk to be valid |
| 13:43 | <hsivonen> | is for each a SpiderMonkeyism in JS? |
| 13:44 | <gsnedders> | hsivonen: Yes. |
| 13:45 | <hsivonen> | gsnedders: thanks |
| 13:45 | <hsivonen> | also learned today: Mochitest doesn't work in Opera |
| 13:45 | <gsnedders> | Uh, it should. |
| 13:46 | <gsnedders> | Like, we have some version of it in our regression tracking system. Whether Mozilla's branch works or not is a separate matter, seeming a lot of Moz tests seem to depend upon non-standard Moz stuff. |
| 13:46 | <jgraham> | gsnedders: We have Mochikit, sure. But is that actually using Mochitest? |
| 13:46 | <hsivonen> | the sample at http://ted.mielczarek.org/code/mozilla/mochitest-maker/ works in Firefox and Chrome but not in Opera |
| 13:47 | hsivonen | tries to gather data to argue that a particular behavior isn't interoperable so changing a test should be ok |
| 13:48 | <gsnedders> | jgraham: Oh, good point. I'm being silly and forgetting that Mochitest isn't the normal Mochikit test harness. |
| 14:04 | <jgraham> | hsivonen: var s = document.createElementNS(kXULNSURI, 'script'); |
| 14:04 | <jgraham> | One has to wonder why |
| 14:20 | <hsivonen> | jgraham: you mean that's in ted's copy of mochitest? |
| 14:20 | <hsivonen> | jgraham: I thought that's supposed to throw in Firefox 4 or later |
| 14:25 | <jgraham> | hsivonen: Yes |
| 14:26 | <jgraham> | hsivonen: I suppose it is not impossible that Opera gets thrown down that codepath and others don't |
| 14:27 | <hsivonen> | jgraham: I would be entirely unsurprised if Opera got sniffed onto a broken codepath |
| 14:28 | <hsivonen> | jgraham: mochikit browser sniffs |
| 14:28 | <jgraham> | I know :( |
| 14:28 | <hsivonen> | (which I think is a terrible idea in code that's used for testing browsers) |
| 14:30 | <jgraham> | What magic do I have to do to make firebug work in Gecko nightly? |
| 14:32 | <Ms2ger> | Set the extensions.checkCompatibility.nightly pref, I assume |
| 14:32 | <hsivonen> | jgraham: installing https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/ might set the pref for you |
| 14:33 | hsivonen | has no idea why https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/ isn't included in nightlies by default, since it is needed for reasonable operation |
| 14:34 | <Ms2ger> | I'm not sure if it's updated to use the new pref already |
| 14:34 | <jgraham> | Ms2ger: Thanks |
| 14:36 | <hsivonen> | I kinda wish Firebug was part of the product and all other extensions had to use JetPack & jsctypes and were banned from doing XPCOM stuff |
| 14:37 | <Ms2ger> | They're going to be happy to hear that :) |
| 14:37 | <hsivonen> | Ms2ger: who is they? |
| 14:38 | <Ms2ger> | Extension developers |
| 14:38 | <jgraham> | hsivonen: Oh, I was wrong. It looks like it document.writes a normal HTML script element |
| 14:38 | <hsivonen> | Ms2ger: well, stuff is sort of creeping to that direction now that every release requires recompilation of binaries |
| 14:39 | <jgraham> | Dunno why that should fail in Opera |
| 14:39 | <hsivonen> | Ms2ger: maybe wishing that JS didn't touch XPCOM is too harsh, but other browsers have more JetPack-y APIs |
| 14:39 | <Ms2ger> | jgraham, did you guys ever implement document.write? :) |
| 14:39 | <gsnedders> | jgraham: DSE? |
| 14:39 | <jgraham> | Ms2ger: Doh! If only we had done that! |
| 14:39 | <Ms2ger> | Sure would make our work easier |
| 14:39 | <jgraham> | gsnedders: In desktop? |
| 14:40 | <gsnedders> | jgraham: Well, you could've enabled it… |
| 14:40 | <gsnedders> | To test something, or something. |
| 14:40 | <jgraham> | gsnedders: Possibly, but I haven't and I doubt hsivonen has |
| 14:40 | <gsnedders> | True. |
| 14:40 | <gsnedders> | But that's my first thought when document.write doesn't work :P |
| 14:43 | <jgraham> | In unrelated questions, is there some easy way in mercurial to set the contents of some files in the working copy to be whatever they were in some specified revision? |
| 14:43 | <Ms2ger> | hg revert? |
| 14:43 | <jgraham> | Like git checkout /path/to/file -- HEAD^ |
| 14:44 | <jgraham> | Ms2ger: Yes |
| 14:44 | <jgraham> | I seem to remember I knew that once before git destroyed my brain |
| 14:44 | <Ms2ger> | You use git? |
| 14:44 | <Ms2ger> | I feel sorry |
| 14:44 | <jgraham> | Local branches are pretty awesome |
| 14:45 | <jgraham> | I haven't worked out if mercurial bookmarks are actually useful or not yet because they seem to work in such a half-assed way |
| 14:46 | <jgraham> | (note: *seem*. I'm sure I haven't worked out how to use them correctly yet) |
| 14:53 | <AryehGregor> | jgraham, that's like a three-line change, I could do it pretty easily. The original harness works that way. |
| 14:53 | AryehGregor | looks |
| 15:02 | <AryehGregor> | jgraham, okay, fixed in tip (352:2da6dcfaf2a1). |
| 15:03 | <jgraham> | AryehGregor: Thanks! |
| 15:03 | <AryehGregor> | Now Opera fails only 27817/87266. |
| 15:04 | <Ms2ger> | And Fx? |
| 15:04 | <jgraham> | Yeah, but at least we can check we don't regress those 87266-27817 |
| 15:05 | <AryehGregor> | Ms2ger, I was trying to test, but my machine started swapping, so I killed Firefox. |
| 15:05 | <AryehGregor> | I'm pretty sure my original harness didn't use that much RAM. |
| 15:05 | AryehGregor | tries again |
| 15:05 | <Ms2ger> | It runs fine on my .5GB of RAM, so I'd assume not |
| 15:06 | <AryehGregor> | Which, my original harness or the tesharness.js version? |
| 15:06 | <Ms2ger> | Original |
| 15:06 | <AryehGregor> | Meaning reflection-original.html? |
| 15:06 | <Ms2ger> | Sounds right |
| 15:06 | <jgraham> | It could be building the table. Or it could be leakyness in testharness.js |
| 15:07 | <AryehGregor> | Wow, Firefox takes a long time to run reflection-onepage.html now. |
| 15:07 | <AryehGregor> | That was one reason I had the tests fail early, so there would be fewer tests . . . |
| 15:09 | <AryehGregor> | There must be some bug in Firefox or something, because it's taking minutes to run them, and Chrome and Opera took much less. |
| 15:09 | <jgraham> | Can you run the individual subsections? |
| 15:09 | <AryehGregor> | Oh, wait, it just finished. |
| 15:10 | <AryehGregor> | 15377/87266 failed. |
| 15:10 | <AryehGregor> | In 5.0a2. |
| 15:10 | <AryehGregor> | Firefox always did substantially better than any other browser. |
| 15:10 | <AryehGregor> | Now I closed the tab and it's started using 100% CPU again, and hasn't freed the memory . . . |
| 15:11 | <AryehGregor> | You guys moving to process-per-tab anytime soon, Ms2ger? :) |
| 15:11 | <Ms2ger> | Soon? Not really |
| 15:12 | Ms2ger | doesn't really follow that |
| 15:13 | <AryehGregor> | It's still the table layout that takes by far the most time in all browsers for testharness.js. |
| 15:13 | <AryehGregor> | Anyway, Chrome 13 dev fails 23125/87266. |
| 15:13 | <AryehGregor> | Not much better than Opera. |
| 15:16 | <AryehGregor> | Oh, the tests don't run in IE9 anymore. Sigh. |
| 15:18 | <AryehGregor> | The -original ones do, just not -onepage. |
| 15:22 | <AryehGregor> | BTW, running -original in Chrome takes about 6.5s to run, including display time. about:memory says it uses 31,168k of memory, as compared to 383,812k for -onepage. |
| 15:22 | <AryehGregor> | Part of that is surely because the size of the resulting page is vastly smaller -- not only are successes not recorded anywhere in the DOM, but they're aggregated very heavily, in some cases with >100 failures per line. |
| 15:23 | <AryehGregor> | Part also might be because of the use of <ul>s instead of tables. |
| 15:23 | <jgraham> | What happens if you remove the <div id="log"></div>? |
| 15:23 | <AryehGregor> | Worth investigating. |
| 15:23 | Philip` | suggests <pre> and ASCII art for the output, since that would be much more efficient |
| 15:25 | <AryehGregor> | jgraham, then it takes about the same time as -original, and uses much less memory than before but still over twice as much as -original (51,652k vs. 22,372k). |
| 15:25 | <AryehGregor> | Of course, -original doesn't have many actual features, it's just a custom-tailored thing that does exactly what I want, so it's not like it's a fair comparison. |
| 15:25 | <jgraham> | Before you said 31,168k |
| 15:26 | <AryehGregor> | Hmm. |
| 15:26 | <AryehGregor> | I might have been reading from the wrong line. |
| 15:26 | <AryehGregor> | about:memory in Chrome has the tab name left-aligned and the memory usage right-aligned, so there's a huge gap. |
| 15:26 | AryehGregor | closes the tab and opens a new one to check |
| 15:27 | <AryehGregor> | Now it's 32,844k. |
| 15:27 | <AryehGregor> | And -onepage has dropped to 43,916k. |
| 15:27 | <AryehGregor> | Curious. |
| 15:27 | <AryehGregor> | Maybe it's doing GC in the background? |
| 15:27 | <jgraham> | So it uses about 50% more memory without output |
| 15:27 | <AryehGregor> | Anyway, the memory usage is higher but acceptably so, it's the log that causes all the problems. |
| 15:27 | <jgraham> | That's not too surprising |
| 15:28 | <AryehGregor> | It'd be interesting to try making the log a big <ul> and see how that works. It might not be a very big improvement, since it could just be the number of nodes in the DOM that's causing the problem. |
| 15:28 | <jgraham> | I'm not sure what to do about it. The log could be generated lazily for big testsuites |
| 15:28 | <AryehGregor> | Or big testsuites could opt into an alternative log that doesn't even add passed tests to the DOM, for instance. |
| 15:28 | <AryehGregor> | Adding them but hiding them doesn't seem to help the memory usage. |
| 15:28 | <jgraham> | Yes, that would work too |
| 15:29 | <AryehGregor> | Is the log meant to be used by machines, or only people? |
| 15:29 | <Ms2ger> | Only people |
| 15:29 | <jgraham> | Only people |
| 15:29 | <AryehGregor> | Then test suites could also specify some mechanism of aggregating similar errors, the way my original harness does. |
| 15:29 | <AryehGregor> | But that would be more involved. |
| 15:30 | <AryehGregor> | Not adding passed tests to the DOM should be pretty simple. |
| 15:30 | <AryehGregor> | And for the reflection tests, it would cut the size of the DOM by 80% or so. |
| 15:30 | <AryehGregor> | Anyway, later, have to go now. |
| 15:30 | <Ms2ger> | That would make the log look rather sad :) |
| 15:31 | <AryehGregor> | Well, you could remove the "Fail" column and just have the table titled "Test failures (passes not reported)" or something. |
| 15:36 | <matjas> | hsivonen: What are your thoughts on adding `apple-touch-icon` to http://microformats.org/wiki/existing-rel-values? Feels dirty, but only as dirty as `shortcut`, amirite |
| 15:40 | <smaug____> | how do I CC someone to a chromium bug? |
| 15:41 | <smaug____> | I can't find any UI for that |
| 15:44 | <paul_irish> | smaug____: users cannot, but i can if you want |
| 15:46 | <smaug____> | users cannot, huh |
| 15:46 | <smaug____> | strange UI |
| 15:46 | <smaug____> | paul_irish: do you access to security bugs? |
| 15:46 | <paul_irish> | nope. |
| 15:47 | <paul_irish> | if its a security ticket, just mention that someone should be cc'd in the report |
| 15:47 | <smaug____> | k |
| 15:47 | <smaug____> | thanks |
| 15:47 | <paul_irish> | np |
| 15:47 | <hsivonen> | oh. matjas already left |
| 15:48 | <hsivonen> | matjas: in case you are reading the logs: I'd have expected someone to register apple-touch-icon by now and find it interesting that it hasn't been registered, yet |
| 15:48 | <hsivonen> | even tough apple-* meta names have already been registered |
| 15:50 | <Peter`> | smaug____: there is a little star you can click on each issue. That was you can cc yourself. |
| 15:51 | <Peter`> | For other people you need contributor access, or as Paul said, mention it in the ticket itself. |
| 15:52 | <smaug____> | Peter`: it was a google employee who asked to be CC'ed to a bug |
| 15:52 | <hsivonen> | OK, now I realize why the microformats.org registry isn't getting new values |
| 15:55 | <hsivonen> | The surrounding wiki page confuses people |
| 15:56 | <hsivonen> | e.g. Dom added apple-touch-icon but not to the HTML5 extension table |
| 15:56 | <hsivonen> | and the table that it got added to doesn't have the right columns for HTML5 registrations |
| 16:00 | hsivonen | pinged Dom to ask if he meant not to register those values for HTML5 use |
| 16:00 | <hsivonen> | given that he did register meta names *for HTML5 use* at the same time |
| 16:43 | <David_Bradbury> | When something in the spec says "Warning! Likely to change!" - Such as the gradiant stops in the Canvas element - does that mean if I'm developing a product now that uses that feature, I may have to change it in the future for it to work? |
| 16:45 | <Philip`> | David_Bradbury: Where does it say that? |
| 16:47 | <Philip`> | David_Bradbury: The only warning I see near there in the WHATWG spec is point at the "serialization of a color" algorithm |
| 16:47 | <David_Bradbury> | Philip`: Actually, my apologies, I thought it was pointing to the gradiant stops - It was pointing to serialization |
| 16:47 | <Philip`> | Ah, okay |
| 16:47 | <David_Bradbury> | :) |
| 16:48 | <Philip`> | That's something that's already inconsistent between browsers, I think |
| 16:48 | <Philip`> | so you can't rely on the spec's behaviour anyway |
| 16:48 | <David_Bradbury> | I just found out about whatwg today - I've always gone to the W3C - This is a nice resource! |
| 18:21 | <Hixie> | hsivonen: thanks |
| 18:21 | <Hixie> | MikeSmith: the JS was required to avoid spam bugs |
| 18:21 | <Hixie> | MikeSmith: so if you make JS no longer required, it may dramatically increase the level of spam |
| 18:21 | <Ms2ger> | Hixie, the JS was broken |
| 18:21 | <Hixie> | ah ok |
| 18:21 | <Hixie> | well then nevermind |
| 18:31 | <Hixie> | heycam|away: could you send a reply to the mail with subject line "What is the intended behaviour for undefined mandatory arguments"? |
| 18:42 | <Hixie> | oh hey, there's some sort of cvs conflict with the w3c html spec |
| 18:42 | <Hixie> | MikeSmith: is it safe for me to blow away whatever is causing that conflict? |
| 18:54 | <beowulf> | is window.innerWidth part of any whatwg spec or future spec? |
| 18:54 | <matjas> | hsivonen: I went ahead and registered `openid.server` and `openid.delegate`. |
| 18:54 | <Hixie> | beowulf: it's part of cssom view |
| 18:58 | <beowulf> | Hixie: thanks |
| 19:07 | <beowulf> | where would i be best sending a query on cssom view? |
| 19:08 | <Ms2ger> | www-style |
| 19:08 | <Ms2ger> | But the editor is touring in South America, so it might be a while |
| 19:12 | <beowulf> | 'k |
| 20:16 | <zewt> | eddie's baaaack |
| 20:21 | <Ms2ger> | I wonder how long it'll take him to figure out spamming doesn't work |
| 20:22 | <Hixie> | let me know if he does anything that requires, uh, moderator supervision |
| 20:23 | <zewt> | he's just ... noisy, heh |
| 20:23 | <zewt> | never seems to post in any threads but his own so he's easy to ignore |
| 20:25 | <Hixie> | k |
| 20:26 | <Hixie> | if anyone gets too noisy on the list let me know and i'll take care of it |
| 20:26 | <Hixie> | i don't read the list in realtime so it's hard for me to spot that kind of thing |
| 21:02 | <jgraham> | AryehGregor: So the reason to dislike implicitly adding scripts in the background is that it can be confusing |
| 21:02 | <AryehGregor> | How so? |
| 21:02 | <jgraham> | e.g. if I do document.getElementsByTagName("script")[1] in a test no realising that the test harness has inserted a script of its own |
| 21:03 | <Ms2ger> | That^ |
| 21:03 | <jgraham> | *not |
| 21:03 | jgraham | doesn't want to sound Scottish |
| 21:04 | <AryehGregor> | Hmm. |
| 21:06 | <AryehGregor> | I think that's better than requiring the extra tag, especially if lots of different people are writing a limited number of tests. |
| 21:06 | <AryehGregor> | As long as the tag is inserted unconditionally, it's easy to figure out what the problem is if you happen to hit it, which you probably won't. |
| 21:09 | <jgraham> | I think that explicit is better than implicit and that it is very few keystrokes to copy and paste the <script src="testharness.js"></script> line and add the string "report" |
| 21:09 | <zewt> | explicit isn't better than implicit when it's explicit boilerplate that's the same in everything |
| 21:09 | <AryehGregor> | Right. |
| 21:10 | <AryehGregor> | If you're worried about messing up the DOM, how about it inserts the script tag and then immediately removes it? |
| 21:10 | <AryehGregor> | The script still runs, right? |
| 21:13 | <jgraham> | zewt: Well that's a matter of taste. Python's explicit self could be seen as unnecessary boilerplate, for example |
| 21:14 | <zewt> | it's also a matter of degree |
| 21:14 | <jgraham> | AryehGregor: I would generally like to avoid doing non-obvious DOM manipulation before running tests |
| 21:14 | <jgraham> | Unless there is a compelling reason |
| 21:14 | <jgraham> | I don't think "I don't want to copy one line" is very compelling |
| 21:17 | <AryehGregor> | I think it is. :) |
| 21:18 | <AryehGregor> | I think complaints about non-obvious DOM manipulation, on the other hand, are not compelling at all unless you can give specific cases where something might break. |
| 21:19 | <AryehGregor> | Which you did for the case where the script is added and left there, but not when it's removed. |
| 21:19 | <AryehGregor> | That seems extremely harmless given that except if implementers install a custom one, the script will do nothing. |
| 21:19 | <AryehGregor> | I can't see what negative effect it could possibly have. |
| 21:20 | <jgraham> | Since the whole point is for implmentors to install a custom one, that doesn't seem like a good premise :) |
| 21:20 | <jgraham> | But the point is that if you break something to do with DOM manipulation you will sudenly get a whole bunch of test fails |
| 21:21 | <The_8472> | <AryehGregor> I can't see what negative effect it could possibly have. <- famous last words |
| 21:21 | <jgraham> | And someone (possibly me) ill have to spend their time looking at the failed tests and working out what actually went wrong |
| 21:21 | <jgraham> | *will |
| 21:22 | <jgraham> | Not doing unnecesary DOM manipulation was a design principle for the test runner |
| 21:22 | <AryehGregor> | Why is it more likely that you'll break something having to do with DOM manipulation than having to do with regular <script>s? |
| 21:22 | <jgraham> | Because script scheduling is hard? |
| 21:23 | <jgraham> | Also because in general the ECMAScript engine is a rather seperate component |
| 21:23 | <jgraham> | Changes outside the ES engine rarely break things inside the ES engine |
| 21:23 | <AryehGregor> | What kind of bug in DOM manipulation could possibly break adding and removing a script element without breaking everything anyway? |
| 21:24 | <jgraham> | I don't really want to find out :) |
| 21:25 | <The_8472> | why not ajax-load and window.eval the script? i found that to be a somewhat decent replacement for loading <script> tags into the dom |
| 21:25 | <jgraham> | But one can imagine the script failing to execute, for example, so all the tests pass but no results are reported |
| 21:25 | <jgraham> | The_8472: No. :) |
| 21:26 | <The_8472> | or rather: window.eval.apply(window,...) to set the context |
| 21:26 | <AryehGregor> | jgraham, wouldn't that break four bajillion sites as well? |
| 21:26 | <AryehGregor> | It seems like awfully basic functionality. |
| 21:26 | <Philip`> | Seems like the common case (a hundred thousand hand-written mostly-simple test cases containing the boilerplate) will be far more common than the rare case where the browser severely breaks script loading and doesn't already have loads of lower-level tests that will help identify the problem |
| 21:27 | <Philip`> | Can't the main .js file just have a "// >>>>>>>>>>>>>>>>>>>>>>> Browser vendors insert your custom code here: ... // <<<<<<<<<<<<<<<<<<<< Don't dare touch anything below this line or you'll get merge conflicts" in it? |
| 21:27 | <AryehGregor> | Right. You're arguing for a slight burden for the overwhelmingly common case, which adds up to a lot of burden if you multiply it out. In exchange for avoiding a hypothetical and unquantifiable problem, which wouldn't affect non-implementers no matter what and would only affect implementers in very implausible situations. |
| 21:28 | <AryehGregor> | That's another possibility. |
| 21:28 | <AryehGregor> | I don't think the extra include makes any sense. |
| 21:28 | <jgraham> | Philip`: The problem is that when you get a regression report with hundreds of regressions, it's hard to tell which are the simple ones that clearly identify the bug, and which are the complex ones that fail as a side efect of the bug |
| 21:28 | <Philip`> | Then the cost is just proportional to the number of browsers and the number of updates to the harness, which should be much less than the number of test cases |
| 21:30 | <jgraham> | Really, the cost per test of including one extra line is tiny. It probably takes < 1s per testcase |
| 21:30 | <jgraham> | s/case/ file/ |
| 21:31 | <Philip`> | It costs much more when you forget to include it |
| 21:31 | <Philip`> | which will probably not be uncommon |
| 21:35 | <jgraham> | 1) create a test-template.html file tht people can use for a starting point 2) make the tests not run if you fail to include it |
| 21:36 | <jgraham> | That seems to solve all those problems |
| 21:38 | <jamesr> | (sorry to jump in lacking context) are these tests intended to be completely automated (i.e. you click, it tells you how many passed)? |
| 21:38 | <AryehGregor> | jamesr, yes. |
| 21:39 | <AryehGregor> | Except without the "click" part. |
| 21:39 | <jamesr> | sure |
| 21:39 | <AryehGregor> | It runs when you load the page. |
| 21:39 | <jamesr> | and how many (order of magnitude) tests? |
| 21:40 | <jgraham> | jamesr: Unknown. Maybe 100,000 but not in 100,000 files |
| 21:41 | <jgraham> | Probably more like 1000 files |
| 21:41 | <AryehGregor> | jamesr, currently the number of test files is on the order of maybe a couple hundred, I think. |
| 21:41 | <AryehGregor> | Most only contain a few tests and run almost instantly. |
| 21:41 | <AryehGregor> | My reflection tests are one file with tens of thousands of tests, and I plan to write more like that. |
| 21:41 | <heycam> | Hixie, will do later today |
| 21:41 | <AryehGregor> | My DOM Range tests are already somewhat similar. |
| 21:42 | <jgraham> | Also the html5lib tests |
| 21:42 | <AryehGregor> | Are those also zillions of tests in one file? |
| 21:43 | <jgraham> | heycam: 04:33 < jgraham> Any opinions on what http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1013 should log? I think true, [object HTMLImageElement], undefined, but no browser agrees with me |
| 21:43 | <jgraham> | AryehGregor: Between 1 and about 5000 |
| 21:44 | <heycam> | jgraham, will check that a bit later too |
| 21:45 | <jamesr> | heycam: thanks for editing the callback stuff. i've been completely slammed |
| 21:46 | <heycam> | jamesr, no problem, I only resolved the easiest issue anyway ;) |
| 21:49 | <jgraham> | heycam: great, thanks |
| 21:50 | <Hixie> | heycam: thanks |
| 21:53 | <Philip`> | The canvas tests are 800 files already |
| 21:54 | <Philip`> | Most could probably be merged into one file easily, but some might depend on loading order so they're probably trickier |
| 21:57 | <jgraham> | Having one test per file isn't a problem |
| 21:59 | <jamesr> | heycam: i'm gonna have to skip the call, but feel free to ping me here if anything interesting comes up |
| 21:59 | <jamesr> | the agenda looked dry |
| 22:00 | <heycam> | jamesr, sure |
| 23:17 | <AlexNRoss> | Odd... W3 Validator reports: "Bad valuedofollow for attribute rel on element a: Keyword dofollow is not registered." |
| 23:18 | <AlexNRoss> | I know it's not in the HTML5 spec, however it is an initiative done by Google that was initiated some time ago; would have thought that it would have been added to the spec already. |
| 23:44 | heycam | removes "Hixe the Pixie" from the CC list of his mail |
| 23:44 | <heycam> | *Hixie |