| 05:32 | <annevk> | MikeSmith: FirefoxNightly |
| 05:45 | <MikeSmith> | annevk: yeah already running Nightly too |
| 06:09 | <mkwst> | MikeSmith: File a bug at https://crbug.com/new and ping me the ID? |
| 07:54 | <Ms2ger> | Remember when Microsoft would never submit feedback unless we'd publish a fork at w3c? https://github.com/whatwg/html/issues/210#issuecomment-144211444 |
| 07:55 | <MikeSmith> | mkwst: seems it's https://code.google.com/p/chromium/issues/detail?id=537360 |
| 07:56 | <MikeSmith> | mkwst: chatted with scottmg about it a bit a few hours earlier |
| 07:57 | <mkwst> | MikeSmith: Does https://code.google.com/p/chromium/issues/detail?id=537437 help? e.g. make sure that chrome://flags/#enable-javascript-harmony is disabled? |
| 07:57 | mkwst | turns #whatwg into a Chrome support channel. |
| 07:59 | <MikeSmith> | heh |
| 07:59 | <MikeSmith> | yeah I |
| 07:59 | <MikeSmith> | I'm posting a comment there now |
| 07:59 | <MikeSmith> | the problem in fact goes away if I disable chrome://flags/#enable-javascript-harmony |
| 08:07 | <mkwst> | Wunderbar! Solved! /me closes the bug |
| 08:10 | <mkwst> | The V8 folks sit right behind me. I'll poke them. |
| 09:03 | <MikeSmith> | mkwst: cheers |
| 10:31 | <Vritika> | Hello!..., I am Vritika Soni. I am interested in Outreach Program(Outreachy). I found Mozilla organization and I would like to work on its project. I am a newbie so I need guidance in this program. |
| 10:34 | <Ms2ger> | Alright, first lesson: stay connected to IRC until someone answers your question |
| 10:36 | <ondras_> | :-) |
| 10:36 | <jgraham> | Or at least until someone *reads* your question |
| 10:50 | <MikeSmith> | mkwst: is much happening with Entry Point Regulation since last year? |
| 10:51 | <MikeSmith> | anybody working on implementing it other than the extension that was developed? |
| 10:51 | <mkwst> | MikeSmith: We published a draft in June (http://www.w3.org/TR/epr/). |
| 10:51 | <mkwst> | MikeSmith: We haven't prioritized it in Chrome, but I know Google's infrastructure security team wants it. |
| 10:52 | <mkwst> | MikeSmith: It will bubble back up in Q1, probably. Last I heard, David was working on a Service Worker-based polyfill. |
| 10:55 | <MikeSmith> | mkwst: OK, thanks |
| 10:55 | <mkwst> | MikeSmith: Why do you ask? :) |
| 10:56 | <MikeSmith> | just showed up on my github radar due to Wendy creating a new repo for it |
| 10:56 | <MikeSmith> | and then when I saw the notification I recalled that I hadn't heard much more about since the time when David introduced it last year or so |
| 11:03 | <mkwst> | MikeSmith: Ah. Right. I'm splitting webappsec into a bajillion repositories. No normative change. :) |
| 11:05 | <MikeSmith> | mkwst: coolーyeah, I support the move to multiple repos 🍻 |
| 11:06 | <MikeSmith> | *decision to move to multiple repos |
| 11:53 | <annevk> | https://www.google.com/#q=spec.whatwg.org Where does Google gets it weird metadata from? |
| 11:53 | <annevk> | "XHR spec" |
| 11:53 | <annevk> | "WhatWG" |
| 11:54 | <annevk> | "WHATWG: Living HTML - HTML Standard" |
| 14:06 | <ondras> | annevk: please, is space allowed in path of <img src="... ..." /> ? |
| 14:07 | <ondras> | (src being http://stuff) |
| 14:07 | <annevk> | ondras: spaces are not allowed in URLs |
| 14:08 | <ondras> | annevk: okay, also řšž are to be percent-encoded even inside a quoted src attribute? |
| 14:08 | <ondras> | (percent-encoded utf-8 bytes, more precisely) |
| 14:10 | <annevk> | ondras: no you can use those |
| 14:10 | <annevk> | ondras: just make sure everything is utf-8 |
| 14:10 | <annevk> | ondras: and expect percent-encoded bytes in JavaScript and on the server |
| 14:12 | <ondras> | annevk: okay, interesting. Firefox apparently silently converts space to %20 when parsing the img src |
| 14:12 | <ondras> | hm, other browsers as well |
| 14:18 | <annevk> | ondras: sure, everyone does that |
| 14:18 | <annevk> | ondras: also mandated by the URL standard :-) |
| 14:18 | <annevk> | ondras: it's just a conformance error since it makes the URL less portable |
| 14:22 | <annevk> | The amount of confusion around SOP is too damn high |
| 14:22 | <annevk> | Latest victim https://twitter.com/aerotwist/status/649214802305417216 |
| 14:22 | <annevk> | Which was reviewed by mkwst and several others of Chrome security no less |
| 14:23 | <mkwst> | Hrm? I think you might have misunderstood hjs point. |
| 14:23 | <mkwst> | He wants to access insecure podcast data from a secure page. He can't. |
| 14:24 | <mkwst> | He wants to access cross-origin podcast data from podcasters who don't serve CORS headers. He can't. |
| 14:24 | <mkwst> | A proxy would allow him to do so, but he outlines some reasons that proxies are a bad idea. |
| 14:25 | <mkwst> | He's bummed that a combination of SOP and MIX (both of which he suggests are good in and of themselves) stop him from building the thing he wants to build without a proxy. *shrug* |
| 14:25 | <Ms2ger> | I don't want him to access my private podcasts |
| 14:25 | <annevk> | mkwst: he also says that a proxy shouldn't have access without CORS |
| 14:25 | <annevk> | mkwst: which is just wrong |
| 14:25 | <annevk> | mkwst: perhaps you didn't read the “How About a Big Proxy?” section? |
| 14:26 | <mkwst> | annevk: If he said that, I missed it when I talked with him. |
| 14:26 | <annevk> | mkwst: I mean I understand this problem |
| 14:26 | <annevk> | mkwst: I wrote about it |
| 14:26 | <annevk> | mkwst: I just don't understand the assertion about proxies and CORS |
| 14:27 | <mkwst> | annevk: Yes. I agree with you that "if the resource is delivered over HTTPS and without the CORS header, the proxy won’t be able to access it on behalf of the client" seems wrong. |
| 14:27 | <mkwst> | annevk: I don't see that as the crux of the article. :) |
| 14:28 | <annevk> | mkwst: I mean the rest of the article was already known |
| 14:28 | <annevk> | mkwst: and this new assertion is false |
| 14:28 | <annevk> | mkwst: hopefully it gets more folks to think about the problem |
| 14:28 | <mkwst> | *shrug* I don't see the new assertion as the important part. :) |
| 14:28 | <annevk> | mkwst: and hopefully he'll clarify that statement |
| 14:34 | <jochen__> | annevk: is there something like a 'loading principal' and 'triggering principal' in spec language? |
| 14:34 | <jochen__> | annevk: apparently these are concepts in firefox |
| 14:41 | <annevk> | jochen__: I think request's client is somewhat close to triggering |
| 14:42 | <annevk> | jochen__: not sure about loading |
| 14:42 | <annevk> | jochen__: I haven't really found a need for them |
| 14:42 | <jochen__> | hum |
| 14:42 | <jochen__> | so I'm asking because the referrer thing |
| 14:42 | <jochen__> | if a document includes a cross origin css file that in turn references an image |
| 14:43 | <jochen__> | both chrome and firefox will use the css file's url as basis for the referrer for the load of the image |
| 14:43 | <annevk> | jochen__: Gecko has some stuff they expose through those just for extensions and privileged code that would be hard to match, but we don't write specs for those |
| 14:43 | <jochen__> | now the question is what kind of term can I use to describe this situation in the referrer spec short of adding an exception for css documents? |
| 14:43 | <annevk> | jochen__: the way that should work is that CSS should get its Fetch act together and define the referrer for their fetches |
| 14:43 | <annevk> | jochen__: when they define the referrer, they can just set it to the URL of the CSS resource if it's an external resource and leave it as "client" when it's inline |
| 14:44 | <annevk> | jochen__: I guess you could add a warning that CSS (and SVG) haven't defined Fetch integration yet |
| 14:44 | <annevk> | jochen__: numerous things are therefore unclear |
| 14:44 | <jochen__> | so the referrer spec always uses the current 'incumbent settings object' as source for the referrer |
| 14:45 | <jochen__> | would that be the svg document once they got this sorted out? |
| 14:45 | <annevk> | jochen__: the referrer spec should use request's client, no? |
| 14:45 | <annevk> | jochen__: for SVG documents, yeah, it'll be the same as HTML documents |
| 14:45 | <annevk> | jochen__: and SVG images cannot fetch external resources so don't matter |
| 14:46 | <jochen__> | ehrm, i meant css |
| 14:46 | <jochen__> | i guess i'll just add an explicit section CSS documents |
| 14:46 | <annevk> | jochen__: for CSS what happens is that CSS sets referrer to a URL |
| 14:47 | <annevk> | jochen__: so you get an explicit URL that you then modify as you see fit |
| 14:47 | <annevk> | jochen__: no settings objects involved |
| 14:51 | <jochen__> | well, somewhere the url has to come from |
| 14:52 | <jochen__> | at least in chrome it comes from the css parser context |
| 14:52 | <jochen__> | which in turn gets it from some document |
| 14:52 | <annevk> | jochen__: I see |
| 14:53 | <annevk> | jochen__: well yes, some document fetches a CSS resource, then feeds that response to CSS along with sufficient other data, CSS then should do the rest, e.g., take the url from the response and use that as base URL and referrer |
| 14:54 | <jochen__> | is there a spec text for that? |
| 14:54 | <annevk> | jochen__: see above where I mentioned that CSS does not really have its act together |
| 14:54 | <jochen__> | well, they don't use fetch |
| 14:54 | <jochen__> | but there should be something that says how to load css images and fonts, no? |
| 14:54 | <annevk> | They don't really use anything, but if you were to take that literally CSS wouldn't use service workers either, etc. |
| 14:55 | <annevk> | CSS of course uses something, and everyone knows it's Fetch, it's just not written down |
| 14:55 | <annevk> | So theoretically a ton of stuff breaks and the theory should really be fixed |
| 14:55 | <annevk> | But in practice everyone has managed to deal |
| 14:56 | <jochen__> | sooo |
| 14:56 | <jochen__> | i'll add some text to the referrer spec that says "css should make sure it uses the referrer policy from whereever it felt like getting the referrer from in the first place" |
| 14:57 | <annevk> | It seems very reasonable to add a warning or even try to explain how it should work |
| 15:24 | <Domenic> | annevk: did you start https://github.com/whatwg/html/issues/210 yet or shall I |
| 15:26 | <parul> | Hello |
| 15:28 | <parul> | i am interested in mozilla "visual design with research data" project.please inform me the irc channel for it. |
| 15:28 | <parul> | so I will start contributing for it. |
| 15:35 | <annevk> | Domenic: I haven't |
| 15:35 | <Domenic> | annevk: k, taking it |
| 15:35 | <annevk> | Domenic: I've been meaning to do some more Fetch stuff, but I keep getting distracted |
| 15:36 | <annevk> | parul: hey, I'm not familiar with that project |
| 15:36 | <Domenic> | annevk: do more URL stuff! |
| 15:36 | <annevk> | parul: do you know who's responsible? |
| 15:37 | <parul> | annevk: no I don't know who is the mentor of this project |
| 15:37 | <annevk> | parul: from the wiki page it seems like you want to ping ilana on irc.mozilla.org |
| 15:38 | <annevk> | parul: assuming you were asking about https://wiki.mozilla.org/Outreachy/2016/December_to_March#Visual_Design_with_Research_Data |
| 15:38 | <parul> | annevk:I get the info of this project from this link https://wiki.mozilla.org/Outreachy/2016/December_to_March |
| 15:39 | <annevk> | parul: yeah, this IRC channel is only for "Contribute to the HTML Standard!" |
| 15:39 | <annevk> | (from those projects, anyway) |
| 15:39 | <parul> | annevk: irc channels,mentors and the mailing list is not mention there. |
| 15:39 | <annevk> | Domenic: yeah, I've blocked on that since the base URL thing is still a bit unclear |
| 15:40 | <annevk> | Domenic: I guess I should update some issue |
| 15:40 | <annevk> | parul: it says "Mentor: Ilana Segall", no? |
| 15:40 | <annevk> | parul: and if you click that name an IRC nickname is suggested, and I can tell that person is active on irc.mozilla.org |
| 15:42 | <parul> | annevk: well fine, sorry my mistake |
| 15:42 | <annevk> | parul: no worries, happy to help |
| 15:43 | <parul> | annevk: okey |
| 15:50 | <annevk> | Domenic: in particular, I was thinking that a base URL change thingie which is needed for :visited would help |
| 15:50 | <annevk> | Domenic: but then I realized it wouldn't do any good for elements not currently in the document |
| 15:50 | <annevk> | Domenic: so I guess we still need to define the base URL updating on the getter thingie... |
| 15:51 | <annevk> | Domenic: but also have this base URL change thing... |
| 15:51 | <Domenic> | annevk: yeah, seems likely... :-/ |
| 15:51 | <annevk> | Domenic: or would it be better to just have the base URL change thing, but somehow iterate over all elements whose node document is the document |
| 15:52 | <Domenic> | annevk: I think doing the lazy thing mostly, and having the base URL change thing be a special thing for CSS, makes a lot of sense. matches implementations, and makes the weird thing special-cased. |
| 15:52 | <annevk> | Domenic: I doubt that matches Gecko |
| 15:52 | <annevk> | Domenic: and it's not a big bone for custom elements either |
| 15:52 | <Domenic> | annevk: really? it seems like the only sane implementation strategy. |
| 15:53 | <annevk> | Domenic: because it's impossible to notify elements not in a document? |
| 15:54 | <Domenic> | annevk: not impossible, but a lot more work to keep track of them all, and slower (although I guess changing base URLs should not happen that often). |
| 15:54 | <Domenic> | annevk: and if everything else is lazy (because get the input wants to happen lazily), it only makes sense to do the same for base |
| 15:55 | <annevk> | Domenic: I guess I'm somewhat convinced with the lazy approach since base URL changes in general are just a really bad idea |
| 15:58 | <annevk> | Domenic: thanks for reminding me and talking through this, needed that |
| 16:01 | <Domenic> | :) |
| 16:42 | <annevk> | HTML has 121 closed PRs already |
| 16:42 | <annevk> | Is that about 4 a day or am I misrepresenting when we started? |
| 16:50 | <zcorpan> | philipj: i think bugzilla bugs should be RESOLVED MOVED when there's a PR |
| 16:59 | <Domenic> | annevk: looks like we started about August 26-27 |
| 16:59 | <Domenic> | so... yeah |
| 17:07 | <zcorpan> | time for a new REC? |
| 18:58 | <wanderview> | cool to see edge bugs referenced in whatwg github issues... if only they were links |
| 19:02 | <Domenic> | baby steps ^_^ |
| 19:03 | <Domenic> | grrr, why didn't i write the streams tests in web-platform-tests format the first time around... |
| 19:04 | <Domenic> | do people know the best pattern for a test that should run the same in both workers and window? |
| 19:05 | <Domenic> | Maybe it is something like this https://github.com/domenic/unhandled-rejections-browser-spec/blob/master/tests/promise-rejection-events.html |
| 19:05 | <gsnedders> | Hah, I remember people questioning why Opera bugs occasionally got referenced, given the lack of access. |
| 19:06 | <gsnedders> | Domenic: that's more or less what i'd suggest |
| 19:06 | <Domenic> | gsnedders: would be sweet if I could avoid generating that .html file manually for each test, somehow. |
| 19:07 | <gsnedders> | Domenic: too quickly gets into magic, IMO |
| 19:08 | <Domenic> | meh, don't really know |
| 19:15 | <Domenic> | gsnedders: so this service_worker_test seems to be a blink-specific thing... any thoughts on how I should test in service workers? |
| 19:16 | <wanderview> | Domenic: I think best worker/window approach is to make a .js file that gets run in both cases... in worker context you make a shim for asserts that proxies back to main thread |
| 19:17 | <wanderview> | not sure that has been done yet for wpt anywhere yet |
| 19:17 | <gsnedders> | Domenic: No. |
| 19:17 | <gsnedders> | Domenic: I know next to nothing about service workers :) |
| 19:18 | <wanderview> | Domenic: service_worker_test() should be in upstream wpt |
| 19:18 | <Domenic> | Ah, I found it, yeah. https://github.com/w3c/web-platform-tests/blob/e5e8fb9ebc4d5b2220abff5679fa0781c01f2c05/service-workers/service-workers/resources/test-helpers.js |
| 19:18 | <wanderview> | yea |
| 19:19 | <wanderview> | Domenic: one complaint we have about a lot of the current wpt tests that involve workers... they tend to be all or nothing... not broken up into separate test cases so we can't mark the one thing we don't implement yet as EXPECTED_FAIL |
| 19:19 | <wanderview> | Domenic: thanks for writing wpt tests, though |
| 19:20 | <Domenic> | wanderview: I plan to write lots of test cases in each file, then use a .html file that runs that file in all four types of workers... |
| 19:20 | <Domenic> | wanderview: will get your review |
| 19:20 | <wanderview> | cool |
| 19:20 | <wanderview> | r+ |
| 19:21 | <annevk> | TabAtkins: the way <input type> defaulting works is extremely common among most (if not all) enumerated attributes |
| 19:21 | <annevk> | TabAtkins: if custom elements would not match that they would be weird |
| 19:22 | <TabAtkins> | annevk: I don't think it's a good idea for custom elements to match, honestly. enum properties work differently, CSS properties work differently, etc. |
| 19:23 | <TabAtkins> | enum attributes are just weird, and matching the platform as we add new ones to HTML is fine, but I would not match that in a custom element. |
| 19:23 | <annevk> | I totally would. Changing the attribute is actually what's completely alien |
| 19:24 | <annevk> | Parsing the attribute and based on that potentially changing the default state is much more logical |
| 19:31 | <zcorpan> | TabAtkins: html (and xml languages too) accept any value for attributes generally |
| 19:32 | <TabAtkins> | There's no way for CSS to expose a *generic* mechanism addressing the issue, tho. At best it can do something host-language specific, so that browsers hide the complexity of the big selector in their selector matching code instead. |
| 19:32 | <TabAtkins> | zcorpan: Sure. But there's nothing requiring the attribute to *stay* the value it's set to, in the presence of JS. |
| 19:34 | <zcorpan> | TabAtkins: maybe so, but JS does not need to be involved for this problem to appear, so it's a bit moot point :-) |
| 19:35 | <TabAtkins> | Right, the problem is that you can't define what set of keywords an enumerated attribute accepts. I'm saying that, in the presence of JS, you can fix that (and imo should for your custom elements). |
| 19:37 | <zcorpan> | :input-type(newtype) would also let you style the control differently only in UAs that support "newtype" |
| 19:38 | <TabAtkins> | Yeah. It's just a specialized "only for <input type>" mechanism. |
| 19:39 | zcorpan | awaits csswg members to Genericalize it so it can apply to Other Host Languages as well |
| 19:45 | <TabAtkins> | Like I just said, we can't. |
| 19:45 | TabAtkins | is unsure at what level of sarcasm zcorpan is operating. |
| 19:46 | <zcorpan> | i can include the end tag for you: </sarcasm> |
| 19:47 | <TabAtkins> | What I meant is that <input type> is not the only enumerated attribute with this behavior, and probably not the only enumerated attribute that wants to have UA-default styles based on itself. |
| 19:48 | <tantek> | The SARCASM Host Language needs no end tag. |
| 19:50 | <gsnedders> | zcorpan: I'm struggle to infer the open tag |
| 19:51 | <zcorpan> | gsnedders: i can write you a DTD if you send me chocolate |
| 19:54 | <gsnedders> | zcorpan: hah, you admit British chocolate is better? ;P |
| 19:54 | <TabAtkins> | zcorpan: And without some form of "generic-ness", then specifying the pseudo-class is just moving the complexity from the UA stylesheet to the UA's selector definition. It doesn't improve the brittleness/verbosity; either way you have a list of values that need to be maintained. |
| 19:55 | <zcorpan> | TabAtkins: <button type>, <menu type>... i think there's not much more in html that makes sense to style differently based on an enum attribute |
| 19:56 | <TabAtkins> | The benefits to authors are that (a) they can then use rando values in their own page and still match them as :input-type(text), which seems low value, and (b) they can use new types and match them with :input-type(new) if they're supported (but if they're not, they'll get caught by :input-type(text), so I'm unsure in practice of the usefulness of that). |
| 19:56 | <zcorpan> | gsnedders: i'll know it when i get it :-) |
| 19:56 | <gsnedders> | zcorpan: :) |
| 19:58 | <zcorpan> | TabAtkins: it seems useful to me to have :input-type(text) match unsupported types. why would you not want to style them as other regular text fields, assuming you don't polyfill them to something else? |
| 19:58 | <TabAtkins> | I dunno! |
| 19:59 | <JonathanNeal> | What’s this? :input(text) selector? |
| 19:59 | <zcorpan> | JonathanNeal: CSS7!! |
| 19:59 | <zcorpan> | <http://www.w3.org/mid/CAAWBYDCzcZ4dpNw3gjWnYrTOqN2UbSCKcYoGG7RSytHju8moqw⊙mgc>; |
| 20:00 | <JonathanNeal> | Neat. |
| 20:01 | <TabAtkins> | zcorpan: (Note that, as I said in the email, I'm not opposed to :input-type(), I just don't currently believe this problem is sufficiently worthwhile to address with new syntax.) |
| 20:01 | <JonathanNeal> | Neat. Like :input(text) => input:not([type]), input[type="text"] ? |
| 20:02 | <TabAtkins> | JonathanNeal: Also input:not([type=password]):not([type=tel])... |
| 20:02 | <TabAtkins> | Because <input type=foo> is a text input. |
| 20:03 | <TabAtkins> | Rather, it's explictly equivalent to `input:not([type]), input[type]:not([type=password])...` |
| 20:06 | <TabAtkins> | As an idle thought, a genericization would probably look like a switch statement... |
| 20:12 | <Domenic> | I am not really opposed to input:not([type=password i]):....... |
| 20:12 | <Domenic> | it's ugly but for UA stylesheets it should be fine |
| 20:12 | <Domenic> | it's not like we're going to add new input types soon |
| 20:15 | <gsnedders> | case insensitive? |
| 20:15 | <Domenic> | yes, <input type="PASSWORD"> is still a password |
| 20:32 | <tobie> | TabAtkins: does Bikeshed have a mechanism to include the content of external resources similar to: https://www.w3.org/respec/ref.html#data-include ? |
| 20:32 | <TabAtkins> | Not currently. |
| 20:32 | <tobie> | How could you even process that information so quickly? |
| 20:32 | <TabAtkins> | ??? |
| 20:33 | <tobie> | !!! |
| 20:34 | tobie | had a long day. |
| 20:34 | <tobie> | Is this somehow planned? |
| 20:34 | <tobie> | Easy/hard given the current architecture? |
| 20:35 | <TabAtkins> | It's not currently in my plans, but I'm not opposed. Feel free to file an issue on me for it. I'd appreciate some pointers to existing usage of this in ReSpec. |
| 20:35 | <tobie> | I'm using it to include code samples of live apps. |
| 20:40 | <TabAtkins> | tobie: Why not include it inline? |
| 20:41 | <JonathanNeal> | Tangent: [type=password i], in today CSS does this work, are attribute selectors even case-sensitive? |
| 20:43 | <tobie> | I have the apps and use case doc in the same repo, like that I don't have any copy-pasting to do. |
| 20:44 | <tobie> | Added the links to https://github.com/tabatkins/bikeshed/issues/496 |
| 20:47 | <robertkowalski> | heya |
| 20:48 | <robertkowalski> | i want to start to work on a spec for console.log and friends |
| 20:48 | <Domenic> | \o/ |
| 20:49 | <robertkowalski> | but before i start i was wondering if i need to use a special kind of test framework / test runner |
| 20:49 | <TabAtkins> | Didn't somebody already start on that? |
| 20:49 | <Domenic> | TabAtkins: yep, and stall |
| 20:49 | <TabAtkins> | Right. Maybe it can be reused rather than starting from scratch. |
| 20:49 | <Domenic> | robertkowalski: web-platform-tests are the best tests: https://github.com/w3c/web-platform-tests |
| 20:50 | <Domenic> | robertkowalski: http://testthewebforward.org/docs/ |
| 20:50 | <robertkowalski> | cool thank you Domenic |
| 20:52 | <tobie> | iirc MikeSmith had a draft of the console API in the Browser Testing and Tools WG |
| 20:53 | <tobie> | It's mentioned in the charter but can't seem to find it online. |
| 20:53 | <TabAtkins> | tobie: That makes sense. |
| 20:53 | <TabAtkins> | (re: using examples in both explainer and spec) |
| 20:53 | <TabAtkins> | File an issue on me? |
| 20:54 | <tobie> | https://github.com/tabatkins/bikeshed/issues/496 |
| 20:54 | <TabAtkins> | danke |
| 20:57 | <MikeSmith> | philipj (or anybody) about the 0.03% threshold of usage-counter data for blink intent-to-deprecate features, what does that work out as far as number of sites? (I mean the number within whatever sample the usage-counter data is collected from) |
| 20:58 | <tobie> | robertkowalski: found this: http://sideshowbarker.github.io/console-spec/ |
| 20:58 | <MikeSmith> | and it is sites, right? not URLs/documents |
| 20:58 | <MikeSmith> | yeah that doc is quite imcomplete |
| 20:58 | <MikeSmith> | the best resource for console still remains http://getfirebug.com/wiki/index.php/Console_API |
| 20:58 | <philipj> | MikeSmith: Chrome's data is percentage of page views, so it can't be compared with number of sites in a corpus like httparchive |
| 20:59 | <MikeSmith> | philipj: ah OK, makes sense |
| 20:59 | <philipj> | MikeSmith: it's quite likely that there are some counters with high usage only due to youtube.com or similar |
| 21:00 | <MikeSmith> | ah |
| 21:00 | <philipj> | zcorpan: oh, right, should I fix the two that I've closed? |
| 21:00 | <zcorpan> | philipj: naw |
| 21:02 | <MikeSmith> | tobie: robertkowalski https://github.com/DeveloperToolsWG/console-object/blob/master/api.md is good |
| 21:02 | <MikeSmith> | and https://developer.mozilla.org/en-US/docs/Web/API/Console |
| 21:07 | <tobie> | TabAtkins: I'm having a hard time getting em-dashes to work. Shouldn't https://github.com/w3c/sensors/blob/gh-pages/index.bs#L119 so it? |
| 21:07 | <TabAtkins> | Assuming there's no spaces at the ends of those lines, yes, it should. |
| 21:08 | <tobie> | there isn't. |
| 21:09 | <TabAtkins> | Hmmm, it is indeed not working. Will look. |
| 21:10 | <tobie> | ty |
| 21:11 | <tobie> | I kind of cargo-culted the boilerplate metadata, so I might be doing something dumb there. |
| 21:13 | <TabAtkins> | tobie: Nope, it was a dumb thing on my part. |
| 21:13 | <TabAtkins> | Accidentally required the following line to start with whitespace for the emdash conversion to happen. |
| 21:14 | <TabAtkins> | Just pushed the fix. |
| 21:14 | <tobie> | oh, cool. |
| 21:14 | <TabAtkins> | (My specs tend to indent the text, to make headings more obvious on a quick scan, so i didn't notice the problem. |
| 21:14 | <TabAtkins> | ) |
| 21:15 | <tobie> | Yeah, I got used to sticking everything as far left as possible to avoid weird markdown bugs. |
| 21:16 | <TabAtkins> | I don't (and won't) implement the "indent means code block" part of Markdown, so feel free to indent. |
| 21:16 | <tobie> | Mind pulling in https://github.com/tabatkins/bikeshed/pull/493 while you're at it? |
| 21:16 | <tobie> | Oh, you're planning to cherry-pick markdown. Sounds fun. |
| 21:17 | <tobie> | CommonMark-- ? |
| 21:17 | <tobie> | :P |
| 21:18 | <tobie> | TabAtkins: I had added support for that in Respec https://github.com/w3c/respec/blob/develop/js/core/markdown.js#L141-L183 |
| 21:19 | <tobie> | But it still acted weird on occasion. Or at least I feared it would. |
| 21:19 | <TabAtkins> | Yeah, Bikeshed's markdown handles HTML nesting properly. Indented code is fundamentally incompatible with that. |
| 21:22 | <tobie> | I'm not sure what you mean by "Bikeshed's markdown handles HTML nesting properly." |
| 21:23 | <TabAtkins> | Bikeshed intermixes HTML and Markdown in a sane way, I mean. |
| 21:25 | <tobie> | yeah. Regular markdown certainly doesn't. |
| 21:26 | <TabAtkins> | Largely because of the historical mistake of indented code blocks. ^_^ |
| 21:26 | <TabAtkins> | So yeah, I'm gradually approaching consistency with CommonMark except for that point. |
| 21:27 | <TabAtkins> | (Unsure if I'll ever fully implement CommonMark's multi-line backtick semantics, tho. They require some weird back-and-forth integration between parser levels.) |
| 21:36 | <robertkowalski> | MikeSmith: oh btw why did you stop working on the console api? was it too boring? |
| 21:40 | <MikeSmith> | robertkowalski: I can't say I ever really put much work into it. I put it together intending that somebody else might pick up work on it |
| 21:41 | <MikeSmith> | but that said it's never been a high priority for me personally |
| 21:41 | <MikeSmith> | I guess that's true of others as well |
| 21:42 | <MikeSmith> | it's not clear how strong of a need we have for a high level of interoperability around it |
| 21:42 | <MikeSmith> | the main reason to have a spec is to ensure we get interoperability among implementations |
| 21:43 | <MikeSmith> | and to avoid creating interoperability frustrations for devs |
| 21:44 | <MikeSmith> | I could be wrong but I think console interoperability (or lack of) doesn't seem like a pain point for devs currently |
| 21:44 | <MikeSmith> | TabAtkins: http://stackoverflow.com/questions/32874967/html5-image-preloading if you have any insights |
| 21:56 | <robertkowalski> | MikeSmith: *nod* |
| 21:57 | <robertkowalski> | MikeSmith: maybe i'll pick it up. i like to write those spec tests |
| 21:57 | <robertkowalski> | i wrote some with another test framework ~1yr ago |
| 21:58 | <MikeSmith> | TabAtkins: thanks (would upvote that but I'm out of votes for today until ~1hr or so from now) |
| 21:59 | <MikeSmith> | robertkowalski: if you do pick up work on it I would be glad to help with review and such |
| 21:59 | <MikeSmith> | but note that terinjokes has been working on something too from time to time |
| 21:59 | <MikeSmith> | not sure where he's at with it currently but maybe y'all could collaborate |
| 22:00 | <MikeSmith> | robertkowalski: https://github.com/terinjokes/console-spec |
| 22:00 | <MikeSmith> | http://terinjokes.github.io/console-spec/ |
| 22:01 | <MikeSmith> | btw how do we test the console object? |
| 22:01 | <MikeSmith> | given that it's not exposed to web content |
| 22:03 | <robertkowalski> | in node we could listen on stdout / stderr i guess and regarding browsers i was hoping that http://testthewebforward.org/ would support it in some way |
| 22:09 | <MikeSmith> | robertkowalski: yeah the testharness for testtwf runs in-browser strictly in JS, so it has no way to get to console output afaict |
| 22:10 | <MikeSmith> | but yeah I had not been thinking about the node.js/io.js context |
| 22:12 | <jgraham> | Yeah, you can't test the console method in a cross browser way afaik |
| 22:12 | <jgraham> | Unless we start exposing test-only APIs |
| 22:13 | <jgraham> | Which has been sugggested, but I am somewhat sceptical about |
| 22:16 | <robertkowalski> | could we implement the tests in node and browser vendors could port it into their testsuites? |
| 22:16 | <robertkowalski> | feels a bit uncool, but better than nothing i guess |
| 22:17 | <gsnedders> | BTW, if anyone has any opinions on what needs sorted out with the CSS testsuite, prod me |
| 22:22 | <jgraham> | robertkowalski: I don't see how node helps you here |
| 22:28 | <robertkowalski> | jgraham: build the reference testsuite or even reference implementation in node |
| 22:29 | <robertkowalski> | jgraham: and hoping others will follow / start helping to make testing in browsers easier :) |
| 22:30 | <robertkowalski> | <- specs newbie |
| 22:43 | <gsnedders> | robertkowalski: and how do you know the reference implementation is right? |
| 22:43 | <Domenic> | robertkowalski: in terms of web tests the most important test will be the stuff that can be observed from scripts (and thus cause potential interop problems) |
| 22:43 | <Domenic> | robertkowalski: so e.g. what methods exist on console, and when or if they ever throw errors |
| 22:44 | <Domenic> | robertkowalski: the "side effect" of logging to console is less important to test (but, would be nice for devs, so that they know they can use e.g. %s across all browsers and get useful results.) |
| 22:47 | <jgraham> | Right so there is some useful stuff you can test |
| 22:48 | <jgraham> | But without any way to read back the console it's unclear that an implementation like console = {log: function(data){}} wouldn't pass most tests |
| 22:53 | <Domenic> | good enough for web compat |
| 23:12 | <TabAtkins> | Yeah, just need a bunch of manual tests unfortunatekly. |