| 11:43 | <smaug____> | Hmm, does some spec define DataChannel |
| 11:45 | <Ms2ger> | Sounds like WebRTC? |
| 11:46 | <smaug____> | yeah, something like that |
| 11:46 | <smaug____> | but that could in fact be gecko thingie |
| 11:46 | <smaug____> | it is hard to follow what is happening in webrtc world |
| 11:46 | <smaug____> | I'm not sure the spec has been reviewed too well |
| 11:48 | <annevk> | http://dev.w3.org/2011/webrtc/editor/webrtc.html |
| 11:48 | annevk | looks |
| 11:48 | <Ms2ger> | Ah, annevk is going to review? Excellent :) |
| 11:49 | <annevk> | haha doubt it, looks big |
| 11:49 | <annevk> | looks like a severe case of ReSpec |
| 11:52 | <smaug____> | problem is also that implementations seem to be ahead of the spec |
| 11:55 | <annevk> | http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCPeerConnection o_O |
| 11:55 | <annevk> | smaug____: yeah I saw some web sites using it already |
| 11:58 | <annevk> | ReSpec really makes this spec unreadable |
| 15:48 | GPHemsley | wonders, in a way not intended to be rude, where TabAtkins learned his English. |
| 15:49 | GPHemsley | also still thinks that the CSS Counter Styles "width" property should not include the negative sign. |
| 15:49 | <GPHemsley> | s/property/descriptor/ |
| 16:39 | <TabAtkins> | GPHemsley: From America? |
| 16:39 | <TabAtkins> | I've got a few pet peeves that make me write things in a particular way (fucking latin-based irregular plurals), but otherwise speak normal English as far as I know. |
| 16:41 | <miketaylr> | not just America, but America America (Texas) |
| 16:41 | <TabAtkins> | Real America, natch. |
| 16:41 | <TabAtkins> | Texas: The America of America http://smbc.myshopify.com/products/texas-shirt |
| 16:42 | <GPHemsley> | I can't say things like "We’d appreciate people to review this draft carefully" |
| 16:42 | <TabAtkins> | Hm, yeah, that's actually slightly awkward. |
| 16:42 | <GPHemsley> | though this is just the latest of many recent examples of people using infinitive in strange ways |
| 16:43 | <TabAtkins> | Which probably means a grammatical shift in english. |
| 16:43 | <GPHemsley> | Though I think they're often native French speakers |
| 16:43 | <GPHemsley> | I wish I had more examples to furnish |
| 16:45 | <astearns> | TabAtkins: are there any CSS names, keywords, etc. that use the plurals that you detest? |
| 16:45 | <TabAtkins> | Not keywords or property names or anything. |
| 16:45 | <TabAtkins> | I really just hate axes as a plural of axis. |
| 16:46 | <GPHemsley> | Would you prefer axises? |
| 16:46 | <TabAtkins> | Yes, and I used that in my specs until fantasai did a search-and-replace on me. |
| 16:46 | <GPHemsley> | I mean, I prefer appendixes over appendices, for example |
| 16:46 | <GPHemsley> | but axises seems a little odd to me |
| 16:47 | <astearns> | I just have a hard time pronouncing 'axises' - once I start, I keep putting additional sibilants on the end |
| 16:47 | <TabAtkins> | I get that, and it's probably part of why the irregular plural became popular (also, 1900s grammarians had a massive language-boner for Latin). |
| 16:48 | <GPHemsley> | :) |
| 16:48 | <TabAtkins> | But the double-sibilant pattern appears all over English, and we deal. |
| 16:48 | <TabAtkins> | For example, denoting ownership of anything ending in an s. |
| 16:48 | <GPHemsley> | axis's |
| 16:49 | <TabAtkins> | The Johnsons' house (the house belonging to Mr. and Mrs. Johnsons). |
| 16:49 | <TabAtkins> | We spell it without the s, but still pronounce the implied s there. |
| 16:49 | <GPHemsley> | Who has a last name of Johnsons? >_> |
| 16:49 | <astearns> | misses's |
| 16:49 | <TabAtkins> | GPHemsley: They exist! |
| 16:49 | <GPHemsley> | OK, Mr. Atkin |
| 16:50 | <GPHemsley> | But I'm totally down with data as singular |
| 16:51 | <TabAtkins> | Yeah, sure, that's become a mass noun (and, though I'm not certain, I think it may even have started as data, and then back-formated into datum for a single piece?) |
| 16:51 | <GPHemsley> | Unless you're actually talking about handful of data points (which you rarely are), I can't take you seriously if you use data as plural at this point |
| 16:51 | <GPHemsley> | I don't recall |
| 16:52 | <GPHemsley> | Here's a question: None/Neither – singular or plural? |
| 16:52 | <GPHemsley> | I guess we're only talking agreement at this point |
| 16:53 | <TabAtkins> | I think I make it plural? |
| 16:53 | <miketaylr> | both wfm |
| 16:53 | <TabAtkins> | "Neither have done something" |
| 16:53 | <miketaylr> | "neither is correct" & "neither are correct" |
| 16:53 | <GPHemsley> | yeah, I agree |
| 16:53 | <TabAtkins> | But I'd accept, and probably say at times, "has" there. |
| 16:53 | <miketaylr> | "none is correct" feels weird though |
| 16:53 | <GPHemsley> | I think that particular example (with "something") is an odd construct |
| 16:58 | <Hixie_> | holy crap, the WebRTC API is a disaster now |
| 16:59 | <Hixie_> | it's gone from an API where you could make a video conferencing system in a dozen lines of HTML and an off-the-shelf server, to something where even I have no idea what's going on. |
| 17:01 | <TabAtkins> | That's what happens when an API group goes off to its own WG and nobody follows them. |
| 17:41 | <Hixie_> | TabAtkins_: i don't understand your e-mail. what wouldn't work? |
| 17:41 | <Hixie_> | TabAtkins_: you set the styles for a vertical control and for a horizontal control using separate pseudos, and then you set it to horizontal or vertical by setting the dimensions accordingly. |
| 17:41 | <TabAtkins> | Give me an example of some theoretical syntax for how to select, in CSS, whether an element is mostly tall or mostly squat, and style it accordingly. |
| 17:42 | <TabAtkins> | And how are those pseudos assigned? Magically? |
| 17:42 | <Hixie_> | "assigned"? |
| 17:42 | <TabAtkins> | That means they're irrevocably magic, and can't be done with Web Components. :/ |
| 17:42 | <Hixie_> | the element has the vertical pseudos if it's vertical and the horizontal ones if it's horizontal |
| 17:43 | <Hixie_> | well once you have web components, there's no problem at all. you just bind the appropriate component for what you want. |
| 17:43 | <TabAtkins> | How? |
| 17:44 | <Hixie_> | however you bind components |
| 17:44 | <TabAtkins> | I mean, how do you preferentially bind the vertical version when it's tall? |
| 17:44 | <TabAtkins> | Or are you saying that you just choose which one you want? |
| 17:44 | <Hixie_> | the author just choses the one the author wants |
| 17:45 | <TabAtkins> | All right, cool. The attribute-based approach is doing the same thing, just communicating in the more natural HTML way. |
| 17:45 | <Hixie_> | the attribute-based approach is <font> all over again. let's not go there. |
| 17:46 | <TabAtkins> | Until we get decorators, it's the only non-magic way. And it transitions cleanly into the decorator-based way. |
| 17:46 | <Hixie_> | i have neither a problem with magic, nor a problem with not solving it for now :-) |
| 17:47 | <TabAtkins> | I have problems with both. Thus, the disconnect. |
| 17:47 | <Hixie_> | i do have a problem with presentational attributes |
| 18:11 | <Hixie_> | are we really just redefining ISO-8859-1? |
| 19:17 | <annevk> | someone managed to review WebRTC in the interim? |
| 19:19 | <annevk> | ooh I see, Hixie_ found out it's a clusterfuck too |
| 19:21 | <annevk> | Hixie_: we're defining iso-8859-1 as a label |
| 19:21 | <annevk> | Hixie_: of windows-1252 |
| 19:23 | <Hixie_> | annevk: i'm not one to shy away from arrogantly displacing other standards bodies' work, obviously, but isn't that a bit of a big leap even for us? |
| 19:24 | <Hixie_> | annevk: i mean, isn't ISO-8859 used elsewhere than the web? |
| 19:24 | <Hixie_> | annevk: or is it really treated as win1252 everywhere |
| 19:25 | <annevk> | is HTML parsed as per the HTML Standard everywhere? |
| 19:25 | <annevk> | I'd say the end goal is definitely that everyone gets the same encoding library |
| 19:25 | <Hixie_> | no, it wasn't parsed per the HTML Standard anywhere. But we didn't make things that were previously valid HTML parse differently, and we did study pretty much every major implementation. |
| 19:26 | <Hixie_> | and HTML is pretty specific to the Web |
| 19:26 | <annevk> | Wasn't <title/test/ valid HTML? |
| 19:26 | <SimonSapin> | Hixie_: that why I named by implementation "python-webencodings" rather than python-encodings. |
| 19:26 | <Hixie_> | annevk: not per HTML1 |
| 19:26 | <SimonSapin> | my* implementation |
| 19:26 | <annevk> | hmm |
| 19:26 | <Hixie_> | annevk: it briefly was with HTML4, but that was never widely implemented except by the validator |
| 19:27 | <Hixie_> | but even that was changed at some point |
| 19:27 | <annevk> | Hixie_: I could define iso-8859-1 as an encoding, but you could never get to it from web content, seems kinda meaningless |
| 19:29 | <Hixie_> | annevk: what's wrong with what we had before, where ISO-8859-1 was an encoding defined by ISO, but there was no way to refer to its decoder from Web content, because its label caused win1252 decoding, except that it was non-conforming to use bytes that would get processed "wrongly"? |
| 19:29 | <Hixie_> | that would at least mean that people who later reuse the text in iso-8859-1-true environments don't get screwed accidentally |
| 19:29 | <Hixie_> | if they use a validator, anyway |
| 19:30 | <annevk> | Given that there are all kinds of pitfalls with non-utf-8 encodings, it didn't seem worth distinguishing those cases. |
| 19:30 | <Hixie_> | anyway, i have to go afk for a bit. i'm just a bit worried that we're doing something with knock-on effects we haven't fully considered. your call, though, obviously. |
| 19:30 | <Hixie_> | ttyl |
| 19:31 | <annevk> | My take on this has been is that we need to define the legacy, but want everyone on board the utf-8 rocket. |
| 19:32 | <annevk> | So spending much time with weird error conditions in the legacy, while using it is wrong anyway is not worth it. Then on top of that, having to go through numerous specifications that do not define all the details you need to know to implement legacy encodings, was something we could improve on. |
| 19:43 | <annevk> | Hmm |
| 19:43 | <annevk> | https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/is |
| 19:43 | <annevk> | So, ==, ===, and now Object.is |
| 19:43 | <annevk> | for -0 and NaN |
| 19:59 | <jsbell> | annevk: Don't forget the internal SameValueZero for Maps/Sets |
| 20:00 | <annevk> | Maybe wycats is right and I should attend one of those meetings for fun times |
| 20:00 | <jsbell> | Where SameValueZero(NaN, NaN) but also SameValueZero(0, -0) |
| 20:00 | <annevk> | wow |
| 20:00 | <annevk> | that's brilliant |
| 20:01 | <annevk> | should introduce ==== for Object.is and ===== for that one |
| 20:02 | <annevk> | I wonder if companies will start using this as an interview question. "Tell me what you know about comparators in JavaScript and their negative zero and NaN handling." |
| 20:18 | <TabAtkins> | annevk: Object.is was introduced pretty much solely to avoid ====. |
| 20:21 | <miketaylr> | because fourquals doesn't sound quite as nice as threequals |
| 20:22 | <TabAtkins> | I pronounce === as "equals" and == as "kinda like". |
| 21:31 | <annevk> | Hixie_: http://html5.org/r/7782 looks most excellent |
| 21:50 | <Hixie_> | annevk: cool. btw, i hate to suggest this now that i use them all, but we should consider renaming these algorithms not to sound so similar |
| 21:50 | <Hixie_> | annevk: there's so going to be confusion between "decode", "utf-8 decode", and "utf-8 decoder" |
| 21:51 | <annevk> | I was kinda hoping only the JavaScript API would hook into the latter, but I think that may have been a false hope |
| 21:52 | <annevk> | Hixie_: If I introduce "bomless utf-8 decode" as an alias for the latter, would that help? |
| 21:53 | <Hixie_> | well the last one doesn't really exist, it's just the "decoder" for "utf-8" (which BTW I spelt "UTF-8" in the HTML spec, since it's an acronym) |
| 21:53 | <Hixie_> | it's the first two that are more confusing |
| 21:53 | <annevk> | (it's also an exposed name in the DOM, which is why it's utf-8) |
| 21:54 | <annevk> | I see you do use "utf-8 decoder" specifically |
| 21:54 | <annevk> | I thought all the other entry points would use "decode" |
| 21:54 | <Hixie_> | something like "generic decoder" or "generic byte-to-string converter algorithm" instead of "decode" |
| 21:54 | <Hixie_> | might distinguish it from the actual decoders |
| 21:55 | <Hixie_> | and something like "BOM-stripping UTF-8 byte-to-character stream conversion algorithm" for utf-8 decode, similarly :-) |
| 21:55 | <Hixie_> | anyway |
| 21:55 | <SimonSapin> | renaming to avoid "decode" and "decoder" being two different things: yes please |
| 21:55 | <Hixie_> | i'm fine if you leave them as is |
| 21:55 | <annevk> | so you only use "decoder" as a generic for form stuff |
| 21:55 | <Hixie_> | less work for me |
| 21:56 | <annevk> | maybe "resource decode" and "utf-8 resource decode"? |
| 21:57 | <annevk> | I'll think about it some more |
| 23:31 | <Hixie_> | heh, unicode tr9 (updated) step BD9's algorithm uses a "COMEFROM" operator in the third bullet |
| 23:37 | <Hixie_> | unicode will have at least three separate characters that are trains. |
| 23:37 | <Hixie_> | now i like trains as much as the next guy, probably more, but... really? |