| 04:32 | <manu1> | hsivonen: I'd appreciate responses to http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Apr/0128.html and http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Apr/0129.html as your time allows (RDFa ISSUE-130 and ISSUE-132). |
| 05:02 | <othermaciej> | manu1: how come HTML+RDFa issues are getting processed in the RDFa WG instead of the HTML WG? |
| 05:02 | <othermaciej> | manu1: should HTML+RDFa no longer be an HTML WG deliverable, since it is being worked on elsewhere and another WG is purporting to make decisions about it? |
| 05:05 | <hsivonen> | othermaciej: looks like we shouldn't pretendthat it's an HTML WG deliverable |
| 05:07 | <Hixie> | i'm amused that the discussion in the e-mails above isn't about whether or not the technical issues are resolved, it's about whether or not they are substantive and how to record that. |
| 05:19 | <hsivonen> | Hixie: I disagreed with the substance of some decisions, too. I find it annoying thasubstantive changes are downplayed as nonsubstantive in the DoC that gets shown to the Ditector |
| 05:20 | <Hixie> | hsivonen: yeah, but that wasn't what the reply was about |
| 05:21 | <hsivonen> | that is, I think the substantiveness of a change should depend on what specs said and now say rather than what the WG meant when ispecced something else |
| 05:21 | <hsivonen> | *it specced |
| 05:26 | <othermaciej> | W3C Process does say that substantiveness should be evaluated from the point of view of a hypothetical reviewer of the spec |
| 05:26 | <othermaciej> | not from point of view of wg members |
| 05:27 | <othermaciej> | "A substantive change (whether deletion, inclusion, or other modification) is one where someone could reasonably expect that making the change would invalidate an individual's review or implementation experience. " |
| 05:27 | <othermaciej> | <http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs>; |
| 05:28 | <othermaciej> | by that standard, it's pretty hard for a change not to be substantive |
| 05:29 | <hsivonen> | the changes for sure affected the validator impl |
| 05:31 | <Hixie> | you two are so cute, acting as if the process is ever followed |
| 05:56 | <othermaciej> | Hixie: I certainly don't have the desire to try to make other WGs follow it |
| 06:21 | <annevk> | hmm I wonder when WebVTT will get the rest of the HTML entities |
| 06:22 | <Hixie> | i was wondering the same earlier :-) |
| 06:22 | <Hixie> | the ones we've added have clear use cases |
| 06:38 | <annevk> | zcorpan: you still have some unliked [SELECTORS] [HTML] in your quirks mode doc |
| 06:38 | <annevk> | also unlinked |
| 06:40 | <zcorpan> | yeah i'll take a pass some day to clean it up |
| 06:50 | <Hixie> | are string indexes in JS not lvalues? |
| 06:51 | <othermaciej> | what do you mean by "string indexes"? |
| 06:51 | <Hixie> | s[4] |
| 06:51 | <Hixie> | wait, are strings in js immutable? |
| 06:51 | <othermaciej> | js strings are immutable, yes |
| 06:51 | <Hixie> | damnit |
| 06:51 | <Hixie> | k |
| 06:51 | <Hixie> | you'd think it would at least throw an exception or SOMEthing |
| 06:52 | <othermaciej> | I do believe "foo"[0] = "x" will not throw, but it won't do what you want |
| 06:52 | <Hixie> | i can definitely confirm _that_ |
| 06:52 | <othermaciej> | reason being that it theoretically creates a String object wrapper around the string and assigns its property named "0" |
| 06:52 | <Hixie> | jeez |
| 06:52 | <othermaciej> | the wrapper is then discarded at the end of the statement |
| 06:52 | <annevk> | mwaha |
| 06:52 | <Hixie> | so is there some convenient idiom for updating a string? |
| 06:53 | <othermaciej> | depends on what you mean |
| 06:53 | <Hixie> | i want to replace the nth character of string S with new character X |
| 06:53 | <othermaciej> | there's no way to modify a string value |
| 06:53 | <Hixie> | there's like six zillion ways to do this in perl |
| 06:53 | <Hixie> | ok how about getting back a new string value that i assign to the same variable |
| 06:54 | <annevk> | Hixie: http://stackoverflow.com/questions/1431094/how-do-i-replace-a-character-at-a-particular-index-in-javascript |
| 06:54 | <Hixie> | seriously there's no better way than substr? |
| 06:54 | <Hixie> | jeez |
| 06:55 | <annevk> | but hey, next version of JavaScript might have classes and indexing by code point, it's a great language! |
| 06:55 | <othermaciej> | checking if there is a better way than substr |
| 06:59 | <othermaciej> | I guess depending on context slice might be easier to use than substr |
| 07:00 | <othermaciej> | function replaceChar(str, char, index) { return str.slice(0, index - 1) + char + str.slice(index); } |
| 07:00 | <Hixie> | that's basically the same code |
| 07:01 | <othermaciej> | true, I guess I might have an off-by-one bug also |
| 07:28 | <rniwa> | annevk: hi annevk! |
| 07:28 | <annevk> | hey rniwa |
| 07:29 | <rniwa> | annevk: are you following the context free (i.e. insertion-mode free) parsing algorithm discussion on public-webapps? |
| 07:29 | <annevk> | just a little bit |
| 07:30 | <rniwa> | annevk: k. |
| 07:30 | <rniwa> | annevk: i think there's a consensus that it's a good idea |
| 07:30 | <rniwa> | annevk: but there's some disagreement as to what exactly it should do |
| 07:31 | <rniwa> | annevk: particularly with respect to xml elements and whether parser should reject 'bad' html construct or not. |
| 07:31 | <rniwa> | Hixie: maybe you'll have some opinion on this? |
| 07:32 | <annevk> | I think you're wrong about jQuery's approach being wrong |
| 07:32 | <annevk> | it buys you quite a bit |
| 07:32 | <rniwa> | annevk: ok. |
| 07:32 | <annevk> | for instance <td> tags will not be dropped on the floor |
| 07:32 | <rniwa> | annevk: could you respond to the thread then? |
| 07:33 | <rniwa> | annevk: what do you mean? |
| 07:34 | <annevk> | if you do not adjust the insertion mode accordingly |
| 07:35 | <rniwa> | annevk: sure, but why do we want to adjust the insertion mode for the top-level element though? |
| 07:35 | <annevk> | by adjusting the insertion mode as Yehuda suggests this works perfectly for innerHTML on fragments |
| 07:35 | <rniwa> | annevk: isn't better to allow any top-level element? |
| 07:35 | <annevk> | rniwa: that's how innerHTML works |
| 07:35 | <rniwa> | annevk: sure because we have a context element. |
| 07:35 | <rniwa> | annevk: but for fragment, we don't have a context element. |
| 07:36 | <annevk> | yeah but you can derive it from the first token |
| 07:36 | <annevk> | first tag token |
| 07:36 | <rniwa> | annevk: but if we have something like <frameset></frameset><p>hello, world</p> |
| 07:36 | <rniwa> | annevk: then we're going to drop the p. |
| 07:36 | <annevk> | sure |
| 07:37 | <rniwa> | annevk: why is that desirable behavior here? |
| 07:37 | <annevk> | if you do :root { display:none } your page won't be displayed |
| 07:37 | <annevk> | because not reusing the HTML parser mechanism is even worse |
| 07:38 | <annevk> | because then you'll have a new set of quirks and behaviors to learn, parsing becomes unpredictable, etc. |
| 07:38 | <rniwa> | annevk: we can use the html5 parsing algorithm for elements below that. |
| 07:39 | <rniwa> | annevk: i could be convinced that this is a good idea though. |
| 07:39 | <annevk> | I'm not sure what you mean by "elements below that" |
| 07:39 | <rniwa> | annevk: what i mean is that we can allow any element at the top level (i.e. immediate children) |
| 07:40 | <rniwa> | annevk: and once you go below that level, context is well-defined |
| 07:40 | <rniwa> | annevk: i just don't see why we want to deduce the context from the first element. that sounds very arbitrary to me. |
| 07:40 | <annevk> | how is it arbitrary? |
| 07:40 | <rniwa> | annevk: why not second element or the last element for example. |
| 07:40 | <annevk> | what's your use case? |
| 07:41 | <annevk> | well in parsing there are no elements until you start parsing, so you don't know what the last element is until you parse the first |
| 07:42 | <rniwa> | annevk: right. |
| 07:42 | <annevk> | e.g. if the first is <plaintext> and you parse it per HTML rules it there won't be last element |
| 07:42 | <rniwa> | that's a good argument. |
| 07:43 | <annevk> | first is very logical imo, especially for table templating which cannot work without this logic |
| 07:43 | <annevk> | s/this logic/this behavior/ |
| 07:43 | <annevk> | you'd have to define a completely new insertion mode for what you're suggesting, have you tried thinking it out? |
| 07:44 | <rniwa> | annevk: oh, table should work regardless. because the alternative is to allow any element for the top-level. |
| 07:44 | <rniwa> | annevk: right. |
| 07:44 | <annevk> | <p><td><p> |
| 07:44 | <rniwa> | annevk: re: new insertion mode. |
| 07:44 | <annevk> | what will that do in your mode? |
| 07:44 | <annevk> | something completely different from how HTML behaves today? |
| 07:45 | <rniwa> | annevk: yeah, those unbalanced pairs are tricky ones. |
| 07:45 | <annevk> | Yehuda has put quite a bit of thought into this, had it tested it in the wild by millions of developers, wrote a detailed proposal for the HTML parser section |
| 07:46 | <annevk> | dismissing that without a good alternative in place seems unwise |
| 07:47 | <rniwa> | annevk: oh where is that document available? |
| 07:47 | <annevk> | bug somewhere |
| 07:47 | <annevk> | let me check |
| 07:47 | <rniwa> | annevk: that sounds very useful. |
| 07:48 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694 |
| 07:49 | <annevk> | I forgot Ms2ger assigned it to himself for some reason and there's no corresponding bug on HTML for Hixie to fix |
| 07:50 | <rniwa> | annevk: i'm not seeing anything Yehuda posted other than his spec patch though. |
| 07:51 | <annevk> | that's a proposal no? |
| 07:51 | <rniwa> | annevk: ah, okay. I thought he had written some documentation on "tested it in the wild by millions of developers, wrote a detailed proposal for the HTML parser section" |
| 07:52 | <annevk> | well he's on the jQuery team |
| 07:52 | <annevk> | and as far as I know wrote this part of jQuery which has been used by lots of people that use jQuery :) |
| 07:54 | <rniwa> | annevk: okay, i'll really appreciate it if you could post some of your arguments. |
| 07:54 | <rniwa> | annevk: since we desperately need responses from non-Google / non-jQuery people LOL |
| 07:56 | <annevk> | mkay, after breakfast |
| 07:56 | <rniwa> | annevk: thanks :) |
| 11:51 | <annevk> | heycam|away: are you taking a break from IDL questions such as http://lists.w3.org/Archives/Public/public-script-coord/2012AprJun/0137.html ? |
| 12:04 | <MikeSmith> | fyi, http://www.w3.org/Bugs/Public not responding |
| 12:04 | <MikeSmith> | working on it |
| 12:07 | <zcorpan> | https://bugs.webkit.org/show_bug.cgi?id=84469#c1 |
| 12:08 | <smaug____> | zcorpan: good luck trying to convince webkit to drop support for bad features |
| 12:11 | <zcorpan> | thanks :) |
| 12:11 | <davidb> | at |
| 12:13 | <zcorpan> | smaug____: i don't care so much that it's a "bad" feature, i mostly just want interop, and secondarily minimizing the number of quirks |
| 12:16 | <annevk> | heh, MikeSmith already reported what I was about to mention, good man |
| 12:16 | <MikeSmith> | :p |
| 12:17 | <MikeSmith> | I'm told it should be fixed within the next 60 minutes or so |
| 12:28 | <MikeSmith> | for appcache, does the spec define what exceptions/error messages should be thrown after the app-specific maximum storage limit is reached? |
| 12:37 | <annevk> | zewt: my apologies for not reading your email correctly with respect to all "non-ASCII" as &#...; and removing all encoders |
| 12:37 | <annevk> | zewt: that is indeed not possible |
| 12:38 | <annevk> | zewt: e.g. passwords are known to rely on windows-1252 specifics |
| 12:46 | <MikeSmith> | hsivonen: any clue why http://validator.nu/?doc=http%3A%2F%2Fw3.org is defaulting to XHTML5 validation instead of XHTML1? |
| 12:47 | <MikeSmith> | maybe this is a regression I introduced with my changes to the presets |
| 12:55 | <zcorpan> | MikeSmith: i think it has done that for some time |
| 12:55 | <zcorpan> | MikeSmith: xml mode looks at just namespace, not doctype |
| 12:55 | <zcorpan> | MikeSmith: at first it defaulted to xhtml1 validation, iirc, but hsivonen changed it at some point |
| 13:09 | <MikeSmith> | zcorpan: OK |
| 13:38 | <smaug____> | "the end of the file being the four ways in which a line can end." |
| 13:38 | <smaug____> | I don't understand |
| 13:39 | <smaug____> | "four"? |
| 13:39 | <smaug____> | http://dev.w3.org/html5/eventsource/#event-stream-interpretation |
| 13:39 | <annevk> | CR, LF, CRLF, EOF |
| 13:43 | <smaug____> | annevk: well, the spec defines end of line ( cr lf / cr / lf ) |
| 13:43 | <smaug____> | but ok |
| 13:44 | <smaug____> | or no |
| 13:44 | <smaug____> | end of file is end of file |
| 13:45 | <annevk> | I think actually we changed that to not make EOF act as end of line for security |
| 13:45 | <annevk> | to ensure you knew it was not an accidental EOF |
| 13:49 | <zewt> | annevk: pretty much what I expected |
| 13:50 | <zewt> | annevk: (seems worth suggesting the impossible now and then, in case my assumptions are wrong) |
| 13:53 | <annevk> | zewt: yeah |
| 13:53 | <annevk> | zewt: I like to challenge to establishment |
| 13:53 | <annevk> | the* |
| 13:54 | <zewt> | down with the man |
| 13:54 | <zewt> | or something |
| 13:54 | <gsnedders> | Is there anything that gives unserializable DOMs, or is it merely implicit from the parsing algorithm? |
| 13:54 | gsnedders | wonders how to work that out |
| 13:55 | <annevk> | setAttribute("xmlns", "hahahaha") |
| 13:55 | <smaug____> | gsnedders: unserialized DOM? |
| 13:55 | <smaug____> | er |
| 13:55 | <smaug____> | serializable |
| 13:56 | <gsnedders> | smaug____: a DOM that cannot be serialized as HTML. |
| 13:56 | <smaug____> | but yeah some xmlns tricks may do it, I think |
| 13:56 | <gsnedders> | I meant a list of what is unseriailizable, not if there was anything, duh. |
| 13:58 | <annevk> | "Serializing XHTML fragments" has a list |
| 13:59 | <annevk> | not sure if that list is complete though, despite it claiming it is |
| 14:00 | <annevk> | oh maybe it is correct, it says "a node" rather than Attr/Element |
| 14:00 | <annevk> | kind of vague |
| 14:04 | <annevk> | smaug____: so at the end of that server-sent events section it says this |
| 14:04 | <annevk> | smaug____: "Once the end of the file is reached, any pending data must be discarded. (If the file ends in the middle of an event, before the final empty line, the incomplete event is not dispatched.)" |
| 14:04 | <annevk> | smaug____: I think it still saying that bit about four and such is an oversight |
| 14:05 | <annevk> | smaug____: I'll file a bug |
| 14:05 | <smaug____> | thanks |
| 14:08 | <annevk> | smaug____: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16866 |
| 14:11 | <smaug____> | what is Opera's UA string |
| 14:11 | <smaug____> | Opera/9.80 ...Version/11.62 |
| 14:11 | <smaug____> | o_O |
| 14:12 | <wilhelm> | 10 is a difficult number. |
| 14:12 | <annevk> | it used to be beautifully short, then someone fucked it up |
| 14:12 | <wilhelm> | Or, it used to be. |
| 14:14 | <gsnedders> | Given we have to fight not to get bogusly UA sniffed on Google and FB, yet alone the long tail, breaking where we do get UA sniffed correctly is probably a battle too far… |
| 14:14 | <smaug____> | UA strings are hard |
| 14:15 | <gsnedders> | Hint: Opera Mobile 12 works fine with the version of m.facebook.com that iOS/Android's browsers get. |
| 14:15 | <gsnedders> | Maybe all browsers should just standardize on one UA string and be done with it. |
| 14:16 | <gsnedders> | Kill UA sniffing overnight. |
| 14:16 | <zewt> | gsnedders: you won't change the UA string, so why would anybody else :) |
| 14:17 | <zewt> | User-Agent: transistors |
| 14:17 | <annevk> | might as well remove the header then |
| 14:20 | <gsnedders> | annevk: That would break too much. Going for something that looks like some current browser wouldn't. |
| 14:25 | <gsnedders> | jgraham: Know of anyone doing anything to constants.py, or planning on doing so? |
| 14:25 | gsnedders | has huge unicode-cleanup patch |
| 15:18 | <jgraham> | gsnedders: No |
| 15:44 | <jonnybarnes> | So I was looking at the HTML spec on how to use cite with blockquote |
| 15:45 | <jonnybarnes> | and in the first example it gives with a figure element containing a blockquote and figcaption |
| 15:45 | <jonnybarnes> | the figcaption has </cite> tag that isnt closing an open <cite> tag |
| 15:45 | <jonnybarnes> | surely this is wrong? |
| 15:46 | <MikeSmith> | jonnybarnes: yeah it's wrong if it doesn't have a cite start tag |
| 15:46 | <jonnybarnes> | relevent section: http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#dom-quote-cite |
| 15:47 | <jonnybarnes> | MikeSmith: who's job is it to fix the spec then? I have no idea how this works |
| 15:47 | <MikeSmith> | jonnybarnes: file a bug |
| 15:48 | <MikeSmith> | http://w3.org/brief/MjA2 |
| 15:49 | <jonnybarnes> | can I post a bug about the whatwg spec to the w3? |
| 15:49 | <annevk> | yes |
| 15:49 | <smaug____> | hrm, implementing xhr.timeout broke some sites :( |
| 15:49 | <annevk> | W3C and WHATWG share some infrastructure |
| 15:50 | <MikeSmith> | W3C and WHATWG are blood brothers |
| 15:50 | <annevk> | smaug____: Microsoft's implementation? |
| 15:50 | <annevk> | smaug____: or people extending XHR themselves? |
| 15:50 | <smaug____> | annevk: I mean Gecko's implementation |
| 15:51 | <annevk> | smaug____: sure, I'm wondering why |
| 15:51 | <smaug____> | some scripts expect that timeout can be used with sync |
| 15:51 | <smaug____> | http://code.google.com/p/ext-basex/issues/detail?id=7 |
| 15:52 | <smaug____> | but let's see how common this is |
| 15:52 | <jonnybarnes> | Looks like there's already a bug been opened for it |
| 15:52 | <smaug____> | I'd really like to keep all the new features for async only |
| 15:53 | <annevk> | the way people work around it is by not using timeout :/ |
| 15:53 | <zewt> | doesn't make sense at all to fail outright in that case ... |
| 15:53 | <annevk> | with all those libraries nobody has any idea anymore what they're actually doing |
| 15:53 | <zewt> | at most it should ignore it |
| 15:54 | <annevk> | zewt: that's not consistent with the API |
| 15:54 | <zewt> | then the API is wrong, IMO |
| 15:54 | <annevk> | okay |
| 15:54 | <smaug____> | zewt: what API is wrong? |
| 15:54 | <zewt> | if you have an API foo(a, {b: 1}), and old versions of the API don't know about 'b', it doesn't make sense for new versions which do support it to start failing |
| 15:54 | <smaug____> | the JS script library API, sure |
| 15:54 | <zewt> | that was a crappy explanation of what I'm thinking |
| 15:55 | <zewt> | if foo(a, {b:1}) works in browser 1.0, which doesn't know about 'b' (and therefore ignores it entirely), it doesn't make much sense for browser 2.0, which now supports 'b' but only in certain circumstances, to start failing where it used to work |
| 15:56 | <smaug____> | you can't make that kinds of API |
| 15:56 | <zewt> | what? |
| 15:56 | <smaug____> | we've seen plenty of problems when adding support for new APIs |
| 15:57 | <smaug____> | whenever a new property is added to any form control element, some site breaks |
| 15:57 | <zewt> | if FF used to not support timeout at all, and people were specifying timeouts (perhaps for other browsers), you can't make timeout suddenly start failing--that's basic backwards-compat |
| 15:57 | <zewt> | ignoring it when it's not allowed doesn't have that problem |
| 15:58 | <zewt> | (i really don't understand why timeout wouldn't be allowed with sync, though--seems to me that's the case where you *really* need it) |
| 15:59 | <smaug____> | we don't want to make sync more useful in any case |
| 15:59 | <smaug____> | I have the plan to remove sync XHR in window context |
| 15:59 | <smaug____> | may take several years |
| 16:00 | <zewt> | i wouldn't put money on that ever happening, heh |
| 16:20 | <dglazkov> | good morning, Whatwg! |
| 16:21 | <Ms2ger> | Bonsoir |
| 17:15 | <Ms2ger> | gsnedders, I know someone who's doing something with constants.py |
| 18:30 | <annevk> | "By this estimate, most of the translation on the planet is now done by Google Translate. (We can’t speak for the galaxy; Douglas Adams’s “Babel fish” probably has us beat there.)" :) |
| 18:51 | <zewt> | special thanks to google for crippling the translate api |
| 18:52 | <zewt> | making clear a lesson i thought was obvious from the start: you can never *really* depend on any free web api, no matter who the provider is |
| 18:53 | <zewt> | apparently, a good html templating system for python simply doesn't exist |
| 18:54 | <annevk> | yeah I'm a bit scared with such APIs starting to be used for platform features |
| 18:54 | <annevk> | e.g. for geolocation |
| 18:54 | <annevk> | they also wanted to expose geocoding as a platform API |
| 18:54 | <annevk> | and voice web services are under discussion |
| 18:55 | <annevk> | not really sure if it's a good idea to ingrain those kind of things |
| 18:55 | <zewt> | it doesn't make much sense to me to basically bake web APIs into the platform as platform APIs; if it's available as a web API, and the consequences of that are OK for you, then just use the web API |
| 18:56 | <zewt> | (not sure about the particulars of what you're referring to) |
| 19:06 | <annevk> | I agree with you |
| 19:06 | <annevk> | I'm not really sure why it ever went there, convenience I guess |
| 19:06 | <zewt> | i'd find it an inconvenience (since it's just an extra layer between me and the real API) |
| 19:07 | <annevk> | maybe the idea was to do it all in a single request |
| 19:07 | <annevk> | for geolocation anyway |
| 19:08 | <annevk> | because getting your location requires wi-fi data etc. |
| 19:08 | <zewt> | well getting your location from system data is a different thing |
| 19:08 | <annevk> | so if the service took that kind of data and gave back the place name, that'd be nice |
| 19:08 | <annevk> | well it's system data combined with a network request |
| 19:08 | <zewt> | i mean, you can't get wifi/gps/cell tower location data from a web API; you need a system API |
| 19:09 | <annevk> | system data you probably do not want to expose to the web |
| 19:09 | <zewt> | sure you do (in the appropriately abstracted form) |
| 19:12 | <zewt> | i guess the related risk is when the geolocation API uses a geoip web service as a data point, it falls over if that service goes away ... but I guess that's not really a problem with the API itself (since it's not specific to it), and it's the browser's risk |
| 19:13 | <zewt> | (which they're free to take) |
| 19:13 | <annevk> | if a browser doesn't use a web service for that it cannot guarantee good quality |
| 19:14 | <zewt> | mobile can, far better than a web service |
| 19:14 | <annevk> | so in effect web services are now a required part of browsers |
| 19:14 | <zewt> | desktops generally have no options other than geoip |
| 19:14 | <annevk> | even on mobile you use wi-fi etc. to determine the position much much faster |
| 19:18 | <zewt> | not really required, since it's not actually a required API--you can always just refuse all geo API requests |
| 19:18 | <zewt> | if it was something more fundamental that would break everything if it didn't work, then yeah, that'd be a real problem |
| 19:18 | <annevk> | if you want market share it's required |
| 19:19 | <zewt> | nobody on desktops cares about geolocation |
| 19:19 | <annevk> | says who? |
| 19:19 | <zewt> | who says people do? |
| 19:19 | <zewt> | on mobile falling back on gps is typically fine (and if you're on mobile and that's too slow, you probably have to solve that at a platform level anyway) |
| 19:19 | <annevk> | dunno, but I've certainly used it |
| 19:21 | <zewt> | i seriously doubt lacking the geolocation API on a desktop browser would have a real impact on market share |
| 19:21 | <zewt> | besides, on most desktops all you're likely to get is geoip anyway, and people do that server-side whether or not you have the geo api |
| 19:22 | <zewt> | dunno if desktop browsers do wifi lookups on laptops |
| 19:33 | <Philip`> | zewt: Opera does wifi lookup on my laptop |
| 19:33 | <Philip`> | (or at least it did when it first supported) |
| 19:33 | <Philip`> | *was |
| 20:42 | <othermaciej> | MikeSmith: are you around? |
| 20:42 | <MikeSmith> | yeah |
| 20:42 | <othermaciej> | MikeSmith: I need help with two things |
| 20:43 | <othermaciej> | maybe 3 |
| 20:43 | <othermaciej> | 1) I would like to change the description text for the whatwg cg, not sure how to do it |
| 20:43 | <othermaciej> | the text that currently says "Community group around the HTML living standard and its related Web Application technology specifications." |
| 20:43 | <othermaciej> | 2) I would like to change the CG page to point people to whatwg⊙wo as the public list for the CG instead of public-whatwg⊙wo |
| 20:44 | <othermaciej> | 3) My W3C CVS access seems to be busted, I could use tech support or something |
| 20:44 | <othermaciej> | #3 is a bit lower priority |
| 20:47 | <heycam> | annevk, just been working on other things the last week, I'll get to it soon sorry |
| 20:47 | <heycam> | *last couple of weeks |
| 20:50 | <MikeSmith> | othermaciej: gimme 30 minutes or so |
| 20:52 | <othermaciej> | MikeSmith: ok! |
| 20:56 | <jgraham> | othermaciej: CVS acces being busted is supposed to be a hint |
| 20:57 | <jgraham> | :p |
| 20:57 | <othermaciej> | a hint about what? that I'm fired from being a volunteer? |
| 20:57 | <Ms2ger> | Use HG |
| 21:36 | <Hixie> | roc: is https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html uncontroversial now? or is there some other proposal? i'm having trouble figuring out which audio proposal has the bulk of browsers behind it these days |
| 21:42 | <TabAtkins_> | Hixie: To the best of my knowledge, yes, that's the one we're going with now. But roc should probably answer just to be sure. |
| 21:44 | <Hixie> | right... i seem to recall it was not always a given, which is why i'm questioning |
| 21:46 | <Hixie> | is anyone working on MIDI on the Web? |
| 21:51 | <smaug____> | well, mediastreams will be there too |
| 21:52 | <smaug____> | web audio has many issues still |
| 21:52 | <smaug____> | but the wg lists both web audio and media stream processing API as its proposals |
| 21:53 | <smaug____> | Hixie: I believe roc is about the land the implementation for Mediastream processing API real soon |
| 21:53 | <Hixie> | smaug____: are they mutually exclusive or are they complementary? |
| 21:53 | <roc> | Web Audio has the Webkit browsers behind it |
| 21:54 | <smaug____> | my assumption has been that they will be merged somehow |
| 21:54 | <smaug____> | and drop some features from Web Audio |
| 21:54 | <Hixie> | so mutually exclusive? |
| 21:54 | <Hixie> | or rather, overlapping? |
| 21:54 | <smaug____> | I'd say overlapping |
| 21:55 | <Hixie> | k |
| 21:55 | <smaug____> | at least partially |
| 21:56 | <roc> | Web Audio may have too much momentum behind it to change or drop any of it |
| 21:56 | <smaug____> | it isn't even spec'ed properly yet |
| 21:56 | <smaug____> | so sure there can be changes |
| 21:57 | <roc> | changes that don't break compatibility, sure |
| 21:57 | <Hixie> | is there momentum beyond a single implementation? |
| 21:57 | <roc> | no |
| 21:57 | <Hixie> | then it doesn't have too much momentum |
| 21:57 | <roc> | Google's evangelized it and developers are using it |
| 21:58 | <smaug____> | for Chrome-only games, I assume |
| 21:59 | <Hixie> | it might have too much momentum for the exact names used in webkit's implementation to have incompatible definitions, but one can always change the names |
| 21:59 | <roc> | currently, although Safari will support it too |
| 21:59 | <smaug____> | but since web audio API is currently still mainthread only API, it really doesn't work well enough |
| 22:00 | <roc> | Google's evangelists are out there telling everyone this is how Web audio is going to be done (the "Web Audio" name was brilliant), and people are building based on that assumption |
| 22:00 | <roc> | I can't fight that |
| 22:00 | <Hixie> | roc: sure you can. if it's not implemented, it doesn't matter what people said. |
| 22:00 | <Hixie> | shipped code wins every time |
| 22:01 | <smaug____> | well, I don't still buy it. Google has tried similar thing for example with speech stuff, and it didn't work. |
| 22:01 | <Hixie> | exactly |
| 22:01 | <roc> | but devs are actually using Web Audio |
| 22:01 | <Hixie> | so? |
| 22:02 | <roc> | so I don't think telling them "no, use this instead for Firefox" is going to get a good reception |
| 22:03 | <jernoble> | smaug____: "mainthread only API"? what do you mean? |
| 22:03 | <Hixie> | so don't say that. say "no, use this instead for all browsers, it's what will be implemented by everyone" |
| 22:03 | <roc> | Web Audio isn't terribly bad, or obnoxious |
| 22:03 | <Hixie> | and make sure that there is in fact a single api used by everyone |
| 22:03 | <zewt> | jernoble: realtime audio (or semi-realtime, eg. games) needs to be low-latency; that wants to be able to feed audio in a thread to avoid underruns |
| 22:03 | <roc> | Hixie: I can't say that while no-one but Mozilla (and maybe Opera) have agreed to implement it |
| 22:04 | <smaug____> | jernoble: Mediastream processing API is heavily multithreaded (using workers), Web Audio API isn't |
| 22:04 | <Hixie> | roc: so change it so that others will agree to implement it |
| 22:04 | <jernoble> | zewt: yes, and the audio processing runs off the main thread, specifically to meet those goals. |
| 22:04 | <roc> | smaug____, zewt: Web Audio has off-main-thread builtin processing nodes |
| 22:04 | <smaug____> | roc: not for JS stuff |
| 22:04 | <jernoble> | zewt: it's only the setup of the scene graph that occurs on the main thred. |
| 22:04 | <jernoble> | *thread |
| 22:04 | <roc> | smaug____, zewt: and Chris Rogers agrees that Workers should be added to Web AUdio somehow |
| 22:05 | <roc> | Hixie: Chris Rogers and others don't object to MediaStream Processing per se, their argument is that Web Audio is here, people are using it, and it's good enough so why do anything else |
| 22:05 | <smaug____> | sure, I know what. But it isn't there. I assume if you add support for multithreading, web audio api will look a lot more like mediastream processing |
| 22:05 | <zewt> | <smaug____> but since web audio API is currently still mainthread only API, it really doesn't work well enough |
| 22:05 | <smaug____> | which is why I think the APIs will merge somehow |
| 22:06 | <Hixie> | roc: "why do anything else" would be "because it's not getting implemented in more than webkit" |
| 22:06 | <roc> | heh |
| 22:06 | <roc> | well |
| 22:07 | <roc> | that argument hasn't worked so far :-) |
| 22:07 | <Hixie> | sounds like the group is dysfunctional if there are multiple specs, implementations won't agree to implement the same one, and nobody is willing to compromise to come up with a common spec |
| 22:08 | <roc> | so |
| 22:08 | <roc> | there are two main differences between the current specs |
| 22:08 | <roc> | one is that Web Audio defines a big set of builtin-nodes and expects you to use them because their JS support is weak |
| 22:08 | <roc> | while MSP focuses on JS workers and doesn't define a big set of built-in nodes |
| 22:09 | <roc> | that's easy to compromise on --- just merge. I've already agreed to do that. |
| 22:09 | <roc> | the other big difference is that Web Audio is based on an AudioNode graph and MSP is based on MediaStreams |
| 22:09 | <roc> | there you can't really compromise |
| 22:10 | <roc> | that's the problem |
| 22:11 | <smaug____> | (one problem is that the builtin-nodes in Web Audio API really aren't spec'ed well enough. They are in the level "this node modifies data somehow") |
| 22:11 | <roc> | that can be fixed, and Chris Rogers has agreed that it should be fixed |
| 22:12 | <smaug____> | sure |
| 22:12 | <smaug____> | just hasn't happened yet, and someone from Google almost seriously suggested that webkit's implementation should be the reference implementation for nodes |
| 22:13 | <roc> | several people have suggested that, but just because they don't understand Web standards. Chris doesn't hold to that. |
| 22:14 | <roc> | What I really want is for Microsoft to take a position. |
| 22:14 | <roc> | But for some reason they won't. |
| 22:14 | <smaug____> | I just think we can't really live without something like MSP |
| 22:14 | <Hixie> | that would probably break the deadlock, it's true |
| 22:15 | <smaug____> | but we can live without web audio api |
| 22:15 | <Hixie> | maybe they're just stuck, confused about whether to screw over their arch enemies apple and google, or their arch enemies opera and mozilla ;-) |
| 22:17 | <roc> | I think it's pretty obvious who their real arch-enemies are :-) |
| 22:28 | <Hixie> | themselves? :-) |
| 22:32 | <cbright6062> | hmmmmm |
| 23:11 | <JVoracek> |