| 00:00 | <AryehGregor> | bga_, who's talking about collision? |
| 00:01 | <bga_> | AryehGregor and it has slowest speed of calculation |
| 00:01 | <AryehGregor> | That's irrelevant, you can iterate the function to get slower calculation speed. |
| 00:01 | <AryehGregor> | The choice of hash function is more or less immaterial to this discussion. |
| 00:01 | <AryehGregor> | Since they're all designed to be relatively fast. |
| 00:03 | <jcranmer> | hash(msg) = 1 |
| 00:04 | <bga_> | AryehGregor GOST is designed to be as slow as possible. it uses bigints |
| 00:04 | <bga_> | look at http://en.wikipedia.org/wiki/GOST_(hash_function) |
| 00:05 | <AryehGregor> | Are bigints supposed to be slow? |
| 00:05 | <AryehGregor> | People use 64-bit machines these days, you know. |
| 00:06 | <AryehGregor> | The page you link to does not claim GOST is designed to be as slow as possible. |
| 00:06 | <AryehGregor> | Indeed, that would be pretty ridiculous. |
| 00:08 | <Hixie> | foolip: yt? |
| 00:08 | <bga_> | when compared different hash functions i found GOST most hard to implement and calculation |
| 00:09 | <Hixie> | you implied in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10320#c20 that TTML has an equivalent to WebSRT's voice feature and that it was a good solution, but I can't find it in the spec http://www.w3.org/TR/ttaf1-dfxp/ |
| 00:09 | <Hixie> | foolip: am I looking in the wrong place? |
| 00:10 | <bga_> | but ok. it just constant C - time of calculation |
| 00:10 | <jacobolus> | is it true that it's impossible to get gecko + webkit's linear gradients to do the same thing for a diagonal gradient unless the precise box dimensions are known? |
| 00:11 | <jacobolus> | it seems like gecko uses point + angle, while webkit use 2 points |
| 00:11 | AryehGregor | points jacobolus to TabAtkins |
| 00:11 | <jacobolus> | but the points are defined relative to the edges of the box the gradient is being drawn in |
| 00:12 | <jacobolus> | so as that box changes shape, the webkit gradient changes angle, while the gecko gradient (defined in terms of angle) obviously doesn't |
| 00:13 | <jacobolus> | this seems like the sort of thing that would be pretty easy to avoid with some minimal communication between devs, no? |
| 00:13 | <jacobolus> | :p |
| 00:15 | <AryehGregor> | jacobolus, the WebKit variant was the original, nonstandard way of doing things. Mozilla follows a draft spec written by TabAtkins. Once everyone is satisfied with the draft, WebKit will implement that syntax too. |
| 00:16 | <AryehGregor> | Or at least so I understand it. |
| 00:16 | <AryehGregor> | Then vendors can remove prefixes. |
| 00:16 | <jacobolus> | aha |
| 00:16 | <jacobolus> | AryehGregor: you know where that draft spec lies? |
| 00:17 | <AryehGregor> | jacobolus, http://dev.w3.org/csswg/css3-images/#gradients |
| 00:17 | <jacobolus> | oh, http://dev.w3.org/csswg/css3-images/#gradients |
| 00:17 | <jacobolus> | :) |
| 00:17 | <jacobolus> | thx |
| 00:18 | <jacobolus> | AryehGregor/TabAtkins: so in the spec'd version, a top left to bottom right gradient now requires knowing image dimensions and doing some trigonometry? |
| 00:18 | <AryehGregor> | Don't ask me, I have no idea. |
| 00:18 | <AryehGregor> | I think I used gradients once. |
| 00:18 | <AryehGregor> | When doing my website. |
| 00:18 | <bga_> | wow md2 http://www.php.net/manual/en/function.hash.php#89574 |
| 00:20 | <jacobolus> | oh, I see, if no angle is specified, and the first point is in a corner/middle of a side, the gradient will point at the opposite corner. interesting |
| 00:21 | <jacobolus> | okay, this version seems reasonable enough to me. does anyone have any idea how long it will take webkit to implement to this new spec? |
| 00:22 | <jacobolus> | on the other hand, the radial gradients in TabAtkins' spec are dramatically less flexible than the webkit ones, so far as I can tell |
| 00:23 | <jacobolus> | the linear gradients are also less flexible, but if you know box dimensions they can be made to do most of what the webkit ones can |
| 00:23 | <Hixie> | hmm |
| 00:23 | <AryehGregor> | jacobolus, best wait for TabAtkins to get back, he'll probably have answers to all these things. |
| 00:23 | <jacobolus> | okay :) |
| 00:24 | <jacobolus> | there's probably plenty of email discussion about it someplace |
| 00:24 | <Hixie> | if we make voices in websrt be marked up as <v speaker's name>, and if we make ::cue-part() take a whole selector rather than the weird thing it has now, i wonder how we do voice selection |
| 00:24 | <AryehGregor> | Yes, it's been discussed a lot on www-style. |
| 00:24 | <Hixie> | ::cue-part(v.speaker\'s\ name) ? |
| 00:24 | <Hixie> | that's pretty lame... |
| 00:25 | <Hixie> | also if we allow multiple voices per cue, how do we style the cue's outer box based on the voice? hmmm |
| 00:25 | <AryehGregor> | jacobolus, https://bugs.webkit.org/show_bug.cgi?id=28152 |
| 00:26 | <jacobolus> | AryehGregor: thanks |
| 00:27 | <jacobolus> | I'm trying to make a better gradient definer interface dealie, that will try to graph some perceptually-relevant color attributes along the gradient, so I'm trying to figure out how the various gradients actually work :) |
| 00:27 | AryehGregor | wtfs at Thom's post, 4000 words in a bug comment |
| 00:28 | <paul_irish> | jacobolus: i'd be very interested in seeing that, if you're looking to share |
| 00:28 | <jacobolus> | paul_irish: haven't started implementation yet :) |
| 00:28 | <paul_irish> | btw, thoroughly enjoyed your HSL HSV article, which i read through the other day |
| 00:28 | <jacobolus> | ah, thanks! |
| 00:28 | <jacobolus> | paul_irish: if you have any comments, I'd appreciate any feedback |
| 00:29 | <paul_irish> | no specific comments, just smiles. |
| 00:29 | <jacobolus> | I think the only real problem w/ the article as it stands is that the lead and first section or two could be more newbie-friendly |
| 00:29 | <jacobolus> | thanks :) |
| 00:29 | <jacobolus> | also at some point the figures need to be renumbered to reflect their current order |
| 00:30 | <jacobolus> | paul_irish: sometime in the future I want to write a better article about CIELAB, and flesh out the one about the Munsell system |
| 00:35 | <othermaciej> | AryehGregor: which bug comment is that? |
| 00:35 | <othermaciej> | oh, I see |
| 00:35 | <othermaciej> | goodness me that'sa lot |
| 00:37 | <bckenny> | jacobolus: where's this article? :) |
| 00:38 | <hsivonen> | so looks like soon Opera is going to be the only one without onerror https://bugs.webkit.org/show_bug.cgi?id=8519 |
| 00:41 | <jacobolus> | bckenny: http://en.wikipedia.org/wiki/HSL_and_HSV |
| 00:41 | <bckenny> | ha, I think I've been to this blog before |
| 00:41 | <bckenny> | sweet |
| 00:47 | <jacobolus> | bckenny: esp. important IMO is the section http://en.wikipedia.org/wiki/HSL_and_HSV#Disadvantages |
| 00:47 | <TabAtkins> | jacobolus: What's the question now? |
| 00:48 | <jacobolus> | TabAtkins: I was just noticing that it's impossible to get webkit & gecko gradients to do quite the same thing |
| 00:48 | <TabAtkins> | Yes. |
| 00:48 | <TabAtkins> | There are a handful of imo unimportant use-cases that you can't address with the draft gradients, but you can with webkit. |
| 00:49 | <TabAtkins> | Note that if the box dimensions are known then you *can* do everything with draft gradients, with a little bit of calculus. |
| 00:49 | <jacobolus> | TabAtkins: right. I think someone might like them, but you're probably right that at some point SVG/canvas/something becomes a better tool for more complexity |
| 00:50 | <bckenny> | jacobolus: definitely. there has also been interest in alternate gradient and transition color functions, so please definitely weigh in on the subject |
| 00:50 | <bckenny> | we want good looking colors |
| 00:50 | <TabAtkins> | Indeed, that's very explicitly the goal - I'm keeping the gradient syntax simple and easy, and letting SVG address more complicated cases if need be. |
| 00:50 | <jacobolus> | TabAtkins: that webkit can make radial gradients w/ non-concentric inside/outside can't be emulated can it? |
| 00:50 | <TabAtkins> | No. |
| 00:51 | <TabAtkins> | I may address that at some point, but decided against the added complexity for now. |
| 00:51 | <TabAtkins> | (It would mean an extra point argument between the current point and shape arguments.) |
| 00:51 | <jacobolus> | TabAtkins: are the webkit folks likely to implement your spec anytime soon? |
| 00:52 | <TabAtkins> | Yes, simon fraser (the relevant dude) is satisfied with my spec now that I've addressed his concerns wrt interpolating. |
| 00:52 | <jacobolus> | bckenny: alternate transition functions don't help all that much IMO as long as the color space in use is not perceptually relevant :) |
| 00:53 | <jacobolus> | bckenny: so my solution would be to just make a gradient w/ 50 points in it or something, and then I can move them wherever I want |
| 00:53 | <TabAtkins> | Hixie: Accept strings *or* escaped idents in ::cue-part. |
| 00:54 | <TabAtkins> | That's our solution for font-family. |
| 00:54 | <jacobolus> | TabAtkins: do you know where in the spec compositing of CSS colors w/ alpha is defined? |
| 00:54 | <TabAtkins> | It's not - it was defined by the Porter-Duff paper decades ago. |
| 00:55 | <TabAtkins> | That said, I'm going to add a note talking about it. |
| 00:55 | <jacobolus> | TabAtkins: I'm assuming it's just some kind of linear interpolation relative to sRGB space? |
| 00:55 | <jacobolus> | TabAtkins: okay, I have that paper somewhere. but the paper doesn't say anything about gamma-compressed color spaces |
| 00:55 | <TabAtkins> | gamma correction applies when you're displaying the color, not computing it, right? |
| 00:56 | <jacobolus> | depends who is doing the computing :) |
| 00:56 | <TabAtkins> | True. |
| 00:56 | <jacobolus> | Alvy Ray Smith wrote something at some point about how everyone should always use linear space for compositing |
| 00:56 | <jacobolus> | but I'm not sure everyone else agrees |
| 00:56 | <jacobolus> | Adobe for instance never does, in Photoshop |
| 00:56 | <jacobolus> | they just composite relative to current color space, because it's fastest |
| 00:57 | <bckenny> | jacobolus: ok, hopefully i'm not going to put my foot in my mouth here, but theoretically there is some function that will take a displayed color and map it to a space like CIELAB whatever |
| 00:57 | <Hixie> | TabAtkins: the idea is to put a whole selector in there |
| 00:58 | <jacobolus> | bckenny: sure, but that starts making things complicated relative to what people are used to |
| 00:58 | <bckenny> | jacobolus: so would there be an easily defined, perceptually pleasant, transition function there? |
| 00:58 | <Hixie> | TabAtkins: the problem is that the selector syntax expects attribute/value pairs, whereas all i have here is a string |
| 00:58 | <TabAtkins> | Hixie: Oh. Hrm, then. |
| 00:58 | <TabAtkins> | So, you're mapping voices to CSS classes? |
| 00:58 | <bckenny> | I guess my question is, what are the options other than going straight through gray |
| 00:59 | <jacobolus> | bckenny: sure, ArcGIS for example does (can do) its gradients (Color Ramps) relative to CIELAB in either polar coordinates or rectangular coordinates |
| 00:59 | <jacobolus> | and it generally works much better than using HSL/HSV |
| 00:59 | <jacobolus> | or RGB |
| 00:59 | <bckenny> | that's what I was getting at before, since currently browsers just go through RGB |
| 01:00 | <jacobolus> | bckenny: but the problem is that you start getting colors that are out of gamut, and then your implementation has to decide how to do the gamut mapping to bring them back into gamut |
| 01:00 | <TabAtkins> | Consider, btw, how to duplicate the behavior of premultiplied rgb in other color spaces. |
| 01:01 | <jacobolus> | bckenny: and here's a 300 page book on that subject http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470758937.html |
| 01:02 | <jacobolus> | TabAtkins: yeah, that's what I meant about how browsers do compositing. is it spec'd out how to interpolate between two RGBA colors in a gradient? |
| 01:02 | <TabAtkins> | Yes. You do linear interpolation in premultiplied sRGB space. |
| 01:02 | <jacobolus> | ah, okay, great |
| 01:03 | <TabAtkins> | This is the same as <color> interpolation for transitions/animations, btw. |
| 01:03 | <jacobolus> | TabAtkins: If and when I get this gradient creator/viewer dingus implemented, I'll let you know :) |
| 01:04 | <jacobolus> | TabAtkins: ever see this page? :) http://www.all-in-one.ee/~dersch/gamma/gamma.html |
| 01:06 | <TabAtkins> | I hadn't, but that's an excellent illustration of why you should be doing composition work before applying gamma. ^_^ |
| 01:06 | <Hixie> | TabAtkins: i don't know what i'm mapping them to currently |
| 01:06 | <Hixie> | TabAtkins: classes is one option |
| 01:06 | <Hixie> | TabAtkins: but it's not very clean |
| 01:06 | <Hixie> | TabAtkins: (i want to add classes also, as <span class class class>) |
| 01:06 | <jacobolus> | TabAtkins: but I'm pretty sure that as you've defined it, that's not done. :-) |
| 01:06 | <TabAtkins> | Hixie: ::cue-part(v[speaker="speaker's name"]) |
| 01:07 | <TabAtkins> | jacobolus: I haven't said anything about gamma correction at all. I'm gamma-agnostic. |
| 01:07 | <jacobolus> | TabAtkins: that's somewhat okay though, as long as everyone is on the same page, and I can add extra points to my gradient to make it do what I want :) |
| 01:07 | <Hixie> | that was my other thought, but i'm skeptical about making up "pseudo-attribute" names like that |
| 01:07 | <TabAtkins> | Hixie: There's nothing wrong with that. You don't have real attributes in webSRT, or if you do, they're drawn from a limited set. |
| 01:07 | <jacobolus> | TabAtkins: okay, but sRGB is a gamma-compressed space, so if you interpolate linearly relative to sRGB.... :) |
| 01:07 | <Hixie> | fair enough |
| 01:08 | <jacobolus> | anyhow, there are advantages and disadvantages to each |
| 01:08 | <TabAtkins> | jacobolus: Oh, is it? Okay, then I was mistaken. I had no idea sRGB was gamme-compressed. |
| 01:08 | <TabAtkins> | jacobolus: Ah, now I see why that is, be looking at the math on that page. |
| 01:08 | <jacobolus> | TabAtkins: http://en.wikipedia.org/wiki/File:SRGB_gamma.svg |
| 01:09 | <bckenny> | jacobolus: I don't think you should depend on the wrong behavior too much...theoretically browsers (or operating systems) should be filtering and compositing in linear space |
| 01:10 | <bckenny> | and someday we'll actually get there |
| 01:10 | <jacobolus> | bckenny: I doubt it |
| 01:10 | <jacobolus> | bckenny: if everyone does their compositing in gamma compressed space, then changing the behavior is a bug |
| 01:10 | <jacobolus> | because it will change appearance |
| 01:10 | <bckenny> | but its unspecified |
| 01:10 | <jacobolus> | well, it should be specified one way or the other |
| 01:10 | <bckenny> | all thats specified is input and display spaces |
| 01:11 | <jacobolus> | I think it might actually be specified in CSS3; I'll go read again |
| 01:12 | <jacobolus> | bckenny: it defers to http://www.w3.org/TR/2003/REC-SVG11-20030114/masking.html#SimpleAlphaBlending |
| 01:13 | <jacobolus> | hmm, it's not clear whether SVG defines if things should be composited in document color space or in linear space |
| 01:13 | <bckenny> | http://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#ColorInterpolationProperty |
| 01:13 | <bckenny> | yeah its not clear at all |
| 01:14 | <TabAtkins> | Hmm, yeah. That should probably be cleared up in Colors 4. |
| 01:14 | <jacobolus> | oh, I see. "auto: Indicates that the user agent can choose either the sRGB or linearRGB spaces for color interpolation. This option indicates that the author doesn't require that color interpolation occur in a particular color space." |
| 01:14 | <TabAtkins> | Oh, *that's* what linearRGB means. I've never been clear on that. |
| 01:14 | <jacobolus> | that's probably a bad way to define the spec |
| 01:14 | <jacobolus> | means that auto might render substantially differently in 2 implementations |
| 01:14 | <bckenny> | it was probably for performance and to match reality :) |
| 01:15 | <jacobolus> | leaving authors quite confused |
| 01:15 | <TabAtkins> | In practice, I think everyone uses sRGB in practice. |
| 01:15 | <TabAtkins> | That is, linear interpolation between the components of a color expressed in rgb(). |
| 01:15 | <jacobolus> | TabAtkins: yes, since it's faster (just takes some multiplications/additions) |
| 01:15 | <bckenny> | yeah, I think so too |
| 01:15 | <bckenny> | although images with color profiles might be a weird case |
| 01:15 | <TabAtkins> | But yeah, switching to linearRGB should be an option. |
| 01:16 | <jacobolus> | whereas linearizing the components requires mapping through a lookup table |
| 01:16 | <TabAtkins> | I think we're *supposed* to obey color-interpolation. |
| 01:16 | <TabAtkins> | jacobolus: Well, that's still a cheap mapping, but yeah. |
| 01:16 | <jacobolus> | TabAtkins: there's no color-interpolateion in CSS though? |
| 01:16 | <TabAtkins> | It's in SVG, but HTML content should be able to use it through CSS. |
| 01:16 | <TabAtkins> | Emphasis on *should*. |
| 01:16 | <jacobolus> | TabAtkins: sure, it's cheap on modern hardware, but people were making these decisions in like 1990 |
| 01:17 | <jacobolus> | where by people I mean Adobe |
| 01:18 | <jacobolus> | TabAtkins: okay, well it might make sense to add that if that property exists it should be respected for gradients/rgba colors in CSS too :) |
| 01:19 | <TabAtkins> | Oh, certainly. color-interpolation should be respected for *all* uses of color. |
| 01:19 | <jacobolus> | TabAtkins: it's not clear whether the interpolation of SVG gradients follows color-interpolation, in the SVG spec |
| 01:19 | <jacobolus> | or only compositing |
| 01:19 | <TabAtkins> | That's a good topic to bring up for the FXTF. I'll put it on my board. |
| 01:20 | <jacobolus> | (i.e. the word "interpolation" doesn't show up in http://www.w3.org/TR/SVG/pservers.html ) |
| 01:22 | <jacobolus> | TabAtkins: while we're at it, it would be really nice if we could do some fast vector math on arrays of numbers in javascript; would make custom color stuff a lot easier :) |
| 01:23 | <TabAtkins> | JS isn't my bag. Bug some of the other google engineers. ^^; |
| 01:23 | <TabAtkins> | (I love JS, but I'm not good on the JS-standardization stuff.) |
| 01:23 | <jacobolus> | well, just in general, javascript's support of data structures is totally lame :) |
| 01:23 | <bckenny> | theres a thread about that very topic right now in the public webgl list |
| 01:24 | <jacobolus> | bckenny: link? |
| 01:24 | <jacobolus> | if it can be done in webgl apis I'd be satisfied-ish |
| 01:24 | <jamesr_> | there are some ecma proposals on the table |
| 01:25 | <bckenny> | https://www.khronos.org/webgl/public-mailing-list/archives/1012/msg00080.html |
| 01:27 | <jacobolus> | bckenny: thanks. yes, even fast 4x4 array manipulation would be great |
| 01:29 | <jacobolus> | esp. if there are apis for things like matrix inversion |
| 01:30 | <jacobolus> | I guess there is in CSSMatrix |
| 01:30 | <jacobolus> | I should try playing with that |
| 01:30 | <TabAtkins> | We're throwing away CSSMatrix, at least for now. |
| 01:30 | <jacobolus> | oh. is there something implemented I should use? |
| 01:30 | <TabAtkins> | No clue. |
| 01:30 | <TabAtkins> | You might be able to use CSSMatrix for now. I'm just warning you that it's going away. |
| 01:31 | <jacobolus> | heh, okay |
| 01:31 | <jacobolus> | TabAtkins: do these discussions get summarized anywhere that's easy for someone to get up to speed w/ current thinking on the subject? |
| 01:32 | <TabAtkins> | The www-style list. ^_^ |
| 01:33 | <jacobolus> | I don't have the time to follow www-style and the html5 mailing lists and all the public javascript lists &c. &c. in detail, but am definitely interested in the subject |
| 01:33 | <TabAtkins> | You can try searching lists.w3.org's archive. |
| 01:33 | <bckenny> | WebKitCSSMatrix is also (mostly) immutable right now, which can be problematic with garbage collection |
| 01:33 | <bckenny> | but it is definitely fast on iOS |
| 01:34 | <bckenny> | thats partly what that webgl thread was about |
| 01:34 | <jacobolus> | I wonder what the best way is to interpolate values relative to a lookup table in javascript |
| 01:34 | <jacobolus> | I guess I can just use javascript arrays |
| 01:35 | <bckenny> | how expensive is the function that generates the tables? |
| 01:35 | <bckenny> | pure math js is pretty fast these days |
| 01:35 | <jacobolus> | bckenny: depends; in some cases there's nothing but a table to go by |
| 01:36 | <jacobolus> | in others I can try doing the math direct and compare |
| 01:36 | <jacobolus> | I wish I could just use numpy in the browser; life would be lovely |
| 01:42 | <Hixie> | TabAtkins: my effort to save time by tweaking my publication system so that you can deal with the TR/ stuff is nearing completion but may have failed in its overall stated mission (namely, to save time)! |
| 01:43 | <TabAtkins> | Haha. |
| 01:43 | <jacobolus> | hehe |
| 01:44 | <Hixie> | my preprocessor has accrued so much crap over the years that it's now reached the point where if i was starting over, it would just make more sense to use a general purpose tool chain like the c preprocessor and make. |
| 01:44 | <Hixie> | but oh well. |
| 01:45 | TabAtkins | is horrified by the thought of using the C preprocessor. |
| 01:45 | <Hixie> | you'd be equally horrified, maybe will be equally horrified, at the thought of using the monster that's evolved to be what i use |
| 01:46 | <Hixie> | on another note, i think i wish anolis had an option to strip comments |
| 01:47 | <TabAtkins> | I suggest scrapping the whole thing and switching to Lisp and macros. |
| 01:51 | <Hixie> | ok i think i'm going to upload the relevant files to the dev.w3.org cvs repo if that works for you |
| 01:51 | <TabAtkins> | That works. |
| 01:56 | <Hixie> | TabAtkins: http://dev.w3.org/html5/boilerplate/ |
| 02:01 | <jacobolus> | TabAtkins: I'm not finding the discussion where CSSMatrix is being dropped; was that within the last week or two? |
| 02:01 | <TabAtkins> | Within the last month, at least. |
| 02:01 | <jacobolus> | on www-style? |
| 02:02 | <TabAtkins> | Maybe on FX. |
| 02:02 | <TabAtkins> | public-fx⊙wo, that is. |
| 02:03 | <Hixie> | TabAtkins: k, it's ready. basically, edit those files -- it should be somewhat self-explanatory but feel free to ask any questions you may have -- and then let me know when you've changed something and i'll pull the updates and regen |
| 02:04 | <TabAtkins> | Hm, kk. |
| 02:17 | <jacobolus> | all I'm finding is http://lists.w3.org/Archives/Public/www-style/2010Dec/0074.html |
| 02:18 | <TabAtkins> | jacobolus: I'm heading out for the day, so I'll pick this up tomorrow and try to find some of the stuff. |
| 02:18 | <jacobolus> | TabAtkins: no worries |
| 02:18 | <jacobolus> | TabAtkins: tomorrow and the next day I'm offline, but I'll come bug you more about it in a few days or a week :) |
| 02:19 | <jacobolus> | thanks for all your answers |
| 03:08 | <bga_> | http://twitter.com/slicknet/status/14514661722427392 |
| 03:09 | <Hixie> | he hasn't seen <samp> |
| 03:42 | <nessy> | Hixie: can we address individual cues in WebSRT/<track> by cue identifier? |
| 03:43 | <nessy> | ::cue only addresses all the cues IIUC |
| 07:04 | <Hixie> | MikeSmith: nah that's easy. Just enumerate them all, sort them all, and check for dupes. |
| 07:06 | <MikeSmith> | yeah I was just bellyaching |
| 07:07 | <MikeSmith> | though I do wonder now what the error message will end up looking like |
| 07:08 | <Hixie> | "You have listed %d tracks that are all %s, %s, and %s. You should distinguish your tracks so that the user can tell which is which." |
| 08:58 | <foolip> | Hixie, what I was referring to was the ttm:agent attribute, see the example in http://www.w3.org/TR/ttaf1-dfxp/#metadata-vocabulary-agent-example-1 |
| 08:59 | <foolip> | The good part being that a short id is used and is linked to the full name of the character and actor, not necessarily the syntax as such |
| 09:00 | <foolip> | I think that e.g. <v bond> and *optional* extra metadata about the voices would be a sensible approach |
| 09:37 | <annevk> | Hixie, TabAtkins, are you also going to take care of the Disposition of Comments? |
| 09:54 | <jgraham> | TabAtkins: I'm pretty sure that the kind of box that was mentioned in the <comment> thread is not either like a pullquote or like a chart |
| 09:54 | <jgraham> | I think it is a perfectly valid use of <aside> though |
| 09:55 | <jgraham> | And if the spec disagrees I think the spec is silly (I already think that using <aside> for sidebars is the weirdest possible use) |
| 15:37 | <AryehGregor> | Who decided that sizeof() in C should behave differently for arrays and pointers? It's quite inconsistent. |
| 15:38 | <bga_> | heh |
| 15:38 | <bga_> | K&R! |
| 15:39 | <jcranmer> | it's quite helpful though |
| 15:39 | <jcranmer> | arrays ≠pointers |
| 15:40 | <AryehGregor> | Yeah, but if you have a static array and you change it to a pointer because it's too big to go on the stack, suddenly your sizeof() calls silently do something different. |
| 15:40 | <jcranmer> | int arr[] = {1, 2, 3, 4}; |
| 15:40 | <jcranmer> | &arr == arr |
| 15:40 | <AryehGregor> | &arr == arr? o_O |
| 15:40 | <jcranmer> | yep |
| 15:40 | AryehGregor | clearly doesn't know enough C |
| 15:40 | <jcranmer> | that trips up SO many students |
| 15:41 | <AryehGregor> | That makes no sense. |
| 15:42 | <bga_> | sizeof(&arr[0]) |
| 15:42 | <Philip`> | AryehGregor: Using sizeof on arrays seems quite risky - better to have some macro that returns number of elements, and fails on pointers |
| 15:42 | <jcranmer> | arrays are closer to labels |
| 15:43 | <AryehGregor> | Philip`, in other words, the feature is ill-conceived. |
| 15:43 | <jcranmer> | so the address of this label is the location it is at |
| 15:43 | <jcranmer> | you also can't legally say arr = foo; |
| 15:43 | <Philip`> | ...although actually I'm not sure how possible it is to have a macro like that |
| 15:43 | <Philip`> | I've got some code with |
| 15:43 | <Philip`> | template<typename T, size_t n> u8 (*ArraySizeDeducer(T (&)[n]))[n]; |
| 15:43 | <Philip`> | #define ARRAY_SIZE(name) (sizeof(*ArraySizeDeducer(name))) |
| 15:43 | <Philip`> | but apparently it fails in GCC, so it just uses |
| 15:44 | <Philip`> | #define ARRAY_SIZE(name) (sizeof(name) / (sizeof((name)[0]))) |
| 15:44 | <Philip`> | there, which won't detect accidental use of pointer types |
| 15:44 | <jcranmer> | static assert name == &name? |
| 15:46 | <Philip`> | void* x; x = &x; // now x == &x, and you can't tell that statically |
| 15:46 | <jcranmer> | well, that would require a good static analysis to detect your trick |
| 15:46 | <AryehGregor> | I would be so much happier writing OpenCL if the compiler didn't routinely do things like go into an infinite loop for no obvious reason. |
| 15:47 | <jcranmer> | s/good/decent/ |
| 15:47 | <Philip`> | jcranmer: Indeed, and you can't do a static assert except for conditions which a dumb static analysis can definitely find the answer to |
| 15:48 | <bga_> | may be c99 will fix your problem |
| 15:49 | <Philip`> | AryehGregor: Maybe it's trying to optimise your non-terminating program into a pre-computed constant return value? |
| 15:50 | <AryehGregor> | Philip`, I hope not, since my program is supposed to terminate. |
| 15:50 | <AryehGregor> | Other users of this GPU would be annoyed, otherwise. |
| 16:02 | <Aleoss> | What is wrong with this X-UA-Compatible value? "IE=edge;chrome=1;FF=3;Opera=9;Konqueror=3;Safari=3;OtherUA=4" |
| 16:02 | <Aleoss> | Validator says it is a bad value. |
| 16:02 | <jcranmer> | everything is ancient? |
| 16:03 | <Aleoss> | jcranmer: Has nothing to do with the versions, but rather the syntax obviously. |
| 16:03 | <AryehGregor> | Aleoss, X-UA-Compatible is nonstandard and invalid to begin with. |
| 16:03 | <AryehGregor> | Also, nothing actually pays attention to it other than IE and the Chrome plugin for IE, so those extra values are nonsense. |
| 16:03 | <AryehGregor> | Chrome Frame, that's what it's called. |
| 16:03 | <Philip`> | Aleoss: Everything is wrong with it |
| 16:03 | <Aleoss> | AryehGregor: So I should send it in HTTP headers only or not bother with it at all? |
| 16:03 | <AryehGregor> | Aleoss, don't bother with it at all. |
| 16:04 | <AryehGregor> | Unless you want to opt in to Chrome Frame, then I guess you need it. |
| 16:04 | <AryehGregor> | For IE=edge, make sure you have a correct doctype, then you'll get that automatically. |
| 16:04 | <AryehGregor> | (If your page validates as HTML5, you have a correct doctype.) |
| 16:04 | <Philip`> | Especially the OtherUA=4, which I assume was copied-and-pasted many times from the original announcement without anyone stopping to think about what it actually meant |
| 16:04 | <AryehGregor> | This is all copied and pasted from the original announcement? |
| 16:05 | <Philip`> | No, some has accreted since then |
| 16:05 | <Aleoss> | Philip`: That would just mean version 4 of anything else. |
| 16:05 | <AryehGregor> | Which makes no sense. |
| 16:05 | <AryehGregor> | The entire thing makes no sense. |
| 16:05 | <AryehGregor> | That header was made up by IE and no one else uses it or plans to ever use it, except Chrome Frame. |
| 16:06 | <Philip`> | http://www.alistapart.com/articles/beyonddoctype - <meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" /> |
| 16:06 | <AryehGregor> | And IE doesn't even need it if you have a good doctype. |
| 16:06 | <Aleoss> | AryehGregor: <!DOCTYPE html> |
| 16:06 | <AryehGregor> | Aleoss, that's fine. Then leave out the meta. |
| 16:06 | <AryehGregor> | The validator says it's invalid for a reason. :) |
| 16:09 | <Philip`> | There should be a law that if you publish an article with some markup that people shouldn't copy and paste directly into their own pages, you must surround it with a flashing red border and "DO NOT USE THIS EXAMPLE DIRECTLY" warnings surrounding it, and it should be rendered as an image so they can't copy it as text |
| 16:11 | <bga_> | and google do not find your text. yes |
| 16:12 | <bga_> | user-select: none; is better |
| 16:13 | <david_carlisle> | Philip`: re laws, i just copied the markup that you posted to http://krijnhoetmer.nl/irc-logs/whatwg/20101214#l-671 but it appears to be invalid |
| 16:16 | <Philip`> | david_carlisle: I shall hand myself in to the authorities forthwith |
| 16:16 | <Philip`> | though I will fight attempts at extradition |
| 18:27 | <JonathanNeal> | I think most browsers have chosen font-size: 16px; and font-family: serif; to be the default font style of a document, but this isn't actually required or recommended by w3c or whatwg. Is that correct? |
| 18:28 | <AryehGregor> | Seemingly. |
| 18:31 | <jcranmer> | JonathanNeal: most likely desire of browsers for consistency |
| 18:31 | <AryehGregor> | If they're all the same, it should be added to the spec. |
| 18:31 | <jcranmer> | for what it's worth, elinks seems to think that a monospace font works quite well |
| 18:34 | <AryehGregor> | I imagine elinks does not closely adhere to the contents of the rendering section. |
| 18:34 | <TabAtkins> | Is elinks one of the terminal browsers? |
| 18:35 | <jcranmer> | yes |
| 18:36 | <TabAtkins> | Then it can use the limitations clause to justify its breakage of various parts of the spec. ^_^ |
| 18:37 | <jcranmer> | well, I'm sure you could have a terminal that uses serif fonts |
| 18:37 | <jcranmer> | I don't think anyone wants to have such a thing |
| 18:37 | <jcranmer> | but it's possible |
| 18:37 | <AryehGregor> | Related to lynx. |
| 18:37 | <AryehGregor> | Thus the name. |
| 18:37 | <TabAtkins> | It'd still probably end up rendering it monospace, right? |
| 18:37 | AryehGregor | just uses lynx when he needs a text browser |
| 18:37 | <TabAtkins> | AryehGregor: Yeah, I suspected. |
| 18:37 | <TabAtkins> | Me too. |
| 18:37 | <AryehGregor> | There's technically no rule that terminals have to be monospace. |
| 18:38 | <AryehGregor> | You could use Arial for your terminal if you really wanted. |
| 18:38 | <TabAtkins> | Hm, I guess so. You'd probably make a lot of things render really weird. |
| 18:38 | <AryehGregor> | Needless to say, yeah. |
| 18:38 | <JonathanNeal> | So, if all browsers have followed 16px serif are you saying it should seriously be considered for the spec? |
| 18:38 | <AryehGregor> | These browsers probably output ASCII art, too. |
| 18:38 | <AryehGregor> | JonathanNeal, yes, that may as well be added to the rendering section. |
| 18:39 | <TabAtkins> | If websites are designed taking advantage of the consistency (which I'm sure they are), then yes. |
| 19:10 | <dglazkov> | I think your last email was good, TabAtkins, but not sure yet whether the explanation is super clear :) |
| 19:10 | <dglazkov> | I wonder if Boris hangs out here, maybe it's best to 'splain in irc? |
| 19:12 | <TabAtkins> | Doesn't look like he does. |
| 19:13 | <dglazkov> | :( |
| 19:13 | <TabAtkins> | I hear they have an entire IRC network to themselves, though. ^_^ |
| 19:14 | <Philip`> | Themselves plus the spammers |
| 19:15 | <AryehGregor> | He's here sometimes. |
| 19:15 | <AryehGregor> | I think. |
| 19:15 | <AryehGregor> | Apparently not often. |
| 19:23 | <annevk> | I managed to reduce my encoding dataset to 89 variants on the train. This is probably as good as it is going to get. |
| 19:25 | <annevk> | Why isn't the CSS-based XBL part of the discussion yet? |
| 19:25 | annevk | thought that was rather interesting |
| 19:26 | <TabAtkins> | One piece at a time. ^_^ |
| 19:26 | <annevk> | Euhm, no? |
| 19:26 | <annevk> | I don't want XBL twice. |
| 19:27 | <TabAtkins> | Nah, I meant that we're trying to discuss one thing at a time. |
| 19:27 | <TabAtkins> | Agreed that we don't want XBL twice. This should all be part of the same framework. |
| 19:28 | <annevk> | By putting it in CSS it is somewhat more clear that it is immutable, maybe... |
| 19:28 | <annevk> | Doing that at a markup level is somewhat weird... |
| 19:28 | <annevk> | All markup so far can be scripted, after all. |
| 19:28 | <TabAtkins> | We don't always want it to be immutable, though. |
| 19:30 | <dglazkov> | what's immutable? |
| 19:30 | <annevk> | Well, the current proposal was to make the templates immutable, right? |
| 19:31 | <annevk> | But then CSS can be scripted too so I guess my comparison does not hold... |
| 19:31 | <dglazkov> | annevk: ah. gotcha |
| 19:31 | <dglazkov> | annevk: no, the idea is that you can mutate templates all you want -- it just won't affect the existing instances |
| 19:31 | <TabAtkins> | No, templates are mutable too. The point is that once you *apply* a template all the informatino in it is cloned out, so you can forget about the template it came from. |
| 19:32 | <annevk> | Ah, so when you add new elements the template would apply to you get it with changes? |
| 19:32 | <Hixie> | would be nice to have a way to do it all from CSS |
| 19:32 | <dglazkov> | like you bend your cookie cutter to make tree-shaped cookies, and then into a man-shaped cookies. The re-bending shouldn't change all your tree-shaped cookies into man-shaped cookies :) |
| 19:32 | <Hixie> | even if it just means having "HTML islands" in CSS files |
| 19:32 | <dglazkov> | Hixie: eeew |
| 19:32 | <annevk> | It would obsolete the whole need for all these crazy pseudo-elements in CSS... |
| 19:32 | <annevk> | Which is a win, I think. |
| 19:33 | <dglazkov> | Hixie: that was an instinctive reaction, but now that I think about it ... |
| 19:33 | <Hixie> | yeah |
| 19:33 | <Hixie> | same here |
| 19:33 | <dglazkov> | you could devise easier parsing rules |
| 19:33 | <Hixie> | at first i'm like "ew" |
| 19:33 | <Hixie> | and then i'm like "well" |
| 19:33 | <dglazkov> | <template><tr></template> |
| 19:33 | <Hixie> | and then i'm like "hmm" |
| 19:34 | <annevk> | dglazkov, like WebSRT parsing rules maybe? |
| 19:34 | dglazkov | looks up WebSRT |
| 19:34 | <Hixie> | there's definitely a lot to define if we go that route |
| 19:34 | <TabAtkins> | That... might help with the crazy parsing rules. |
| 19:34 | <annevk> | (at least the markup subset) |
| 19:34 | <Hixie> | annevk: i don't think the websrt parsing rules would really fit, but yeah |
| 19:35 | <dglazkov> | holy crap you guys are crazy |
| 19:35 | <dglazkov> | sorry, just started reading websrt |
| 19:36 | <annevk> | dglazkov, <evil laugh here> |
| 19:37 | <dglazkov> | I think I am going to go ahead and not read it. Just annevk's blog post is fine. Otherwise, I might go Scanners |
| 19:38 | <dglazkov> | ok, you may have something there Hixie -- about HTML islands in CSS. Even though it sounds disgusting. It's like that nordic fish dish or something. |
| 19:40 | <Hixie> | yeah it's definitely not aestheticaly obvious |
| 19:41 | <dglazkov> | but would allow avoiding using processing directives I think |
| 19:42 | <TabAtkins> | If we went the "HTML Islands" route, I'd probably see if we could just reuse Anne's XML5. |
| 19:44 | TabAtkins | wants to file a bug to deprecate <input type=reset>, and then file bugs on each browser to remove support so they're a noop. |
| 19:45 | <Dashiva> | "Please upgrade to an older browser to use reset buttons" |
| 19:45 | <TabAtkins> | Yus. |
| 19:46 | <TabAtkins> | Nobody actually uses them. Except me, accidentally. |
| 19:47 | <othermaciej> | TabAtkins: there doesn't seem to be much upside to removing support |
| 19:48 | <annevk> | seem kind of useful for a preferences panel |
| 19:49 | <TabAtkins> | othermaciej: The upside is that I stop resetting forms accidentally. |
| 19:49 | <Dashiva> | Add a confirmation dialog preference setting option |
| 19:54 | <dglazkov> | roc: do you know how to summon Boris? :) |
| 19:55 | <dglazkov> | I think TabAtkins' explanation is pretty good -- agian :) |
| 19:57 | <othermaciej> | TabAtkins: I guess the term in my utility function representing your convenience doesn't have a very high coefficient |
| 19:58 | <TabAtkins> | othermaciej: Get a better utility function. |
| 20:10 | <MrWax> | Does anyone know when likely we will be able to implement offline cache db's with HTML5 ? I mean when more than just FF (Indexeddb) support it? |
| 20:23 | <dglazkov> | ok, I don't like HTML Islands again. Because now you can't build templates imperatively. |
| 20:23 | <dglazkov> | and they're not DOM. |
| 20:23 | <annevk> | CSS has an API |
| 20:23 | <dglazkov> | so you can't refer to them |
| 20:24 | <annevk> | pretty sure we could have all of that |
| 20:24 | <annevk> | not sure if we want that though |
| 20:24 | <dglazkov> | annevk: ah, build templates imperatively as part of CSSOM? |
| 20:25 | <annevk> | something like that |
| 20:25 | <annevk> | they could be DocumentFragment or some such |
| 20:25 | <annevk> | or just an Element I guess |
| 20:42 | <dglazkov> | interesting. I think the idea is at least worth experimenting with |
| 21:20 | <dglazkov> | annevk, Hixie: are you going to float this idea to public-webapps? |
| 21:23 | <annevk> | I hope Hixie will; I don't quite have the full picture |
| 21:23 | <dglazkov> | Hixie: it seems there's a fairly broad agreement about templates being non-reflective. Should I document this in a bug somewhere or what do I do? Teach me the proces, Master |
| 21:23 | <annevk> | I just thought it should be considered in the XBL discussion as it seemed like a nice enough idea |
| 21:26 | <annevk> | dglazkov, it being documented in email should be sufficient assuming Hixie will continue to be the editor of that document |
| 21:26 | <dglazkov> | annevk: great! |
| 21:29 | <zcorpan> | dglazkov: how about "HTML Components"? |
| 21:29 | <annevk> | dglazkov, btw, http://www.w3.org/TR/NOTE-HTMLComponents |
| 21:29 | <annevk> | aah, zcorpan won |
| 21:29 | <dglazkov> | zcorpan: sure, sounds good :) |
| 21:30 | <zcorpan> | wow, i didn't know they made a w3c spec for it |
| 21:30 | <dglazkov> | it's not a spec, it's a note. Which means we can take the name, right? |
| 21:30 | dglazkov | knows nothing about standards process. |
| 21:30 | <dglazkov> | except that it's painful |
| 21:31 | <annevk> | names are not really reserved, but picking a name that does not conflict with what Microsoft did might be wise |
| 21:31 | <dglazkov> | "The spec formerly know as XBL2" |
| 21:32 | <dglazkov> | know->known drats |
| 21:32 | <dglazkov> | DOM Chunks |
| 21:32 | <dglazkov> | :D |
| 21:33 | <annevk> | ooh, new Opera build is significantly better |
| 21:33 | <annevk> | at least in terms of tab space allocation |
| 21:34 | <annevk> | DOM Chunks haha |
| 21:34 | <zcorpan> | same as in previous build. keep up! or, i mean, you're on vacation, go away :P |
| 21:34 | <annevk> | though it would have to be Web Chunks ;p |
| 21:34 | <dglazkov> | :) |
| 21:34 | <zcorpan> | Web Slices? oh wait |
| 21:36 | <dglazkov> | I don't see a problem with using Web Components |
| 21:37 | <dglazkov> | It's not like Oracle is going to come at us for naming the spec Web SQL Database :) |
| 21:37 | <dglazkov> | and it makes good sense |
| 21:41 | <annevk> | If it is going to be part of HTML it will just be part of HTML... No separate name needed. If it is going to be part of CSS I suspect something like CSS Components Module... |
| 21:46 | <TabAtkins_> | Well, it's still useful to have a name for the chunk, like Web Storage or Server-Sent Events have. |
| 21:46 | <TabAtkins_> | dglazkov: "maximum-pleasure encapsulation" makes me feel dirty inside. |
| 21:51 | <dglazkov> | TabAtkins_: mission accomplished! |
| 22:04 | <zcorpan> | fwiw, i recall that when i was a beginner with html and css, i wanted a way to put html in css |
| 22:05 | <jlebar> | Hixie, ping? |
| 22:09 | <roc> | dglazkov: he's bz |
| 22:09 | <dglazkov> | roc: thanks! |
| 22:10 | <roc> | not currently online it seems |
| 22:13 | <Aleoss> | "Bad value tablist for attribute role on element ul." How is this possible? According to the HTML5 spec, "tablist" is a valid role attribute value for the ul element. |
| 22:18 | <Aleoss> | http://www.whatwg.org/specs/web-apps/current-work/#annotations-for-assistive-technology-products-%28aria%29 |
| 22:23 | <Aleoss> | Anyone? |
| 22:27 | <zcorpan> | Aleoss: http://bugzilla.validator.nu/ |
| 22:28 | <Aleoss> | zcorpan: That requires that I register there. |
| 22:28 | <zcorpan> | yes? |
| 22:29 | <zcorpan> | send email to hsivonen⊙if if you don't want to register |
| 22:31 | jgraham | is impressed that dglazkov managed to turn the XBL2 discussion into a naming bikeshed so early and so eagerly |
| 22:32 | <annevk> | haha http://www.flickr.com/photos/tantek/5218572290/ CSS WG in action |
| 22:32 | <jgraham> | I vote for WebCOM, of course. Because what could be make web developers feel more like Real Programmers (TM) than using COM |
| 22:32 | <dglazkov> | jgraham: :D |
| 22:33 | <dglazkov> | jgraham: to be fair, I did create a separate thread. |
| 22:33 | <jgraham> | dglazkov: :) |
| 22:49 | <bga_> | WebCOM? |
| 22:49 | <bga_> | is it COM for web |
| 22:50 | <bga_> | i mean http://en.wikipedia.org/wiki/Component_Object_Model |
| 22:52 | <bga_> | ah sorry |
| 22:52 | <bga_> | i see |
| 23:46 | <Hixie> | jlebar: pong |
| 23:46 | <Hixie> | dglazkov: the e-mail thread is in my "XBL" pile |
| 23:47 | <Hixie> | TabAtkins_: re type=reset, what you should instead do is lobby browsers to implement "undo"-level functionality for the button |
| 23:47 | <Hixie> | TabAtkins_: so that you can just go Edit>Undo after accidentally clicking the button, and have the UA refill in all the controls |
| 23:49 | <Hixie> | dglazkov: re the name, if it becomes part of HTML then the name will just disappear |
| 23:49 | <Hixie> | if it becomes part of CSS then the name will change similarly |
| 23:49 | <Hixie> | so I wouldn't worry about it |
| 23:50 | <Hixie> | (if it becomes part of CSS it'll become BECSS) |
| 23:55 | <dglazkov> | I don't think it's CSS-ey spec |
| 23:55 | <dglazkov> | but I understand what you're saying |
