| 09:00 | <AryehGregor> | Does anyone know why this gives null in WebKit? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1844 |
| 09:00 | <AryehGregor> | (accessing iframe.contentDocument from iframe.onload) |
| 09:00 | <AryehGregor> | (with a data URL) |
| 09:00 | <AryehGregor> | Oh, data URLs are treated as different origins, aren't they? |
| 09:00 | <AryehGregor> | Blech. |
| 09:01 | <AryehGregor> | Any way around that? |
| 09:01 | <AryehGregor> | Specifically, any way I could have the iframe call a function of its parent, or vice versa? |
| 09:01 | AryehGregor | glares at WebKit |
| 09:02 | <AryehGregor> | Well, IE doesn't support data URLs in iframes anyway. |
| 09:02 | <AryehGregor> | So I guess I realistically have to use separate pages to test this. |
| 09:02 | <AryehGregor> | Bother. |
| 09:35 | <AryehGregor> | Bah, and now WebKit doesn't support document.contentType! |
| 09:35 | <AryehGregor> | Any way to get at the MIME type of the current document in WebKit? |
| 09:38 | AryehGregor | just skips that check in WebKit for now, it's only a sanity check anyway |
| 12:50 | <hsivonen> | haha. IETF-minded folk shocked at annevk routing around their Stop Energy. Film at 11. |
| 12:52 | <karlcow> | s/IETF-minded/some/ |
| 12:54 | <hsivonen> | https://mobile.twitter.com/stilkov/status/257462943359324160 is almost topic material. Please give up your ambition for logic, consistency and architecture. Thanks. |
| 13:06 | <Ms2ger> | karlcow, aww, you ruined that conversation ;) |
| 13:09 | <karlcow> | Ms2ger: because I'm a peace maker. It's in my nature. :) I do not think making generalization helps in any way. It just put oil on fire. These [w3c|ietf|whatwg] people are $BLAH. |
| 13:09 | <Ms2ger> | I'll just say "These people", then :) |
| 13:11 | <karlcow> | I would say that each of us reacts emotively to many things far far far away from technical issues often. Both Anne and Hixie have sometimes inflammatory languages, but so do Julian etc. |
| 13:11 | <karlcow> | It's individuals more than groups ☺ and Yes I do too and it makes me sad when I do ;) |
| 15:28 | AryehGregor | writes hasFeature() tests |
| 16:40 | <AryehGregor> | Is document.implementation.hasFeature("org.w3c.svg", "1.0") going to return true in any browser? Really? |
| 16:40 | AryehGregor | tests |
| 16:40 | <AryehGregor> | Yes, that's "w3c", not "w3". |
| 16:41 | <AryehGregor> | Yes, it does in all browsers except Gecko. |
| 16:41 | <AryehGregor> | WTF. |
| 16:41 | <AryehGregor> | Seriously? |
| 16:41 | <AryehGregor> | I hope that's at least in some standard. |
| 16:41 | <Ms2ger> | SVG |
| 16:41 | <AryehGregor> | Sigh. |
| 16:43 | <AryehGregor> | *And* document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#BasicStructure";, "1.1")? |
| 16:43 | <AryehGregor> | Please at least don't tell me those are in the *same* standard. |
| 16:44 | <AryehGregor> | That one seems to even return true in Gecko, but I don't see how . . . |
| 16:44 | <AryehGregor> | This is the right code, isn't it? |
| 16:44 | <AryehGregor> | Could we just return true always, maybe? |
| 16:45 | <hsivonen> | hasFeature() { return true; } |
| 16:47 | <AryehGregor> | http://dxr.mozilla.org/mozilla-central/content/base/src/FragmentOrElement.cpp.html#l693 |
| 16:47 | <Ms2ger> | hsivonen, wfm :) |
| 16:47 | <AryehGregor> | I don't see how document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#BasicStructure";, "1.1") returns true. |
| 16:47 | <Ms2ger> | nsSVGFeatures::HasFeature(aObject, aFeature) |
| 16:48 | <AryehGregor> | Of course. |
| 16:48 | AryehGregor | didn't look closely enough |
| 16:58 | <AryehGregor> | Why is isSupported() taken out of the spec but hasFeature() still in it? |
| 18:00 | <annevk42> | AryehGregor: hasFeature is in all browsers and is used somewhat |
| 18:00 | <annevk42> | AryehGregor: if we can make it always return true though, I'm definitely in favor of that |
| 18:01 | <annevk42> | AryehGregor: that sounds a lot better than storing that gigantic silly map of strings |
| 20:08 | <annevk> | so I resolved https://www.w3.org/Bugs/Public/show_bug.cgi?id=19528 but apparently Larry excludes himself from most emails |
| 20:08 | <annevk> | oh well |
| 20:28 | <annevk> | karlcow: "Specs do not suffer, implementers do." is nice |
| 20:30 | <karlcow> | a new clothing line? :p |
| 20:30 | <karlcow> | luckily enough I'm not working for marketing. |
| 20:31 | <annevk> | karlcow: I guess the thing with the stuff I do is that I can only get so far with talking with those people. It's so much easier to just attempt to demonstrate a better approach (and possibly fail) than to convince everyone upfront |
| 20:31 | <annevk> | karlcow: e.g. rewriting the way DOM Events worked it was far easier to just try it out and see where I'd end up than to discuss it for a few months with some people |
| 20:32 | <annevk> | karlcow: and since it's kinda disruptive I guess some class of people gets upset and I don't really like that, but I haven't really found a way around that either |
| 20:33 | <karlcow> | annevk: understood. The *only* issue I have in the dialogs is the way *WE* (aka any sides) have a tendency to frame the discussions and look for disagreement instead of sharing expectations and experimenting. ☺ OTOH, it's also because I'm less implicated that I have the luxury to be able to say that. Life in the end. |
| 20:34 | <annevk> | I guess it's nice to say "we" because it means I'm not alone :-) |
| 20:38 | <annevk> | I've been looking at the disagreement on twitter and one thing that comes up is that because it's from browsers it's not cool (I'm unemployed, but I suppose I fit into that camp somehow), because it's imperative it's broken (this has been discussed many times before), that we should fix the implementations (seems kinda contra-IETF, running code?) |
| 20:41 | <annevk> | And to me these are things I have moved beyond. I know browsers care about the web a lot. A whole lot. I know imperative is way better for implementors and QA and to ensure the specification covers all details (many declarative specifications have holes). And I know running code and web compatibility matters over whatever any kind of standard says. |
| 20:41 | <annevk> | I'm no longer interested in covering all that ground over and over again. |
| 20:42 | <karlcow> | I think some persons would prefer to keep separate the abstract model and its processing. The agreement is not that far in terms of acknowledging the requirements mutual needs. An abstract layer and a processing layer. BUT it takes effort and time to do that because against on both sides on the main interest. |
| 20:43 | <annevk> | There is an abstract model. A URL that consists of various components. There's syntax (not defined yet) and processing (parsing). |
| 20:43 | <karlcow> | annevk: yup, because your main focus is about the applicability of the Web in today's browsers. And that's perfectly fine and valid. The abstract model is also interesting for some other people. It allows different type of discussions and endeavors. |
| 20:43 | <annevk> | And as a bonus there's an API too. |
| 20:43 | <karlcow> | annevk: not the same type of abstract model. |
| 20:44 | <annevk> | Not sure what other abstract model there would be for URLs. |
| 20:44 | <karlcow> | It's the cliché discussion in between French mathematicians and German mathematicians :) |
| 20:44 | <annevk> | And I do not care about today's browsers necessarily. I care about interpreting URLs a hundred years from now in documents produced ten years ago. |
| 20:45 | <karlcow> | ☺ you have a better crystal ball than mine ;) |
| 20:46 | <karlcow> | and more ambition |
| 20:51 | <annevk> | GPHemsley++ |
| 21:14 | <myusuf3> | quick question about html5lib |
| 21:15 | <myusuf3> | any idea when its going to use bs4? |
| 21:39 | <SimonSapin> | myusuf3: what do you mean? |
| 21:48 | <jgraham> | myusuf3: (going to bed now, but...) bs4 can use html5lib iirc. The html5lib support for BS should probably not be used, instead you should use the bs support for html5lib. But I might be wrong |