| 02:06 | <gavinc> | cross window javascript would be right nice right now |
| 02:07 | <gavinc> | maybe I can make postMessage work |
| 02:54 | <zewt> | firefox taking a new top seat of the month for bad ui: fullscreening dims the window every single time |
| 02:55 | <zewt> | smells like contrived security issues that don't actually actually exist being used as an excuse to annoy every user of (sites that use) the api |
| 02:56 | <zewt> | ... switching youtube back to flash |
| 04:44 | <gsnedders> | So, those following progress of html5lib will be happy to hear I've just regressed almost every test. |
| 05:08 | <gsnedders> | And now we're basically working on Py3! |
| 05:08 | <ruby_on_tails> | hello |
| 05:46 | <zewt> | bleh, only thing i seriously dislike about dom events is how capturing event listeners aren't run before non-capturing event listeners in the AT_TARGET phase; easily its biggest, ugliest wart |
| 11:06 | <jgraham> | https://github.com/mozilla/mozilla-central |
| 11:07 | <jgraham> | Anyone know if that's a one-way sync or there is some solution for pushing there? |
| 11:10 | <Ms2ger> | It's one-way |
| 15:13 | <zewt> | wish people would stop rolling the rand()%2?"URL":"URI" dice and just call them what they are: URLs |
| 15:22 | <divya> | zewt++++ |
| 15:25 | <zewt> | particularly silly when people talk about the "URIs" returned by "createObjectURL" |
| 16:01 | <divya> | ahahahah |
| 16:01 | <divya> | URIs must die |
| 19:02 | <tantek> | indeed. URLs++ :) |
| 19:07 | <zewt> | (i don't particularly care about which definition is used--just the silly idea that we have two different things that people actually differentiate between) |
| 19:16 | <tantek> | zewt TBH sometimes "URL" in the name of an API is purely legacy for naming reasons, and it may have been expanded to return URIs without bothering to change the name. |
| 19:16 | <tantek> | usually this is easy enough to determine by asking the question is there anyway the API can return something like an "isbn:" URI |
| 19:18 | <tantek> | also WP asserts that "about:" is a "URI" scheme (more than a "URL" scheme) http://en.wikipedia.org/wiki/About_URI_scheme |
| 19:18 | <tantek> | so if an API can return an "about:…" value, then it's returning a URI rather than a URL (unless we want to rewrite that Wikipedia article) |
| 19:19 | <tantek> | for ISBN: I see how it makes sense to call it a URI (*identifier*) rather than a URL ("locator/location" etc.) |
| 19:20 | <tantek> | for about: I'm on the fence - it's always "felt" like a URL to me (it goes somewhere predictable and does something) rather than a URI, but I don't really have the energy/time to fight that fight on Wikipedia. |
| 19:21 | <tantek> | or perhaps someone who has a better understanding of why "about:" is considered a URI could explain why that is, rather than just a URL. |
| 19:22 | <tantek> | but your overall statement I have to agree with, in typical conversation it makes sense to just refer to URLs. |
| 19:27 | <tantek> | ok, by this WP defn, I think about: could be considered a URL scheme: http://en.wikipedia.org/wiki/Uniform_Resource_Locator#URLs_as_locators |
| 19:28 | <tantek> | "provides a means of locating the resource by describing its primary access mechanism (e.g., its network location)" |
| 19:28 | <tantek> | primary access mechanism = the browser |
| 19:28 | <tantek> | for about: |
| 19:29 | <zewt> | i don't see any point to even drawing the distinction |
| 19:29 | <tantek> | and that quote is apparently even from http://tools.ietf.org/html/rfc3986 |
| 19:29 | <tantek> | 1.1.3. URI, URL, and URN |
| 19:29 | <tantek> | which is a better citation that WP |
| 19:30 | <tantek> | ergo, I think we can assert that about: URIs are actually just URLs. |
| 19:31 | <tantek> | I'm not sure it ever made sense to come up with URIs that were *not* URLs. e.g. how useful is isbn: ? |
| 19:32 | <zewt> | useful for linking, in the intent sense (if the user can configure which site he wants to view book references on); doesn't make sense for generic fetching (xhr) |
| 19:33 | <zewt> | same with mailto, irc, anything else intent-y |
| 19:39 | <zewt> | though I suppose in principle they could, if they defined a protocol, eg. if isbn: was defined as returning a JSON block with the title and author--the user could plug in whatever data service he wants and sites requesting isbn:1234 would get data from that service |
| 19:40 | <zewt> | then doing an xhr fetch on isbn:12345 would be no different than http://amazon.com/get-isbn-info/12345 (not to say that would actually be useful, just that there doesn't *have* to be any difference) |
| 20:06 | <tantek> | I guess I don't see a point to linking to a scheme (like ISBN: ) until it actually does something (like mailto: and irc: already do something) |
| 20:06 | <tantek> | even others one might presume would be popular, like "tel:" have had very little uptake in practice |
| 20:07 | <tantek> | at least that's been our experience with microformats like hCard, people will markup a class="tel" but not bother to figure out how to make a "tel:" hyperlink work - too much hassle. |
| 20:08 | <tantek> | e.g. does anyone know if *any* of the (supposed) smart phones out there have a browser that when you click on a "tel:" hyperlink actually launches the phone/dialer application to dial the phone number? |
| 21:03 | <adlwalrus> | is the foreget param of location.reload standardized? |