| 00:17 | <Hixie> | jgraham: when you do tests for unload, one thing to see is what happens on pagehide and beforeunload, which fire around the same time |
| 03:39 | <Hixie> | good times, the w3c html wg editors have now changed the specs to contain the lies I had removed years ago :-) |
| 03:41 | <Hixie> | hahaha and they removed the guarantee that they'll reply to feedback |
| 03:42 | <Hixie> | and they added a note saying their document shouldn't be cited |
| 03:42 | <Hixie> | well, can't argue with that one :-P |
| 04:19 | <zewt> | sounds like typical "phew finally we're rid of that guy standing in our way let's do everything we've ever wanted" |
| 04:20 | <zewt> | similarly i wonder if somebody who used to work at google and kept the search page sane left a couple years ago, since all of a sudden all kinds of horrible nonsense started showing up on the search, the lack of which was what defined google search as non-crappy for so long |
| 07:34 | <annevk> | GPHemsley: thanks for the report; should be fixed now, but I should really find a better solution |
| 07:34 | <annevk> | GPHemsley: I don't really know what the problem is unfortunately, I think something goes wrong when writing the cache to disk |
| 08:50 | <Stevef> | hixie: which lies have been added back into w3c spec? |
| 09:03 | <annevk> | Stevef: presumably one can find out by looking at the HTML WG commit log, however I have no idea how their github setup works |
| 09:04 | <Stevef> | annevk: sure, just curious |
| 09:05 | <annevk> | me too |
| 09:05 | <Stevef> | annevk: i did have a look but couldn't see anything of note |
| 09:05 | <annevk> | pointer? |
| 09:17 | <Stevef> | annevk: i just looked at the status of this document section in the spec, presuming it was soemething there, can't make any sense out of github |
| 09:19 | <annevk> | is http://dev.w3.org/html5/spec/ still the latest? |
| 09:20 | <annevk> | it has today's date, but also mentions the WHATWG a fair bit and does not mention github... |
| 09:20 | <annevk> | oh well, whatever |
| 09:20 | <darobin> | annevk: I don't think the header material has been updated much |
| 09:20 | <darobin> | it won't be finalised before the issue attached to it is resolved anyway |
| 09:21 | <darobin> | http://dev.w3.org/html5/spec/ is updated every hour or so with what's in GH IIRC |
| 09:21 | <annevk> | darobin: where can I see what's been committed in github limited to the W3C copy? |
| 09:22 | <darobin> | I think that at some point later on I'll write up a history section so I can introduce plenty of new lies of my own |
| 09:22 | <darobin> | annevk: you mean without the commits imported from what? |
| 09:22 | <annevk> | darobin: yeah I guess |
| 09:23 | <darobin> | mmmm, I'm not sure the GH interface can filter that |
| 09:23 | <annevk> | darobin: or with, assuming they are easily distinguishable |
| 09:23 | darobin | multitasking atm, can't check |
| 09:23 | <annevk> | no rush, not even a real need, just curious :) |
| 09:23 | <darobin> | annevk: you can look at the commits tab on the repo's interface |
| 09:24 | <annevk> | oh so just https://github.com/w3c/html/commits |
| 09:24 | <darobin> | otherwise, I'm pretty sure you can do filters using git log, but it's "Work" |
| 09:24 | <annevk> | okay |
| 09:25 | <annevk> | ah, Hixie was presumably referring to the edits by Microsoft |
| 09:25 | <annevk> | e.g. https://github.com/w3c/html/commit/b5fde23fa2855418a281cddefaf672e05379a77f |
| 09:27 | <annevk> | https://github.com/w3c/html/commit/9652303ca313a5e2b5cd1cb80dbd1deac713ac55 also changed something not mentioned in the commit |
| 09:28 | <annevk> | I guess techtoons is from Microsoft too? |
| 09:29 | <annevk> | gotta go |
| 10:08 | <Stevef> | FYI created twitter account with feed of W3C HTML commits https://twitter.com/HTML_Commits |
| 10:22 | <beowulf> | hey, does anyone know of examples of AT/screen readers that have trouble with a page that only use H1s? |
| 10:24 | <beowulf> | and is there a better place to ask my question? :) |
| 10:31 | <smaug____> | moznet's #accessibility might be a better place to ask |
| 10:54 | <Stevef> | beowulf: what do you mean by trouble? |
| 10:56 | <Stevef> | beowulf: for AT that does not support the HTML5 concept of heading levels the structure will be flattened, 1 AT currently supports the HTML5 outline - JAWS 13+ , but its flaky |
| 10:59 | <beowulf> | Stevef: that's what I mean, ya. only one works, hmm. what kind of problems does a flat structure bring? |
| 11:00 | <beowulf> | Stevef: is this a good list for me to work off for trying stuff out? http://en.wikipedia.org/wiki/List_of_screen_readers |
| 11:03 | <Stevef> | beowulf: it means that AT users will not be able to understand the structure as well as when the levels are correctly exposed, when level is exposed users can navigate by level, it helps them understand the relationship between content blocks |
| 11:05 | <Stevef> | beowulf: I would suggest using NVDA on windows, VoiceOver on Mac OSx, iOS, Orca on linux |
| 11:06 | <beowulf> | Stevef: cheers! |
| 11:07 | <Stevef> | beowulf: this http://www.paciellogroup.com/blog/2012/02/rough-guide-browsers-operating-systems-and-screen-reader-support/ may also be helpful in regards to which browsers to use |
| 11:10 | <Ms2ger> | krijn, down again? |
| 11:10 | <krijn> | Yeh |
| 11:10 | <krijn> | Moving again :/ |
| 11:10 | <krijn> | Hopefully up again tonight, faster |
| 11:11 | <Ms2ger> | \o/ |
| 11:24 | <smaug____> | good that there is the backup logging |
| 11:32 | <sedovsek> | Hey! I've got a weird rendering issue on Safari6 when it comes to translate3d transforms |
| 11:32 | <sedovsek> | http://shrani.si/f/2L/xI/3AJuuVvj/screen-shot-2012-09-18-a.jpg |
| 11:32 | <sedovsek> | (It duplicates/translates the image and keeps the original intact) |
| 11:56 | <smaug____> | sedovsek: file a bug on Apple ? |
| 11:56 | <sedovsek> | smaug____: I might... |
| 11:56 | <sedovsek> | http://shrani.si/f/3v/Oy/4ufaLtAr/screen-shot-2012-09-18-a.jpg - more detailed example. |
| 11:57 | <sedovsek> | After I've changed the img source, it changes, but the origin stays at the same position. |
| 11:57 | <sedovsek> | The origin = 8.png, which was replaced with 2.png. |
| 11:57 | <smaug____> | "might". browser vendors need the bugs filed to be able to fix them ;) |
| 11:59 | <sedovsek> | True, true. |
| 12:12 | <cabanier> | scribenick: cabanier |
| 12:12 | <cabanier> | topic: Dynamic document loading |
| 12:12 | <cabanier> | link: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/MappingTopics |
| 12:13 | <jgraham> | cabanier: Wrong channel? |
| 12:13 | <heycam> | yes :) |
| 12:21 | <annevk> | hmm |
| 12:21 | <annevk> | the .hash and .search part of the URL API suck |
| 12:23 | <annevk> | for a URL http://example.org/?# both will return the empty string |
| 12:23 | <annevk> | but they also return the empty string for http://example.org/ |
| 12:23 | <annevk> | and setting them to the empty string for the first URL will not remove ? and # from the URL |
| 13:02 | <annevk> | matjas: thanks for the punycode link, going to take a look now |
| 13:04 | <annevk> | matjas: mapDomain does not seem to follow IDNA separator requirements |
| 13:11 | <annevk> | matjas: typo in https://github.com/bestiejs/punycode.js/blob/master/punycode.js#L201 |
| 13:21 | <annevk> | matjas: also, what's BestieJS? |
| 13:27 | <darobin> | is there any spec that gives any ounce of clarity as to whether redirects should be honoured on DELETE? |
| 13:27 | <Ms2ger> | I'd default to "no" |
| 13:28 | <darobin> | well, given that this is HTTP that would be my default too |
| 13:28 | <darobin> | but hey it's not like we've got stuff built on top of this |
| 13:28 | darobin | writes a test to figure out if browsers are as random as CLI clients for this |
| 13:29 | <miketaylr> | annevk: it's more or less a collection of scripts that don't suck |
| 13:29 | <annevk> | miketaylr: heh |
| 13:31 | <annevk> | so the problem with this library is its toASCII method name |
| 13:31 | <annevk> | which seems to indicate it implements http://tools.ietf.org/html/rfc3490#section-4.1 but it really doesn't |
| 13:32 | <miketaylr> | annevk: ah, here we go https://github.com/bestiejs/bestiejs/blob/master/README.md |
| 13:32 | <annevk> | e.g. ™.com -> tm.com |
| 13:32 | <annevk> | I doubt it does that |
| 13:37 | <annevk> | right |
| 13:37 | <annevk> | see http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1775 and compare with browsers |
| 13:38 | <annevk> | of course it never claimed to implement that |
| 13:50 | <annevk> | hmm |
| 13:50 | <annevk> | this might be something IDNA2008 changed |
| 13:50 | <annevk> | ffs |
| 14:04 | <annevk> | not sure why I forgot about http://unicode.org/reports/tr46/ |
| 14:12 | <annevk> | oh, Gecko does not even have IDNA2008 https://bugzilla.mozilla.org/show_bug.cgi?id=479520 |
| 14:12 | <annevk> | Opera does since 11.60 |
| 14:12 | <annevk> | yay for domain names I guess |
| 14:15 | <zcorpan> | having it breaks http://tinyarrows.com/ |
| 14:16 | <annevk> | ooh |
| 14:16 | <annevk> | Opera does not do UTS 46 |
| 14:16 | <annevk> | in Opera ™.com does indeed become xn--y2g.com |
| 14:17 | <annevk> | they should have taken this a bit more seriously, I mean this is not like XML 5th Edition |
| 14:17 | <annevk> | this is stuff that's actually used |
| 14:19 | <zcorpan> | i guess idna2008 needs to be changed since there are urls on the web expecting some characters to work (tinyarrows is what i know about) |
| 14:20 | <annevk> | do you know if it would work if you implemented UTS 46? |
| 14:21 | <annevk> | afaict IDNA2008 is pure Punycode without some kind of filtering step beforehand (NAMEPREP in IDNA2003) |
| 14:22 | <annevk> | Opera had the same problem with not recognizing certain label separators such as U+3002 |
| 14:22 | <zcorpan> | i don't know, i haven't read much about this |
| 14:22 | <annevk> | required in IDNA2003 and also in UTS 36 |
| 14:22 | <annevk> | euh 46 |
| 14:24 | <zcorpan> | DSK-235264 |
| 14:26 | <annevk> | oh Yngve |
| 14:37 | <annevk> | can anyone tell me where http://faß.de/ goes in IE? |
| 14:45 | <zcorpan> | ie8 on XP goes to www.bayern-fass.de |
| 14:46 | <annevk> | thanks, but I think IE8 is too old, IDNA2008 is from end of 2010 |
| 14:46 | <darobin> | ah, I'm glad to see W3C isn't the only organisation with highly sensible year-based naming conventions |
| 14:47 | zcorpan | boots ubuntu again |
| 14:48 | <annevk> | darobin: or alone in pushing out updates to standards without ensuring all stakeholders follow them |
| 14:49 | <darobin> | wait, there are stakeholders in standards? |
| 14:49 | <darobin> | you're making that up... |
| 14:49 | <annevk> | maybe |
| 14:55 | <jgraham> | Good way to deal with vampires |
| 14:55 | <jgraham> | And I'mn pretty sure there are lots of them involved with standards |
| 15:05 | <darobin> | oh yes, the famed Buffy The Stakeholder |
| 15:09 | <annevk> | short summary: http://annevankesteren.nl/2012/09/idna |
| 15:18 | <tomasf> | annevk: what does "hierarchical URLs" mean? why do these things not apply to URLs with other schemes? |
| 15:19 | <annevk> | tomasf: data URLs don't have a domain name |
| 15:19 | <annevk> | neither do javascript URLs |
| 15:20 | <tantek> | hey annevk - I have a comment about a www-archive post of yours |
| 15:20 | <tomasf> | annevk: oh, right. I see |
| 15:20 | <annevk> | tantek: go ahead |
| 15:20 | <tantek> | this one: http://lists.w3.org/Archives/Public/www-archive/2012Aug/0028.html |
| 15:20 | <tantek> | I understand your perspective in that thread |
| 15:20 | <annevk> | tomasf: I guess mailto might be an edge case |
| 15:20 | <tantek> | though I come to a different conclusion |
| 15:21 | <annevk> | tantek: you mean you read the Agreement in a different way? |
| 15:21 | <tantek> | as quoted in your email from http://www.w3.org/Consortium/Legal/2007/06-invited-expert.html#L118 |
| 15:21 | <tantek> | " «Branching» is one example of a non-permissible derivative work. " |
| 15:21 | <annevk> | tantek: because the W3C agrees with my reading afaict |
| 15:21 | <tantek> | in the context there, it implies branching *outside* W3C |
| 15:21 | <tantek> | in my opinion that leads to only one logical conclusion |
| 15:21 | <tantek> | Since W3C doesn't want branches of specs *outside* of W3C, it's W3C's WDs (etc.) that themselves become branches. |
| 15:22 | <tantek> | while the main "trunk" lives elsewhere with a more liberal license |
| 15:22 | <tantek> | this has already happened with W3C HTML5 branching from WHATWG HTML. |
| 15:22 | <annevk> | yeah, but it gets hazy when you get contributions from others |
| 15:22 | <tantek> | so you only allow contributions to others to the main "trunk" that lives outside W3C |
| 15:23 | <tantek> | but yes, it may get hazy if other contributors contribute directly to a W3C branch of a spec |
| 15:23 | <tantek> | harder to incorporate those into trunk |
| 15:23 | <tantek> | due to the branch license |
| 15:24 | <annevk> | and since using it in that manner would not match their intent, they could still try to find ways to make it difficult |
| 15:24 | <annevk> | I rather have it solved |
| 15:24 | <tantek> | in the example of Fullscreen, since we're the only contributors I don't see a problem with continuing with trunk development being CC0+OWFa |
| 15:24 | <tantek> | it will take quite a lot of time to match whatever "intent" happens to be strong enough to motivate clarification, and also take such time to "make it difficult" |
| 15:25 | <darobin> | actually, I don't think that there's an intractable problem with people contributing to a W3C branch — you just need to make sure that they sign the RF commitment (which is separate from the copyright issue) |
| 15:25 | <darobin> | the problem is more in moving a spec that has already been published under W3C © to an open repo |
| 15:25 | <Ms2ger> | I don't think there's an intractable issue either |
| 15:25 | <tantek> | I'm fine to act within this particular reading of "branching not allowed" (thus W3C works themselves become branches) |
| 15:25 | <Ms2ger> | You just don't work at the W3C |
| 15:26 | <darobin> | tantek: that said I agree with annevk though, it would be better to get this fixed |
| 15:26 | <tantek> | and simultaneously pursue the issue of overturning such wording about branching at the AC/AB level |
| 15:26 | <tantek> | darobin - agreed long term better to get this fixed |
| 15:26 | <tantek> | however, I see nothing that prevents acting this way in the "short term" (in the mean while) |
| 15:26 | <darobin> | the way of getting movement on this is not the AB at this point |
| 15:27 | <darobin> | but it should be possible to mount an AC push — it just needs to be properly coordinated and politically well-organised |
| 15:27 | <tantek> | there's no urgency for a "fix" |
| 15:27 | <tantek> | because the "problem" just results in the consequence that W3C works themselves become branches. |
| 15:28 | <darobin> | I agree that we can largely make this work in the short term |
| 15:28 | <tantek> | therefore only those that care about *that* as a "problem" (that W3C works themselves become branches) need to bother with putting energy into an actual fix. |
| 15:28 | <tantek> | in the mean time, meh |
| 15:28 | <tantek> | all that wording does is encourage trunk spec development outside of W3C |
| 15:28 | <annevk> | tantek: my work is https://github.com/whatwg now |
| 15:29 | <darobin> | tantek: indeed — though that wasn't foreseen when the wording was crafted |
| 15:29 | <annevk> | tantek: when the W3C Agreement is changed I'm happy to reconsider |
| 15:30 | <annevk> | tantek: btw, if you want access, do you have a github account? |
| 15:30 | <tantek> | annevk, thanks annevk - I will treat https://github.com/whatwg/fullscreen as trunk for Fullscreen |
| 15:30 | <tantek> | that would be great |
| 15:31 | <annevk> | ah, tantek is you :) |
| 15:31 | <tantek> | :) |
| 15:31 | <annevk> | added you |
| 15:31 | <darobin> | annevk: given that setup, why bother with IE status in the first place? you can work on the lists, there are no calls, you just commit to some other repo and someone ships to TR now and then... |
| 15:31 | <annevk> | darobin: I wanted to bother because I was also a Chair |
| 15:32 | <darobin> | if you want to attend f2fs it's a chair's call anyway |
| 15:32 | <darobin> | oh right, the notifications stuff |
| 15:32 | <darobin> | does that group really need a chair? :) |
| 15:32 | <tantek> | annevk, I'm also happy to reconsider when the W3C IE Agreement is changed |
| 15:32 | <annevk> | darobin: and some companies are happier with W3C standards and I don't care strongly either way |
| 15:33 | <tantek> | but until then, that wording in the agreement makes a strong case for trunk spec development outside-of-W3C, and I will communicate that as such to anyone at W3C that asks. |
| 15:33 | <darobin> | annevk: sure — but my point is that those can still be W3C standards without you being an IE, the only thing that blocks is chairing WebNotifs |
| 15:33 | <annevk> | darobin: well and somebody doing the forking |
| 15:33 | <darobin> | tantek: you coming to TPAC? |
| 15:33 | tantek | notices that https://github.com/whatwg doesn't publicize members, is that deliberate? |
| 15:33 | <darobin> | annevk: there doesn't need to be any forking... |
| 15:33 | <annevk> | tantek: oh no, we can do that |
| 15:33 | <tantek> | darobin - trying to make travel plans :( |
| 15:34 | tantek | hates dealing with travel plans |
| 15:34 | <annevk> | darobin: need to change the boilerplate and such :) |
| 15:34 | <darobin> | wasn't the semantic web supposed to make travel plans automatic? |
| 15:34 | tantek | is considering notifying W3C that they ought to consider Halloween a religious holiday to be avoided for those that celebrate it as such. |
| 15:34 | <darobin> | annevk: that's, like, nothing :) |
| 15:35 | <darobin> | in fact if you're consistent across specs we could probably set it up once and for all |
| 15:35 | <darobin> | then for TR snapshots you just need a "document contact" — nothing says it has to be the editor |
| 15:35 | <darobin> | tantek: well, we celebrate it as such with a good game of Werewolk :) |
| 15:36 | <annevk> | darobin: works for me :) |
| 15:36 | <darobin> | annevk: well if it works for you, I reckon you can make that the plan :) |
| 15:36 | <darobin> | (and come to TPAC) |
| 15:37 | <darobin> | as for chairing WebNotifs, I guess plh can find someone else — it doesn't seem like a highly political group |
| 16:04 | <tantek> | annevk - how do I link to https://github.com/whatwg/fullscreen/blob/master/Overview.html so that it views as a web page, not as raw HTML? |
| 16:05 | <annevk> | tantek: http://fullscreen.spec.whatwg.org/ |
| 16:05 | <annevk> | tantek: it updates automatically on push |
| 16:05 | <tantek> | thanks |
| 16:09 | <tantek> | is W3C bugzilla your preferred issue tracking mechanism for Fullscreen, or is that just one input? |
| 16:09 | <tantek> | this: https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Fullscreen&resolution=--- |
| 16:10 | <annevk> | it's easier to track |
| 16:10 | <annevk> | but the last commit was based on an email thread |
| 16:10 | <tantek> | right - saw the thread |
| 16:33 | <JonathanNeal> | If a polyfill is code that fills in missing gaps of (existent) functionality, what would you code that fills in missing gaps of (non-existent) functionality? Still a polyfill? |
| 16:34 | <JonathanNeal> | An example of this non-existent polyfill would be https://github.com/scottjehl/picturefill (from before it was specced) |
| 16:35 | <JonathanNeal> | And I would further define it as "proposed functionality". |
| 16:35 | <jgraham> | "javascript library" |
| 16:36 | <JonathanNeal> | all right. seemed like it was a little more specific than that. |
| 16:37 | <jgraham> | "javascript library that makes dangerous assumptions about future markup design and will likely provide a back-compat problem when new features are added to browsers" |
| 16:37 | <jgraham> | (although using <div> and data- is fine) |
| 16:37 | <jgraham> | (so that example is probably OK) |
| 16:42 | <JonathanNeal> | Bah. Wikipedia has it written that "polyfills can also be used to add entirely new functionality to browsers" http://en.wikipedia.org/wiki/Polyfill |
| 16:43 | <JonathanNeal> | I'm geeking over semantics again, but that seems like too liberal an interpretation. That would make all javascript libraries a kind of polyfill, jgraham. :( |
| 16:45 | <JonathanNeal> | They are really more like "javascript spoilers". |
| 16:59 | <annevk> | it's just a script... |
| 17:03 | <JonathanNeal> | so is a polyfill, so is a library. |
| 18:18 | <Hixie> | talk about missing the point. search for backingStoreRatio on www.html5rocks.com/en/tutorials/canvas/hidpi/ and weep at how people miss the point of prefixes. |
| 18:21 | <Ms2ger> | There's a point to prefixes? |
| 18:21 | <Hixie> | there's a point |
| 18:21 | <Hixie> | it's a misguided point, but it's a point nonetheless :-) |
| 18:22 | <Ms2ger> | Zing |
| 18:23 | <jwalden> | they seemed to work better when web developers weren't following browser developments so closely, so you had fewer, and more conscientious, developers using them |
| 18:23 | <Hixie> | the ones using them are still not following development, as clearly shown by the blog post above |
| 18:24 | <Hixie> | in other news i have NO IDEA how to spec this nonsense with unload/pagehide/beforeunload/navigation/traversal |
| 18:25 | <Hixie> | http://www.whatwg.org/issues/#navigation |
| 18:35 | <rniwa> | Hixie: navigation within the navigation? |
| 18:39 | <Ms2ger> | Yo dawg |
| 18:44 | <Hixie> | rniwa: for instance |
| 18:46 | <jgraham> | Hixie: That makes two of us :( |
| 18:46 | <Hixie> | what happens if in a subframe pagehide the page navigates a sibling iframe, should that sibling get two unloads? one? |
| 18:46 | <Hixie> | what if you do it in the beforeunload? |
| 18:47 | <Hixie> | what if you are going back, and in that unload you navigate a subframe? |
| 18:47 | <Hixie> | plus i really don't understand the compatibility constraints |
| 18:47 | <Hixie> | i'm tempted to file a bug on the htmlwg, paste in all the feedback, and wait for darobin to fix it, but i know what would really happen is they'd reject it and say that if i disagree i should write a CP |
| 18:48 | <Hixie> | so that isn't helpful |
| 18:48 | <rniwa> | Hixie: i don't think chrome fires beforeunload even… |
| 18:48 | <Hixie> | rniwa: in general? or in that case? |
| 18:48 | <rniwa> | Hixie: in general. |
| 18:48 | <Hixie> | pretty sure it fires it in general |
| 18:48 | <jgraham> | Yeah, it really does |
| 18:49 | <othermaciej> | q+ |
| 18:49 | <darobin> | hmmm, if it's a real bug I doubt it would be rejected |
| 18:49 | <rniwa> | oh oops, yeah we do fire. |
| 18:49 | <darobin> | I reserve the right to defer it to 2016 though ;-) |
| 18:49 | <othermaciej> | oops |
| 18:49 | <jgraham> | I'm sort of hopeful that the compat. constraints are "do what either Gecko or WebKit already does and you will be fine" |
| 18:49 | <darobin> | wrong channel :) |
| 18:49 | <rniwa> | Hixie, jgraham there is a bug… |
| 18:50 | <jgraham> | The problem is I don't know how to write down an algorithm that is sure to do what Gecko or WebKit already does |
| 18:50 | <Hixie> | darobin: imho this is a CR blocking bug since you couldn't exit CR with the spec incorrectly describing this (unless you violate w3c process like everyone else, of course) |
| 18:50 | <Hixie> | jgraham: yeah i don't even understand what they do |
| 18:51 | <darobin> | Hixie: your view of process is highly literalist :) |
| 18:51 | <Hixie> | jgraham: and what they do is different and bz says what webkit does is not compatible enough for gecko |
| 18:51 | <jgraham> | Indeed |
| 18:51 | <Hixie> | darobin: my view is that the process should either be followed or it's pointless |
| 18:51 | <jgraham> | My view is that it's pointless :) |
| 18:51 | <Hixie> | well, yes |
| 18:51 | <Hixie> | but then we should dump it |
| 18:51 | <Hixie> | not pretend to follow it and say that we're just being "not literalist" |
| 18:52 | <jgraham> | (I think blocking patent policy on the navigation algorithm being right is absurd) |
| 18:52 | <Hixie> | agreed |
| 18:52 | <jgraham> | (I think the navigation algorithm being right is high priority for the spec) |
| 18:52 | <Hixie> | agreed |
| 18:52 | <Hixie> | i just wish i understood what "right" was :-P |
| 18:53 | darobin | process *shrug*, just interested in getting shit done, and getting RF out o fit :) |
| 18:53 | <Hixie> | getting shit done by delaying it til 2016? :-) |
| 18:53 | <rniwa> | as long as the navigation algorithm doesn't involve longdesc, we should be able to spec in the next few years :) |
| 18:53 | <darobin> | 2016 is, like 5.7 or something :) |
| 18:54 | <Hixie> | "high priority" is hopefully faster than 4 years |
| 18:54 | <darobin> | rniwa: I think we should add longdesc actually — it's important to be able to get a longer description of the reason why you're navigating |
| 18:55 | darobin | dusts out his "This is a joke" emoticon set, seems useful |
| 18:55 | <Ms2ger> | iframe longdesc? |
| 18:55 | <darobin> | History.longdesc too! |
| 18:55 | <rniwa> | Hixie: not sure… this P1 bug in WebKit has been open since 2005: https://bugs.webkit.org/show_bug.cgi?id=3710 |
| 18:56 | <Hixie> | hah |
| 18:57 | <Ms2ger> | Pah |
| 18:57 | <Ms2ger> | We've got bugs open that were marked P1 in 2002 |
| 18:57 | <rniwa> | darobin: should it take an URL or string? |
| 18:57 | <Ms2ger> | rniwa, list of URLs |
| 18:57 | <Ms2ger> | Like profile |
| 18:57 | <darobin> | URLs? OMG, nevarh! |
| 18:57 | <darobin> | it should be an XRI |
| 18:57 | <jgraham> | Hixie: It wasn't clear to me that the WebKit behaviour wasn't compatible. |
| 18:58 | <Hixie> | jgraham: yeah the bugs are 404 now |
| 18:58 | <jgraham> | Indeed |
| 18:58 | <Hixie> | jgraham: so, hard to say |
| 18:58 | <darobin> | rniwa: lovely bug that — what kind of caret do you display when you have a ligature glyph that spans directional boundaries? |
| 18:58 | <rniwa> | dunno |
| 18:58 | <Hixie> | jgraham: what i'd LIKE to say is "while in beforeunload, unload, or pagehide, you cannot navigate anything" |
| 18:58 | <jgraham> | darobin: Is that even possible? |
| 18:59 | <Hixie> | jgraham: in the entire event loop group |
| 18:59 | <Hixie> | jgraham: just like we do with alert() |
| 18:59 | <darobin> | jgraham: you can try :) |
| 18:59 | <Hixie> | pretty sure that's a non-starter though |
| 18:59 | <jgraham> | Hixie: Yeah, that does have the appeal of simplicity |
| 18:59 | <rniwa> | Hixie: that might be incompatible with the Web... |
| 18:59 | <Hixie> | but a boy can dream |
| 18:59 | <rniwa> | Hixie: certainly. |
| 18:59 | <Ms2ger> | Better dream of trains, those can come true :) |
| 19:00 | <darobin> | not navigating in beforeunload/unload would break all those pr0n sites that try to keep people from hitting back I believe |
| 19:00 | <darobin> | (or so I'm told, uh) |
| 19:01 | <Hixie> | speaking of trains, wtf is with the 60215 being out of stock at the factory |
| 19:02 | <Hixie> | it's been months now |
| 19:02 | <Hixie> | grrr |
| 19:02 | <Hixie> | jgraham: what does webkit do, just stop navigation in the bc being unloaded and its descendants and ancestors? |
| 19:09 | <jgraham> | Hixie: I don't recall what happens in descendants/ancestors |
| 19:09 | <Hixie> | what about multiple navigations started from different unload handlers all fired as part of the same dispatch? |
| 19:11 | <jgraham> | In the same document? |
| 19:13 | <jgraham> | Something like http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1776 ? |
| 19:13 | <Hixie> | yeah |
| 19:14 | <Hixie> | i do like this webkit policy of not doing navigation from unload |
| 19:14 | <jgraham> | Chrome ends up at the document in the link, firefox at the image |
| 19:14 | <Hixie> | and how many unloads fire? |
| 19:14 | <Hixie> | one of the big complications is what "cancel previous navigation" means when you're in the middle of dispatching unloads and pagehides |
| 19:14 | <Hixie> | or beforeunloads |
| 19:15 | <Hixie> | do you finish running the unload algorithm before killing the navigation? |
| 19:15 | <Hixie> | i'm thinking of speccing that hte nav algorithm launches beforeunload/unload algorithms async, then blocks on those algorithms, so that canceling navigation never actually cancels the beforeunload/unload algorithms |
| 19:16 | <Hixie> | but the real problem is how to deal with hiearchies |
| 19:16 | <Hixie> | of iframes unloading |
| 19:16 | <jgraham> | In that example both unload events fire |
| 19:17 | <jgraham> | So I imagine it works by saying "if there is another navigation running the unload steps, abort this navigation" |
| 19:17 | <jgraham> | But I have no idea how the multiple frame thing should work |
| 20:59 | <Hixie> | jgraham: which is "this" navigation? |
| 21:17 | <Hixie> | hmmmm |
| 21:17 | <Hixie> | if unload is fired and anything notices, the document's salvageable flag gets set to false |
| 21:17 | <Hixie> | so what if we just say that we also only ever fire unload oncein that case |
| 21:17 | <Hixie> | or something like that |
| 21:52 | <Hixie> | http://www.hixie.ch/tests/evil/page-loading/unload/test.html |
| 21:52 | <Hixie> | browsers |
| 21:52 | <Hixie> | make |
| 21:52 | <Hixie> | no |
| 21:52 | <Hixie> | sense |
| 21:53 | <Hixie> | (opera and IE don't support pagehide so ignore them) |
| 21:53 | <Hixie> | (moving test to 001.html) |
| 21:55 | <Hixie> | it doesn't help my sanity that chrome thinks the page is written in afrikaans |
| 21:58 | <annevk> | I would point you at the channel topic, but I believe you coined that phrase |
| 22:00 | <Hixie> | i'm not even asking for logic |
| 22:00 | <Hixie> | just, like, consistency, would be a start |
| 22:00 | <Hixie> | something that i can spec |
| 22:04 | <annevk> | "Please take into account that the web is crazy, thanks!" |
| 22:04 | <Hixie> | i found the following comment in the spec, and now i want to bash my head against the table: |
| 22:05 | <Hixie> | <!-- an interesting thing to test would be to traverse back |
| 22:05 | <Hixie> | during onload, before the first pageshow has fired, and then to |
| 22:05 | <Hixie> | traverse forward again, and see if we get _two_ pageshows. If |
| 22:05 | <Hixie> | so, it indicates that the history traversal task source has a |
| 22:05 | <Hixie> | higher priority than the DOM manipulation task source. --> |
| 22:05 | <annevk> | learned today (again, I forgot) that IDNA is not interoperable and that the IETF is apparently quite happy to break backwards compatibility |
| 22:06 | <annevk> | heh |
| 22:06 | <annevk> | man, whenever you get close to the UI, there's trouble |
| 22:06 | <Hixie> | also whenever you get close to the network |
| 22:07 | <Hixie> | and since the network and UI are separated by about 5mm these days, we're just screwed |
| 22:07 | <annevk> | heh |
| 22:07 | <annevk> | nn |
| 22:07 | <Hixie> | nn |
| 22:27 | Hixie | was jumping through the spec looking at mentions of 'unload' and came across a section that talks about loading and unloading body parts |
| 22:27 | <Hixie> | that was briefly confusing before i read the context |
