| 00:57 | <gsnedders> | Hixie: OMG THAT IS AMAZING. |
| 00:57 | <gsnedders> | Sorry. |
| 00:57 | <gsnedders> | I may be all of the excite now. |
| 01:02 | <Hixie> | shapeways? |
| 01:02 | <Hixie> | shapeways + sketchup = awesome |
| 01:02 | <Hixie> | not exactly cheap, though |
| 01:26 | <cabanier> | Hixie: was my last reply better? |
| 01:28 | <Yuhong> | As I said before, I now consider HTML version numbering even as a buzzword a misnomer. |
| 02:15 | <gsnedders> | Hixie: Yeah |
| 02:16 | <MikeSmith> | Krinkle|detached: yeah i had asked about that mediawiki resourceloader thing |
| 02:17 | <MikeSmith> | which plainly seems like a not-well-considered hack |
| 02:17 | <MikeSmith> | cwilso: lunch? |
| 03:09 | <cwilso> | Mikesmith: Eiji and I are heading down now |
| 03:12 | <MikeSmith> | cwilso: ok |
| 06:59 | <MikeSmith> | did annevk-cloud or somebody already make an idlharness test for the URL spec? |
| 07:01 | <JakeA> | Can anyone think of a high-profile site that uses web fonts on body copy? |
| 07:02 | <JakeA> | Particularly one that doesn't base64-encode the font |
| 07:13 | <JakeA> | (no worries, got one) |
| 07:21 | <zcorpan> | TabAtkins: you can use rawgithub.com |
| 07:21 | <zcorpan> | oh that was mentioned already |
| 07:22 | <heycam> | TabAtkins, can you include |details, summary { display: block; }| in Bikeshed's style sheet so that <details class=why> looks normal in browsers that don't implement details/summary yet? |
| 07:38 | <Ms2ger> | Well, that "early next week" ended up a little later |
| 07:43 | <heycam> | TabAtkins, also, with my current details/summary patches applied, Firefox renders it like this: http://mcc.id.au/temp/details-why.png |
| 07:43 | <heycam> | I think I'm following the UA style sheet rules that are in the HTML spec |
| 07:50 | <Ms2ger> | Hrm |
| 07:50 | <Ms2ger> | Should :first-child apply to the root? |
| 07:52 | <heycam> | not really clear from the spec... |
| 07:52 | <Ms2ger> | Indeed |
| 08:43 | <annevk-cloud> | MikeSmith: dunno |
| 08:55 | <SimonSapin> | MikeSmith: https://dvcs.w3.org/hg/csswg/rev/db9b855680ef gives a 500 error |
| 08:55 | <SimonSapin> | MikeSmith: who has access to fix it? |
| 09:19 | <MikeSmith> | SimonSapin: seems to be working |
| 09:19 | <SimonSapin> | MikeSmith: yeah, it’s back now |
| 09:20 | <MikeSmith> | the machine isn't super reliable |
| 09:21 | <MikeSmith> | the python hg stuff on the server sometimes gets into a weird error stat |
| 09:21 | <MikeSmith> | *state |
| 09:22 | <MikeSmith> | I'll go in and check the logs and restart the server if it seems like there might be more problems |
| 09:23 | <zcorpan> | MikeSmith: can i haz a bugzilla component for FXTF Geometry spec plz? |
| 09:24 | <MikeSmith> | zcorpan: ah yeah saw that in scrollback |
| 09:24 | <MikeSmith> | oh man |
| 09:24 | <MikeSmith> | cgid daemon process died, restarting |
| 09:24 | <MikeSmith> | Cannot allocate memory: fork: Unable to fork new process |
| 09:25 | <zcorpan> | MikeSmith: k :-) |
| 09:27 | <MikeSmith> | dvcs.w3.org shut itself down and restarted twice withing the last few hours |
| 09:27 | <MikeSmith> | child process 19748 still did not exit, sending a SIGKILL |
| 09:27 | <MikeSmith> | Resource temporarily unavailable: apr_thread_create: unable to create worker thread |
| 09:27 | <MikeSmith> | never seen that before |
| 09:34 | <MikeSmith> | I restarted the server. If anybody starts getting 500's or whatever from it again lemme know |
| 09:36 | <MikeSmith> | zcorpan: make you the default assignee? |
| 09:37 | <zcorpan> | MikeSmith: sure |
| 09:37 | <MikeSmith> | k |
| 09:39 | <MikeSmith> | zcorpan: ready to use |
| 09:40 | <zcorpan> | MikeSmith: thanks! |
| 09:40 | <MikeSmith> | cheers |
| 09:46 | <hsivonen> | do we require new APIs to use EcmaScriptish lists? do we require new APIs to use Promises/Futures? |
| 09:46 | <hsivonen> | what's the latest thinking on Promises/Futures? |
| 09:46 | <hsivonen> | is there documentation for how to write a new API these days? |
| 09:49 | <MikeSmith> | does anybody remember any discussion of http://www.mediawiki.org/wiki/ResourceLoader/ResourceLoaderDynamicStyles_specification on whatwg@ or anywhere at all? |
| 09:49 | <MikeSmith> | <meta content="" name="ResourceLoaderDynamicStyles"> |
| 09:49 | <hsivonen> | are all new APIs that have callback-ish things now blocked on Promises? |
| 09:49 | <MikeSmith> | "The purpose is to mark the DOM position before which dynamic styles should be added." |
| 09:49 | <MikeSmith> | hsivonen: yes, basically |
| 09:50 | <MikeSmith> | as far as I understand it |
| 09:50 | <hsivonen> | so there's this API. and the last time I reviewed it, I said it should use callbacks instead of synchronous operations. so the WG changed it to callbacks |
| 09:50 | <MikeSmith> | hsivonen: as far as how-to-write-a-new-API docs, I think there is something around |
| 09:51 | MikeSmith | looks |
| 09:51 | <hsivonen> | if I now say that it's no good, because it should use promises, it'll sound like "fetch me another rock" |
| 09:51 | <Ms2ger> | hsivonen, alternatively, make annevk tell them to use promises :) |
| 09:51 | <darobin> | there's a lot of talk about a how-to-write-an-API doc, but there's nothing good around |
| 09:51 | <darobin> | I made a braindump a long time ago but it's neither complete, nor good, nor up to speed with today |
| 09:52 | <darobin> | about once a month someone asks if they can use it as a starting point to do something better, I say yes, and nothing happens |
| 09:52 | <darobin> | that said, isn't there something in the whatwg wiki about using promises? |
| 09:53 | <darobin> | hsivonen: just blame them for not finishing faster, if they had shipped they'd be allowed to stick to callbacks |
| 09:53 | <darobin> | if they take even longer, it'll be something other than promises |
| 09:54 | <MikeSmith> | I thought there were notes somewhere at least |
| 09:56 | <MikeSmith> | darobin: I guess I was remembering http://darobin.github.io/api-design-cookbook/ |
| 09:56 | <darobin> | MikeSmith: yeah, that's the one I said was bad |
| 09:56 | <MikeSmith> | oh |
| 09:56 | <darobin> | well, it was initially just a braindump about things that people often did wrong with WebIDL |
| 09:56 | <MikeSmith> | infobot, remove http://darobin.github.io/api-design-cookbook/ from the logs |
| 09:56 | <darobin> | which isn't all that helpful for design |
| 09:56 | <darobin> | heh |
| 09:57 | <darobin> | well, there are probably a few small bits to save |
| 09:57 | <darobin> | but I wouldn't recommend it for anyone |
| 09:57 | <darobin> | anyone can steal the content if they want though |
| 09:57 | <darobin> | (assuming they have the patience to dig for the useful bits) |
| 10:00 | <MikeSmith> | well I canna find anything about Promises nor Futures in wiki.w3.org nor http://www.w3.org/wiki |
| 10:02 | <MikeSmith> | for further depression read http://wiki.whatwg.org/index.php?title=Talk:MetaExtensions&curid=1691&diff=9354&oldid=9302 |
| 10:02 | <MikeSmith> | http://wiki.whatwg.org/wiki/Talk:MetaExtensions#Structured_Data_proposal |
| 10:04 | <MikeSmith> | "authors should know which is the most modern and useful way to provide metadata" = use <meta property=""> with RDFa instead of <meta name=""> |
| 10:04 | <MikeSmith> | nice quote there, though "Ian Hickson has suggested to me that what is more important than whether there are standards that define them, is whether there is any software that consumes them in a useful manner." |
| 10:12 | <wilhelm> | MikeSmith: There are some amusing links from that discussion. Like this: http://members.tripod.com/martin_leese/ |
| 10:14 | <MikeSmith> | wilhelm: wow that's pretty cool |
| 10:14 | <MikeSmith> | guy has a sense of humor at least |
| 10:14 | <wilhelm> | And significant amounts of metadata. |
| 10:15 | <MikeSmith> | yeah |
| 10:15 | <MikeSmith> | "Taught myself the PostScript computer language" |
| 10:15 | <MikeSmith> | I think that's the part that did the permanent damage |
| 10:15 | <MikeSmith> | the red book |
| 10:16 | <MikeSmith> | turns out it's actually a cookbook, for cooking your brain |
| 10:17 | <MikeSmith> | hsivonen: so I been trying to find one good resource on "Why use Promises?" for API design, anywhere, but no luck |
| 10:17 | <MikeSmith> | trying to with Deferreds and other synonyms |
| 10:18 | <MikeSmith> | would be good to have something to point your WG too in your message when you apologize to them for their decision to take your previous advice |
| 10:20 | <Ms2ger> | MikeSmith, I still haven't figured out why you would use promises, so if you find something, let me know |
| 10:21 | <karlcow> | no luck with https://duckduckgo.com/?q=why+promises+extensiblewebmanifesto |
| 10:23 | <karlcow> | https://github.com/slightlyoff/Promises/blob/master/README.md |
| 10:24 | <MikeSmith> | Domenic's slides have too many slides |
| 10:25 | <MikeSmith> | Ms2ger: lacking Domenic_ right now I'm trying to find some Domenic_ words |
| 10:26 | <MikeSmith> | http://www.slideshare.net/domenicdenicola/callbacks-promises-and-coroutines-oh-my-the-evolution-of-asynchronicity-in-javascript |
| 10:26 | <MikeSmith> | slide 42 |
| 10:36 | <Ms2ger> | !summon TabAtkins |
| 10:39 | <annevk-cloud> | hsivonen: promises & arrays, yes; also, unlike the organization, ECMAScript was not renamed |
| 10:42 | <SimonSapin> | annevk-cloud: do you think we should really have HTML define an "environment encoding" for CSS, or is it just nice to have? http://dev.w3.org/csswg/css-syntax/#issue-b26a56fd |
| 10:43 | <SimonSapin> | to simplify the current spec of "charset attr on <link>, then encoding of the referring document" http://dev.w3.org/csswg/css-syntax/#input-byte-stream |
| 10:45 | <annevk-cloud> | If you want a well designed system, yes. |
| 10:58 | <Ms2ger> | SimonSapin, also, might want to ask hsivonen about [css-syntax] Cross-origin fallback charset |
| 11:02 | <SimonSapin> | Ms2ger: if it was an issue, wouldn’t it be for script at well? |
| 11:07 | <Ms2ger> | Oh look, my professor has Opera installed |
| 11:07 | <Ms2ger> | But Chrome and Firefox open |
| 11:11 | <annevk> | Opera was closed first? |
| 11:12 | <Ms2ger> | Or maybe IE |
| 11:13 | <annevk> | SimonSapin: security considerations between style sheets and scripts are different |
| 11:13 | <annevk> | Not sure if Ms2ger is missing the joke or trolling |
| 11:14 | <Ms2ger> | Hey, you know me |
| 11:14 | <Ms2ger> | Surely the latter |
| 11:17 | <annevk> | Yeah |
| 11:45 | <hsivonen> | I thought we had the CSS charset stuff figured out a year ago. Has something changed? |
| 11:47 | <annevk> | hsivonen: I wasn't entirely sure if we were decisive about <link charset=""> |
| 11:48 | <annevk> | hsivonen: and currently http://dev.w3.org/csswg/css-syntax/#determine-the-fallback-encoding seems to allow <link charset="utf-16"> |
| 11:50 | <hsivonen> | is that a problem? |
| 11:51 | <annevk> | hsivonen: I forgot details of XSS bugs basically |
| 11:51 | <annevk> | hsivonen: so I don't know |
| 12:11 | <SimonSapin> | hsivonen: is there a reason the rules for encoding of script would not be safe to use for stylesheets? |
| 12:12 | <annevk> | hsivonen: just invalidated https://bugzilla.mozilla.org/show_bug.cgi?id=145828 Seems like that might (part of) the cause of the mess of your recent cleanup? |
| 12:14 | <hsivonen> | SimonSapin: what's the difference except CSS defaults to UTF-8 when there's no referring doc and JS defaults to windows-1252 and JS doesn't have an internal encoding declaration like @charset? |
| 12:15 | <hsivonen> | annevk: whoa. that bug is sad. thanks for invalidating it. |
| 12:30 | <zcorpan> | does <script> fallback encoding need to work cross-origin for compat? |
| 12:41 | <SimonSapin> | hsivonen: I think it’s the same, other than that |
| 12:41 | <SimonSapin> | the question is: should the document’s encoding only be considered in same-origin? |
| 12:46 | <annevk> | Well, first the question is whether that's a security problem |
| 12:53 | <annevk> | SimonSapin: I recommend looking at what Gecko / Chrome do right now |
| 13:17 | <SimonSapin> | great, http://lists.w3.org sends Content-Type: text/html;charset=ISO-8859-1 for HTML attachments |
| 13:18 | <SimonSapin> | which apparently takes precedence over <meta charset=latin2> in my test case |
| 13:18 | <jgraham> | Yes |
| 13:18 | <jgraham> | Don't you love HTTP |
| 13:19 | <Ms2ger> | ... no? |
| 13:20 | <SimonSapin> | http://lists.w3.org/Archives/Public/www-archive/2013Oct/att-0048/css-cross-origin-encoding.html is green when accessed with file:// |
| 13:22 | <annevk> | I tried to summarize the GitHub discussion here: http://wiki.whatwg.org/wiki/GitHub |
| 13:28 | <hsivonen> | SimonSapin: wouldn't making it non-cross-origin break CDNs if there are scripts being loaded from CDNs with the assumption that the charset inherits? |
| 13:29 | <SimonSapin> | hsivonen, annevk: Firefox and Chromium do use the document’s encoding for cross-origin stylesheets: data:text/html;charset=latin2,<link rel=stylesheet href=http://test.csswg.org/suites/css2.1/20110323/html4/support/none.css><span class=&%23258;&%23733;&%23258;&%23164;&%23258;&%23168>Test |
| 13:29 | <hsivonen> | so what's the problem? |
| 13:30 | <SimonSapin> | hsivonen: there is an open issue in the spec that maybe they shouldn’t: http://dev.w3.org/csswg/css-syntax/#issue-ab273e4b |
| 13:31 | <jgraham> | SimonSapin: That seems like the issue can be closed then |
| 13:31 | <annevk> | So generally the problem with overriding at the embedder's point is that you might leak data from the resource. |
| 13:32 | <hsivonen> | I'd rather not change this without a demo of a credible exploit |
| 13:32 | <hsivonen> | if a credible exploit needs HZ, let's get rid of HZ |
| 13:32 | <annevk> | However, a) the resource is required to be text/css in this scenario b) I cannot think of any encoding tricks that would allow more exposure of information using a different decoder |
| 13:33 | <annevk> | a) is not true for <script> which might be why that is somewhat more dangerous although again I have a hard time thinking of something... |
| 13:36 | <hsivonen> | pretty unlikely for non-scripts to compile as scripts |
| 13:38 | <annevk> | I guess the scenario is that you'd have some UTF-16 JSONP stored on an intranet and using this you can read it. |
| 13:38 | <hsivonen> | annevk: UTF-16 doesn't inherit, though |
| 13:38 | <annevk> | The same would apply to the CSS. Although using UTF-16 as a defence mechanism which does not actually work today in practice is rather broken. |
| 13:38 | <hsivonen> | so you'd need charset="" |
| 13:39 | <hsivonen> | yes, you are doing it wrong if you are using UTF-16 for security |
| 13:39 | <SimonSapin> | hsivonen: it does per http://dev.w3.org/csswg/css-syntax/#input-byte-stream |
| 13:39 | <annevk> | hsivonen: CSS says "Otherwise, if the referring style sheet or document has an encoding, use that as the fallback encoding." |
| 13:39 | <SimonSapin> | is that a bug? |
| 13:39 | <annevk> | I think we considered that to be fine |
| 13:39 | <hsivonen> | oh. my memory fails me then |
| 13:40 | <annevk> | <link charset> and charset of the document <link> is in are in control of the same entity |
| 13:40 | <annevk> | so there's no need treating those differently |
| 13:40 | <hsivonen> | what does the no true Scotsman W3C Meme refer to? |
| 13:40 | <annevk> | and in fact that should become an input parameter as one of the issues in css3-syntax suggests |
| 13:40 | <hsivonen> | public-restrictedmedia? |
| 13:41 | <annevk> | hsivonen: given jernoble seems like hober would be able to explain |
| 13:43 | <annevk> | or jernoble who is actually in this channel :) |
| 13:59 | <Domenic_> | hsivonen: promises are finished and have been for a while. Implementations shipped a few weeks ago. |
| 14:03 | <MikeSmith> | that picture of Lord Hakon looks like he's wearing an electric sombrero |
| 14:47 | <MikeSmith> | Domenic_: is Takeshi Yoshino's Streams draft no longer relevant? |
| 14:47 | <MikeSmith> | I mean https://github.com/tyoshino/stream/blob/master/streams.html |
| 14:48 | <MikeSmith> | annevk: ^ |
| 14:48 | <annevk> | Lol, the Notifications API does not actually define activating a notification (firing click) |
| 14:48 | <annevk> | MikeSmith: http://krijnhoetmer.nl/irc-logs/whatwg/20131028#l-440 |
| 15:10 | <MikeSmith> | annevk: thanks |
| 15:11 | <annevk> | marcosc: what is https://github.com/sensorweb ? |
| 15:12 | <annevk> | marcosc: other than maybe a home for the serial API stuff |
| 15:12 | <marcosc> | Web Serial API |
| 15:12 | <marcosc> | more stuff will likely be needed |
| 15:14 | <Ms2ger> | Clearly we need a Web Parallel API instead |
| 15:16 | <annevk> | marcosc: any reason we need yet another org for that? |
| 15:21 | <marcosc> | annevk: it's nice for communities to have their own space. They might want to create a website, and other bits and pieces. Similar to the RICG. |
| 15:21 | <annevk> | because that was so successful? |
| 15:22 | <jgraham> | marcosc: It's not quite clear why it couldn't happen at the WHATWG |
| 15:23 | <marcosc> | oh, the initial work can be done in the CG (on Gh) and then we can hand it over |
| 15:26 | <annevk> | marcosc: dude, that totally failed last time around |
| 15:27 | <marcosc> | really? |
| 15:27 | <Ms2ger> | marcosc, I can't say I've got good experiences with people inventing something in a silo and then expecting others to just swallow it whole |
| 15:27 | <annevk> | Yeah, each time that happens it's just a massive pain |
| 15:27 | <marcosc> | It's not really a silo. It's just an org on GH with a repo. You can just subscribe to it? |
| 15:28 | <Ms2ger> | marcosc, not useful |
| 15:28 | <marcosc> | how's it any different than the WHATWG? |
| 15:29 | <Ms2ger> | People aren't there |
| 15:29 | <annevk> | marcosc: the WHATWG has implementor buy-in, over 2000 people subscribed with an interest in this space, etc. Seems pretty clear what's different. |
| 15:30 | <marcosc> | Do we want people to subscribe to the mailing list too? |
| 15:30 | <marcosc> | that seems a little aweful |
| 15:32 | <marcosc> | Ok, so, I don't mind moving the repo over |
| 15:32 | <marcosc> | I'll just shut it all down |
| 15:32 | <marcosc> | Where the work is done doesn't matter |
| 15:33 | <annevk> | marcosc: so if you want to write a standard, you need to have lots of eyes |
| 15:34 | <annevk> | marcosc: if you want a sandbox, you can have your private silo, but don't expect standardizing it afterwards to be a breeze |
| 15:34 | <marcosc> | Sure... I'm confused. Is this so you are automatically subscribed to the repo on GH? |
| 15:34 | <marcosc> | Is all discussion also supposed to happen on the whatwg list? |
| 15:34 | <annevk> | marcosc: it's not about what I want, it's about what you want |
| 15:35 | <darobin> | <annevk> ... and you probably want to want... what I want |
| 15:35 | <annevk> | marcosc: I would expect the WHATWG list to be kept in the loop, maybe not have all discussion there, but certainly some |
| 15:36 | <marcosc> | sure. But having people subscribe to the WHATWG firehose seems like a nonstarter to me. |
| 15:36 | <marcosc> | But I don't mind having the repo hosted there. |
| 15:37 | <annevk> | marcosc: works fine for Fullscreen and the Notifications API, and a number of other small efforts |
| 15:37 | <annevk> | marcosc: but note that a lot of detailed discussion takes places in bugs too |
| 15:38 | <marcosc> | sure |
| 15:39 | <marcosc> | annevk: should I just call the repo "serial" or "serialapi"? |
| 15:39 | <annevk> | and in fact until the responsive images community took a wrongheaded suggestion by someone who almost never posts on the WHATWG list to go away that was working okay too |
| 15:40 | <annevk> | marcosc: "serial" I guess |
| 15:40 | <marcosc> | annevk, I think the people from the community see it differently |
| 15:41 | <marcosc> | unless by okay you mean getting everyoen upset and pissed off, but which yes... it was working great :) |
| 15:41 | <marcosc> | developer community management is not one of the WHATWG's strong suites, but that's ok |
| 15:42 | marcosc | moves stuff over |
| 15:45 | <Ms2ger> | marcosc, in general, "here's a use case" tends to work better than "here's an API" ;) |
| 15:45 | <marcosc> | sure |
| 15:45 | <annevk> | marcosc: if you think we can be better there, you're most welcome to help out :-) |
| 15:46 | marcosc | trying |
| 15:46 | <marcosc> | Let's see how this serial api thing goes |
| 15:52 | <marcosc> | Ms2ger, annevk, how should we handle new Editors? Should they just be organization owners or should there be a contributor team with pull/push rights? |
| 15:53 | <annevk> | marcosc: if this is going to be a bunch of new people maybe add a group for serial? |
| 15:53 | <marcosc> | yeah, it's going to be a few till we work out who will lead it |
| 15:54 | <annevk> | marcosc: the current list of owners is people we feel we can trust, but if there's a bunch of new unknown individuals I'm not entirely sure I want them to be able to just delete everything |
| 15:54 | <marcosc> | exactly my feeling too... I'll make a new group for them |
| 16:06 | <annevk> | marcosc: want @WHATWG to tweet about it? |
| 16:06 | <marcosc> | sure, but let me finish setting up |
| 16:06 | <darobin> | marcosc: note that there's a common misconception about GH ACLs |
| 16:06 | <darobin> | if you create a group to work on a repo, don't give them admin rights |
| 16:06 | <darobin> | it might look like you're giving them admin rights just to the repo, but it actually gives them admin for the org |
| 16:06 | <darobin> | they just need push & pull for pretty much everything to do with a repo |
| 16:06 | <marcosc> | will ping you in a few mins |
| 16:07 | <annevk> | darobin: whoa |
| 16:07 | <darobin> | annevk: yeah |
| 16:08 | <annevk> | FWIW, anyone in this channel who wants to tweet something should just let us know. @WHATWG is community-owned, but restricted because of spammers. |
| 16:08 | <darobin> | annevk: I found out when jgraham started creating new repos under w3c, which we didn't think he would be able to :) |
| 16:09 | <marcosc> | darobin: I only gave push/pull |
| 16:09 | <marcosc> | was only going to give pull |
| 16:09 | <marcosc> | and only for the serial repo |
| 16:09 | <darobin> | marcosc: if people are going to be working on the repo, just giving them pull isn't much :) |
| 16:10 | <Ms2ger> | darobin, eh, make them explain their reasoning in PRs ;) |
| 16:10 | <marcosc> | exactly |
| 16:10 | <darobin> | Ms2ger: heh, sure, but in that case they might as well have their own forks, no? |
| 16:11 | <marcosc> | nah, that get's even messier |
| 16:20 | <annevk> | I wonder if I should attempt to make an IDL version of ServiceWorker |
| 16:21 | <annevk> | It doesn't really seem like anyone is working on a specification either... |
| 16:21 | <Ms2ger> | Eh, specifications are overrated |
| 16:21 | <Ms2ger> | Rough consensus and shipping code is where it's at |
| 16:24 | <annevk> | Short term, maybe |
| 16:25 | <Ms2ger> | In case it wasn't clear, this was most definitely trolling |
| 16:31 | <Domenic_> | annevk: any idea why Firefox 25 (released today) has global.PromiseResolver but not global.Promise? |
| 16:32 | <annevk> | Domenic_: no, but Nightly.app does not have that problem |
| 16:35 | <Ms2ger> | Bah |
| 16:38 | <Ms2ger> | Domenic_, bz wonders how you noticed |
| 16:54 | <Domenic_> | Ms2ger: I saw "Future renamed to Promise" in the FF 25 for devs release notes, so I opened up my console and typed "Promise" which autocompleted to "PromiseResolver" |
| 16:54 | <Ms2ger> | Domenic_, okay, thanks |
| 16:55 | <Ms2ger> | Should be gone again in Fx26; not much we can do about Fx25 at this point, though |
| 16:55 | <Domenic_> | yeah seems fine it's not useful anyway, nobody will depend on it |
| 17:07 | <annevk> | Okay I filed a bunch of bugs on ServiceWorker instead |
| 17:14 | <Domenic_> | annevk: marcosc: I am going to create a repo for streams work; any interest in hosting it under whatwg/ instead of another domenic/ repo? |
| 17:15 | <annevk> | Domenic_: seems good |
| 17:15 | <annevk> | Domenic_: are you a member? |
| 17:15 | <Domenic_> | annevk: nope |
| 17:15 | <annevk> | Domenic_: are now |
| 17:16 | <marcosc> | Domenic_: sounds awesome |
| 17:17 | <Ms2ger> | annevk, so he gets to vote to throw Hixie out? ;) |
| 17:17 | <annevk> | Ms2ger: lowercase GH member ;p |
| 17:17 | <annevk> | although technically uppercase GH Owner |
| 17:18 | <Domenic_> | thanks <3 |
| 17:23 | <SimonSapin> | Does <link rel=stylesheet> even have a charset attribute? |
| 17:23 | <Hixie> | no |
| 17:24 | <SimonSapin> | oh. That means the whole "Environment encoding" concept I’m adding to CSS Syntax is only needed for XML processing instructions :/ |
| 17:30 | <TabAtkins> | heycam|away: Sure, I can do that (re: stylesheet for details/summary) |
| 17:31 | <TabAtkins> | SimonSapin: We could just ignore XML PIs? |
| 17:31 | <TabAtkins> | Ms2ger: What did you summon me for? |
| 17:31 | <Ms2ger> | TabAtkins, I was wondering if :first-child applied to the root element |
| 17:31 | <Ms2ger> | TabAtkins, and where the spec says that |
| 17:32 | <dglazkov> | good morning, Whatwg! |
| 17:32 | <TabAtkins> | Yes it does. http://dev.w3.org/csswg/selectors/#the-nth-child-pseudo "represents an element that has an+b-1 siblings before it in the document tree." |
| 17:32 | <TabAtkins> | There's no explicit mention of parents, on purpose. |
| 17:32 | <TabAtkins> | We discussed this in the CSSWG a few months ago, and clarified the language accordingly. |
| 17:35 | <MikeSmith> | annevk: is there an open bug for getting rid of xml:base? |
| 17:35 | <MikeSmith> | gecko bug |
| 17:35 | <MikeSmith> | or also blink bug if you know of one |
| 17:35 | <Ms2ger> | TabAtkins, browsers don't seem to agree |
| 17:36 | <TabAtkins> | That's very possible. |
| 17:36 | <MikeSmith> | annevk: nm |
| 17:36 | <MikeSmith> | found https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c5 |
| 17:36 | <TabAtkins> | I think Blink skips the root element, frex. |
| 17:36 | <TabAtkins> | We should fix that. |
| 17:37 | <annevk> | MikeSmith: only Gecko implements xml:base as far as I can tell |
| 17:37 | <TabAtkins> | Skipping elements without a parent complicates lots of other things, like use of :nth-child in a shadow tree (there's no parent element there, just a shadow root) |
| 17:37 | <MikeSmith> | annevk: oh. all the more reason to drop then I guess |
| 17:37 | <annevk> | MikeSmith: yeah, it'll simplify a bunch of things greatly |
| 17:38 | <SimonSapin> | TabAtkins: re :first-child, is that a change from level 3? |
| 17:38 | <MikeSmith> | annevk: plus I see I'm already had Cc'ed myself on that bugg |
| 17:38 | <SimonSapin> | 3 says "and has a parent" explicitly |
| 17:38 | <MikeSmith> | annevk: yeah |
| 17:38 | <SimonSapin> | TabAtkins: re XML PIs, maybe, though they’re kinda in CSSOM http://dev.w3.org/csswg/cssom/#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction |
| 17:38 | <Ms2ger> | SimonSapin, well, the root has a parent, the document... |
| 17:38 | <TabAtkins> | Ms2ger: Not according to the element tree that Selectors sees. |
| 17:39 | <SimonSapin> | Ms2ger: sorry, "and has a parent element" |
| 17:39 | <Ms2ger> | TabAtkins, where's that defined? :) |
| 17:40 | <TabAtkins> | Ms2ger: It's not. Yay! |
| 17:40 | <SimonSapin> | http://www.w3.org/TR/css3-selectors/#nth-child-pseudo says something different from http://dev.w3.org/csswg/selectors-4/#the-nth-child-pseudo |
| 17:40 | <Ms2ger> | TabAtkins, so then I claim the document is in the tree ;) |
| 17:40 | <TabAtkins> | Technically, HTML should define how it produces an element tree, but I'd be fine with Selectors defining this for HTML and XML. |
| 17:40 | <SimonSapin> | Ms2ger: the document is not an element |
| 17:40 | <TabAtkins> | Ms2ger: That means that "*" would select it. ^_^ |
| 17:41 | <Ms2ger> | TabAtkins, sure |
| 17:41 | <Ms2ger> | TabAtkins, sounds like your spec is broken :) |
| 17:43 | <TabAtkins> | Yeah, it does. |
| 17:44 | <annevk> | TabAtkins: given that Selectors needs to know about text nodes and such, it seems much more useful for Selectors to operate on DOM rather than undefined theory |
| 17:45 | <TabAtkins> | Well, Selectors operates on more than just DOM. There's a library that runs selectors over JSON, frex. |
| 17:45 | <annevk> | Requiring your core constituencies to make that mental translation each time rather than requiring the minority to make the translation of DOM to something else seems to place the burden incorrectly. |
| 17:45 | <Ms2ger> | On the Infoset, clearly |
| 17:46 | <TabAtkins> | But the translation from DOM to Selectors element tree is trivial. |
| 17:46 | <Ms2ger> | No it isn't |
| 17:46 | <Ms2ger> | You're cutting off the document |
| 17:46 | <annevk> | If it was trivial someone would have defined it by now... |
| 17:46 | <jernoble> | hsivonen, annevk: I was referring to public-restrictedmedia, but hober claims to have multiple entendres. |
| 17:46 | <annevk> | jernoble: heh |
| 17:48 | <TabAtkins> | annevk: You know as well as I do that trivial things are often the last things to be defined. ^_^ |
| 17:50 | <annevk> | Well, I guess in this case it just seems bad to me to define it this way. |
| 17:50 | <TabAtkins> | Well, you don't want things like the Document to show up in the Selectors tree, because selecting it is meaningless and confusing. |
| 17:51 | <annevk> | And Selectors even talks about DocumentFragment |
| 17:51 | <annevk> | So if you really want to be abstract; you'll need to carefully define that abstract model in as much detail as the DOM is defined now, and then define the mapping |
| 17:51 | <annevk> | And then wonder why the DOM is not your abstract model for implementations that do not care about the DOM... |
| 17:52 | <annevk> | Something being in a tree does not mean it can be selected... |
| 17:52 | <annevk> | E.g. you cannot select a text node, but selectors assume text nodes are around |
| 17:53 | <TabAtkins> | Only insofar as pseudo-classes are concerned, and they're concerned with tons of shit that is very specific to HTML. |
| 17:53 | <annevk> | And e.g. :empty also refers to processing instructions and such... |
| 17:54 | <TabAtkins> | Yes, that's what I just said. Pseudo-classes operate on information outside the element tree, which is host-language-specific. |
| 17:54 | <TabAtkins> | (Usually - some are just structural.) |
| 17:56 | <SimonSapin> | Ms2ger, annevk: this doesn’t change anything for :first-child, the Level 3 spec says "and has a parent *element*" |
| 17:56 | <Ms2ger> | SimonSapin, and apparently selectors4 tries to change that :/ |
| 17:57 | <annevk> | TabAtkins: you can't have both an "abstract model" and then when you talk about your abstract model also talk about another model |
| 17:57 | <annevk> | TabAtkins: that makes no sense |
| 17:58 | <SimonSapin> | this looks like a bug in L4, implementations do as L3 says: data:text/html,<style>:root:first-child{background:green |
| 17:58 | <TabAtkins> | SimonSapin: Nah, intentional. We discussed this a few months ago. |
| 17:58 | <TabAtkins> | We don't want :nth-child to depend on ahving a parent, as it fucks up our ability to target children of document fragments and shadow roots. |
| 17:58 | <SimonSapin> | TabAtkins: I remember the discussion about DocumentFragment. Did we decide to change it for the root element too? |
| 17:59 | <TabAtkins> | It's against impls, but it's a small, likely insignificant change. |
| 17:59 | <SimonSapin> | did implementers agree to do the change? |
| 17:59 | <TabAtkins> | We discussed it on a call, so probably? |
| 17:59 | <TabAtkins> | I don't recall the details now. |
| 17:59 | <SimonSapin> | should L3 be updated? |
| 17:59 | <TabAtkins> | Don't particularly care. ^_^ |
| 17:59 | <annevk> | lol versions |
| 18:00 | <SimonSapin> | I care for Servo. What should I read? |
| 18:00 | <Ms2ger> | Clearly not L4, that has gratuitous changes |
| 18:00 | <TabAtkins> | The latest spec, always. Why is this even a question? |
| 18:00 | <SimonSapin> | annevk +1 |
| 18:00 | <Hixie> | i thought we agree that :nth-child() and :first-child and :only-child would match :root elements like half a decode ago |
| 18:01 | <Hixie> | agreed |
| 18:01 | <Hixie> | decade |
| 18:01 | <Hixie> | typing hard |
| 18:01 | <SimonSapin> | well, we just passed Acid 1 |
| 18:01 | <SimonSapin> | I’m don’t really bother with the newest stuff yet |
| 18:02 | <annevk> | hehe |
| 18:02 | <TabAtkins> | It's fine to look at a reduced feature set, but never look at old specs. |
| 18:03 | <Hixie> | TabAtkins++ |
| 18:03 | <Hixie> | (that's why it's bad to publish versioned specs) |
| 18:03 | <jgraham> | It's hard not to look at old specs when (unril recently) there were things where you were saying "don't look at X L3, CSS2.1 is more correct" |
| 18:04 | <Hixie> | jgraham: there's still css specs that say that (e.g. css3-content) |
| 18:04 | <TabAtkins> | I apologize that some specs are still too shitty to replace 2.1. |
| 18:05 | <Hixie> | we should just be extending 2.1, imho |
| 18:05 | <Hixie> | instead of fragmenting the tech into multiple shards |
| 18:05 | <Hixie> | but i'm not doing the work |
| 18:05 | <Hixie> | so my opinion is worthless here :-) |
| 18:05 | <jgraham> | Anyway, does anyone actually plan to implement selectors-on-JSON? It might be theoretically trivial (although I doubt it is in detail), but unless there are actual consumers it seems utterly absurd to move up the abstraction ladder just to allow it |
| 18:06 | <Hixie> | you wouldn't need to move the abstraction ladder anyway. you can just define a mapping of JSON to elements. |
| 18:06 | <TabAtkins> | jgraham: I mentioned that in reference to a JS library that does it. |
| 18:06 | <jgraham> | If there are actual consumers, given how unimportant they are compared to web browsers, it it merely absurd to do it that way |
| 18:06 | <jgraham> | Rather than making the consumers do the JSON-to_DOM mapping |
| 18:07 | <TabAtkins> | I don't understand what you're complaining about. |
| 18:07 | <Ms2ger> | Your abstraction |
| 18:07 | <jgraham> | Hixie: Sure, but TabAtkins seems to be saying that selectors needs to operate on a more abstract model than the DOM because of non-browser use cases |
| 18:07 | <annevk> | The HTML parser is defined in terms of DOM. Does not actually mean DOM is required or that you cannot parse into a weird JSON structure instead. It just means it uses the dominant most widely understood tree model to describe its behavior. |
| 18:08 | <Hixie> | jgraham: i'd disagree with "needs". you just need a mapping; it might be cleaner to have an abstraction, but it's not necessary. |
| 18:08 | <TabAtkins> | But then using the DOM directly makes Ms2ger confused, as <html> has Document as parent, but Selectors doesn't want to care about that. |
| 18:08 | <Ms2ger> | TabAtkins, on the contrary |
| 18:08 | <TabAtkins> | DOM has a bunch of extra crap that Selectors doesn't need for its general model. Pseudo-classes operate on more information, but that's fine. |
| 18:08 | <Ms2ger> | TabAtkins, then you could just *say* that Document doesn't count |
| 18:08 | <jgraham> | Hixie: Me too. I am just repeating what TabAtkins is asserting |
| 18:09 | <Hixie> | why would it matter if Document counts? |
| 18:09 | <annevk> | The idea of abstraction for Selectors is nice, but given that it still references a ton of DOM concepts while failing to define a bunch of things, I think it should just give up. |
| 18:09 | <annevk> | be given up* |
| 18:09 | <TabAtkins> | Good lord, you can just file a freaking bug that says "hey, define the mapping between DOM and Selectors plz". |
| 18:10 | <TabAtkins> | The mapping was trivial enough that nobody realized it wasn't defined, because we use the same words in the same way in both trees. |
| 18:10 | <annevk> | That's not the bug TabAtkins. The abstraction layer is not even defined. |
| 18:10 | <TabAtkins> | Then file that bug, rather than bitching about how I should just give up. |
| 18:11 | <annevk> | Well I think you should define the thing in terms of the DOM. Which we use throughout all specs. |
| 18:11 | <annevk> | And is a fine abstraction for people that don't want it directly. |
| 18:12 | <Hixie> | so long as the spec defines itself properly, i don't really care what abstraction model it uses, i'm happy to let the editor figure that out |
| 18:12 | <annevk> | And maybe at some point I'll file a bug about that :-) |
| 18:12 | <Hixie> | and "this css spec is vague" seems like a bug that editors should just assume applies to all css specs they edit :-P |
| 18:12 | <TabAtkins> | What I'm going to do is define the mapping, because the abstraction is simple, and the mapping is trivial. Then I don't have to chase DOM to exclude or modify things that Selectors doesn't want to care about. |
| 18:12 | <fantasai> | You're excluding everything except Elements |
| 18:13 | <fantasai> | I don't think that requires tracking anything |
| 18:13 | <annevk> | Not for :empty you're not fantasai |
| 18:13 | <annevk> | Or for matching in a DocumentFragment... |
| 18:13 | <annevk> | Anyway... day is over |
| 18:14 | <Hixie> | also attributes |
| 18:14 | <SimonSapin> | Hixie: This should probably be added to the HTML spec: http://dev.w3.org/csswg/css-syntax/#environment-encoding-html |
| 18:15 | <Hixie> | SimonSapin: can you post about this on https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 ? thanks |
| 18:15 | <fantasai> | annevk: ok, elements and text |
| 18:15 | <SimonSapin> | will do |
| 18:16 | <Hixie> | fantasai: well, you have to define one way or the other what the implications of comments and PIs are. and namespaces. and attributes. and namespaced attributes. |
| 18:16 | <Hixie> | and CDATA blocks, if you map to XML without mapping to DOM |
| 18:17 | <Hixie> | and DocumentFragments if you want to have :nth-* work on their children |
| 18:17 | <Hixie> | and Document if you want :root to not match :root ~ :root on a DocFrag |
| 18:18 | <Hixie> | also DOCTYPEs if you want to make sure * + :first-child is clearly defined for HTML's root element |
| 18:19 | <Hixie> | the point is just that it needs to be defined, i think |
| 18:22 | <SimonSapin> | <link charset=…> is in http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#obsolete , what does that mean for implementations? |
| 18:22 | <Hixie> | it doesn't do anything with respect to parsing style sheets |
| 18:23 | <Hixie> | the only impact is on the .charset IDL attribute on HTMLLinkElement, which just reflects it |
| 18:23 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#dom-link-charset |
| 18:28 | <SimonSapin> | Hixie: it does in Gecko |
| 18:28 | <SimonSapin> | Hixie: it does in Gecko, BLin |
| 18:29 | <SimonSapin> | Gecko, Blink, and Presto: data:text/html,<link%20charset=latin2%20rel=stylesheet%20href=http://test.csswg.org/suites/css2.1/20110323/html4/support/none.css><span%20class=&%23258;&%23733;&%23258;&%23164;&%23258;&%23168>Test |
| 18:29 | <Hixie> | huh |
| 18:29 | <Hixie> | well, we should either fix the spec or fix the implementations |
| 18:30 | <Hixie> | wait |
| 18:30 | <Hixie> | how are you determining that it has an effect? |
| 18:30 | <Hixie> | i get the same results regardless of the attribute's value |
| 18:31 | <SimonSapin> | I get green with charset=latin2, red without or with another value |
| 18:31 | <Hixie> | hm, i have to reload a bunch of times sometimes to get it to change, but ok, yeah, got it to change |
| 18:31 | <SimonSapin> | this is misintepreting a UTF-8 stylesheet as latin2, and the class name has the corresponding mojibake |
| 18:32 | <Hixie> | well, i guess the question is "does anyone use this" |
| 18:32 | <Hixie> | if not, let's drop it |
| 18:32 | Ms2ger | approves of dropping |
| 18:32 | <SimonSapin> | How can we find out? |
| 18:32 | <Ms2ger> | Even more so if some �Mozilla vendor wants to try |
| 18:32 | <Hixie> | (it's probably not a security risk per se in this case, but changing character encodings in this way is dodgy at the best of times) |
| 18:33 | <Hixie> | SimonSapin: well, chrome or mozilla could add instrumentation |
| 18:34 | <SimonSapin> | I’m gonna specify it, and let someone who cares push for dropping it |
| 18:35 | <Ms2ger> | SimonSapin, do add a note, then |
| 18:35 | <SimonSapin> | ok |
| 18:40 | <Ms2ger> | Wow |
| 18:41 | <Ms2ger> | Calling in DOMParser, XMLHttpRequest, XMLSerializer and RGBColor to support you on naming? |
| 18:45 | <jgraham> | ? |
| 18:46 | <Ms2ger> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0361.html |
| 18:46 | <jgraham> | (XMLHttpRequest has bizarro naming, and not just because it isn't related to XML) |
| 18:46 | <jgraham> | (Surely it should be XmlHttp or XMLHTTP |
| 18:46 | <jgraham> | ) |
| 18:52 | <SimonSapin> | oh, re :first-child, css3-selectors has an errata: http://www.w3.org/Style/2011/REC-css3-selectors-20110929-errata.html |
| 18:57 | <gsnedders> | Yay errata! |
| 18:57 | <Hixie> | could have sworn we agreed to that years ago |
| 18:57 | <Hixie> | like, ~2005 |
| 19:52 | <marcosc> | Hixie: do you want me to do anything with the navigator.languages proposal I have up on GH? |
| 19:54 | <marcosc> | People at Mozilla are asking what happens next with that. |
| 20:00 | <Hixie> | marcosc: is there another browser vendor interested in implementing it? |
| 20:00 | <marcosc> | Well, there was that person from the Chrome team |
| 20:01 | <Hixie> | marcosc: oh that's right. cool. then no, it should just get added in due course. |
| 20:01 | <Hixie> | marcosc: iirc it was sound |
| 20:01 | <marcosc> | Ok, cool. |
| 20:02 | <Hixie> | sorry right now i'm in the middle of this gnarly refactoring of how scripts and ports and workers and event loops work |
| 20:02 | <Hixie> | so that it's not quite as insane as it is in the spec today |
| 20:02 | <Hixie> | trying to define everything in terms of a "script settings object" for each global object |
| 20:02 | <Hixie> | rather than each script having its own referrer source, etc |
| 20:22 | <marcosc> | sounds fun :) |
| 20:22 | <Hixie> | ugh |
| 20:22 | <Hixie> | that's not the word i would use |
| 20:23 | <marcosc> | heh |
| 20:27 | <Hixie> | the worst part of spec writing is that there's no real way to compile and test the resulting program |
| 20:27 | <Ms2ger> | Well, you make us implement it... ;) |
| 20:28 | <Hixie> | "make" |
| 20:28 | <Ms2ger> | You implement it for us in Servo... |
| 20:29 | <Hixie> | my other compilers don't turn around and tell me that actually, they prefer this kind of API design, and also, this file needs this or that feature, and would i therefore code that up, kthxbye |
| 20:29 | <Hixie> | :-P |
| 20:30 | <Hixie> | on the plus side, while much slower than regular compilers, my compiler for the spec _does_ tend to be better about catching bugs |
| 20:30 | <Ms2ger> | bz? |
| 20:30 | <Hixie> | e.g. |
| 23:05 | <Hixie> | can anyone think of a situation where there's a Window object that's not a global scope that some script could in theory execute with, other than when script is disabled? |
| 23:23 | <Hixie> | can anyone think of a way to have a script survive document.open() ? |
