| 00:06 | <smaug____> | Hmm, "Fetching the image must delay the load event of the element's node document" |
| 00:06 | <smaug____> | is that right |
| 00:07 | <smaug____> | should it delay load event only in case img element is in the document |
| 00:07 | <smaug____> | Hixie: ^ |
| 00:07 | <smaug____> | at least the code in Gecko hints that, but haven't tested yet |
| 00:11 | <smaug____> | or no |
| 00:11 | <smaug____> | apparently img is loaded first |
| 00:15 | <JonathanNeal> | smaug____: that’s a weird onload event, you didn’t put it on the actual iframe content, you put it on the node. |
| 00:15 | <smaug____> | JonathanNeal: nothing weird with that load event |
| 00:16 | <smaug____> | that is where is should be when you want to know if something has been loaded to the iframe element |
| 00:16 | <JonathanNeal> | so, if the element has content ready, why would it not display? |
| 00:16 | <smaug____> | what content ready? |
| 00:16 | <JonathanNeal> | hello world |
| 00:17 | <smaug____> | the issue is that accessing contentWindow.document creates an about:blank document |
| 00:17 | <JonathanNeal> | in other words, the iframe has content, and depending upon when you add it depends on whether or not you can see it? |
| 00:17 | <JonathanNeal> | that doesn’t make any sense, and is not consistent with any other browsing experience on any platform. |
| 00:17 | <smaug____> | but simultaneously appending the iframe to document has started a task to load a new about:blank |
| 00:17 | <smaug____> | since no src means about:blank |
| 00:18 | <smaug____> | JonathanNeal: the issue is very similar to window.open() behavior |
| 00:18 | <smaug____> | as I said earlier, I don't recall what the spec says about this |
| 00:19 | <smaug____> | JonathanNeal: See https://twitter.com/hsivonen 's summary ;) |
| 00:20 | <JonathanNeal> | Is iframe.src supposed to report “” as the src when it does what you say? |
| 00:20 | <smaug____> | don't recall what it is supposed to "report" |
| 00:20 | <smaug____> | but no src is supposed to load an about:blank document |
| 00:21 | <smaug____> | but I don't know what the spec says in case there is already that initial about:blank |
| 00:21 | <JonathanNeal> | Well, do you think my expectations are misaligned with how things should work, or are you telling me what the bug is or both? |
| 00:22 | <smaug____> | "When an iframe element is inserted into a document that has a browsing context, the user agent must create a nested browsing context, and then process the iframe attributes for the "first time"." |
| 00:22 | <smaug____> | I'm not saying this isn't a Gecko bug |
| 00:22 | <smaug____> | I'm just explaining what happens |
| 00:23 | <smaug____> | per spec the second about:blank shouldn't be there |
| 00:24 | <smaug____> | JonathanNeal: hsivonen will probably mark your bug to be a dup of some old Gecko bug |
| 00:24 | <JonathanNeal> | smaug____: interestingly enough, i don’t think the example you provided works in any browser except Firefox. |
| 00:25 | <smaug____> | hmm, it doesn't in chromium |
| 00:25 | <smaug____> | that is a chromium bug then |
| 00:25 | <JonathanNeal> | Considering what you said, it’s even more wild! http://jsfiddle.net/nft8puq5/2/ |
| 00:26 | <smaug____> | ( different bug than what we have been discussing ) |
| 00:26 | <JonathanNeal> | Look, addEventListener firing on the iframe that is not there. |
| 00:26 | <JonathanNeal> | I guess it’s just weird that the iframe’s document refreshes, is all. that does not make sense, that it would load one document and then another. |
| 00:27 | <smaug____> | the spec explicitly says "A load event is also fired at the iframe element when it is created if no other data is loaded in it." |
| 00:28 | <smaug____> | JonathanNeal: yeah, that is a Gecko bug, and load event firing incorrectly is a blink bug |
| 00:28 | <JonathanNeal> | smaug____: "if no other data is loaded” not sure what that means, but if i give the iframe data, it definitely ignores it, and also fires the load event. |
| 00:28 | <JonathanNeal> | Thanks so much for finding it in the spec though. |
| 00:54 | <smaug____> | JonathanNeal: how did you manage to paste a link to a 2012 version of html5 spec ;) |
| 00:54 | <smaug____> | we're certainly not trying to implement that one |
| 00:54 | <JonathanNeal> | Google. |
| 06:05 | <hsivonen> | JonathanNeal: I didn't check in a debugger, but it seems to me that you do the stuff you do on Gecko's docshell-created about:blank. Then the event loop spins and the old HTML parser, which we keep around only in order to remain compatible with our old about:blank behavior, overwrites the docshell-created about:blank with a parser-generated about:blank |
| 06:06 | <hsivonen> | JonathanNeal: so you end up seeing the latter, which blows away everything you did with the first one |
| 06:06 | <hsivonen> | JonathanNeal: yes, this is sad |
| 06:06 | <hsivonen> | JonathanNeal: fixing this requires some serious work |
| 06:06 | <hsivonen> | JonathanNeal: fortunately, some of that work is being done in order to support CSP better |
| 06:07 | <hsivonen> | JonathanNeal: when the CSP stuff is done, maybe I should take another attempt at fixing about:blank |
| 08:01 | <zcorpan> | hsivonen: you need to reopen bugs if you want Hixie to see your comment |
| 08:14 | <zcorpan> | Hixie: what's your time table for fixing developers.whatwg.org? |
| 08:14 | <zcorpan> | Hixie: it's the new TR at this point :-P |
| 08:42 | <Domenic> | oh burrrrrn |
| 08:46 | <odinho> | zcorpan: Makes sense. Web developers obviously can't program to a moving target. :] |
| 08:50 | <MikeSmith> | hsivonen: I'm meeting with Makoto Murata this week to discuss him contributing a mechanism for making the error strings in the HTML5 datatype library localizable. I think he wants it for use in the epub checker. |
| 08:50 | <MikeSmith> | hsivonen: whatever we might happen come up with, I'll make sure to get it to you for discussion before he does any work on implementing it |
| 08:52 | <MikeSmith> | hsivonen: to be clear, right now, right now he's only planning/wanting to contribute something for the error messages emitted from the datatype code |
| 08:54 | <MikeSmith> | hsivonen: though if we're going to OK it, I guess we should try to make sure it's generally applicable to as much of the rest of the error-emitting code elsewhere as possible |
| 09:05 | <jgraham> | odinho: Can they program to a stationary target? |
| 09:12 | <odinho> | jgraham: Or indeed any target? |
| 09:32 | <hsivonen> | MikeSmith: OK. makes sense |
| 11:33 | <annevk> | Anyone here happen to be good with wireless routers? We have a "Technicolor TC7200" from the cable provider. Would buying something new extend the range? |
| 11:35 | <annevk> | I was thinking of maybe getting an AirPort Time Capsule so we can do backups and such too |
| 11:38 | <wilhelm> | annevk: Not really, but I got a few for the new offices. The two tips I got were: 5GHz is your friend. Skip the consumer grade stuff. |
| 11:38 | <wilhelm> | Ended up with Cisco Aironet 2602i. |
| 11:40 | <zcorpan> | annevk: i wouldn't consider myself good but i researched it a bit last time i needed to buy one and ended up with ASUS RT-N66U (i think), which has coverage all over my garden |
| 11:42 | <zcorpan> | (but apparently its NTFS impl is broken so don't plug in an external drive formatted as NFTS to it) |
| 11:47 | <annevk> | wilhelm: I wonder if my Xbox 360 can do 5GHz |
| 11:48 | <annevk> | wilhelm: we also have an iPhone 4 and a Macbook Pro from 2010 or so in the mix |
| 11:48 | <annevk> | zcorpan: garden sounds nice :-) |
| 11:54 | <zcorpan> | annevk: yep |
| 11:54 | <annevk> | we can see a park, but no way I can make wifi work there |
| 11:55 | <annevk> | wilhelm: that shit's expensive |
| 11:55 | <zcorpan> | annevk: you sure? there are 1km range routers |
| 11:56 | <annevk> | ooh |
| 11:57 | <annevk> | "The RT-N66U dual-band wireless router from ASUS brings to the fore super-fast connectivity with up to 450 Mbps per band simultaneously. It works in both 2.4 GHz and 5 GHz, and supports up to a massive 300,000 concurrent data sessions - approximately 20 times the capacity of mainstream routers." |
| 11:57 | <annevk> | that one is a bit cheaper as well |
| 11:58 | <zcorpan> | you can have two 2.4 GHz networks, so i have one guest network that only has internet access |
| 11:59 | <wilhelm> | annevk: Yes. The ones I have are for the office. (c: |
| 11:59 | <annevk> | zcorpan: brilliant |
| 11:59 | <wilhelm> | Still not enough to pass through a few layers of 1928-style reinforced concrete, though. :D |
| 12:06 | <annevk> | wilhelm: we're not all based in the bunkers of Oslo |
| 12:11 | <jgraham> | Well metal in the walls seems like it would be the most effective thing in blocking the signal |
| 12:11 | <jgraham> | Which doesn't just mean thick concrete |
| 12:25 | <annevk> | Hmm, I just found out I could set bandwidth to 40MHz |
| 12:32 | <wilhelm> | jgraham: It's either metal, or something else that bends space-time. This is a functionalist building from the 1920s. Nice place, big windows, just downtown. Zero radio communication between rooms. |
| 12:38 | <annevk> | That seems to have helped boost things up a bit, maybe I don't need new stuff for now |
| 12:41 | <annevk> | hsivonen: nice work on getting those encoding changes landed, hoping they'll stick :-) |
| 12:58 | <annevk> | zcorpan: empty string already has a meaning for languages |
| 12:58 | <zcorpan> | annevk: is the meaning wrong for what we want here? |
| 12:59 | <annevk> | zcorpan: unknown language != user's language |
| 12:59 | <annevk> | zcorpan: although apparently there's no such thing as a tag for the user's language |
| 13:00 | <zcorpan> | annevk: user's language is not known by the author :-) |
| 13:00 | <zcorpan> | annevk: lang="" is equivalent to not specifying lang anywhere, isn't it? |
| 13:01 | <annevk> | zcorpan: from that perspective... |
| 13:02 | <annevk> | zcorpan: seems reasonable, chatting with Richard on Skype, but he's a bit busy |
| 13:27 | <Domenic> | annevk: so i am learning that multipart formdata parsing is not well-specified, but larry is trying to make it so, without much traction? how does this impact fetch and FormData? |
| 13:28 | <annevk> | Domenic: there's https://github.com/masinter/multipart-form-data/ but per https://github.com/masinter/multipart-form-data/issues/17#issuecomment-48077041 it's not clear whether he's interested in defining what we need in the end |
| 13:29 | <annevk> | Domenic: the impact is that multipart/form-data parsing is somewhat muddy and might differ until we clearly define the rules |
| 13:29 | <annevk> | Domenic: not so different from user agents not agreeing on how to implement URLs... that seems a bit more significant if you ask me |
| 13:30 | <Domenic> | right |
| 13:31 | <annevk> | Domenic: I hope someone will pick it up, if nobody does, I guess I will at some point |
| 13:33 | <Domenic> | annevk: does it make sense for you to write the algorithms for converting things into larry's format? |
| 13:34 | <annevk> | Domenic: that sounds like the theoretical let's write a URL spec on top of RFC 3986 approach, which is not very attractive from an engineering standpoint |
| 13:34 | <Domenic> | yeah, i dunno |
| 13:35 | <annevk> | The format is not very complicated. Either Larry makes it work or someone else will. No big deal I think |
| 13:59 | <annevk> | https://twitter.com/llaamm1991/status/516947782478102528 hmm |
| 14:02 | <ondras> | poor child. |
| 14:36 | <Domenic> | wowww http://unicode-inc.blogspot.co.uk/2014/09/updated-unicode-security-specifications.html |
| 14:38 | <annevk> | interesting attacks |
| 14:40 | <annevk> | Firefox is not vulnerable, but Chrome will be if they still have the same strategy (which to be fair, I considered to be a good one at the time) |
| 14:46 | <annevk> | zcorpan: care to fix http://mirrors.creativecommons.org/presskit/buttons/88x31/svg/cc-zero.svg |
| 14:56 | <zcorpan> | annevk: for my specs you mean? |
| 14:56 | <zcorpan> | annevk: is there a https url? |
| 14:58 | <annevk> | zcorpan: I meant turn it into better SVG |
| 14:59 | <annevk> | zcorpan: and then perhaps host it on resources |
| 14:59 | <zcorpan> | annevk: ah ok. sure |
| 15:00 | <zcorpan> | annevk: is the icon itself cc0? :-) |
| 15:00 | <annevk> | zcorpan: hmm, actually, per https://creativecommons.org/about/downloads it might not be |
| 15:01 | <annevk> | zcorpan: I might just stop using the icon |
| 15:03 | <zcorpan> | no icon wfm |
| 15:57 | <Domenic> | TabAtkins: how do i tell bikeshed to prefer EDs |
| 15:58 | <Domenic> | tobie: is there a reason WebIDL doesn't point to the ED for the href, if specref prefers "latest and greatest"? |
| 15:59 | <tobie> | Domenic: README predates any of the automation we've added since then. |
| 15:59 | <Domenic> | :-/ |
| 16:00 | <tobie> | Domenic: Yeah, but it wasn't using EDs either back then. |
| 16:01 | <tobie> | I actually started a thread on the topic of what it was folks really wanted on specprod@ a while back. |
| 16:01 | <tobie> | Domenic: it wasn't really conclusive. :) |
| 16:01 | <tobie> | Domenic: given that I actually need to solve that problem for me pretty much as we speak, I'm happy to reopen the conversation. |
| 16:02 | <tobie> | Else, I'll just add an EDDraft prop to the returned object and let folks deal with it as they please. |
| 16:04 | <Domenic> | I mean, this is mainly a Bikeshed level concern for me right now |
| 16:06 | <tobie> | Domenic: I understand. The data's currently not exposed on Specref though. |
| 16:06 | <tobie> | So I'm not sure what Bikeshed can do about that. |
| 16:07 | <tobie> | Unless Bikeshed grabs the JSON directly from the repo rather than from the API. |
| 16:09 | <annevk> | Hixie: I want to put the "This version" URL of my specs inside the <hgroup> after the <h1> before the <h2> |
| 16:09 | <annevk> | Hixie: could you adjust the style sheet to make that look a bit better? |
| 16:10 | <Hixie> | what's the value of the "This version" line? |
| 16:10 | <SimonSapin> | When writing a spec: if I have a term with a definition that can be linked to, should every single occurrence of the term be linked? Only the first of the paragraph? Some other criteria? |
| 16:10 | <Hixie> | also, <hgroup> only takes <hx> children, i'm not sure what you mean |
| 16:10 | <Hixie> | do you have a sample of what you want to do? |
| 16:10 | <Hixie> | like in live dom viewer or something |
| 16:11 | <Hixie> | SimonSapin: i've started just linking every case cos it's easier to reason about when making edits |
| 16:14 | <annevk> | Hixie: https://url.spec.whatwg.org/ has an example |
| 16:15 | <Hixie> | well that's non-conforming |
| 16:15 | <Hixie> | i think maybe you want <header> intead of <hgroup>? |
| 16:15 | <annevk> | but then the <h2> is no longer grouped |
| 16:15 | <annevk> | perhaps I should upgrade the link to be a heading? |
| 16:15 | <tobie> | Domenic: http://lists.w3.org/Archives/Public/spec-prod/2014AprJun/0027.html |
| 16:15 | <Hixie> | yeah i wouldn't use <h2> if you went that route |
| 16:15 | <Hixie> | you could make the link a heading |
| 16:15 | <Hixie> | but the real question |
| 16:16 | <Hixie> | is why bother with the url at all |
| 16:16 | <annevk> | it's a bit of a leftover from the old days, but okay |
| 16:16 | <annevk> | let's nuke it and see how people react |
| 16:16 | <Hixie> | i mean look at the html spec |
| 16:17 | <Hixie> | nobody outside of #whatwg while i was editing it has said anything at all about the header of the html spec |
| 16:20 | <Domenic> | annevk: interesting, no editor |
| 16:20 | <annevk> | Domenic: put it in ack |
| 16:20 | <annevk> | Domenic: same with license |
| 16:20 | <annevk> | not sure about license in ack but didn't feel like a whole new chapter either |
| 16:21 | <Domenic> | I did always find "this version" confusing |
| 16:21 | <Domenic> | Getting rid of OWF patent agreement seems bad? |
| 16:22 | <annevk> | Domenic: it redirects to a Google thing |
| 16:22 | <Domenic> | tobie: I like how "latest" is completely false |
| 16:22 | <annevk> | Domenic: I've asked tantek to clarify |
| 16:22 | <Domenic> | annevk: yeah their redirects seem to go the wrong way heh |
| 16:22 | <tobie> | Domenic: sorry? |
| 16:22 | <Domenic> | "latest" != "ed" in specref |
| 16:23 | <tobie> | there is no latest. |
| 16:23 | <annevk> | Domenic: editors are crazy man |
| 16:23 | <annevk> | Domenic: needs vetting by WG on a teleconference before you can call it stable |
| 16:23 | <Domenic> | tobie: ah was referring to the thread you linked above |
| 16:23 | <Hixie> | you typoed "stale" |
| 16:23 | <annevk> | Hixie: gone |
| 16:24 | <tobie> | Domenic: that's a proposal, not implemented yet. |
| 16:24 | <annevk> | Hixie: heh |
| 16:24 | <Domenic> | tobie: ah ok |
| 16:24 | <Hixie> | annevk: see, isn't that cleaner? :-) |
| 16:24 | <Hixie> | annevk: the "this version" link implies that there might be other versions |
| 16:24 | <annevk> | maybe the next thing to do is make the table of contents some thing that comes from the side as you often see on mobile |
| 16:25 | <Hixie> | annevk: imho it's a symptom of the w3c's snapshot issues |
| 16:25 | <tobie> | Domenic: there was some disagreement in the thread about what should be exposed and how. |
| 16:25 | <tantek> | what's the broken URL |
| 16:26 | <annevk> | tantek: http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0 is the link various specs have and the Mozilla wiki recommends |
| 16:26 | <tantek> | yeah that seems like a redirect broke |
| 16:26 | <tobie> | Domenic: I didn't really need it myself until this week, so didn't look into it more. |
| 16:26 | <tantek> | sigh. |
| 16:27 | <tantek> | it should just serve up https://sites.google.com/site/openwebfoundation/legal/the-owf-1-0-agreements/owfa-1-0 |
| 16:27 | <tantek> | but at the same URL as before |
| 16:27 | <annevk> | okay so that URL should remain working |
| 16:27 | <tantek> | yes it should |
| 16:27 | <tantek> | I don't know why it's showing up as a sites.goole.com URL |
| 16:28 | <tantek> | it should just work as is |
| 16:28 | <annevk> | note that all openwebfoundation.org links redirect |
| 16:28 | <tantek> | noted. and that looks like a bug. |
| 16:28 | <annevk> | okay, so I'll restore the OWF link for now hoping it'll get fixed |
| 16:28 | <annevk> | it will be moved to ack |
| 16:28 | <annevk> | no need to have this on top |
| 16:31 | <annevk> | tantek: see https://url.spec.whatwg.org/#acknowledgments |
| 16:31 | <annevk> | tantek: "Per CC0, to the extent possible under law, the editor has waived all copyright and related or neighboring rights to this work. In addition, as of 30 September 2014, the editor has made this specification available under the Open Web Foundation Agreement Version 1.0." is the text I plan on using from now on |
| 16:32 | <annevk> | tantek: the previous iteration had a plain text version of the link as well, but that seems like bullshit |
| 16:32 | <Domenic> | +1 that |
| 16:33 | <Hixie> | doesn't OWFa 1.0 require a new version of the license with each edit? |
| 16:33 | <Hixie> | and a signature, etc? |
| 16:34 | <Hixie> | i don't understand what it means to say "the editor has made this specification available under the Open Web Foundation Agreement Version 1.0." |
| 16:34 | <Hixie> | also, is it you who is granting your patents, or is it mozilla? |
| 16:35 | <annevk> | ask tantek |
| 16:35 | <annevk> | tantek: ^ |
| 16:35 | <tobie> | Domenic: that said, PR welcomed granted it doesn't make all Urls suddenly EDs (as the last thing I want is another of those sterile discussions directly in my inbox). |
| 16:35 | <Hixie> | annevk: you're the one saying it, i'd hope that you would be able to answer those questions too :-) |
| 16:35 | <Domenic> | tobie: I mean, can I PR WebIDL's href to be the ED? |
| 16:36 | <tobie> | Domenic: you could, but it would be overwritten by the nightly automation script. :( |
| 16:36 | <annevk> | Hixie: I think it's just me |
| 16:37 | <Domenic> | tobie: but for one glorious moment, i would be free ;) |
| 16:37 | <Hixie> | annevk: so do you print the agreement with each commit and store the signed contracts each time? |
| 16:37 | <annevk> | I don't |
| 16:38 | <annevk> | if that's required, I might opt to remove it again I guess; Domenic / tantek? |
| 16:38 | <Hixie> | so what do you mean by "the editor has made this specification available under the..."? |
| 16:38 | <Hixie> | i mean, read the license |
| 16:38 | <Hixie> | :-) |
| 16:38 | <Domenic> | annevk: I know very little besides "more open good" :) |
| 16:38 | <annevk> | so much work :/ |
| 16:38 | <Hixie> | see in particular section 8.8 |
| 16:38 | <Hixie> | i don't really understand what OWFa 1.0 adds, if you're already using CC0 |
| 16:39 | <Domenic> | doesn't CC0 not cover patents at all |
| 16:39 | <Hixie> | in fact, I don't understand how you can both use CC0 and OWFa, doesn't OWFa section 2.1 mean nothing at all if CC0 is used? |
| 16:39 | <Hixie> | Domenic: neither does OWFa 1.0, unless Anne owns patents he hasn't told us about |
| 16:40 | <Domenic> | Hixie: I think the idea is to provide assurance that you don't claim any patents without the reader having to know the editor's patent portfolio |
| 16:41 | <tantek> | Hixie, not AFAIK |
| 16:41 | <Hixie> | Domenic: then I think the CG CLA is probably a better mechanism |
| 16:41 | <Hixie> | tantek: not AFAIK what? |
| 16:42 | <Hixie> | Domenic: since, in particular, it doesn't require that you sign a piece of paper with each contribution |
| 16:43 | <tantek> | CLA fails in practice |
| 16:43 | <tantek> | splitting CLA and FSA was a mistake |
| 16:43 | <Hixie> | the OWF licenses have the exact same split |
| 16:43 | <tantek> | so instead, we switched the model where with each version/commit/date you re-agree to the FSA |
| 16:43 | <tantek> | which is what the boilerplate has |
| 16:43 | <tantek> | Hixie, I know, and that's why we ignore the CLA half |
| 16:43 | <tantek> | it's useless |
| 16:44 | <tantek> | Hixie, the language about "editor has made this specification available under the Open Web Foundation Agreement Version 1.0. " is good enough per our legal review. |
| 16:44 | <tantek> | no need to print stuff out and fax things etc. |
| 16:44 | <Hixie> | i don't understand how your lawyers interpret 8.8 or 2.1 |
| 16:44 | <tantek> | IANAL so I'm not worried about it |
| 16:44 | <tantek> | got it reviewed, good enough, moving forward. |
| 16:45 | <Hixie> | i'm not in the slightest bit worried, i just think it's bogus :-) |
| 16:45 | <tantek> | if you have specific legal issues from your lawyers we can have them talk to ours |
| 16:45 | <tantek> | otherwise, I don't care to spend time on micromanaging license contents |
| 16:45 | <Hixie> | i'm pretty sure my lawyers don't care either :-) |
| 16:45 | <tantek> | well then, let's keep moving forward |
| 16:46 | <Hixie> | doesn't stop it from being bogus :-) |
| 16:46 | <tantek> | as you've pointed out, we've got real bugs to fix :) |
| 16:46 | <tantek> | Hixie - IIRC you think all patents are bogus :P |
| 16:46 | <Hixie> | different meaning of the term |
| 16:47 | <Hixie> | anyway. the OWFa stuff imho is pointless. if we want to resign the FSA each time then we should just do that with the CG FSA, which is much more sound. |
| 16:48 | <Hixie> | annevk: any news on https://bugzilla.mozilla.org/show_bug.cgi?id=974341 ? |
| 16:50 | <tantek> | Hixie, the OWFa stuff gives us a patent commitment *independent of W3C* |
| 16:50 | <tantek> | that's why it's useful |
| 16:50 | <tantek> | the CG FSA is purely for "playing nice with W3C" |
| 16:50 | <tantek> | IMO |
| 16:50 | <Hixie> | ? |
| 16:50 | <Hixie> | what's it got to do with the w3c other than that they host it |
| 16:51 | <annevk> | Hixie: no |
| 16:51 | <annevk> | tantek: hmm, no, FSA gives us much more |
| 16:51 | <Hixie> | annevk: should i wontfix the relevant spec bugs, or is this something that's still in the cards? |
| 16:51 | <annevk> | tantek: e.g. for URL we have commitments from Mozilla and Google |
| 16:51 | <Hixie> | and opera |
| 16:51 | <Hixie> | and darobin, now! |
| 16:51 | <annevk> | Hixie: I guess it might still be in the cards |
| 16:52 | <annevk> | Hixie: I pinged the bug |
| 16:52 | <Hixie> | k |
| 16:53 | <annevk> | tantek: so I guess I'm with Hixie that if OWF only says something about me and a potential co-editor, it's worth zilch |
| 16:53 | <tantek> | annevk - the *CG* gives us much more |
| 16:53 | <Hixie> | (it would be mildly clearer if you used the patent-only one, but i don't see how it's worth any more than just "I don't have any patents, by the way.") |
| 16:54 | <tantek> | we could independently try to get other companies to sign OWFa FSA for WHATWG specs |
| 16:54 | <tantek> | *independently* of W3C |
| 16:54 | <Hixie> | who cares if it's independent of the w3c |
| 16:55 | <Hixie> | i'm not against the w3c, i'm against the w3c's actions that harm interoperability. |
| 16:55 | <Hixie> | the CGs and the FSAs don't harm interoperability. They're great. |
| 16:58 | <annevk> | I think Hixie's right |
| 16:59 | <Hixie> | does firefox really still not support type=date inputs? |
| 17:02 | <Hixie> | anyone got iOS handy? does iOS8's Safari do anything useful with the inputs on http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3218 ? |
| 17:02 | <annevk> | Hixie: no :/ |
| 17:03 | <Hixie> | well that explains not supporting that other one! |
| 17:03 | <Hixie> | (make that http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3219 ) |
| 17:03 | <annevk> | looking |
| 17:04 | <Hixie> | or IE, for that matter |
| 17:04 | <annevk> | Hixie: color not, date and time yes |
| 17:04 | <annevk> | Hixie: datetime not, datetime-local yes |
| 17:04 | <Hixie> | is there any room for placeholders on the ones where they do something useful? |
| 17:05 | <annevk> | Hixie: week renders super weird and doesn't seem to work |
| 17:05 | <annevk> | Hixie: month works |
| 17:05 | <annevk> | Hixie: yeah, but none of them renders anything for "hello" |
| 17:05 | <annevk> | Hixie: I have IE10 I think |
| 17:05 | <Hixie> | oh there is? can you send a screen shot? |
| 17:05 | <Hixie> | where would the placeholder go? |
| 17:06 | <annevk> | I was thinking it could be drawn on the select |
| 17:07 | <Hixie> | thanks |
| 17:08 | <annevk> | Hixie: IE10 does none of this |
| 17:08 | <Hixie> | like firefox? |
| 17:08 | <Hixie> | except not even color? |
| 17:08 | <annevk> | Hixie: correct |
| 17:08 | <annevk> | Hixie: no color |
| 17:09 | <annevk> | I wonder if I can get IE11 |
| 17:09 | <annevk> | Is IE11 out? |
| 17:09 | <annevk> | I have install updates automatically on... |
| 17:09 | <Hixie> | only on win8, iirc? |
| 17:10 | <annevk> | oh |
| 17:10 | <annevk> | seems I have Windows 7, I guess I should get a license from IT or some such |
| 17:11 | <Hixie> | man, i like how i just have to type "h" in the location bar and the html spec url comes right up |
| 17:12 | <kbrosnan> | i belive date is supported on FxAndroid and/or FxOS |
| 17:12 | <Hixie> | not on android |
| 17:12 | <Hixie> | at least, not with the build i have |
| 17:12 | <Hixie> | (android firefox is my default browser on my phone) |
| 17:13 | <kbrosnan> | have it on nightly, let me look |
| 17:13 | <Hixie> | pretty sure i do too |
| 17:13 | <kbrosnan> | er mean input date |
| 17:14 | <Hixie> | not sure how to force an update |
| 17:14 | <Hixie> | i silenced the update notifications at some point since it was driving me crazy |
| 17:14 | <kbrosnan> | data:text/html,<input type="date"> |
| 17:14 | <Hixie> | aha, found the update button |
| 17:14 | <kbrosnan> | functions for me on all branches, 32-35 |
| 17:16 | <Hixie> | not for me... |
| 17:16 | <Hixie> | 35.0a1 |
| 17:16 | <Hixie> | i just get a text field |
| 17:16 | <Hixie> | is there some flag i should flip? |
| 17:21 | <kbrosnan> | http://i5.minus.com/ib0qSl1EYrWS5w.png |
| 17:23 | <kbrosnan> | it is live on release |
| 17:23 | <Hixie> | wait, you can tap that text field and a UI comes up?! |
| 17:24 | <Hixie> | wow, that's terrible! |
| 17:24 | <Hixie> | i would never have guessed that |
| 17:25 | <kbrosnan> | unless you autofocus the field |
| 17:25 | <kbrosnan> | https://bugzilla.mozilla.org/show_bug.cgi?id=769352 |
| 17:26 | <Hixie> | i mean they should at least look like the dropdowns iOS Safari uses... |
| 17:26 | <annevk> | All specs have been updated |
| 17:26 | <annevk> | This version is gone |
| 17:27 | <Hixie> | :-) |
| 17:27 | <annevk> | (Also OWF, until there's a better argument) |
| 17:27 | <kbrosnan> | hm autofocus does not trigger it |
| 17:40 | <Hixie> | Domenic: if i have a promise A |
| 17:40 | <Hixie> | and a promise C |
| 17:40 | <Hixie> | Domenic: and I say var B = A.then(function () { return C; }) |
| 17:40 | <Hixie> | Domenic: what is B? |
| 17:41 | <annevk> | Hixie: a new promise |
| 17:42 | <Hixie> | which is resolved when? when C is resolved? and its value is C's value? |
| 17:43 | <annevk> | Hixie: yes |
| 17:43 | <Hixie> | k, thanks |
| 17:48 | <annevk> | maybe tomorrow I'll run some experiments with a table of contents from this century |
| 17:48 | <annevk> | seems annoying you still have to scroll to see actual content |
| 17:48 | <annevk> | TabAtkins: my changes might have made it harder to migrate to Bikeshed I guess |
| 17:48 | <annevk> | TabAtkins: still interested in that though |
| 19:48 | zcorpan | notices quirks has mixed content |
| 19:57 | <zcorpan> | annevk: don't you think some people may want to email the editor and expect to find that at the top, not in acks? |
| 20:06 | <Hixie> | i haven't found that removing that from the html spec has reduced the amount of feedback i get, fwiw |
| 20:06 | <TabAtkins> | annevk: Kk, I'll mess with it soon. Either tomorrow or Friday. |
| 20:06 | <Hixie> | and it's been removed for a while there |
| 20:13 | <zcorpan> | http://www.w3.org/TR/2014/WD-ttml-imsc1-20140930/#h3_namespaces .... |
| 20:13 | zcorpan | cries |
| 20:16 | <zcorpan> | Hixie: is it intentional that toc.js doesn't run on multipage? |
| 20:42 | <Hixie> | zcorpan: not per se |
| 20:42 | <Hixie> | wait, toc.js? |
| 20:43 | <Hixie> | isn't that dead? |
| 20:43 | <Hixie> | bigger question is why is the shorter toc not being generated at all |
| 20:44 | <zcorpan> | oh the short toc is (supposedly) generated in the toolchain now? |
| 20:44 | <Hixie> | maybe i never actually implemented that... |
| 20:44 | <Hixie> | la la la |
| 20:45 | <zcorpan> | Hixie: toc.js still exists and the source has this: |
| 20:45 | <zcorpan> | if (document.documentElement.className == "big" || document.documentElement.className == "big split index") |
| 20:45 | <zcorpan> | load('toc.js'); |
| 20:45 | <Hixie> | i don't think i set the class right these days either |
| 20:49 | <Hixie> | haha yeah i never implemented SmallTOC |
| 20:49 | <Hixie> | d'oh |
| 21:59 | <annevk> | zcorpan: I hope it will encourage people to file bugs instead |
| 22:00 | <annevk> | zcorpan: we'll see what happens, I don't get that many personal emails about these standards anyway, and mostly they would be better aimed at a public list |
| 22:00 | <zcorpan> | yeah |
| 22:01 | <annevk> | zcorpan: not as bad as https://annevankesteren.nl/2006/03/smil |
| 22:01 | <annevk> | zcorpan: re TTML |
| 22:03 | <zcorpan> | yeah but i would have hoped they didn't repeat the same mistake. /ns/ suggests it's relatively new |
| 22:04 | <annevk> | cue "You must be new here" |
| 22:48 | <SimonSapin> | Domenic, wycats: so, what dherman was talking about is that Servo converts absolute CSS length units like cm and in to px early, in the parser. But we may have to change that, it’s unclear how much CSSOM is expected to preserve the original formatting of stuff |
| 22:56 | <odinho> | Feels a bit weird not saving that metadata at least. |
| 22:56 | <odinho> | Some serializing-deserializing stuff will go bad. Or devtools. |
| 23:26 | <jgraham> | Yeah at this point it's pretty unclear that any statement of the form "Servo has shown that X is possible" is actually true for values of X that might have compat impact |
