| 00:10 | <zewt> | gah, and this same page is navigating on middle click, so when I try to open new tabs from search results it eats the search result window |
| 00:14 | <SamB> | EVILLL! |
| 00:15 | <zewt> | "sloppy" |
| 02:47 | <MikeSmith> | Hixie: fyi the w3c bugzilla now supports private tags. Which apparently are just like keyboards except that they're private, so nobody else can see them and no bugmail notification gets sent went you add them |
| 02:47 | <MikeSmith> | *keywords |
| 02:48 | <MikeSmith> | Hixie: however I can't find anything in the UI that exposes them |
| 02:48 | <MikeSmith> | Hixie: but doing ?quicksearch=tag:TAGNAME will show them |
| 02:55 | <karlcow> | yup, MikeSmith I use that on mozilla bugzilla to cater for some of my bugs list with categories |
| 02:55 | <karlcow> | the search can't be shared. as the tag is private it will have no effect for someone else |
| 02:56 | <MikeSmith> | karlcow: yeah that much I gleaned from the docs, but nowhere in the UI can a find a link to my tags |
| 02:57 | <MikeSmith> | karlcow: docs seem to indicate that the tags you create should show up in every page footer, where the saved searches show up |
| 02:57 | <MikeSmith> | karlcow: but I see nothing there |
| 02:58 | <karlcow> | the tags are not visible for me too on Mozilla, just the feature for adding the tag. |
| 02:58 | <MikeSmith> | karlcow: ah OK, that's good :( |
| 02:58 | <MikeSmith> | karlcow: good that it's not just me but sad for you |
| 02:59 | <karlcow> | :) |
| 02:59 | <MikeSmith> | karlcow: I was worried that it might be a results of w3c bugzilla using custom page templates or something |
| 03:00 | <karlcow> | another thing which is practical in the mozilla bugzilla is the tag on specific comments |
| 03:00 | <karlcow> | which in this case is public and shared |
| 03:00 | <karlcow> | and visible |
| 03:03 | <karlcow> | we used it for making a wrapper selecting some specific comments |
| 03:03 | <karlcow> | The wrapper: http://webcompat.com/simplebug/index.html#mozilla/843126 |
| 03:04 | <karlcow> | the bug https://bugzilla.mozilla.org/show_bug.cgi?id=843126 |
| 03:04 | <karlcow> | the comment with the tag |
| 03:04 | <karlcow> | https://bugzilla.mozilla.org/show_bug.cgi?id=843126#c7 |
| 03:05 | <karlcow> | ah interesting the tags are visible only if logged in :) |
| 03:07 | <karlcow> | http://www.la-grange.net/2014/05/26/tagged-bug |
| 03:08 | <MikeSmith> | karlcow: http://www.bugzilla.org/releases/4.4.4/release-notes.html#v44_feat_bug_tags ーNote that when you add a new tag, no saved search based on this tag is created anymore, as you can easily create it yourself if you really need it. |
| 03:09 | <MikeSmith> | karlcow: tag on specific comments? |
| 03:09 | <karlcow> | yup |
| 03:09 | MikeSmith | checks karlcow URLs |
| 03:10 | <MikeSmith> | oh wow |
| 03:10 | <MikeSmith> | dunno if we have that comment-tagging thing yet in our 4.4.2 instance at w3c, do we? |
| 03:11 | <MikeSmith> | that would be great for tagging all the noise comments in bugs so that they don't show up |
| 03:11 | <MikeSmith> | or conversely for tagging just all the useful comments |
| 03:12 | <MikeSmith> | hmm but only if it actually shows/hides |
| 03:13 | <MikeSmith> | karlcow: I don't see what actually happens when I click any of the "Comment Tags:" links at https://bugzilla.mozilla.org/show_bug.cgi?id=843126 |
| 03:13 | <karlcow> | it seems not in W3C bugzilla. In Mozilla bugzilla, I have in the prefs a "Enable tags for bugs " |
| 03:14 | <MikeSmith> | ok |
| 03:14 | <karlcow> | nothing happens it just tag the comments. The way we used is to cherry-pick some comments for using in another apps. |
| 03:15 | <MikeSmith> | ah OK |
| 03:15 | <karlcow> | You could imagine for example, a spec with links to the issues and the described resolution of an issue is in a specific comment which is automatically extracted because it carries a specific tag. |
| 03:18 | <MikeSmith> | yeah |
| 03:19 | <MikeSmith> | there are many cases already where I could have used this |
| 03:19 | <MikeSmith> | karlcow: but the biggest case I can think of is for auto-generating a Disposition of Comments report for last call |
| 03:20 | <karlcow> | indeed |
| 03:21 | <MikeSmith> | karlcow: so I can tag a particular comment as the resolution for the bug, and maybe also some other comment as a statement from the bug report that they're satisfied with the resolution |
| 07:53 | <mathiasbynens> | annevk: reminder http://krijnhoetmer.nl/irc-logs/whatwg/20140505#l-608 |
| 08:27 | <annevk> | MikeSmith: so if Glenn Adams keeps doing that, I think we should just have a WHATWG XMLHttpRequest component |
| 08:28 | <annevk> | mathiasbynens: the second link now works |
| 08:28 | <annevk> | mathiasbynens: again, note that these tests are not necessarily up to date |
| 08:35 | <mathiasbynens> | annevk: i know, i ended up writing my own scripts that generated e.g. https://github.com/mathiasbynens/windows-1252/blob/c234dee4d60da023542cad4d8684428e47692ae3/tests/tests.js#L47-L48 |
| 08:36 | <mathiasbynens> | but still, nice – thanks! |
| 08:36 | <annevk> | mathiasbynens: that looks good, I guess you also want to have random order and such of the bytes |
| 08:37 | <annevk> | mathiasbynens: and boundary checks where it switches from outputting bytes / code points to reading from a table first |
| 08:37 | <annevk> | mathiasbynens: and then ideally submit them to the platform-tests initiative |
| 08:40 | <annevk> | http://tech.oimou.com/post/86713933184/xmlhttprequest-responseurl seems like there's a lot of people wanting to detect redirects in XMLHttpRequest |
| 08:40 | <annevk> | I guess I could try pointing them to http://fetch.spec.whatwg.org/#atomic-http-redirect-handling |
| 08:41 | <MikeSmith> | annevk: remind me what Glenn did? |
| 08:41 | <MikeSmith> | annevk: ... this time |
| 08:41 | <MikeSmith> | mathiasbynens link? |
| 08:41 | <Ms2ger> | MikeSmith, reopen bugs because they were only fixed in the whatwg spec |
| 08:41 | <annevk> | MikeSmith: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25540#c3 |
| 08:41 | <MikeSmith> | ah |
| 08:41 | <MikeSmith> | well that's just obnoxious |
| 08:42 | <Ms2ger> | You remember who you're talking about, right? |
| 08:43 | <MikeSmith> | wait.. the normal answer would be "me" |
| 08:43 | <MikeSmith> | anyway yeah I'm happy to create an XHR component if needed |
| 08:44 | <MikeSmith> | I'm also happy to remind Glenn that the W3C XHR editors are on record as claiming that they are just publishing a "snapshot" of the upstream XHR spec |
| 08:44 | <MikeSmith> | unless the tune has changed since the last time I was paying attention |
| 08:45 | <Ms2ger> | I suspect a new component would waste minimal time |
| 08:45 | <MikeSmith> | ok |
| 08:46 | <MikeSmith> | well if/when annevk wants it actually created, I'll make it. I seem to remember that last time somebody suggested we create one, annevk said he didn't want it created (yet) |
| 08:47 | <annevk> | MikeSmith: lets see how it plays out I guess |
| 08:47 | <MikeSmith> | k |
| 08:49 | <annevk> | Somewhat surprising that the only noise online about the addition of XMLHttpRequest.prototype.responseURL is coming from Japan |
| 08:49 | <mathiasbynens> | MikeSmith: you mean a link to the script that generated that test data? it’s not public (but i can make it public if you’d like) |
| 08:49 | <MikeSmith> | foolip: thanks for the webvtt idl review & merge. that'ill make plh happy |
| 08:50 | <mathiasbynens> | basically parses annevk’s index.txt files in the Encoding Standard, and then goes from there |
| 08:50 | <annevk> | mathiasbynens: why don't you use the JSON file? |
| 08:51 | <mathiasbynens> | annevk: the index files are normative, but the JSON file isn’t |
| 08:51 | <annevk> | darobin: you keep breaking threading |
| 08:51 | <MikeSmith> | mathiasbynens: nah it's OK. I was just a bit confused. Trying to read several things at the same time.. |
| 08:51 | <annevk> | mathiasbynens: except you probably know I generate the index files from the JSON :-) |
| 08:52 | <annevk> | Maybe I should say the JSON file is normative? Hmm |
| 08:52 | <annevk> | http://utf-8.jp/ :-) |
| 08:52 | <foolip> | MikeSmith: np |
| 08:53 | <mathiasbynens> | annevk: well, it would’ve helped me a tiny bit :) |
| 08:56 | <zcorpan_> | mathiasbynens: you should have just trusted the json file despite not being normative :-P |
| 08:58 | <mathiasbynens> | zcorpan_: NEVER! |
| 08:58 | <darobin> | annevk: huh? |
| 08:59 | <annevk> | darobin: your replies in the "Re: Should minimal contentEditable default text input" thread keep creating a new thread in Gmail |
| 08:59 | <darobin> | annevk: well, I'm reyplying normally and I see them threaded here — Gmail bug? |
| 08:59 | <darobin> | (barring that, Thunderbird bug) |
| 09:00 | <zcorpan_> | mathiasbynens: :-) |
| 09:01 | <annevk> | darobin: one or the other I guess |
| 09:01 | <annevk> | mathiasbynens: not sure how to resolve that, I'm taught not to have multiple normative formats |
| 09:02 | <darobin> | annevk: just checked, the In-Reply-To header on my reply to you is correct, so GMail threading is trying to be overly smart |
| 09:02 | <annevk> | mathiasbynens: aah, I know, I'll say that the JSON one is non-normative but is also the source of the data, so if you can reverse engineer it, it's normative |
| 09:02 | <darobin> | Email sucks. Film at 11. |
| 09:02 | <annevk> | mathiasbynens: as in, I'll explain more clearly that the reason it's non-normative is because I don't want to define two formats |
| 09:02 | <annevk> | mathiasbynens: and the other format one due to historical precedence |
| 09:02 | <mathiasbynens> | Almost Normative™ |
| 09:03 | <annevk> | Normative Enough For mathiasbynens |
| 09:03 | <mathiasbynens> | it’s fine really, both formats are easy to consume anyway |
| 09:03 | <zcorpan_> | rfc6919 might be relevant here |
| 09:04 | <mathiasbynens> | if this were TC39 we’d just call it Annex B |
| 09:32 | <foolip> | annevk: why did you keep the from parameter in http://html5.org/tools/web-apps-tracker?from=8647 instead of to? |
| 09:32 | <foolip> | seems like an odd choice if it's only possible to show a single revision diff anyway |
| 09:33 | <annevk> | foolip: hadn't really thought about it much |
| 09:33 | <annevk> | foolip: I think ideally I just make the short URLs work |
| 09:33 | <annevk> | foolip: and no longer redirect to the longer form |
| 09:56 | <foolip> | annevk: yeah, that would work too |
| 10:20 | <annevk> | foolip: done |
| 10:55 | <foolip> | annevk: the short URL link is a bit useless now :) |
| 10:55 | <foolip> | oh, and yay \o/ |
| 10:58 | <annevk> | foolip: good point |
| 11:00 | <annevk> | I like how much this thing is simplified now |
| 11:10 | <foolip> | annevk: http://html5.org/r/8640 is a bit useless because it didn't touch source, did the old script show only revisions that did? |
| 11:13 | <annevk> | foolip: I made a change to at least output the change message there |
| 11:14 | <annevk> | foolip: however, for the main page it would probably be good to filter them somehow |
| 11:14 | <foolip> | annevk: git log -- source would be the command |
| 11:15 | <foolip> | maybe the "--" isn't necessary when you're doing it from a script |
| 11:15 | <annevk> | foolip: was just adding that |
| 11:15 | <annevk> | foolip: well the way I invoke git is kind of hacky |
| 11:15 | <annevk> | foolip: due to an old Python version |
| 11:15 | <foolip> | 'Paths may need to be prefixed with "-- " to separate them from options or the revision range, when confusion arises.' is what the manpage says |
| 11:17 | <annevk> | foolip: https://github.com/whatwg/web-apps-tracker/commit/08e8fa780846f38cd29858e551ca0b7b8fb5b8dd |
| 11:29 | <annevk> | Oh, the person contributing patches for responseURL seems to be Japanese |
| 11:41 | <foolip> | annevk: cool, everything works now AFAICT. do you have the autoupdate set up? |
| 11:45 | <annevk> | foolip: yeah, via a push hook |
| 11:45 | <annevk> | I guess at some point I could look into having the splitter using the same source for the spec so I don't have two copies |
| 11:46 | <annevk> | Although Hixie seems to be building his own toolchain so maybe that'll just obsolete it |
| 11:48 | <annevk> | mathiasbynens: jtcranmer: maybe instead of domainToASCII and such we should have new Domain() or some such |
| 11:49 | <foolip> | annevk: to replace anolis, or just for splitting? |
| 11:50 | <annevk> | foolip: I think both |
| 11:50 | <annevk> | foolip: I want to switch to Bikeshed personally at some point (Tab's tool) |
| 11:50 | <foolip> | is that why recently when the spec loads it takes a second before the style is applied? |
| 11:50 | <foolip> | doing more with scripts? |
| 11:51 | <annevk> | foolip: I think that's Hixie experimenting with the style sheet, as far as I know the toolchain has not been changed |
| 11:51 | <foolip> | ok |
| 11:51 | <annevk> | foolip: no, I think the main idea was to have a faster version of what Anolis and the splitter are doing now |
| 11:52 | <annevk> | mathiasbynens: jtcranmer: it depends a bit as to what kind of things we're interested in exposing, TLDs, labels, effectiveTLDs, DNS queries? |
| 11:53 | <annevk> | I guess DNS might be bad for privacy, although maybe that's exposed through timing already |
| 11:56 | <mathiasbynens> | what do you mean by effective TLDs? would it just return the TLD for a given domain, or do something more clever based on https://www.publicsuffix.org/? |
| 11:57 | <mathiasbynens> | having those methods on URL (as it is now) seems more convenient in most cases i imagine |
| 11:58 | <annevk> | mathiasbynens: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=25865 for effective TLD |
| 11:59 | <annevk> | mathiasbynens: yeah I guess I should try to avoid churn as well; we can always layer these statics on a lower-level primitive later |
| 12:54 | <annevk> | It'd be kinda cool if IDL had knowledge of window / document objects / script setting objects |
| 12:55 | <annevk> | Instead of something accepting a DOMString, you could have "ToURL" that'd do the ScalarValueString dance, but also parsing relative to the script settings object and just hand you the URL where you write the rest of the algorithm |
| 12:55 | <annevk> | And throw a TypeError if the URL parser returns failure |
| 13:09 | <annevk> | Domenic: ^^ |
| 13:10 | <annevk> | Taking decisions away from specification authors seems like a good thing |
| 14:14 | <annevk> | Hixie: maybe give a different box than "Note" for domintro? |
| 14:31 | <annevk> | JakeA: why does https://slightlyoff.github.io/ServiceWorker/spec/service_worker/ now render without style sheet? |
| 14:44 | <annevk> | JakeA: progress events seems like another case that'd be different between default() and fetch() |
| 14:47 | <SamB> | annevk: don't you have devtools you could use to find out what's preventing the stylesheet from loading ;-P |
| 15:05 | <JakeA> | annevk: how so? |
| 15:05 | <annevk> | JakeA: no idea how XHR upload progress events should work otherwise |
| 15:06 | <JakeA> | Both fetch & default resolve after headers |
| 15:07 | <annevk> | JakeA: *upload* |
| 15:07 | <annevk> | JakeA: is the idea respondWith(event.default()) or just event.default() is the whole deal |
| 15:08 | <annevk> | JakeA: in the latter case, should it return anything? |
| 15:09 | <JakeA> | annevk: it's still passed to respondWith, so it can be used as a fallback to another thing |
| 15:10 | <annevk> | JakeA: so it's different from the default (not handling the event) |
| 15:10 | <annevk> | JakeA: bit confusing but okay |
| 15:10 | <JakeA> | annevk: see http://jakearchibald.com/2014/service-worker-first-draft/#recovering-from-failure |
| 15:10 | <JakeA> | annevk: I think event.default is a terrible API, that's why I keep trying to find ways not to have it :D |
| 15:11 | <annevk> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/242#issuecomment-44197133 |
| 15:12 | <annevk> | JakeA: anyway, upload progress events would get lost without it |
| 15:12 | <JakeA> | annevk: if request.body is a stream, wouldn't upload progress be based on the reading of that stream? |
| 15:13 | <JakeA> | annevk: but yeah, if you consumed all of that stream in the SW, you'd get to 100% quickly |
| 15:13 | <annevk> | JakeA: no, upload progress events are about transmitted bytes |
| 15:13 | <JakeA> | But it would work fine with fetch() |
| 15:13 | <annevk> | JakeA: so e.g. if you have compression or some such that would matter |
| 15:14 | <annevk> | JakeA: so it's up to the network layer and not up to request.body |
| 15:14 | <JakeA> | annevk: hmm, need to look at the XHR spec more closely for that |
| 15:14 | <annevk> | JakeA: and it wouldn't work fine with fetch(), since you've lost context at that point |
| 15:15 | <annevk> | (well, I guess you haven't since you're reading that stream... however, we don't have streams, let alone streams that span realms) |
| 15:15 | <JakeA> | annevk: can you add a ticket for that? (Sorry, bank holiday here so I'm not at laptop) |
| 15:16 | <annevk> | JakeA: for which bit? |
| 15:16 | <JakeA> | annevk: handling progress events |
| 15:19 | <annevk> | JakeA: we could not have default() btw and just use a flag on the request object and keep track of magic request objects that way, but using a different method seems clearer |
| 15:19 | <annevk> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/289 |
| 15:24 | <annevk> | How does one get notified on gist.github.com activity? |
| 15:25 | <JakeA> | annevk: there's a watch button on repos |
| 15:25 | <annevk> | JakeA: not on GitHubGist? |
| 15:36 | <JakeA> | annevk: ah sorry, not reading properly |
| 15:48 | <annevk> | SamB: any updates on https://github.com/whatwg/resources.whatwg.org/pull/1 ? |
| 16:11 | <SamB> | annevk: hmm, perhaps I should look at fixing the bugs in rsvg/inkscape ... |
| 16:11 | <SamB> | or at least forwarding them to the respective upstreams |
| 16:14 | <SamB> | <SamB> annevk: hmm, perhaps I should look at fixing the bugs in rsvg/inkscape ... |
| 16:14 | <SamB> | <SamB> or at least forwarding them to the respective upstreams |
| 16:14 | <annevk> | SamB: yeah saw that |
| 16:14 | <SamB> | wasn't sure |
| 16:48 | <annevk> | cool, logo licensing sorted |
| 17:43 | <Krinkle> | #omgomg Did we just land a specification for Element#closest in DOM? Like jQuery#closest a bit |
| 22:53 | <Domenic> | Gist notifications were removed about 1.5 years ago and still haven't returned. Much rage. |
| 22:53 | <Domenic> | (Also, yay, I have internet again!) |