| 00:44 | <zewt> | nothing quite as much fun as discussions of the general form "i just started reading web specs yesterday, and you're doing everything wrong" |
| 00:46 | <jacobolus> | is this a reasonable place to mention a typo in http://www.w3.org/TR/css-variables/#custom-property ? in the example, "main-color" should be "var-main-color" and "accent-color" should be "var-accent-color" |
| 00:46 | <jacobolus> | TabAtkins: ↑ |
| 02:26 | <rillian> | TabAtkins: have you looked at the new CSS selectors in the WebVTT spec? http://dev.w3.org/html5/webvtt/#css-extensions |
| 02:27 | <rillian> | I'd like to get a sanity check on the design before we start implementing in Firefox. |
| 04:08 | <annevk> | I updated http://quuz.org/webvtt/ a bit. |
| 04:44 | <TabAtkins> | rillian: Yeah, they're kosher. I helped design it early, and the pseudo-classes are already in Selectors 4. |
| 04:44 | <annevk> | TabAtkins: so you can't do something like ::before { content: voice } at the moment which seems sad |
| 04:45 | <TabAtkins> | annevk: Hm, interesting. |
| 04:45 | <annevk> | TabAtkins: and the restrictions on properties might be arbitrary? |
| 04:45 | <annevk> | TabAtkins: and if this is going to be implemented in terms of components long term, how will that affect this design and usage of pseudo-elements? |
| 04:46 | <TabAtkins> | I don't know if captions are meant to be addressed in components. |
| 04:46 | <TabAtkins> | And I'm fine with custom things for built-in stuff, even if they *could* be done less conveniently with components. |
| 04:47 | <TabAtkins> | annevk: There's a voice attribute, so if we support ::cue(::before)), you can just do "content: attr(voice);" |
| 04:48 | <annevk> | TabAtkins: if components are the way to explain elements, they need to be able to explain captions I think |
| 04:48 | <TabAtkins> | The property restrictions may be arbitrary. It's supposed to be the properties that you can put on ::first-line |
| 04:48 | <TabAtkins> | Plus maybe something else? |
| 04:48 | <annevk> | As part of the "no magic" strategy... |
| 04:49 | <TabAtkins> | annevk: Maybe? They obviously need some ability to take a selector and apply it over a subtree. |
| 04:49 | <TabAtkins> | Maybe Components level 2. ^_^ |
| 04:49 | <TabAtkins> | (Right now you can only surface individual elements as pseudo-elements.) |
| 04:50 | <annevk> | I meant to look into that. Whether components had a way to let styles bleed through. It seems the answer is no? |
| 04:50 | <annevk> | Do they just inherit var-*? |
| 04:51 | <annevk> | Overall that sounds okayish I suppose. |
| 05:42 | <TabAtkins> | annevk: There's a switch you can set to let selectors match through, which defaults to false. |
| 05:43 | <TabAtkins> | There's another switch for inheritance, which defaults to true. |
| 05:43 | <TabAtkins> | And yes, it's expected that variables will be a major way to style them. |
| 05:43 | <TabAtkins> | But there is also a way to declare certain shadow elements as pseudo-elements on the component root. |
| 05:44 | <rillian> | TabAtkins: another thing we talked about is assigning automatic consistent colours to <v> nodes based on the attribute value |
| 05:44 | <rillian> | it would be nice if there were some way to do that with CSS |
| 05:46 | <TabAtkins> | That seems... hard. |
| 05:46 | <TabAtkins> | It's basically declarative randomness, no? |
| 05:53 | <annevk> | TabAtkins: yes |
| 05:53 | <annevk> | TabAtkins: you have a WebVTT file, which may be streaming, which has X different voices, which you want to allocate different colors so you can easily distinguish who is speaking (as alternative for the ::before thing) |
| 05:55 | <TabAtkins> | This doesn't have to be random, actually. Hmm. If you didn't care what the values were, perhaps a color hashing function, which takes an arbitrary input (like an attr(voice) value) and produces a color from it. |
| 05:55 | <TabAtkins> | This wouldn't guarantee the values were different, or far enough apart to be distinguishable, but it'd give you a good chance of it. |
| 05:56 | <TabAtkins> | Alternately, make it explicit. Create a list of values, and have the page consume them by associating them with a key. The value assigned to each key is stable for the page, and the order they're consumed is defined somehow. |
| 05:56 | <TabAtkins> | So you could define, say, 20 colors for voices. |
| 05:57 | <annevk> | TabAtkins: alternatively, you'd do it on a per-cue basis I suppose |
| 05:58 | <TabAtkins> | annevk: You want persistent colors for each voice across a video. |
| 05:58 | <annevk> | TabAtkins: upfront doesn't work for live-captioning |
| 05:58 | <annevk> | (not sure that will ever happen in practice in that way though :)) |
| 05:59 | <TabAtkins> | annevk: I meant that you declare a list of 20 appropriate colors up-front. CSS figures out which colors attach to which voice for you, first-come-first-serve. |
| 06:00 | <annevk> | Ah yeah. Combined with the hash table that works. |
| 06:01 | <annevk> | Does seem like a pie-in-the-sky feature a bit, but worth keeping in mind. |
| 06:02 | <TabAtkins> | Finding use-cases outside of WebVTT would help. |
| 06:05 | <annevk> | You could maybe generalize it to select the first value from this list of values based on a string, then forever associate that value with that string and remove it from the list. |
| 06:06 | <annevk> | And then do silly things with it. |
| 06:07 | <annevk> | Color table rows based on their sort key? |
| 06:08 | <annevk> | Should patent that. "New CSS-based feature to do silly things." |
| 06:15 | <rillian> | TabAtkins: it could even select from an ordered list of colours |
| 06:15 | <rillian> | oh, you said that |
| 06:20 | <TabAtkins> | annevk: Yeah, generalizing to arbitrary values is pretty obvious. |
| 06:20 | <TabAtkins> | And your example isn't too terrible. ^_^ |
| 06:20 | <annevk> | Make it so! |
| 06:20 | <TabAtkins> | Point is, sounds like a useful tool for a variety of disparate and somewhat interesting use-cases that are difficult to address otherwise. |
| 06:21 | <TabAtkins> | Ooooh, I wonder how much I can bodge this into a randomness feature. |
| 06:21 | <TabAtkins> | Because why force people to declare values when they don't have to? We can create some random functions, valid only in the list-declaring at-rule. |
| 06:22 | <TabAtkins> | This solves at least part of the "when do you evaluate?" problem with declarative randomness. |
| 06:22 | <MikeSmith> | does Chromium not support audio/mpeg? |
| 06:22 | <TabAtkins> | Like, let the list be capped with a random function, so it generates infinite values after your predefined ones. |
| 06:23 | <annevk> | TabAtkins: I think you might want "repeat" too, or random-from-list |
| 06:23 | <annevk> | but yeah |
| 06:24 | <annevk> | man, styling my website in random colors would be great |
| 06:25 | <TabAtkins> | Haha |
| 06:45 | <rillian> | MikeSmith: I believe it doesn't. MP3 is still a non-free format. |
| 06:45 | <MikeSmith> | rillian: ok |
| 09:36 | <annevk> | So where's hallvors? I'm getting pretty close to using Fetch in XMLHttpRequest to see what might break... |
| 09:36 | <annevk> | Also, I guess I want some feedback from Hixie and others. Maybe I should send email. |
| 10:15 | <darobin> | heh, "pretty dry reading" |
| 10:16 | <darobin> | annevk: "HTML Standard's fetch and potentially CORS-enabled fetch algorithms", -> potentially? |
| 10:16 | <darobin> | annevk: "and make provide a model" s/make// |
| 10:18 | <darobin> | annevk: "to fetch a resource or URL" what's the diff? |
| 10:19 | <darobin> | annevk: "Note: The block cookies flag is obsolete now." if so, then please either remove it or indicate why it's still in |
| 10:20 | <darobin> | annevk: "The element's node document. " -> The element's document node. maybe? |
| 10:22 | <Ms2ger> | darobin, no, "node document" is a well-defined term |
| 10:23 | <darobin> | ah, the DOM4 node document? |
| 10:23 | <darobin> | an indication that this is a term would help, I failed to parse the sentence on reading |
| 10:24 | <Ms2ger> | Hmm, yes, that should be a link |
| 10:24 | <Ms2ger> | Hrm |
| 10:24 | <Ms2ger> | Something is wrong with the preprocessing |
| 10:26 | <darobin> | a lot of terms seem to be getting style but no link, too |
| 10:27 | Ms2ger | looks what's up |
| 10:29 | <Ms2ger> | People complain about tar arguments, but ln sucks too |
| 10:29 | <darobin> | annevk: ["true" is a string, while true is a byte string. ] maybe that example would be clearer if you didn't use a common boolean term |
| 10:29 | <darobin> | Ms2ger: you don't say :) |
| 10:30 | <darobin> | annevk: "considers bytes in the range 0x41 to 0x5A to be a match for their corresponding byte in the range 0x61 to 0x7A." -> does this need to state that the reverse is true too? |
| 10:30 | <darobin> | annevk: "via data URL" -> URLs |
| 10:32 | <annevk> | darobin: so lots of thanks, will try to address these tomorrow |
| 10:33 | <annevk> | darobin: seems we're heading out for food |
| 10:33 | <darobin> | sure, I'll just keep dumping stuff in the logs |
| 10:33 | Ms2ger | messes with the xrefs in the meantime |
| 10:33 | <darobin> | mostly it seems editorial so fart |
| 10:33 | <darobin> | so *far* |
| 10:33 | <annevk> | :-) |
| 10:34 | <darobin> | annevk: "A arequest has an associated " -> request |
| 10:52 | <Ms2ger> | darobin, what was the potentially thing about? |
| 10:54 | <darobin> | Ms2ger: ah, I can parse that sentence better on re-reading it |
| 10:54 | <darobin> | it's "potentially-CORS-enabled" |
| 10:55 | <darobin> | on first read it seemed to say "this specification supplants (...) HTML Standard's fetch" and, you know, maybe, CORS-enabled fetch |
| 10:56 | <darobin> | I think the "potentially" is useless and would be better dropped |
| 10:56 | <Ms2ger> | Heh |
| 10:56 | <Ms2ger> | Well, that's the goal of this spec :) |
| 10:57 | <darobin> | yeah, which is why it should be clear and not "potential" :) |
| 10:58 | <darobin> | hmmm, most of these algorithms I can't usefully review without writing the code to match |
| 10:59 | darobin | food |
| 10:59 | <Ms2ger> | Anyway, xrefs and "a arequest" should be fixed |
| 11:04 | <marcosc> | slightlyoff: can you help us out quickly with some Futures spec terminoloty? https://github.com/sysapps/web-alarms/issues/29#issuecomment-18271329 |
| 11:05 | <marcosc> | or terminology :) |
| 11:27 | <darobin> | I love the mention that using cookies is a fingerprinting vector :) |
| 11:30 | <Ms2ger> | Keep your fingers off my cookies |
| 11:30 | <Ms2ger> | Cookies are delicious delicacies |
| 11:47 | <darobin> | annevk: some more notes for when you come back https://gist.github.com/anonymous/fe3aa4243ae7b4f68376 |
| 11:47 | <darobin> | I guess that for such editorial stuff I could have made a pull request |
| 11:47 | <darobin> | will see about that next time |
| 13:50 | <slightlyoff> | marcosc: yeah, sorry for the delay |
| 13:53 | <marcosc> | slightlyoff: no probs, thanks for commenting |
| 15:34 | <Ms2ger> | SimonSapin, how's the new job? :) |
| 15:35 | <SimonSapin> | Ms2ger: It’s awesome :D |
| 15:35 | <SimonSapin> | and a bit overwhelming |
| 15:43 | <MikeSmith> | rillian: fwiw I managed to build Chromium with audio/mpeg support by feeding it a couple of gyp flags |
| 15:43 | <MikeSmith> | http://www.chromium.org/audio-video#TOC-GYP-Flags |
| 15:43 | <MikeSmith> | I guess that probably enables H.264 support too |
| 15:48 | <TabAtkins> | Good lord, tc39 is *actually* telling me that I shouldn't reuse their data structures, and should instead just reinvent a Map-lookalike every time I want to use a Map in a spec. |
| 15:48 | <TabAtkins> | This is a dream, right? |
| 15:48 | <TabAtkins> | I'm dreaming right now? |
| 15:49 | <Ms2ger> | No, no |
| 15:49 | <odinho> | Sweet dreams |
| 15:49 | <Ms2ger> | That's Javascripty |
| 15:49 | <Ms2ger> | It's the Idiomatic Way |
| 15:50 | <jgraham> | TabAtkins: In a moment MikeSmith will turn into Carrie Fisher and kiss you |
| 15:50 | <jgraham> | Which is weird |
| 15:50 | <TabAtkins> | jgraham: But oddly arousing. |
| 15:50 | <jgraham> | But it's your dream |
| 15:51 | <TabAtkins> | Does MikeSmith have the buns on before he changes? |
| 15:51 | <jgraham> | Sure, like normal |
| 15:52 | <TabAtkins> | Cool, cool, just making sure. |
| 15:52 | <TabAtkins> | Wouldn't want it to get weird or anything. |
| 17:35 | <zewt> | "Modified UTF-8 form"? there's a sequence of words that makes me rage inside |
| 18:31 | <rniwa> | zewt: sounds like a scary stuff. |
| 18:31 | <rniwa> | zewt: where did you find this horror? |
| 20:01 | <zewt> | google docs :( |
| 20:01 | <zewt> | (for Java stuff so the real blame might be on Oracle or Sun or whoever) |
| 20:02 | <zewt> | http://developer.android.com/training/articles/perf-jni.html |
| 20:09 | <Philip`> | zewt: Is the problem that you're wanting some actual documentation of the JNI API, not just a collection of random tips? |
| 20:13 | <Philip`> | zewt: Oh, I guess you were actually responding to rniwa |
| 20:13 | <Philip`> | in which case I'm pretty sure it's Sun's fault |
| 20:18 | <Philip`> | zewt: http://docs.oracle.com/javase/1.3/docs/guide/jni/spec/types.doc.html#16542 - been there since at least 1997, apparently |
| 20:19 | <Philip`> | Back then they thought a 16-bit char would be a sensible idea, too |
| 20:19 | <Philip`> | but it turns out Unicode is hard :-( |
| 20:35 | <dekiss> | when Google joined whatwg? |
| 20:44 | <jgraham> | dekiss: WHATWG doesn't have members really |
| 20:44 | <jgraham> | But Google employees have been active for a long time |
| 20:44 | <dekiss> | ? |
| 20:44 | <dekiss> | cmon |
| 20:44 | <dekiss> | apple opera mozilla started it right? |
| 20:44 | <dekiss> | well |
| 20:44 | <dekiss> | who operate it then? |
| 20:44 | <dekiss> | it has closed membership i dont understand |
| 20:44 | <dekiss> | it must have directors or something |
| 20:45 | <dekiss> | right? |
| 20:45 | <dekiss> | you want to say it has some kind of directors and it works like closed organization? |
| 20:46 | <jgraham> | Apparently the amount that you can get done without a heavyweight bureaucracy would surprise you |
| 20:46 | <jgraham> | WHATWG theoretically has a group of appointed members that can tell Hixie that he's useless |
| 20:47 | <jgraham> | In practice they have, as far as I know, done nothing |
| 20:47 | <jgraham> | In fact it's hard to imagine what they would do |
| 20:47 | <hober> | i think they actually did something once |
| 20:47 | <jgraham> | Because the response to the failure mode "Hixie has gone mad and won't listen to reason" is to fork the spec |
| 20:47 | <hober> | but i don't remember what it was |
| 20:48 | <jgraham> | Didn't they vote to allow annevk to join their club? |
| 20:48 | <jgraham> | AFAIK the WHATWG site is hosted on Hixie's Dreamhost account |
| 20:49 | <jgraham> | In the early days some lawyers at Opera, Mozilla and Apple were involved in licensing the specification |
| 20:49 | <jgraham> | Apart from that it's just a mailing list |
| 20:50 | <dekiss> | hm |
| 20:50 | <dekiss> | its offiocial standard |
| 20:50 | <dekiss> | and 99% use it |
| 20:51 | <jgraham> | In this context I don't know what an "official" standard is |
| 20:51 | <jgraham> | It's not like there are laws about HTML compliance |
| 20:52 | <jgraham> | Browser vendors and market forces are the ultimate arbiters of what gets implemented |
| 20:52 | <dekiss> | hm |
| 20:52 | <dekiss> | what about w3? |
| 20:53 | <jgraham> | But there is some competition between venues for doing standards work |
| 20:53 | <dekiss> | Tim don't have power? |
| 20:53 | <dekiss> | that is plain bad |
| 20:53 | <dekiss> | money=BAD |
| 20:53 | <jgraham> | On brand name, efficiency, IPR commitments, etc. |
| 20:53 | <dekiss> | jgraham I know thats true I just try to cinvience myself in oppposite |
| 20:54 | <jgraham> | So W3C have comparatively strong IPR policies which several vendors particuarly like |
| 20:54 | <jgraham> | e.g. Microsoft won't do work in the WHATWG |
| 20:54 | <jgraham> | They also have a rather strong brand |
| 20:55 | <jgraham> | Although they are currently engaged in a self-destruct campaign on that front |
| 20:55 | <dekiss> | why? |
| 20:56 | <jgraham> | I don't know why. |
| 20:57 | <jedimind> | hey its a place w/ people and stuff |
| 20:57 | <jedimind> | crazy |
| 20:57 | <jgraham> | But the whole DRM thing is doing a lot of harm to the whole "W3C => good for the web" association they have managed to build up |
| 20:58 | <jgraham> | Also among vendors they are not renouned for being a place to get stuff done with a minimum of overhead |
| 20:59 | <gavinc> | Okay, those are same vendors pushing the DRM stuff. |
| 20:59 | <jgraham> | On the other hand WHATWG has a minimum of Process and is generally rather efficient at solving technical challenges, but doesn't offer the Patent policy so is rather weak on the IPR front |
| 21:00 | <jgraham> | (OTOH, it is possibly to republish WHATWG specs through W3C which can provide the benefits of both organisations) |
| 21:04 | <astearns> | jgraham: those benefits being all the process of the W3C plus all the snarking from WHATWG about that process? |
| 21:04 | <dekiss> | hm |
| 21:06 | <jgraham> | astearns: More like "getting stuff done from WHATWG without that process" |