| 00:01 | <Hixie> | wtf was i doing in r3826 |
| 00:02 | <Hixie> | fixing aryeh's bug apparently |
| 00:02 | <Hixie> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Sep/0356.html |
| 00:03 | <Hixie> | i wonder why i did it like that |
| 00:18 | <Hixie> | well, today's checkins ought to give those of you reading the checkins plenty to worry about |
| 00:18 | <nessy> | ? |
| 00:18 | <nessy> | make me worried! |
| 00:19 | <Hixie> | basically i just made a bunch of invasive changes to the most sensitive algorithms in the spec. |
| 00:20 | <nessy> | hope I don't mingle that up when I apply it to the w3c spec - you do give me plenty of challenges! |
| 00:20 | <Hixie> | heh |
| 00:20 | <Hixie> | actually these should be relatively easy to apply, i think |
| 00:20 | <nessy> | ah goody |
| 00:20 | <Hixie> | it's more whether they're right or wrong that's the problem :-) |
| 00:20 | <Hixie> | testing them in particular |
| 00:20 | <nessy> | hmm... |
| 07:09 | <annevk> | How do you tell whether a browser parsed something as a hostname or IPv4 address? |
| 07:12 | <annevk> | And should we support IPv4 address formats that are outlawed but supported by some browsers? E.g. http://0x12.0x12/ yields 18.0.0.18 |
| 07:12 | <annevk> | Where do I go for answers to these questions? |
| 07:15 | <jgraham> | annevk: You should probablt ask annevk. I hear he is working on this stuff. |
| 07:17 | <othermaciej> | annevk: you would need a hostname that loads as an IP address but fails to load as a hostname on your particular network configuration; or vice versa |
| 07:18 | <annevk> | othermaciej: so the URL stack just passes it to the network stack to let them figure it out? |
| 07:18 | <othermaciej> | annevk: I suspect browsers do not actually care if they parsed something "as a hostname" or "as an IPv4 address", since only the network layer cares, though perhaps in some cases different normalization rules apply |
| 07:18 | <othermaciej> | do you think you need an answer to this question for purposes of URL parsing? |
| 07:19 | <othermaciej> | either way, this piece gets returned in the "host" component when parsing |
| 07:19 | <annevk> | IPv6 has normalization rules. And IPv4 can have normalization rules if you support things such as 0x12 which is not allowed per the IETF RFC yet Chrome and Opera support it. IPv4 is also not allowed to be shortened (e.g. only one dot) per the RFC, but again Chrome and Opera support it and maybe IE too? |
| 07:19 | <othermaciej> | perhaps there is different normalization in some cases, I presume that would be observable |
| 07:20 | <othermaciej> | I think allowing weird IP address formats is a potential security risk |
| 07:20 | <othermaciej> | so probably should not be allowed unless it is required for web compat |
| 07:21 | <annevk> | yeah I read that too somewhere, but not what the risk was |
| 07:22 | <annevk> | http://tools.ietf.org/html/rfc3986#section-7.4 |
| 07:23 | <annevk> | it seems Safari does not handle them, although I have some trouble getting the console to work there |
| 07:24 | <othermaciej> | what trouble are you having specifically? |
| 07:24 | <othermaciej> | I think the risk is: |
| 07:24 | <othermaciej> | - inconsistent parsing between different software components == risk |
| 07:24 | <othermaciej> | - weird formats are more likely to confuse users if displayed to them |
| 07:25 | <othermaciej> | at least those are the risks I can think of |
| 07:26 | <annevk> | I was mostly wondering whether a) to bother with formats such as 0x12.0x12.0x12.0x12 or 18.18 and b) whether I need to make a distinction between IPv4 addresses and domain names |
| 07:27 | <annevk> | I think you answered both, so thanks :) |
| 07:30 | <annevk> | othermaciej: while you're here, do you know anything about WebKit's plans with regards to IDNA2008 / UTS #46 or is that maybe outside the scope of the WebKit project? |
| 07:31 | <othermaciej> | annevk: I think WebKit contains some IDNA parsing code but I don't know the details with our plans on that |
| 07:31 | <othermaciej> | I think we were annoyed that IDNA changed incompatibly |
| 07:32 | <othermaciej> | but I can't remember what our conclusion was; not something I was closely involved in |
| 07:32 | <annevk> | heh, not alone in being annoyed :) |
| 08:02 | <annevk> | https://bugs.webkit.org/show_bug.cgi?id=55315 still unconfirmed |
| 08:03 | <annevk> | (IDNA2008 bug for WebKit) |
| 08:08 | <othermaciej> | UNCONFIRMED doesn't necessarily mean anything |
| 08:11 | <othermaciej> | we do have some internal bugs on IDNA2008 that are not scheduled for any release |
| 08:11 | <othermaciej> | so I expect Safari does not support it and does not necessarily plan to |
| 08:11 | <othermaciej> | the bugs mention some sites that work under IDNA2003 but would break under 2008 |
| 12:53 | <annevk> | Is there any object besides WorkerGlobalScope that implements WorkerUtils? |
| 12:53 | <annevk> | And from WorkerUtils, why is navigator bound to it but importScripts is tied to WorkerGlobalScope (in prose and URL usage) |
| 12:55 | <zcorpan> | to the first question i think the answer is "no" |
| 12:57 | <annevk> | shouldn't it be flattened in then? |
| 13:02 | <zcorpan> | maybe? the interfaces around workers changed (was simplified) a while back, it might be possible to simplify it some more now |
| 13:30 | <alefteris> | Can http://validator.w3.org/nu/ validate HTML5 with the creative commons suggested code snippet (uses RDFa)? |
| 13:31 | <Ms2ger> | Why would you use rdfa? |
| 13:32 | <danbri> | alefteris, do you have a concrete example page to check? |
| 13:32 | <alefteris> | yes, just a minute, thanks |
| 13:33 | <danbri> | I thought http://validator.nu/ used to have an html5+rdfa option, but seems not |
| 13:40 | <alefteris> | danbri, here http://jsfiddle.net/7RZ59/ |
| 13:41 | <alefteris> | danbri, validator Info: Using the schema for HTML5 + SVG 1.1 + MathML 3.0 + RDFa Lite 1.1 + Microdata |
| 13:44 | <danbri> | alefteris, great ... just useful to have a specific example for folk here |
| 13:44 | <danbri> | i'm curious what validator.nu gurus have to say too |
| 13:45 | <danbri> | I don't think you need xmlns:dct="http://purl.org/dc/terms/"; |
| 13:45 | <danbri> | use dc: or dc:terms from http://www.w3.org/2011/rdfa-context/rdfa-1.1 and they're pre-declared |
| 13:45 | <danbri> | cc: also |
| 13:46 | danbri | got to run |
| 13:46 | <alefteris> | I'll try and revice the example, thanks |
| 14:02 | <alefteris> | Revised example: http://jsfiddle.net/7RZ59/2/ Now I just get an error on the cc link. Any idea what I'm doing wrong? |
| 14:02 | <hsivonen> | Validator.nu support RDFa Lite in the sense of not treating it as invalid |
| 14:09 | <jgraham> | Oh look hsivonen is back :) |
| 14:09 | <alefteris> | hsivonen, don't understand RDFa but if that's the case as you say, the validator should ignore xmlns and property attributes? |
| 14:14 | <hsivonen> | alefteris: xmlns is typically an error in text/html. |
| 14:17 | <scor> | alefteris: you should probably use RDFa 1.1 which deprecates xmlns |
| 14:18 | <alefteris> | scor, like this? http://jsfiddle.net/7RZ59/2/ |
| 14:19 | <scor> | alefteris: yes, that works |
| 14:21 | <alefteris> | is there any intro article into rdfa 1.1 from the authors perceptive? |
| 14:21 | <scor> | alefteris: you should probably start here: http://www.w3.org/TR/rdfa-lite/ |
| 14:22 | <alefteris> | thanks |
| 14:43 | <annevk> | hey hsivonen, wb |
| 14:43 | <annevk> | hsivonen: fwiw http://wiki.whatwg.org/wiki/Talk:Main_Page |
| 14:43 | <annevk> | hsivonen: last entry |
| 14:44 | <annevk> | zcorpan: should I file a bug? |
| 14:46 | <zcorpan> | annevk: about workers? |
| 14:46 | <annevk> | zcorpan: y |
| 14:46 | <zcorpan> | annevk: sure |
| 14:47 | <annevk> | done |
| 14:48 | <annevk> | I wonder if we should align URL terminology with the JavaScript API... |
| 14:48 | <annevk> | maybe in due course |
| 15:11 | <annevk> | so |
| 15:11 | <annevk> | http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html#url |
| 15:11 | <annevk> | all that parameter stuff |
| 15:12 | <annevk> | 1) is it implemented? |
| 15:12 | <annevk> | 2) is there no way to do that more elegantly? |
| 15:15 | <annevk> | and do people really care that much about the query part? |
| 15:30 | <darobin> | annevk: yes, I have written code that would rely on stuff like that |
| 15:30 | <darobin> | as for more elegantly, *shrug* |
| 15:31 | <darobin> | you can build something more elegant on top of that, and it will be able to use your own conventions (e.g. for structured fields) |
| 15:35 | <annevk> | what do you mean rely? |
| 15:36 | <annevk> | you mean browsers support that? |
| 15:36 | <darobin> | that *would* rely |
| 15:36 | <annevk> | ah |
| 15:36 | <darobin> | right now I'm pretty sure I'd handroll it |
| 15:36 | <annevk> | wouldn't you just use cool looking paths though? |
| 15:36 | darobin | tries to recall which project he had to parse queries on recently |
| 15:37 | <darobin> | not for everything |
| 15:37 | <darobin> | if you have a *lot* of options, writing routers for cool looking paths becomes painful |
| 15:38 | <annevk> | I suppose |
| 15:38 | <darobin> | so I'd keep the paths to a few fundamentals, and add query params for all the options |
| 15:39 | <annevk> | just wonder if something like url.query["q"] = "test" would not be a whole lot nicer |
| 15:39 | <annevk> | though that's simplified... meh |
| 15:40 | <darobin> | yes, but you can have the same key multiple times |
| 15:40 | <annevk> | darobin: fwiw, we got some people that are pretty unhappy with the "nicer API can be on top approach" |
| 15:40 | <annevk> | darobin: e.g. Alex Russell would prefer the platform to be pretty |
| 15:40 | <darobin> | yeah, there always are :) |
| 15:40 | <darobin> | and with a pretty face like his I can't blame him |
| 15:41 | <annevk> | not sure how realistic that is, but it seems a worthwhile goal |
| 15:41 | <annevk> | heh |
| 15:41 | <darobin> | I have yet to see a pretty API to query strings though, tbh |
| 15:41 | <annevk> | well it's an ordered list of tuples |
| 15:41 | <darobin> | e.g. you could have url.query.param be either a string or an array depending on number |
| 15:41 | <annevk> | with some relationship between tuples that share the first value |
| 15:41 | <darobin> | but that just peppers your code with isArray checks |
| 15:42 | <darobin> | or it could always be an array even if of one element |
| 15:42 | <annevk> | I was thinking always return array but you can set either |
| 15:42 | <darobin> | but let's face it — that just sucks |
| 15:42 | <darobin> | well it's consistent — but it's not pretty :) |
| 15:42 | <annevk> | yeah, basically query sucks |
| 15:43 | <darobin> | well, yeah |
| 15:43 | <annevk> | PHP has some nice hack |
| 15:43 | <annevk> | only "name[]" is exposed as array |
| 15:43 | <darobin> | honestly, the Perl community wrote about 2000 different interfaces to queries — if it were possible to make a nice one it'd exist I think |
| 15:43 | <annevk> | if you use name you just get the first |
| 15:43 | <darobin> | yes, that's what I meant about structured keys, it's not just PHP but a rather common convention |
| 15:44 | <annevk> | that makes some amount of sense |
| 15:44 | <darobin> | but I don't think common enough that you could bake it into the standard |
| 15:44 | <annevk> | well we could actually for the API... |
| 15:44 | <darobin> | mmm, true that |
| 15:44 | <annevk> | if you don't like the API, make another one on top of .search |
| 15:45 | <darobin> | so essentially leave the ugly stuff ugly but provide nice stuff as well — that wfm |
| 15:45 | <darobin> | right |
| 15:46 | <darobin> | systems I've used recognise not just name[] but also name[42], name[something], name[7][9] (IIRC) |
| 15:49 | <GPHemsley> | Are IDs now any string of any characters? |
| 15:49 | <darobin> | not spaces |
| 15:49 | <GPHemsley> | right |
| 15:50 | <GPHemsley> | so, except spaces? |
| 15:50 | <darobin> | use the spec, GPHemsley :) http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-id-attribute |
| 15:51 | <GPHemsley> | I am. |
| 16:03 | <zcorpan> | does appcache not support using cross-origin resources yet? |
| 16:04 | <zcorpan> | or does it? |
| 16:06 | <zcorpan> | context: http://forums.whatwg.org/bb3/viewtopic.php?f=1&t=4357 |
| 16:07 | <annevk> | jgraham: can you edit my comment in https://bugs.opera.com/browse/CORE-48687 to make it sane? |
| 16:08 | <annevk> | jgraham: for some reason BTS fucked up the domain |
| 16:08 | <annevk> | jgraham: and I lost edit rights :/ |
| 16:11 | <odinho> | annevk: Hmm. It's ß in the edit view. |
| 16:11 | <annevk> | well sucks then :) |
| 16:11 | <annevk> | they'll figure it out |
| 16:11 | <odinho> | hehe, trying to html escape it makes it doubly worse. |
| 16:13 | <odinho> | annevk: allows ß in text but not in urls. |
| 16:14 | <annevk> | silly |
| 16:14 | <annevk> | you'd better not mangle user input much if you create bug tracking software |
| 16:32 | <Ms2ger> | "I think there are actually existing problems in Chapter 10" |
| 16:33 | Ms2ger | tries to avoid cynical comments |
| 16:49 | <jgraham> | Ms2ger: Where;s that from? |
| 16:49 | <Ms2ger> | #css |
| 16:55 | <GPHemsley> | annevk: Do all the single-byte encodings share US-ASCII in the first 0x7F code points? |
| 16:56 | <Ms2ger> | All the ones we don't hate do |
| 16:56 | <Ms2ger> | EBCDIC doesn't |
| 16:57 | <annevk> | GPHemsley: http://encoding.spec.whatwg.org says yes |
| 16:57 | <GPHemsley> | oh, a new URL! |
| 16:57 | <annevk> | GPHemsley: yeah, see http://www.whatwg.org/specs/ |
| 16:57 | <annevk> | GPHemsley: I'll blog about it one day |
| 16:57 | <GPHemsley> | heh |
| 16:57 | <Ms2ger> | I guess I should parsing.s.w.o at some point |
| 16:59 | <annevk> | https://github.com/whatwg/url maybe I'll update url.spec.whatwg.org later today |
| 16:59 | <annevk> | but I should probably spec the parser before it's worthy of review |
| 17:00 | <GPHemsley> | Ms2ger: I notice EBCDIC isn't even in that spec |
| 17:00 | <annevk> | Ms2ger: or maybe merge it into DOM? |
| 17:00 | <annevk> | gotta go, back later maybe |
| 18:00 | <annevk> | Hixie: for some reason dfn.js does not work on http://url.spec.whatwg.org/ |
| 18:25 | <annevk> | Hixie: http://www.whatwg.org/specs/ is not ordered in any way? |
| 18:49 | <jgraham> | annevk: Why doesn't specs.whatwg.org resolve? Or is that what you're fixing? |
| 19:10 | <annevk> | jgraham: it's spec.whatwg.org |
| 19:10 | <annevk> | jgraham: is there some easy way we can make specs.whatwg.org and *.specs.whatwg.org work? |
| 19:11 | <jgraham> | Well given sufficient access to the server config, yes |
| 19:12 | <jgraham> | I have no idea what dreamhost allows though |
| 19:12 | <annevk> | there's DNS access |
| 19:13 | <annevk> | if someone can tell Hixie how to make it work via DNS I'm sure it should be no problem |
| 19:14 | <Hixie> | annevk: it's roughly ordered by topic |
| 19:52 | <Hixie> | jgraham: why does this end up at "Document" and not "initial"? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1785 |
| 19:53 | <Hixie> | opera gets to initial, but firefox and chrome don't |
| 19:55 | <Hixie> | wait, that's all kinds of wrong |
| 20:02 | <jgraham> | Hixie: Firefox gets to initial afaict, but it doesn't get a history position |
| 20:03 | <Hixie> | looks like when you hit the "empty" step in the "process iframe src attributes" or whatever it's called, we should do a replacement-enabled navigation to about:blank |
| 20:03 | <Hixie> | rather than nothing |
| 20:03 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=18664 |
| 20:05 | <jgraham> | Is it "with replacement enabled" because it is happening in a load event? |
| 20:06 | <Hixie> | i hope not, but i guess that's possible... |
| 20:07 | <jgraham> | I think it probably is |
| 20:08 | <jgraham> | I think there is a rule like "navigations that are triggered before the document is completely loaded are performed with replacement enabled" |
| 20:08 | <Hixie> | looks like yes |
| 20:08 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1791 |
| 20:08 | <jgraham> | But I am not 100% sure on that ofc |
| 20:09 | <Hixie> | oh you think it's just anything before "completely loaded"? |
| 20:09 | <Hixie> | hmm |
| 20:10 | <Hixie> | step 16 of the form submission algorithm already does that for form submission |
| 20:10 | <Hixie> | interesting |
| 20:10 | <Hixie> | as does the location.href setter! |
| 20:10 | <Hixie> | interesting |
| 20:11 | <Hixie> | i wonder how widespread this should really be |
| 20:11 | <Hixie> | clicking a link while a page is loading clearly shouldn't do it |
| 20:11 | <Hixie> | so it's not a blanket statement |
| 20:11 | <jgraham> | No, user interaction is always magic |
| 20:12 | <jgraham> | Or always non-magic, depending on your point of view :) |
| 20:12 | <Hixie> | i guess heh |
| 20:13 | <Hixie> | ok i've noted what i think should happen in the bug |
| 20:13 | <Hixie> | lunch now |
| 20:14 | <Ms2ger> | krijn, still down? |
| 20:47 | <jgraham> | I am fascinated to see which bits of the spec the W3C think have "interoperability proven by the web". I somehow doubt it will be the same bits I would pick. |
| 20:53 | <othermaciej> | jgraham: if you consider that it's "judgment call" interop rather than interop proven by a thorough test suite, I would say: |
| 20:53 | <othermaciej> | - parsing algorithm |
| 20:54 | <othermaciej> | - most basic elements inherited from html4 that remain conforming (e.g. div, span, i, em) |
| 20:54 | <othermaciej> | - <video> excluding the more advanced features like MediaController and <track> (which are arguably separate features) |
| 20:54 | <othermaciej> | that being said, the plan doesn't include a list, just suggests making one |
| 20:54 | <othermaciej> | and you can and should have input on that list |
| 20:56 | <jgraham> | othermaciej: I would say that the parsing algorithm is one of the few things that does have a testsuite to suggest interoperability :) |
| 20:57 | <othermaciej> | jgraham: true, but I would also say that more tests are not needed, even though one could probably think of more edge cases to test |
| 20:57 | <jgraham> | Right, there are always more cases to test |
| 20:58 | <annevk> | wow, Apple Maps, kinda blows |
| 20:58 | <jgraham> | But it doesn't seem like a case where interoperability is proven by the web |
| 20:59 | <othermaciej> | html5 video (basic stuff at least) seems like a better case of that |
| 20:59 | <othermaciej> | given numerous prominent sites using it and working cross-browser |
| 20:59 | <othermaciej> | and setting aside the regrettable codec issues |
| 20:59 | <jgraham> | But pretty much everything that is "DOM0" and everything to do with navigation and so on is demonstrably non-interoperable |
| 20:59 | <jgraham> | And I doubt that will change in 24 months |
| 20:59 | <annevk> | same for DOM Level 2 HTML stuff |
| 21:01 | <othermaciej> | jgraham: anything that sites manage to use without needing browser-specific code paths would count to me as "judgment call" roughly interoperable, if not thoroughly interoperable in detail; but that is just my opinion |
| 21:01 | <othermaciej> | the point of departure here is how to get to REC in less than a decade |
| 21:01 | <jgraham> | I woukd prefer that we were honest and said "we know these bits of the spec aren't bug free but we are shipping anyway" |
| 21:01 | <othermaciej> | this requires abandoning the "comprehensive test suite for everything" assumption |
| 21:02 | <othermaciej> | to me, "Qualitatively interoperable at at a judgment level, not necessarily for every spec assertion. A test suite may be used as guidance for the qualitative decision." says "we know these bits of the spec aren't bug free but we are shipping anyway" |
| 21:02 | <jgraham> | Well more precisely it requires abandoning the idea that the spec will be correct except for minor bugs |
| 21:03 | <jgraham> | Truly abandoning that would of course mean moving to a process where that was a baked-in truth rather than something to be hushed up |
| 21:03 | <jgraham> | But baby steps... |
| 21:23 | <Hixie> | hahahaha |
| 21:23 | <Hixie> | i just saw the e-mail jgraham is talking about |
| 21:24 | <othermaciej> | jgraham: I see it as taking gradual steps towards a more living-standard-esque model |
| 21:24 | <othermaciej> | while being able to claim it is consistent with at least the letter of the w3c process |
| 21:24 | <othermaciej> | jgraham: comments on list (either on the whole plan thing or the cr exit criteria) would be welcome |
| 21:24 | <Ms2ger> | It won't be consistent with the letter |
| 21:24 | <Hixie> | i'm not aware of any areas that don't have tests that have any sort of serious interop |
| 21:24 | <Ms2ger> | But that doesn't mean you can't claim that |
| 21:25 | <Ms2ger> | After all, that's a long W3C tradition |
| 21:25 | <othermaciej> | the point is not to go for "serious" interop |
| 21:25 | <Hixie> | it's not clear what the point is |
| 21:25 | <Ms2ger> | There is a point? |
| 21:25 | <Hixie> | it's clearly not "get to REC ASAP" |
| 21:25 | <Hixie> | since that could happen right now |
| 21:25 | <Hixie> | it's clearly not "remove bugs from the spec", since you can't do that without testing |
| 21:26 | <Hixie> | it's clearly not "write a spec that people can implement and be confident they are interoperable with other UAs and content", since that would need removing the bugs |
| 21:26 | <Hixie> | as far as i can tell, it's "pretend to follow the process so we can feel good without actually achieving anything truly useful" |
| 21:27 | <Ms2ger> | Sounds about right |
| 21:27 | <othermaciej> | it's "get to REC ASAP subject to the constraint that you could argue it is consistent with the W3C Process" |
| 21:27 | <Ms2ger> | s/feel good/feel good or get paid/, I guess |
| 21:27 | <othermaciej> | fyi the letter of the process on what is required for exit from CR is here: http://www.w3.org/2005/10/Process-20051014/tr.html#cfr |
| 21:28 | <Ms2ger> | "If the Director believes that immediate Advisory Committee review is critical to the success of a technical report, the Director MAY accept to Call for Review of a Proposed Recommendation even without adequate implementation experience;" |
| 21:28 | <Ms2ger> | Just call that |
| 21:28 | <Hixie> | i can argue that it is consistent with the W3C process to get to REC right now |
| 21:29 | <Hixie> | and it would be no less valid an argument than if we do what that e-mail suggests |
| 21:29 | <Ms2ger> | The Director has been clear he doesn't care about interop |
| 21:29 | <othermaciej> | neither the WG nor the W3C Team seem convinced by "REC immediately", though I would personally not have a problem with it relative to the current pan |
| 21:29 | <Ms2ger> | Anyway, I've long given up on the HTMLWG producing anything useful, so do whatever |
| 21:30 | <Hixie> | othermaciej: if the goal is "do whatever it takes to convince the staff that we should go to REC", that's a pretty messed up goal |
| 21:31 | <othermaciej> | Hixie: given that the staff have veto power over transitions, it's hard to see how any other goal is possible |
| 21:31 | <Hixie> | there are tons of other goals possible |
| 21:32 | <Hixie> | e.g. "make a high quality spec that, if implemented, results in a UA that is interoperable with the legacy content on the web and provides new features for new applications" |
| 21:32 | <Hixie> | that's roughly my goal |
| 21:32 | <Hixie> | turns out you can do that without having to convince the w3c staff of anything :-) |
| 21:32 | <Ms2ger> | othermaciej, do you seriously think W3C staff would use their veto power? |
| 21:32 | <othermaciej> | REC has IPR disarmament value |
| 21:33 | <Hixie> | true |
| 21:33 | <othermaciej> | thus, it's useful to get to REC as quickly as possible given organizational constraints, even if also pursuing other goals |
| 21:34 | <othermaciej> | Ms2ger: I have evidence to believe they would |
| 21:34 | <Ms2ger> | Hah |
| 21:35 | <Hixie> | anyway, presumably this won't stop tests for the more critical legacy areas (that we somehow have "proof are interoperable") from being made |
| 21:35 | <Ms2ger> | It'll stop Microsoft from submitting tests |
| 21:35 | <Ms2ger> | Not sure if that's a net loss |
| 21:35 | <othermaciej> | no, this is intended to stop the test suite from gating REC, not stop tests from being created |
| 21:35 | <Hixie> | k |
| 21:35 | <Hixie> | well i don't think the test suite should gate REC, so that's fine. :-) |
| 21:35 | <othermaciej> | test suite work should continue beyond REC, obviously |
| 21:39 | <Hixie> | ok, let me get back to fixing these parts of the spec that we've proved interoperable... |
| 21:39 | <Hixie> | specifically, loading blank URLs into iframes |
| 21:57 | <Hixie> | anyone know what bug this is really for? https://github.com/w3c/html/commit/b55b3ce3bf7dd3deec9129766f5738b2d033ecca |
| 21:57 | <Hixie> | 18224 (as in the bug comment) doesn't seem to have anything to do with it |
| 21:58 | <Hixie> | 18226 maybe |
| 22:01 | <hober> | that commit message makes me go cross-eyed |
| 22:33 | <Hixie> | hober: dunno if you care, but https://www.w3.org/Bugs/Public/show_bug.cgi?id=18226 has an incorrect fix |
| 22:44 | hober | looks |