| 08:15 | <odinho> | Lachy: 21:54 < dfltr> Sort of a random question: http://www.whatwg.org/specs/web-apps/current-work/multipage/selectors.html#selector-enabled states that inputs with type="hidden" should be omitted from :enabled, but currently no browsers support this in their qSA implementations. Is this an in-progress feature or a known issue? |
| 08:17 | <Lachy> | odinho, I mailed whatwg about that issue 2 months ago. Hixie hasn't addressed it yet. |
| 08:20 | <odinho> | Lachy: Oookay :D |
| 08:44 | <jgraham> | zcorpan: Did you say you had a tool for minimising SVG? |
| 08:44 | <zcorpan> | http://simon.html5.org/tools/js/svg-optimizer/ |
| 08:44 | <jgraham> | Thanks |
| 08:48 | <zcorpan> | it doesn't perform some obvious optimization like removing useless namespace declarations, metadata, etc, but that's usually simple to do manually |
| 08:49 | <jgraham> | Yeah, it would be nice if it removed inkscape-induced cruft |
| 08:53 | <heycam> | jgraham, you can try SVG Scour, which I think had removing inkscape cruft in mind |
| 08:53 | <heycam> | http://codedread.com/scour/ |
| 08:54 | <jgraham> | heycam: Thanks |
| 11:02 | <jgraham> | I would like to propose the onlick content attribute |
| 11:03 | <jgraham> | Because I seem to be unable to type "click" |
| 11:05 | <odinho> | jgraham: propose it on the list |
| 11:06 | <jgraham> | Alternatvely I want a device with a humidity sensor |
| 11:15 | <krijn> | *fingers crossed* |
| 11:17 | <krijnh> | \o/ |
| 11:22 | <zcorpan> | krijnh: hmm? |
| 11:23 | <krijn> | Almost up! |
| 11:23 | <zcorpan> | oh |
| 11:24 | <zcorpan> | nice |
| 11:24 | <krijnh> | http://twitter.com/krijnhoetmer/status/236415363259183104 |
| 11:26 | <zcorpan> | looks like a case from 1995 |
| 11:26 | <Ms2ger> | Nice wall |
| 11:27 | Ms2ger | furiously refreshes |
| 11:27 | <Ms2ger> | \o/ |
| 11:27 | <krijn> | Hey, you're working on some bullshit HTML standard from last century, I'm working on a crappy desktop server! |
| 11:27 | <krijn> | Stop ignoring the fact XHTML will take over some day! |
| 11:29 | Ms2ger | ignores krijn instead |
| 11:29 | <krijnh> | :) |
| 11:29 | <krijnh> | Me too! |
| 11:29 | <krijn> | Ohnoes! |
| 11:29 | <krijnh> | http://krijnhoetmer.nl/irc-logs/ up again? |
| 11:30 | <Ms2ger> | It is |
| 11:31 | Ms2ger | waves at the peanut gallery |
| 11:31 | <krijnh> | Is irc.w3.org still relevant? |
| 11:32 | <krijnh> | Is this topic already old? |
| 11:32 | <krijnh> | Should I stfu again? |
| 11:32 | <odinho> | All that smart stuff I wrote in the down time, noone will ever see it... |
| 11:33 | <zcorpan> | krijnh: you mean #html-wg? |
| 11:33 | <odinho> | Unless you take donations of logs? :P |
| 11:33 | <odinho> | Although I guess i should s/smart/stupid/ and not donate any logs so people see the reality :P |
| 11:33 | <krijnh> | zcorpan: yeah |
| 11:34 | <krijnh> | odinho: I could fill up the gaps, yes |
| 11:37 | <krijn> | Stevef: there, you can power up my PageRank again via Twitter ;) |
| 11:46 | <jgraham> | krijn: You realise that you could buy a Raspberry Pi for like 25 USD and it would be better than that thing, right? :p |
| 11:47 | <krijn> | No |
| 11:49 | <jgraham> | It would be smaller and use less electricity. That's better along some axis. I admit that it wouldn't allow you to use floppy disks. |
| 11:50 | <krijn> | Nor my awesome mIRC logger |
| 11:52 | <Ms2ger> | Didn't rniwa implement testharness.js support for webkit? |
| 11:53 | <jgraham> | I thought he did something at least |
| 12:01 | <AryehGregor> | Oh, did he? |
| 12:01 | <AryehGregor> | Awesome! |
| 12:03 | <krijn> | lol Stevef |
| 12:03 | <Stevef> | krijn: i like to be obliging |
| 12:08 | <krijn> | Some background, for those caring: we had a little second hand clothes shop, an office and a house (where my mother, brother and sister lived), but they had to throw away all of that (high server costs! ;) and start over again somewhere else. Server now is in a new (much smaller) clothes shop, but office and family is gone there. Result: a much slower internet connection in the new place (less usa |
| 12:08 | <krijn> | ge). If anyone thinks it's too slow, I'm open for donations :] |
| 12:20 | Ms2ger | likes http://testsuite.org/ |
| 12:50 | <AryehGregor> | krijn, what are the requirements for a host? |
| 13:05 | <AryehGregor> | Did you say this thing actually runs in mIRC? |
| 13:06 | <Ms2ger> | He appears to have said that |
| 13:06 | <AryehGregor> | :/ |
| 13:06 | <AryehGregor> | No wonder. |
| 13:08 | <svl> | krijn is just very, very good at paving cowpaths |
| 13:08 | <jgraham> | Actually logging IRC doesn't seem to be that hard. krijn's main value proposition is the little yellow markers people can use to stoke up flamewars |
| 13:08 | <svl> | or at least at placing the occasional cobblestone on them |
| 13:13 | <Stevef> | jgraham: http://krijnhoetmer.nl/irc-logs/whatwg/20120817#l-81 thats BS! |
| 13:49 | <AryehGregor> | jgraham, we currently detect unreliable tests by hand, file bugs on them by hand, add comments to the bugs by hand every time a known-flaky test fails using a special web interface, and then if a test starts failing far too much we disable it indefinitely by editing our test manifests by hand. And when too many tests fail on a platform, we just completely silence reporting of tests for that platform until someone goes through all the failure |
| 13:49 | <AryehGregor> | s and alters all the test manifests to skip the platform. By hand. |
| 13:49 | <AryehGregor> | Oh, and our Android test devices like to randomly die during tests, so that on any given test run a few Android runs will usually fail with no explanation. |
| 13:50 | <jgraham> | I see |
| 13:51 | <jgraham> | When we add a testit is first run 200 times to check that it produces consistent results. If it doesn't it is marked as unstable and the results are ignored for the purposes of regression detection. |
| 13:53 | <jgraham> | Then we can also mark failures in stable tests as non reproducable and query to see which tests are producing too many non reproducable fails |
| 15:20 | <dglazkov> | good morning, Whatwg! |
| 15:39 | <jarek> | Hi |
| 15:40 | <jarek> | what's the official stance on presentational attributes in SVG? Are they considered to be good or bad practice now? |
| 15:41 | <jarek> | presentational attributes in HTML were deprecated long time ago, will this also happen with SVG for the sake of consistency? |
| 15:41 | <zcorpan> | SVG is an image format, it's inherently presentational |
| 15:42 | <jarek> | zcorpan: but it shares a lot of CSS rules with HTML |
| 15:42 | <zcorpan> | that doesn't make it any less an image format |
| 15:44 | <zcorpan> | (gotta go) |
| 15:44 | <shepazu> | jarek: they are still supported, and will be for the foreseeable future. There's nothing wrong with presentational attributes, but if you don't like them, don't use them |
| 15:46 | <jarek> | I'm not really convinced that having two ways for doing the same thing is good for the standard |
| 15:46 | <jarek> | presentational attributes made sense back when XSLT and SMIL were alive |
| 15:47 | <shepazu> | jarek: you think that deprecating all content using presetanational attributes is better for the standard? |
| 15:47 | <jarek> | shepazu: in the longer run, yes |
| 15:48 | <jarek> | shepazu: there are many SVG documents that are mixing both types (e.g. files coded by hand and then tweaked in Inkscape) |
| 15:49 | <shepazu> | jarek: this is a pretty philosophical point, and I'm not convinced that it's a problem in practice, nor that the simplistic "style vs. content" argument is relevant to SVG |
| 15:56 | <jarek> | is this theoretically possible that HTML5+CSS4will eventually support all the features of SVG? |
| 15:57 | <jarek> | gradients, transforms and filters are already there |
| 15:58 | <jarek> | the biggest missing feature is <path> element |
| 15:59 | <shepazu> | jarek: it's not theoretical… HTML5 already supports all the features of SVG… it's called SVG |
| 16:00 | <jarek> | shepazu: all HTML5 does is support for inline SVG element, you still have to work with awkward SVG DOM and use SVG namespaces |
| 16:01 | <shepazu> | well, SVG2 will solve some of that |
| 16:01 | <jarek> | will it be still XML-based? |
| 16:02 | <shepazu> | anyway, HTML5 is feature-frozen, so it would be some future HTML spec, and I don't think it's likely |
| 16:02 | <shepazu> | it's markup-based |
| 16:02 | <shepazu> | later, I have a meeting now |
| 16:03 | <smaug____> | shepazu: luckily this channel is about HTML spec which isn't frozen ;) |
| 16:05 | <jgraham> | What is this "frozen" of which you speak? |
| 16:12 | <jgraham> | smaug____: Your history tests scare me. I look at them, go "oh, surely everyone's interoperable on that" and then get 3 different behaviours in three browsers |
| 16:17 | <Ms2ger> | jgraham, could have got 5 |
| 16:31 | <tantek> | Lachy, odinho re: that input hidden and :enabled issue - was that logged in bugzilla? can we add this testcase/example to it? Test here: http://jsfiddle.net/duHdp/ (from dfltr) |
| 16:32 | <jgraham> | Hmm, so if I understand the spec correctly, the behaviour of history.go(-1); history.go(1) depends on whether the previous page is in the fast back cache |
| 16:33 | <jgraham> | Um, not quite |
| 16:33 | <jgraham> | But something like that |
| 16:34 | <jgraham> | Oh, no that is an example |
| 16:34 | <jgraham> | Or, maybe I am wrong |
| 16:35 | <Ms2ger> | Maybe? |
| 16:35 | <jgraham> | Well I am clearly wrong about some things |
| 16:35 | <jgraham> | I think this is one of them |
| 16:35 | <jgraham> | For some reason I thought that the navigate algorithm cleared out any other history traversal tasks |
| 16:36 | <jgraham> | Hmm, maybe it does |
| 16:36 | <jgraham> | Depends what calls "update the session history with the new page" |
| 16:38 | <jgraham> | Ah, but this is "entry update" |
| 16:38 | <jgraham> | Should probably think somewhere other than IRC |
| 17:47 | <Hixie> | sicking: do you have a link to the e-mail where you asked for popstate to not fire during load? I thought the spec used to prevent that, and the Mozilla proposal was to switch to firing it always because it was considered really bad to stop links from working while the page was loading some huge image, or something. |
| 17:48 | <sicking> | Hixie: i don't have a link no. Define "during load" |
| 17:48 | <sicking> | Hixie: we requested multiple change |
| 17:48 | <sicking> | s |
| 17:49 | <sicking> | Hixie: one was to remove the behavior of "always fire a popstate event when firing a load event" |
| 17:49 | <sicking> | Hixie: another was to "allow popstate to fire while the page is loading, I.e. before the load event has fired, when a history traversal happens" |
| 17:52 | <sicking> | Hixie: the blog post explains it pretty well, no? |
| 18:02 | <Hixie> | sicking: i thought your e-mail just now was requesting that we not fire it while page was loading? |
| 18:02 | <Hixie> | sicking: maybe i misread your e-mail |
| 18:02 | <sicking> | Hixie: i might have been unclear |
| 18:03 | <Hixie> | "it's unfortunate if the spec still calls for popstate to be fired during pageload" |
| 18:03 | <Hixie> | i guess that can eb read both ways |
| 18:03 | <Hixie> | anyway as far as i know the spec exactly matches the requests you (mozilla) made |
| 18:12 | <sicking> | Hixie: yeah, i think i read it the other way |
| 18:12 | <sicking> | Hixie: lemme recheck the thread and clarify |
| 18:14 | <sicking> | Hixie: i think he's saying that the spec calls for popstate to automatically fire when the initial "load" event fires for a page load. So no state transitions happening other than loading the page |
| 18:15 | <sicking> | Hixie: in fact, i'm quite certain that is what he says given the provided examples |
| 18:16 | <sicking> | i'll check if his spec quotes are accurate, but if they are the spec doesn't follow the mozilla proposal |
| 18:16 | <Hixie> | i'm not aware of 'popstate' being mentioned anywhere near the 'load' event |
| 18:16 | <Hixie> | they're in different chapters |
| 18:17 | <Hixie> | the only place in the spec that fires popstate is the "traverse the history" algorithm, and then only if /state changed/ is true |
| 18:18 | <Hixie> | that's true when the page is first navigated to, but that's _long_ before 'load' fires |
| 18:19 | <Hixie> | (in fact in most UAs I'd expect that to happen before you have any chance of hooking an event handler for it) |
| 18:20 | <Hixie> | (it is guaranteed to be before any script execution, though i guess not before the <body onpopstate> is parsed, so it could theoretically be detected) |
| 18:21 | <sicking> | Hixie: define "when the page is first navigated to" |
| 18:22 | <sicking> | Hixie: the mozilla proposal was that popstate only fires when transitioning sessionhistory entries by the current Document doesn't change |
| 18:22 | <Hixie> | well you definitely have to fire it if you go from doc A at state 1 to doc B and back to doc A at state 2 |
| 18:22 | <Hixie> | i guess we could not fire it when you're going to the document for the first time |
| 18:23 | <sicking> | how could you go back to doc A at state 2? |
| 18:23 | <Hixie> | (first navigated = when the Document has no session history entry that it has ever been traversed to) |
| 18:23 | <sicking> | if you left doc A at state 1 to doc B, and then go back, wouldn't you end back at state 1 in doc A? |
| 18:23 | <Hixie> | not if you go forward or back in the session history by more than one step at a time |
| 18:24 | <sicking> | ah, yes |
| 18:25 | <sicking> | so if you have three entries in SH: <A, 1> <A, 2> <B, 1>. And then go from first to third, no popstate fires. but if you then go from third to second, popstate does need to fire |
| 18:25 | <Hixie> | right |
| 18:25 | <Hixie> | currently, if you click on a link to <C, 1>, it also fires, as soon as the page is shown |
| 18:25 | <Hixie> | we can change that though |
| 18:25 | <sicking> | but if you have <A, 1> <A, 2> and the user is at the second state and clicks a link to document B then no popstate should fire at any time |
| 18:26 | <Hixie> | (there's no risk of compat issues since you can barely ever detect it anyway) |
| 18:26 | <sicking> | yeah, i think we should change that |
| 18:26 | <Hixie> | currently the spec treats that as if you are going from <B, null> to <B, 1>, which is why it fires the event, fwiw |
| 18:27 | <sicking> | it's unclear what the compat risk is since i don't know how much of the page can be parsed at that time. But gecko already does this, so i'm not too worried about compat risk |
| 18:27 | <sicking> | especially for Gecko since we wouldn't change :-) |
| 18:27 | <Hixie> | and the other browsers ahven't updated to the new model anyway, right? |
| 18:27 | <sicking> | i don't think Webkit does what the spec currently or Gecko does though |
| 18:28 | <sicking> | i thought webkit had implemented the gecko model a long time ago, but apparently they have bugs |
| 18:28 | <sicking> | this stuff really really needs a test suite |
| 18:28 | <sicking> | i'm quite worried that IE gets it totally wrong |
| 18:28 | <Hixie> | filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=18605 |
| 18:30 | <sicking> | thanks |
| 19:00 | <nvartolomei> | . |
| 19:37 | <Yuhong> | Just posted this: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-August/036933.html |
| 20:52 | <jgraham> | sicking: Hmm we have tests for the history state stuff. Did we not release them? |
| 20:52 | <jgraham> | Oh we did |
| 20:52 | <jgraham> | http://w3c-test.org/html/tests/submission/Opera/historyinterface/ |
| 20:53 | <sicking> | jgraham: They apparently missed this case though, since I believe Gecko passes them |
| 20:53 | <jgraham> | sicking: Not the gecko I have here at least |
| 20:54 | <jgraham> | They might have missed this case of course, we don't claim to write perfect tests :) |
| 20:54 | <sicking> | hmm.. yeah, you're right. I seem to recall being told we pass, but i'm clearly wrong |
| 20:54 | <jgraham> | Patches welcome of course |
| 21:33 | <zewt> | (opera history api seemed pretty broken when I was testing recently; clicking <a href=#foo> didn't fire onpopstate) |
| 21:36 | <jgraham> | zewt: Write a test and we will fix it |
| 21:41 | <zewt> | i really wish there was a web app I could just write, run and submit tests from |
| 21:44 | <jgraham> | Yes, several people have suggested that |
| 21:44 | <jgraham> | But really, even a live DOM viewer page that demonstrates the problem and can be turned into a real test would be fine |
| 21:45 | <zewt> | well, it's pretty straightforward, eg. https://zewt.org/~glenn/test-same-hash.html clicking the links does nothing |
| 21:46 | <zewt> | fortunately I can polyfill it pretty easily |
| 21:53 | <zewt> | hmm, is it intentional that when postMessage(stuff, [transfer map]) throws DataCloneError, sometimes the objects are neutered and sometimes they're not (depending on when the exception is thrown)? |
| 22:48 | <rniwa> | how do I write a nullable method using WebIDL? |
| 22:49 | <zewt> | nullable method? |
| 22:49 | <rniwa> | yeah |
| 22:49 | <rniwa> | that may or may not exist. |
| 22:59 | <TabAtkins_> | Don't think you can. |
| 23:00 | <zewt> | doesn't really mesh with prototype chains |
| 23:01 | <TabAtkins_> | Yeah, you'd have to override the method on the instance to be undefined. |