| 00:02 | <erlehmann> | TabAtkins, I asked the alpha gradients question to several people at an extended family gathering. most “non-IT” people initially insist that while the description “50% translucent blue” is understandable (if you have some opaque reference blue), “fully transparent” is something that neither should nor could not be assigned a color in some meaningful way. |
| 00:03 | <Dashiva> | Fully transparent black is a rather amusing concept |
| 00:03 | <TabAtkins> | That matches my thoughts exactly, erlehmann. The fact that "transparent" has a color in the standard rgba syntax is an accident of notation, and shouldn't be considered meaningful imo. |
| 00:04 | <Dashiva> | The downside is that the IPU is no longer a paradox |
| 00:04 | <othermaciej> | it's a coordinate singularity |
| 00:04 | <erlehmann> | indeed |
| 00:05 | <TabAtkins> | Anyway, my mind's made up on the matter. We use premultiplied in CSS transitions and gradients, and that's that. |
| 00:05 | <erlehmann> | And this is why the common sense approach — linear transitioning each value, but having several colors that look transparent, thus using "fully transparent red" when the gradient includes red and "fully transparent blue" — breaks down as soon as we allow that gradients can have more than two control points: It is simply not possible to go from red to transparent to blue then while conforming to our intuition regarding hues. |
| 00:05 | <TabAtkins> | Right. |
| 00:06 | <TabAtkins> | I don't even want to consider how you would apply that approach to a mesh gradient. |
| 00:06 | <erlehmann> | TabAtkins, The end of the story was rather satisfying: My brother sketched a a circle with hue transitions around the border and a transparent center point; thus treating the hue as angle and transparency as radius. It was obvious that using simple vector addition, we could go from every point to every other one and adding more dimensions would preserve this capability. |
| 00:06 | <erlehmann> | And I think sketching out that colorspace further gave us premultiplying. ;) |
| 00:07 | <TabAtkins> | Yeah, it does. |
| 00:07 | <TabAtkins> | In hsla, the premultiplied space is a hypercone. |
| 00:07 | <TabAtkins> | (It's a hyper-triangular prism or whatever in rgba space, but same deal.) |
| 00:10 | <Hixie> | erlehmann: wouldn't you go red -> transparent red -> transparent blue -> blue ? |
| 00:10 | <bckenny> | yes, premultiplied alpha has been the only sane way to do it for like 25 years now |
| 00:10 | <bckenny> | the only problem is precision, but graphics libraries shouldnt be filtering on 8 bit linear color anyway... |
| 00:10 | <TabAtkins> | Hixie: The point is that having to explicitly put in *two* transparent colors is silly. |
| 00:11 | <TabAtkins> | linear-gradient(red, rgba(255,0,0,0) 50%, rgba(0,0,255,0) 50%, blue) is ridiculous. It should just be linear-gradient(red, transparent, blue) |
| 00:12 | <Hixie> | no disagreement from me there |
| 00:12 | <erlehmann> | Hixie, it is not only weird notation, you also cannot express something that from intuition has 3 control points reliably with that — as soon as something has alpha, all is lost. |
| 00:12 | <erlehmann> | so for opaque: red -> green -> blue i can use 3 points. but for transparent i'd need four. weird, wouldn't it be? |
| 00:13 | <Hixie> | well we could certainly make the browsers magically expand "transparent" to two colours in a list of colours like that |
| 00:14 | <erlehmann> | DON'T. ;_; |
| 00:14 | <TabAtkins> | We could. Or we could just work in premultiplied space, where that comes for free. |
| 00:14 | <Hixie> | sounds good to me! |
| 00:14 | <TabAtkins> | (And the "auto-expanding" doesn't work for gradients with non-colinear color-stops, like mesh gradients.) |
| 00:15 | <Hixie> | (how does it just work in premultiplied space?) |
| 00:15 | <TabAtkins> | Hixie: I've already suggested it on the list. Moz and Webkit are in favor. ^_^ |
| 00:15 | <erlehmann> | TabAtkins, is this referring (or “refering”) to canvas gradients? <TabAtkins> Anyway, my mind's made up on the matter. We use premultiplied in CSS transitions and gradients, and that's that. |
| 00:16 | <TabAtkins> | Hixie: In premultiplied, the space of possible colors shrink as the alpha drops, with transparent itself being the only possible color at alpha=0. The particular transformation of the color-space that this implies means that a straight line from a solid color to transparent always passes through equal-hued variants of the color. |
| 00:16 | <Philip`> | (Even if you don't want it to pass through equal-hued variants :-p ) |
| 00:17 | <erlehmann> | it's my brother's napkin-sketch circle, only in THREE DEE! |
| 00:17 | <erlehmann> | Philip`, think outside the cone! |
| 00:17 | <TabAtkins> | (Properly, the number of possible colors doesn't shrink, but the range you can specify does. If you specify colors with discrete components like integers, it reduces the total number of colors, but theoretically there is still the same amount until you hit alpha=0.) |
| 00:17 | <erlehmann> | oh wait, it's 4D. |
| 00:17 | <Hixie> | so going from red to blue via transparent will still have you darkening the colour in the middle? |
| 00:18 | <TabAtkins> | Hixie: No, it looks exactly like it would if you did the two-transparent version. |
| 00:19 | <Hixie> | i'll take your word for it :-) |
| 00:19 | <TabAtkins> | Particularly, things like a transition from white->transparent composited on a white background will be properly invisible, rather than going to a gray in the middle. |
| 00:19 | <Hixie> | well that sounds like a win |
| 00:19 | <TabAtkins> | Hixie: I can draw you diagrams that would make it clearer, but IRC-sized soundbites are hard to communicate color math through. |
| 00:19 | <Hixie> | no need, i have every confidence in your abilities :-) |
| 00:20 | Hixie | goes back to trying to work out how navigation should work during load |
| 00:20 | <TabAtkins> | Heh, I just properly learned my color-math last week. Before this I was trusting *Boris's* abilities, which admittedly is a pretty good idea in general. |
| 00:20 | <erlehmann> | Hixie, basically, the alpha is the lower bound for the rest of the values, since every value gets multiplied with the alpha. you can see, 50% transparent dark-gray should not occur naturally. |
| 00:21 | <TabAtkins> | Nonono, 50% transparent dark gray is perfectly fine. |
| 00:21 | <erlehmann> | I mean in that whitey transition. |
| 00:22 | <TabAtkins> | Oh, okay. |
| 00:22 | <erlehmann> | white -> transparent |
| 00:22 | <TabAtkins> | But still, saying "the alpha is the lower bound for the rest of the values" isn't right. First, it's an upper bound, and second, it's not actually a bound. |
| 00:22 | <erlehmann> | oh. |
| 00:22 | <TabAtkins> | Not in the way that saying that naively implies. |
| 00:22 | <jamesr__> | AryehGregor: yt? |
| 00:22 | <AryehGregor> | jamesr__, yes. |
| 00:22 | <AryehGregor> | (briefly) |
| 00:23 | <TabAtkins> | Yes, the 4-tuple representing a premultiplied color has no components higher than the alpha. But that's a notational convenience. |
| 00:23 | <erlehmann> | TabAtkins, I retract my statement and state the opposite. And yes, I relied on custom of notation. |
| 00:23 | <TabAtkins> | It doesn't imply that any colors are omitted. A color like rgba(0,0,255,.5) is just represented as (0,0,127.5,.5) in the premultiplied tuple, but it represent the same full-blue color. |
| 00:24 | <Hixie> | so how do you represent rgb(0,0,127.5) with 50% transparency? |
| 00:24 | <TabAtkins> | (half-transparent half-full blue, like rgba(0,0,127,.5), is instead written as (0,0,63.5,.5).) |
| 00:24 | <Hixie> | ah |
| 00:24 | <erlehmann> | ba-dum. tssss. |
| 00:25 | <Hixie> | so how do you know what colour you're representing when alpha=0? |
| 00:25 | <AryehGregor> | You're representing "transparent". |
| 00:25 | <TabAtkins> | You're *not* representing a color - that's the point. |
| 00:25 | <TabAtkins> | transparent is hueless. |
| 00:25 | <AryehGregor> | The other channels are fairly useless in that case, after all. |
| 00:25 | <TabAtkins> | So, as an example of why this is good, say you're transitioning from blue to transparent. |
| 00:26 | <TabAtkins> | Start by converting to components - rgba(0,0,255,1) and rgba(0,0,0,0). |
| 00:26 | <TabAtkins> | Then convert to premultiplied tuples - (0,0,255,1) and (0,0,0,0). |
| 00:26 | <erlehmann> | Hixie, on the risk of being corrected again: it's the tip of the hypercone. all unmultiplied RGB colors with full transparency are mapped to it. |
| 00:26 | <TabAtkins> | Then linearly interpolate. |
| 00:27 | <TabAtkins> | Halfway through, you have the premultiplied color (0,0,127.5,.5). Convert that back to rgba space by dividing each component by the alpha, and you find that this is the representation for the color rgba(0,0,255,.5). |
| 00:27 | <Philip`> | One problem is when you need to convert from premultiplied to non-premultiplied, for (0,0,0,0) you have to arbitrarily pick some non-premultiplied colour which is typically (0,0,0,0) but there's no justification for that |
| 00:27 | <Hixie> | so if you're going from white to transparent, why don't you go through grey? isn't one of the interpolated colours going to be (127,127,127,0.5)? |
| 00:27 | <AryehGregor> | Hixie, yes, but in postmultiplied form that's (255, 255, 255, 0.5). |
| 00:28 | <AryehGregor> | You only use the premultiplied form for interpolation, not rendering. |
| 00:28 | Hixie | hugs the html parser like a safety blanket |
| 00:28 | <AryehGregor> | Careful, it's spiky. |
| 00:28 | <TabAtkins> | Hixie: Yeah, it will. Now, convert that tuple back to rgba by dividing each component by the alpha. |
| 00:28 | <TabAtkins> | (You converted from rgba to premult by multiplying each component by the alpha, so dividing is the obvious inverse transform.) |
| 00:29 | <AryehGregor> | Now, what happens when you interpolate between two colors where an intermediate color is imaginary? I.e., it doesn't physically exist and can't be displayed? Someone asked that on the list, and I thought it was a cool question, although it's kind of irrelevant to standard monitors. |
| 00:29 | <AryehGregor> | I guess the UA rounds to the nearest existing color. I wonder how that would look in practice, though. |
| 00:29 | <TabAtkins> | AryehGregor: The obvious thing. You get an imaginary color at some points, which is mapped to an in-gamut color, usually by clipping component-wise. |
| 00:29 | <bckenny> | wait wait, no need to translate back to unpremultiplied |
| 00:30 | <TabAtkins> | AryehGregor: Actually, you often use the premultiplied for rendering as well, because it actually simplifies the compositing math. |
| 00:30 | <erlehmann> | bckenny, ? |
| 00:30 | <bckenny> | (127,127,127,0.5) is half transparent, so when its composited it takes half of the background components and adds 127 to them |
| 00:30 | <TabAtkins> | However, we're used to seeing colors in the rgba space, so it's useful to convert back when talking about colors. |
| 00:30 | <AryehGregor> | Okay, well, I mean that what's displayed is the same as what you get if you specify rgba(255, 255, 255, 0.5) in CSS. |
| 00:30 | <TabAtkins> | Yes. |
| 00:30 | <bckenny> | compositing is color = background * (1-alpha) + foreground |
| 00:31 | <erlehmann> | keep premultiplied for compositing, win price! |
| 00:31 | <bckenny> | so over white, white to transparent would stay white, but over black it would indeed be grey halfway through...but thats what half transparent white over black looks like |
| 00:32 | <bckenny> | ah, sorry, TabAtkins was saying the same thing simultaneously |
| 00:42 | <TabAtkins> | AryehGregor: Unfortunately, Alan Gresley (the guy who asked the question about imaginary colors) doesn't really know what he's talking about. I answered his questions (they're all trivial), but he's very confused about how colors work. |
| 00:42 | <MikeSmith> | commits feed at CIA.vc for the spec appears to be working now |
| 00:42 | <MikeSmith> | http://cia.vc/stats/project/html-spec/.rss |
| 00:43 | <MikeSmith> | I guess I'll need to tweak it to filter only on one of the files |
| 00:43 | <MikeSmith> | because the way it is now, it will send duplicates each time |
| 00:55 | <jamesr__> | AryehGregor: sorry ran off. still there? |
| 00:56 | <jamesr__> | i'm seeing some really slow script on wikipedia.org and want to report it but dunno where |
| 01:00 | <TabAtkins> | Pretty sure he's gone by now, jamesr__ - Aryeh's on east coast time. |
| 01:01 | <jamesr__> | it's only 8pm :P |
| 01:01 | <gsnedders> | It's only 1am. |
| 01:01 | <gsnedders> | There again, I'm a student, so what do people expect? :P |
| 01:05 | <nessy> | it's midday, don't know what you're talking about! |
| 01:11 | <Hixie> | Philip`: yt? |
| 01:54 | <MikeSmith> | I have http://twitter.com/html5 working again |
| 01:54 | <Hixie> | cool |
| 01:55 | <Hixie> | were you using my code before? |
| 01:55 | <Hixie> | and if so, does that mean your new code is a drop-in replacement? :-0) |
| 01:55 | <Hixie> | s/0// |
| 03:06 | <oojacoboo> | anyone know if <figcaption> can be used block level with nested elements ? |
| 03:07 | <oojacoboo> | I am looking to use it in a case with a legend |
| 03:07 | <oojacoboo> | where I have a figure with number representing sections of a screenshot, and want to use <figcaption> with an ordered list to describe the points of the figure |
| 03:24 | <MikeSmith> | feeling an earthquake just now in Tokyo |
| 03:24 | <MikeSmith> | pretty decent size |
| 03:35 | <aaaazzz> | MikeSmith: "6.9 earthquake hits 502 miles South of TOKYO, Japan " |
| 03:35 | <aaaazzz> | MikeSmith: http://earthquake.usgs.gov/earthquakes/recenteqsww/Maps/region/Asia.php |
| 03:35 | <oojacoboo> | ha, wow |
| 03:36 | <oojacoboo> | I was living in Taipei a few months back and we'd get earthquakes all the time |
| 03:36 | <oojacoboo> | once every month or so |
| 03:36 | <MikeSmith> | aaaazzz: thanks |
| 03:37 | <MikeSmith> | that thing must have been pretty strong in Okinawa |
| 03:37 | <aaaazzz> | note the big red square. that's an earthquake in the last few minutes. |
| 03:37 | <oojacoboo> | 6.9 is decent, but not for Japan, the buildings there handle that with ease |
| 03:37 | <oojacoboo> | probably not much damage |
| 03:38 | <MikeSmith> | oojacoboo: I think there are earthquakes in Japan pretty much everyday; just that most of them are not very strong at all |
| 03:38 | <oojacoboo> | it's like that most all places on faults |
| 03:38 | <oojacoboo> | 1-2-3-4 scale quakes |
| 03:39 | <oojacoboo> | you can start to feel it in the upper 4s and 5s, of course, depending on the depth of the quake itself |
| 05:14 | <JonathanNeal> | Anyone here good with javascript and ranges? |
| 08:21 | <MikeSmith> | http://p2pdns.baywords.com/2010/11/30/hello-world/ |
| 08:44 | <Dashiva> | Will they be leveraging the web of trust? |
| 09:18 | <jgraham> | Aren't we onto the Web 2.0 of Trust now? The one where you trust facebook for everything? |
| 10:04 | <Workshiva> | jgraham: I think that requires Semantic Web 2.0 to work |
| 10:07 | <jgraham> | hsivonen: BTW there is now an "official" call for comments about testharness.js on public-html-testsuite |
| 10:12 | <hsivonen> | jgraham: thanks |
| 10:17 | <hsivonen> | my computer use experience became so much better after I patched libgtk-vnc. I guess I should attempt patching libvte again |
| 10:18 | <hsivonen> | maybe I should try patching xserver-xorg-input-wacom, too |
| 10:27 | <Philip`> | Hixie: Pong |
| 10:59 | <MikeSmith> | hsivonen: so we've gotten multiple reports about validator error messages for src-less script elements being confusing/misleading |
| 11:00 | <MikeSmith> | specifically, for the case where you have a script element with an inline script |
| 11:00 | <MikeSmith> | that is, non-empty |
| 11:00 | <MikeSmith> | but you have, e.g., a charset attribute on it |
| 11:20 | <annevk> | strings over enums |
| 11:20 | <annevk> | it does make some sense |
| 11:35 | <hsivonen> | MikeSmith: well, I suppose hacking Jing would be too hard |
| 11:35 | <hsivonen> | MikeSmith: so I guess this needs to move to assertions.sch/Assertions.java :-( |
| 11:35 | <MikeSmith> | yeah |
| 11:35 | <MikeSmith> | hsivonen: I think that's the easiest thing |
| 11:35 | <MikeSmith> | I'm working on it now |
| 11:44 | <MikeSmith> | hsivonen: please try <script defer>var foo;</script> or something at http://www.w3.org/html/check and let me know what you think |
| 11:44 | <MikeSmith> | or async or charset |
| 11:48 | <hsivonen> | MikeSmith: looks good |
| 11:48 | MikeSmith | steps away for a bit |
| 11:48 | <MikeSmith> | ah cool |
| 11:48 | <MikeSmith> | I'll send you a patch to review |
| 11:48 | <hsivonen> | ok |
| 11:48 | <MikeSmith> | thanks |
| 11:48 | hsivonen | wonders how to do printf debugging with X input drivers |
| 11:49 | <hsivonen> | maybe there's a function for dumping stuff in the X server log or something |
| 12:04 | <hsivonen> | http://timesofindia.indiatimes.com/cms.dll/xml/uncomp/articleshow?msid=167551 gives me the YSoD (link from Hixie's anti-XSLT blog post from years ago) |
| 12:05 | <annevk> | "non-xslt top-level element with null namespace uri" |
| 12:05 | <annevk> | good times |
| 12:06 | <annevk> | "That is not possible. Developers would fix the mistake before it hits users." |
| 12:10 | <jgraham> | Maybe the error message should read "Something impossible just happened. If you have any feedback on our handling of this issue, please contact tbray⊙tc" |
| 12:12 | <annevk> | "Also, the author of this site is a bozo." |
| 12:34 | <annevk> | "and had several off-line meetings with the HTML5 chairs" -- http://www.w3.org/QA/2010/11/progress_in_lyon_-_tpac_2010.html -- such usage of "offline" always strikes me as weird |
| 12:36 | <annevk> | "One piece of advice from the AB was to support our current policy of having dues paid in three currencies; even as they advised that this should be reviewed on a regular basis." |
| 12:36 | <annevk> | ?! |
| 12:39 | <jgraham> | You have to pay 1/3 in each currency? |
| 12:40 | <annevk> | no, depends on which W3C host you're associated with |
| 12:41 | <annevk> | I just don't see how the above is advice |
| 12:43 | <hsivonen> | annevk: is trimming whitespace before comparing encoding names an HTML thing or a Web Platform thing? |
| 12:43 | <hsivonen> | that is, should I fix it in the HTML parser or in Gecko's charset alias service? |
| 12:43 | <annevk> | that is a good question |
| 12:44 | <annevk> | and I don't really know; guess it depends on what happens in XML |
| 12:44 | <annevk> | or you can maybe test it with charset=" ..." in HTTP, but Gecko had issues with quotes there... |
| 12:45 | <hsivonen> | what about @charset in CSS? |
| 12:46 | <annevk> | yeah |
| 12:46 | <annevk> | though I guess it ought to be tested in IE |
| 12:46 | <annevk> | and I don't have Windows yet so I cannot help |
| 12:48 | <hsivonen> | ok. |
| 12:50 | <jgraham> | annevk: The case shifting for getAttribute et. al. should happen for any node in a HTML document, right? |
| 12:51 | <annevk> | yes |
| 12:51 | <hsivonen> | no, no |
| 12:51 | <annevk> | oh wait |
| 12:51 | <jgraham> | So how does one deal with foreign content where the name is case shifted |
| 12:51 | <hsivonen> | only if the element is in the HTML namespace |
| 12:51 | <annevk> | rtfs instead |
| 12:51 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html |
| 12:51 | <jgraham> | Ah, somehow I missed the first clause |
| 12:52 | <jgraham> | Sorry for being sumb |
| 12:52 | <jgraham> | *dumb |
| 14:03 | <hsivonen> | does anyone happen to have CSS @charset tests with spaces inside the quoted string? |
| 14:03 | <hsivonen> | (I could make some, but I think I've configured my servers to send a HTTP-level charset for CSS...) |
| 14:06 | <annevk> | you could check if Content-Type: text/html;charset="utf-8" works in IE and then play with that |
| 14:09 | <hsivonen> | I think I'll make a zip file of my test and run it locally on Windows |
| 14:11 | <hsivonen> | Gecko rejects CSS with bogus @charset |
| 14:11 | <hsivonen> | Chrome uses the default charset |
| 14:13 | <hsivonen> | annevk: IE9 doesn't trim spaces in CSS @charset |
| 14:14 | <hsivonen> | and rejects the sheet |
| 14:14 | <hsivonen> | annevk: I guess that makes the behavior of Opera 11 beta a bug |
| 14:14 | <hsivonen> | (Opera 11 beta trims space) |
| 14:19 | <annevk> | hmm |
| 14:19 | <annevk> | I guess only case-insensitive matching is a platform thing then |
| 14:19 | <annevk> | does Opera 11 beta no longer do UTS22? |
| 14:20 | <annevk> | in other news |
| 14:20 | <annevk> | if you define an attribute for the web platform |
| 14:20 | <annevk> | and its setter sometimes throws and only accepts certain values |
| 14:21 | <annevk> | but eventually the attribute "becomes" that value |
| 14:21 | <annevk> | it would be nice if that didn't require a separate variable |
| 14:21 | <annevk> | e.g. http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-withcredentials-attribute has a separate "credentials flag" |
| 14:22 | <annevk> | which is really just reflecting the attribute |
| 14:22 | <annevk> | could I say for step 4 "set the withCredentials attribute to the given value" |
| 14:23 | <annevk> | if you read that literally I guess you would get recursion... |
| 14:23 | <annevk> | bah |
| 14:25 | <annevk> | set the withCredentials attribute value to the given value makes it work, I think |
| 14:25 | <annevk> | Hixie did something like that in the <canvas> API |
| 14:35 | <annevk> | heycam, maybe Web IDL should have support for "string enums" |
| 14:35 | <annevk> | heycam, i.e. attributes that accept a limited amount of string values |
| 14:36 | <annevk> | heycam, it's an extensible pattern that is used quite a lot |
| 14:57 | <hsivonen> | is hixie.ch down? |
| 14:57 | <hsivonen> | ah just really slow |
| 15:42 | <annevk> | heycam, I emailed public-script-coord with somewhat more context |
| 15:52 | <annevk> | RESOLVED: The TAG endorses the health warning "If you deploy a 30x Location: C#D, then be aware that anyone who creates a URI A#B, might be inconvenienced (since there are no fragment combination rules)." |
| 15:52 | <annevk> | oh god |
| 15:52 | <annevk> | this is the first time I have seen a RESOLVED from the TAG |
| 15:52 | <annevk> | does this mean they don't do much? |
| 15:54 | <webr3> | no they were just jammed in a corner and that was the best all round advise for the web - real solution would be to drop frags from HTTP alltogether, Location should be an absolute or relative-uri and not oen with clientside identifiers in it |
| 15:55 | <webr3> | hard to fix deployed mistakes, so can only offer best practise advice in those circumstances |
| 15:55 | webr3 | imo |
| 15:56 | <zcorpan> | better to tell people that they should know that they're inconveniencing other people (how they're being inconvenienced i have no idea) |
| 15:57 | <annevk> | the problem is that fragment identifiers are removed from the request |
| 15:57 | <annevk> | imo |
| 15:57 | <annevk> | and how they work with Location will become interoperable over time, pretty sure of that |
| 15:58 | <webr3> | but they were created for the client, specified by the mediattype and so that no protocol or anything on the web could have juristiction over them, if you need server to know use one of the other uri parts - like query params |
| 15:59 | <webr3> | if you make them webwide, then they are pointless and may as well just be dropped in favour of querystring only |
| 15:59 | <webr3> | webwide as in servers and protocols have knowledge |
| 15:59 | <annevk> | querystrings don't have the same features |
| 16:00 | <annevk> | but I guess if you still believe in content negotiation and such this all works differently |
| 16:02 | <webr3> | what features are missing from querystring but in fragments? (other than the clientside per mediatype nature of them) |
| 16:02 | <annevk> | in particular, you want to know the fragment identifier on the server if you moved from largedocument#foo to just foo |
| 16:02 | <annevk> | so links remain working |
| 16:05 | <webr3> | aye that's a problem for sure |
| 16:05 | webr3 | that I've avoided thus far by not makign hugedocument#foo in the first place :p |
| 16:06 | <annevk> | no blog with #comments? |
| 16:07 | <webr3> | #recentcomments and /all-comments |
| 16:09 | <webr3> | I see the problem btw, have done for ages, but think solving it in this way will create more problems, for instance how long before my blog post is just the post, and comments are pull in from other uris (and on other sites) dynamically depending on the view of the page |
| 16:09 | <webr3> | and/or client considerations |
| 16:51 | <Philip`> | jgraham: With canvas tests, I want to wait for onload and then set some variables (canvas, ctx) which all the subsequent code uses |
| 16:52 | <Philip`> | For synchronous tests, I think I can just do "test(function() { var canvas = ...; subsequent code });" and that's fine |
| 16:52 | <Philip`> | but for async tests I don't see an easy way to do that |
| 16:52 | <jgraham> | Philip`: at the moment the harness assumes that all test objects have been created before onload |
| 16:53 | <jgraham> | so you would have to do |
| 16:53 | <jgraham> | var t = async_test() |
| 16:53 | <jgraham> | addEventListener("load", function() {t.step(function() {/*do the setup here*/})}, false) |
| 16:53 | <jgraham> | or so |
| 16:54 | <jgraham> | Unless I am missing your point |
| 16:54 | <jgraham> | If you have a better way, I am open to suggestions |
| 16:58 | <Philip`> | Hmm, including the setup code that'd be like addEventListener("load", function() { t.step(function() { var canvas = ...; img.onload = t.step(function() { use canvas, img; t.done(); }); } }, false);, I think |
| 17:00 | <Philip`> | Maybe it'd be nice if I could write "var t = test(function() { var canvas = ...; img.onload = t.step(function() { use canvas, img; t.done(); }); });" |
| 17:01 | <Philip`> | Oh, actually, synchronous test doesn't wait for onload either |
| 17:01 | <Philip`> | I think |
| 17:03 | <Philip`> | so I'll have to make almost every test asynchronous (since they need to wait for images and fonts etc to load) |
| 17:05 | <jgraham> | Yeah, sync tests really are sync, they just run straight away |
| 17:08 | <jgraham> | I suppose one could have some hack like "if you pass an async test a function(){} it gets run on onload, and if that test calls a step() before onload() it is an error" |
| 17:08 | <jgraham> | s/onload/load/g |
| 17:08 | <jgraham> | and remove some () |
| 17:12 | <jgraham> | (does that sound like it would be useful?) |
| 17:13 | <Philip`> | Depends on whether running after onload is far more common than the alternative, I guess |
| 17:14 | <Philip`> | Hmm, when I said "img.onload = t.step(function() { use canvas, img; t.done(); });" I think that was wrong |
| 17:14 | <Philip`> | and it needs "img.onload = function() { t.step(function() { use canvas, img; t.done(); }); };" |
| 17:15 | <jgraham> | Well I guess there might be a large class of tests for which some resource is needed after onload |
| 17:15 | <Philip`> | Could t.step return a function that can be called later to execute the test step, rather than executing it immediately? |
| 17:15 | <jgraham> | It could |
| 17:15 | <Philip`> | so that onload = t.step(function() ...) would do the right thing |
| 17:15 | <jgraham> | Or there could be a different method for that |
| 17:16 | <jgraham> | t.step_func or something |
| 17:16 | <Philip`> | In what cases is the current t.step useful? |
| 17:16 | <jgraham> | I agree it seems like an appealing design |
| 17:18 | Philip` | can't think of any cases where he'd want t.step to execute the step immediately |
| 17:19 | <jgraham> | I guess it is always trivial to get the other behaviour, just by doing t.step(function() {})() |
| 17:20 | <jgraham> | So, yes, that seems like an improvement |
| 17:20 | <jgraham> | I guess I should email public-html-testsuite |
| 17:21 | <jgraham> | Since it is a breaking change |
| 17:22 | <Philip`> | I suppose there's no fundamental difference, it just seems more syntactically convenient to get a test-happy wrapped function you can use in async event handlers directly |
| 17:24 | <Philip`> | Then I can do var t = async_test("%(name)s"); on_event(window, "load", t.step(function() { ...; t.done(); })); which isn't terribly verbose |
| 17:27 | <jgraham> | Indeed |
| 17:34 | <Philip`> | "people who have already submitted tests" - there's less than 100 tests currently using .step, and hypothetically probably at least two orders of magnitude more tests that need to be written in the future using these functions, so it doesn't seem particularly important to maintain backward compatibility yet |
| 17:48 | <JonathanNeal> | Anyone here good with createRange, selections, etc? |
| 18:06 | <TabAtkins> | Ranges and selections confuse me. |
| 18:12 | <JonathanNeal> | TabAtkins, me too. |
| 18:12 | <JonathanNeal> | Yesterday I decided I wanted to write a wysiwyg. |
| 18:12 | <TabAtkins> | Now you have many problems. |
| 18:18 | <Workshiva> | Now you have problem{2,} |
| 18:22 | <JonathanNeal> | I like the word "issues" |
| 18:23 | Workshiva | ponders the value of changing <b> into <span> with font-weight: bold; |
| 18:24 | <TabAtkins> | Workshiva: From where? |
| 18:25 | <Workshiva> | In this page I'm working on |
| 18:26 | <Workshiva> | Well, actually, I'm moving a <th> and <td> out of a table, and to preserve the visuals I need to make the part from the th bold somehow |
| 18:27 | <Workshiva> | Some people, when presented with this problem think "I know, I'll use <b>". Now they have change comments. |
| 18:34 | beowulf | doesn't understand Workshiva's problem |
| 18:50 | <hsivonen> | TabAtkins: waht's an effective way to report a bug like https://bugzilla.mozilla.org/show_bug.cgi?id=614864 to people responsible for Google search front end code? |
| 19:01 | <TabAtkins> | hsivonen: I don't know the proper official way. I just use internal Buzz, and it finds its way to the right people. ^_^ |
| 19:02 | <TabAtkins> | I'll push it along, and also ask for a public way to report it and get back to you. |
| 19:02 | <hsivonen> | TabAtkins: thanks |
| 19:03 | <jgraham> | othermaciej: I haven't fully understood your email to public-html-testsuite, but it seems a bit like the "doctor, doctor, it hurts when I do this" joke |
| 19:03 | <othermaciej> | jgraham: look at the test I cited |
| 19:04 | <othermaciej> | jgraham: is there a way to do it "right", but still report each assertion independently in the output? |
| 19:04 | <jgraham> | You're not supposed to create multiple independent tests where the result of one depends on dom manipulation in another |
| 19:04 | <othermaciej> | I know |
| 19:04 | <othermaciej> | that's why I assume I did it "wrong" |
| 19:05 | <othermaciej> | but I like the output produced by my version a lot more than what happens if I do it in the intended way |
| 19:05 | <jgraham> | If they are logically independent tests they should have seperate test() functions |
| 19:05 | <othermaciej> | in fact, I don't see anything wrong with the way I did it, other than grungy syntax and failing to match the intended philosophy of the test framework |
| 19:06 | <othermaciej> | what if they are dependent, but I want to report each result independently? |
| 19:06 | <jgraham> | "don't do that" |
| 19:06 | jgraham | -> food |
| 19:06 | <jgraham> | biab |
| 19:06 | <othermaciej> | are you saying my use case is invalid? |
| 19:07 | <othermaciej> | I don't think having a single result line that says "The second half of the id tests, because at this point I started doing DOM mutation" would improve the quality of my tests |
| 19:07 | <JonathanNeal> | Heck yes, finally did it. |
| 19:07 | <othermaciej> | and even for fully independent tests, having to wrap it in test() { function() { assert_equals(... seems like needless verbiage |
| 19:40 | <jgraham> | othermaciej: Given the simplicity of your DOM manipulations, your test is probably fine |
| 19:41 | <othermaciej> | jgraham: besides my theoretical problem with going against the philosophy (which I'm satisfied to ignore), I think the syntax for doing a series of assertions and reporting on each independently is a bit overly verbose |
| 19:42 | <othermaciej> | for this test at least, I would have found it handy to be able to say test_equals(function() { return "foo"; }, "foo"); |
| 19:43 | <jgraham> | othermaciej: Possibly, but that seems to be optimising for your specific case |
| 19:43 | <othermaciej> | well, I expect any script test with many assertions would benefit |
| 19:43 | <othermaciej> | almost any non-trivial script test is likely to have a dozen or so assertions which are worth reporting independently |
| 19:43 | <jgraham> | It would have the side effect of moving all the calls to e.g. setAttribute out of the try/catch |
| 19:43 | <othermaciej> | the other possibility is to report each assertion, not just each test |
| 19:44 | <othermaciej> | that would have also satisfied my goals and would be syntactically nicer |
| 19:44 | <jgraham> | othermaciej: Not necessarily e.g. Opera house style is one test/file |
| 19:44 | <othermaciej> | doing this set of id tests as one test per file would be a poor way to do it |
| 19:45 | <othermaciej> | it would be even more wastefully verbose |
| 19:45 | <jgraham> | Reporting each assertion seems very bad because, by design, the number of assertions can vary |
| 19:45 | <othermaciej> | WebKit style is to put related tests for one feature in one file |
| 19:45 | <jgraham> | It seems like you can get most of what you want by having an array of functions and running each in turn |
| 19:46 | <othermaciej> | what's the reason not to report each assertion? |
| 19:46 | <othermaciej> | I do not understand the benfit of running 100 assertions and reporting only one vague pass/fail result |
| 19:46 | <jgraham> | Because one assertion might not be meaningful on its own |
| 19:46 | <jgraham> | In this case it is |
| 19:46 | <othermaciej> | yes, I could invent something myself, but I would like the test framework to be good for this kind of test |
| 19:46 | <othermaciej> | I believe it is not |
| 19:46 | <jgraham> | But in a more complex case one assertion !== one pass |
| 19:47 | <othermaciej> | you asked for feedback |
| 19:47 | <jgraham> | othermaciej: Yes, I know :) |
| 19:47 | <othermaciej> | can you give me an example of an assertion that would not be worth reporting? |
| 19:48 | <jgraham> | e.g. if you are checking that part of the dom has a given structure and you do that in several stages |
| 19:48 | <jgraham> | e.g. first you check the number of child nodes for a given element |
| 19:49 | <Philip`> | http://philip.html5.org/tests/canvas/suite/tests/2d.state.saverestore.stackdepth.html does 512 assertions and it's probably not very interesting to know that it's passed 512 of them |
| 19:49 | <othermaciej> | why would it be bad to report which of those steps failed? |
| 19:49 | <jgraham> | then you check they have the expected tag names |
| 19:49 | <jgraham> | It does report which of those steps failed |
| 19:49 | <othermaciej> | or are you saying that in some cases it might not make sense to even run the later assertions? |
| 19:49 | <jgraham> | It doesn't even run them |
| 19:49 | <othermaciej> | I can see how that is a possibility, but I suspect it is the rare case, not the common case |
| 19:50 | <jgraham> | e.g. if you find that node x has 0 children there is no point in trying to find out what their tag names are |
| 19:50 | <jgraham> | and indeed if you do try you are likely to run into more problems |
| 19:51 | <jgraham> | (assuming you expected it to have > 0 for the test to pass) |
| 19:51 | <othermaciej> | we use assertion-style tests in WebKit (using a different harness) and I don't think we've ever had a serious problem with this |
| 19:51 | <othermaciej> | so I am skeptical that it is the common case |
| 19:51 | <othermaciej> | nontheless, if all steps of a multi-step test pass, it seems useful to report that they all passed |
| 19:51 | <othermaciej> | at the very least while developing the test, so you can confirm that all the assertions you expected to be run were run |
| 19:52 | <jgraham> | Well that is possible of course |
| 19:52 | <jgraham> | But it doesn't change the fact that, for your case, multiple test()s are the intended approach |
| 19:53 | <othermaciej> | I agree that it is intended |
| 19:53 | <othermaciej> | I find it overly syntactically inconvenient |
| 19:53 | <othermaciej> | I think this type of test is not uncommon |
| 19:54 | <othermaciej> | while writing it, I saw sicking and weinig writing similar multi-assertion tests where it was worthwhile reporting each |
| 19:54 | <othermaciej> | (it was during TPAC) |
| 19:55 | <othermaciej> | sicking ended up wrapping it all in one test(), so you only get a single pass/fail result, which is unfortunate for anyone trying to use the test to find and fix bugs |
| 19:55 | <jgraham> | So, I am open to suggestions for API changes that would improve the situation |
| 19:55 | <othermaciej> | I suggested two possibilities |
| 19:55 | <othermaciej> | if you want, I can make them more concrete and detailed |
| 19:56 | <othermaciej> | (will post details on the list in that case) |
| 19:57 | <jgraham> | I think blurring the line between an assertion and a test() is the wrong approach. I think one test() === one thing that is reported to the top level harness |
| 19:57 | <jgraham> | and one assertion === one thing required for a test to pass |
| 19:58 | <jgraham> | Adding a more convenient way to run multiple sync tests is possible |
| 19:58 | <jgraham> | Although, in all honesty, I think async tests are more common |
| 19:59 | <othermaciej> | that may be so; I chose to make a sync test because it was easier |
| 19:59 | <othermaciej> | but HTML5 has a lot of DOM interfaces that can be tested sync |
| 19:59 | <othermaciej> | I expect there could be thousands of such tests |
| 20:00 | <jgraham> | I wouldn't expect they all can (or should) be tested with assert_equals though |
| 20:00 | <jgraham> | e.g. you might well want to use assert_readonly |
| 20:00 | <othermaciej> | no, but I expect they can all be tested with the assert_* functions provided |
| 20:00 | <jgraham> | So optimising for the specific case of assert_equals seems wrong |
| 20:01 | <othermaciej> | I think another way to state my issue is this: test() combines multiple purposes |
| 20:01 | <othermaciej> | - It is the exception-catching block that prevents the test framework itself from failing to report a result |
| 20:02 | <othermaciej> | - It is the unit of result reporting |
| 20:02 | <Dashiva> | "XHTML 1.0 - the first baby step toward a well-formed, valid web." |
| 20:02 | <Dashiva> | I guess there is some truth in this, since people will never write valid HTML if we don't force them :) |
| 20:02 | <othermaciej> | - It is the unit of stop-fail combination of assertions (such that if one fails you do not run the rest) |
| 20:03 | <Hixie> | Dashiva: XHTML proponents say that it's ok to send XHTML as text/html, so how is it different? |
| 20:03 | <Hixie> | it's more like "XHTML - another step towards ensuring that all pages are invalid" |
| 20:04 | <othermaciej> | for tests where it is useful to report each test assertion separately, having all those properties for one construct, but a separate construct for the assert, is inconvenient |
| 20:04 | <othermaciej> | I'll make some concrete proposals with worked examples |
| 20:04 | <othermaciej> | I agree that adding *only* test_equals would suck, but I think adding a test_* for each assert_* is one viable option |
| 20:05 | <Dashiva> | Hixie: It introduced an optional failure point by sending as application/xhtml+xml |
| 20:05 | <jgraham> | othermaciej: If you were going to go down that path I would prefer test_assert or something where you pass the function in |
| 20:05 | <othermaciej> | another viable option is to report each assertion independently by default, and run all within a test by default, and add new constructs for the case where you want to bail after a failure, or combine reporting of several assertions |
| 20:06 | <Hixie> | Dashiva: text/html had an optional failure point too, called validation :-) |
| 20:06 | <othermaciej> | I'll post something more precise to the list later today or tomorrow |
| 20:06 | <jgraham> | I really really dislike the idea of reporting each assertion seperatly |
| 20:06 | <othermaciej> | then you can tell me what details of my proposal suck |
| 20:07 | <sicking> | jgraham: why? We do that in mochitest which we use for firefox testing. It makes writing tests quite nice |
| 20:07 | <othermaciej> | I really dislike reporting just one result for many assertions |
| 20:07 | <othermaciej> | it makes the test much less useful for a partially-conforming implementation |
| 20:07 | <othermaciej> | and it makes it harder to see what the test tested, even if it passes |
| 20:08 | <othermaciej> | if there is really a legit reason to do it in some cases, it should be an unusual case and not the default behavior |
| 20:08 | <sicking> | jgraham: one thing that you can do is to by default only print failed assertions. Then you can easily handle having literally thousands of passing assertions without making the result unreadable |
| 20:08 | <Dashiva> | Hixie: This is true, but with xhtml a server admin can disable server-side scripting and set the mime-type for .html! :P |
| 20:09 | <othermaciej> | I kind of like printing the passing assertions as well, but I can see an argument either way |
| 20:09 | <Hixie> | ah well, this is all water under the bridge anyway |
| 20:09 | <jgraham> | othermaciej: It should also be noted that test(f) is a shorthand for async_test().step(f) |
| 20:09 | <jgraham> | So the fact that test() does multiple things is just a convenience |
| 20:10 | <sicking> | othermaciej: i think it's a requirement to at least be able to hide them, but i don't care much if they are hidden or displayed by default |
| 20:10 | <sicking> | note that i think that showing/hiding should be an action the tester-person takes, not that the test itself takes |
| 20:11 | <othermaciej> | sicking: it should be easy to make a setup that can show only failures in the UI |
| 20:11 | <sicking> | othermaciej: true |
| 20:11 | <othermaciej> | also useful would be a failure count at the top, maybe |
| 20:11 | <othermaciej> | all you really need is a distinct class on the result rows that failed |
| 20:11 | <jgraham> | sicking: The conceptual divide is that a test() corresponds to one thing that you want to test whereas an assertion is just a means to an end i.e. you might use many asserts to determine if you got the expected result of your test |
| 20:12 | <jgraham> | I often see tests that have var apssed = passed1 && passed2 && passed3 and so on |
| 20:12 | <jgraham> | Which is bad |
| 20:12 | <othermaciej> | I don't ever see that in WebKit script tests |
| 20:12 | <othermaciej> | where we report each assertion |
| 20:12 | <jgraham> | I don't mind printing the results of asserts in the output |
| 20:13 | <sicking> | jgraham: i'm not sure i understand the purpose of the test/assertion distinction |
| 20:13 | <jgraham> | sicking: Did you see my earlier example? |
| 20:13 | <sicking> | jgraham: no |
| 20:13 | <jgraham> | Where you do something (e.g. set innerHTML) and want to check that you get the DOM you expect |
| 20:13 | <othermaciej> | it's useful in the case where you want to make running an assertion conditional on a previous one passing |
| 20:14 | <jgraham> | So you check a number of things about the resulting DOM |
| 20:14 | <othermaciej> | which I think is the rare case, not the common case |
| 20:14 | <jgraham> | Like the number of nodes, their names, their values, etc. |
| 20:14 | <sicking> | right, i'm not sure i've ever needed to do that |
| 20:14 | <othermaciej> | I don't think I have either, and I have written a lot of assertion-based tests for WebKit |
| 20:14 | <sicking> | (answering maciej) |
| 20:14 | <jgraham> | I see that sort of thing all the time |
| 20:15 | <jgraham> | Philip` had another example from his canvas tests |
| 20:15 | <sicking> | can you point to it? |
| 20:15 | <sicking> | as in, got link? |
| 20:15 | <othermaciej> | I would be highly surprised if it is the majority case |
| 20:16 | <sicking> | indeed |
| 20:16 | <jgraham> | http://philip.html5.org/tests/canvas/suite/tests/2d.state.saverestore.stackdepth.html |
| 20:17 | <sicking> | why do you need the assert/test distinction there? |
| 20:17 | <jgraham> | It was at least a rather common case last time I used a harness with a similar design (testing pure ECMAScript) |
| 20:17 | sicking | isn't sure he's understanding the argument |
| 20:18 | <jgraham> | Because you don't want 512 individual assertions |
| 20:18 | <sicking> | why not? |
| 20:18 | <jgraham> | That test should contribute 1 to the overall results |
| 20:18 | <sicking> | why? |
| 20:19 | <sicking> | the number of pass/fails are meaningless. It's fails != 0 that matters |
| 20:19 | <jgraham> | Because it tests a single point from the spec |
| 20:19 | <othermaciej> | I think it would be useful if that test reported exactly which cases passed or failed |
| 20:19 | <sicking> | first of all that's not really true |
| 20:20 | <sicking> | that testcase tests at least 3 different APIs on canvas |
| 20:20 | <othermaciej> | in the unlikely case that only some of the cases fail, rather than all or none, it's very useful to know precisely which all at once |
| 20:20 | <jgraham> | The number of fails matters in a spec conformance testsuite |
| 20:20 | <sicking> | how? |
| 20:20 | <sicking> | either a browser passes or it fails |
| 20:21 | <othermaciej> | it matters if people start marketing their x% pass rate and comparing to someone else's y% |
| 20:21 | <jgraham> | Not the way it is presented at the moment |
| 20:21 | <othermaciej> | but I don't think tests should optimize for that |
| 20:21 | <jgraham> | I don't think I am optimising for that |
| 20:22 | <sicking> | indeed. It's really really hard to get people to write tests as it is, i don't want to lay the additional constraint of asking them to worry about marketing as well |
| 20:22 | <jgraham> | FWIW qunit uses a similar design |
| 20:22 | <sicking> | i have never cared about how many tests i fail. Only if i the fail count is 0 or not |
| 20:22 | <jgraham> | As does dojo object harness |
| 20:23 | <jgraham> | So there is at least precedent for the one test / multiple assertions in successful existing harnesses |
| 20:23 | <othermaciej> | There is also precedent for the other way |
| 20:24 | <othermaciej> | I don't think precedent is a slam dunk |
| 20:24 | <sicking> | indeed. We're not really breaking new ground here, so I don't think we need to worry about doing something so outragous that people will ask if there is precedence or not |
| 20:24 | <jgraham> | Sure. But my point is that I am not proposing something unreasonable |
| 20:24 | <othermaciej> | IMO we want to make it easy to write tests that are useful to implementors |
| 20:24 | <sicking> | you're not. I just think there are better solutions |
| 20:24 | <sicking> | yup |
| 20:25 | <othermaciej> | reporting failing assertions individually, and reporting multiple failures at once, is generally better for implementors |
| 20:25 | <othermaciej> | for two reasons: |
| 20:25 | <othermaciej> | (1) you can fix more bugs at once pass without having to tackle failing asserts one at a time |
| 20:25 | <othermaciej> | (2) if your implementation is not fully conforming, you can more usefully use the test as a regression test, because you will see if assertions past the first failure go from fail to pass |
| 20:26 | <othermaciej> | (and bonus reason (3), sometimes the first failure is hard to fix but later failures are easy to fix) |
| 20:26 | <jgraham> | If things are independent in the way you suggest they are seperate test()s, not seperate asserts |
| 20:26 | <othermaciej> | therefore, in my opinion the harness should optimize for that case |
| 20:26 | <othermaciej> | by making it the obvious and easy path to create tests that work that way |
| 20:27 | <jgraham> | If the syntax of test()s is too difficult let's wok on that |
| 20:27 | <jgraham> | *work |
| 20:27 | <sicking> | jgraham: i still don't understand the need for the test/assert distinction |
| 20:28 | <sicking> | i'd rather not ever see anyone be asked "can you merge these three tests into one with three asserts as they kind'a test the same thing" |
| 20:28 | <jgraham> | sicking: Then I don't know how to convince you. I see people perform contortions in tests to make the result depend on multiple independent things all the time |
| 20:28 | <sicking> | (or the other way obviously) |
| 20:28 | <jgraham> | If you can write it as three test()s then it shouldn't be one test |
| 20:29 | <sicking> | you can write *any* test as a single test() |
| 20:29 | <jgraham> | Right |
| 20:29 | <jgraham> | That's what I said |
| 20:29 | <sicking> | just do all the testing and set a boolean to false once anything fails. At the end do test(boolean) (or whatever the syntax is, i forget) |
| 20:29 | <sicking> | i also argue that there is no such thing as testing a single feature |
| 20:29 | <jgraham> | That is exactly what I want to avoid |
| 20:30 | <othermaciej> | in HTML5 test suite syntax, I have to do this: |
| 20:30 | <othermaciej> | test(function() { |
| 20:30 | <othermaciej> | assert_equals(document.getElementById("abcd"), document.getElementsByTagName("i")[0]); |
| 20:30 | <othermaciej> | }, "User agents must associate the element with an id value for purposes of getElementById."); |
| 20:30 | <sicking> | it is *very* common for our regression tests to catch regressions in features they don't think they are testing |
| 20:30 | <jgraham> | The "set a boolean to false and make all assertions just assert_true") |
| 20:30 | <othermaciej> | but it could be this: |
| 20:30 | <jgraham> | sicking: Yes, I am well aware of this fact |
| 20:30 | <jgraham> | But I don't see how it is related |
| 20:31 | <othermaciej> | test_equals('document.getElementById("abcd")', 'document.getElementsByTagName("i")[0])', "User agents must associate the element with an id value for purposes of getElementById."); |
| 20:31 | <jgraham> | Except that you are encouraged to put all code inside *some* test() |
| 20:31 | <sicking> | i thought the argument of having test/assert distinction was so that you can test separate features in separate test()s |
| 20:31 | <othermaciej> | (or skip the message if the expressions are informative enough) |
| 20:31 | <jgraham> | othermaciej: I hate the "code as a string" pattern |
| 20:32 | <jgraham> | Also in the webkit tests :) |
| 20:32 | <othermaciej> | or alternately, if I could wrap all my asserts in a single test(), I could drop the single-qoutes from that |
| 20:32 | <othermaciej> | (with test() being there mainly to centralize the exception-catching) |
| 20:33 | <sicking> | i'm not sure what the test() pattern is really buying us. Why can't we just use assertions direction |
| 20:33 | <othermaciej> | I don't see the benefit of requiring the more verbose version to get detailed result reporting |
| 20:33 | <sicking> | err |
| 20:33 | <sicking> | directly |
| 20:33 | <sicking> | and make the test harness hook into onerror to catch exceptions |
| 20:33 | <othermaciej> | it seems like that discourages creating tests with detailed result reporting |
| 20:33 | <jgraham> | sicking: Because then you can only have one test per file or have to manually deal with unexpected exceptions |
| 20:33 | <sicking> | at some point in the future browsers will implement onerror, at which point they'll start failing if they erronously throw somewhere |
| 20:33 | <othermaciej> | onerror is not yet supported enough to do that |
| 20:34 | <jgraham> | Anyway I will haveto bow out of this conversation for a bit |
| 20:34 | <sicking> | othermaciej: but it will be soon enough (say a year or two) i'm assuming |
| 20:34 | <othermaciej> | anyway, I have to run to grab lunch |
| 20:34 | <sicking> | heh |
| 20:40 | <jgraham> | (while I remember, another good example of why you want seperate assert() functions is to check that a feature exists before you try to do something with it, and fail if it does not) |
| 20:47 | <hober> | sicking: OK, I'll write the ISSUE-27 CP |
| 20:48 | <hober> | sicking: when's it due? |
| 20:48 | <sicking> | hober: yay!! thanks! |
| 20:48 | <sicking> | hober: it's way overdue already :( I'll ask maciej when he gets back from food what would be a good new due date |
| 20:48 | <hober> | ahh, ok |
| 20:49 | <hober> | good times :) |
| 20:50 | <hober> | othermaciej: any chance I can get a deadline in the future for the host-the-rel-registry-on-the-µf-wiki ISSUE-27 CP? |
| 20:51 | <othermaciej> | hober: if you volunteer on the list and give a specific reasonable deadline, I expect the chairs would accept that |
| 20:51 | <othermaciej> | (like 1-2 weeks from today max) |
| 20:51 | <hober> | ok |
| 20:51 | <hober> | sounds good |
| 20:54 | <sicking> | jgraham: i don't know why you'd want to do that. Just use the feature and if it fails then you fail the test |
| 20:54 | <hober> | sent |
| 20:56 | <sicking> | jgraham: the only thing i could think of is if you'd want to use some feature that isn't in HTML5, and thus shouldn't be relied upon. But first of all I can't think of a case when that would be, second in this to me seemingly very rare case, you can always just use feature detection and separate code paths. No need for harness support for this. |
| 21:28 | <jgraham> | Hixie: btw I strongly disagree about linking tests to the spec. Unless we link tests to the spec it is almost impossible to determine if we have coverage of a particular area |
| 21:29 | <jgraham> | I don't think questioning invalid tests is the main problem |
| 21:29 | <Hixie> | linking tests to the spec doesn't help you with determining coverage either, unless you plan to have an ungodly number of links per test and plan to be updating them frequently |
| 21:30 | <jgraham> | Why an ungodly number of links per test? I don't think it is a disaster if tests fail to link to APIs that they only use for setup |
| 21:30 | <jgraham> | Because those APIs need detailed tests of their own |
| 21:31 | <jgraham> | (indeed it is probably a good thing) |
| 21:31 | <jgraham> | Certainly what Philip` has done with the <canvas> tests is extremely useful |
| 22:27 | <Hixie> | jgraham: the vast majority of tests will be testing combinations of features |
| 22:27 | <Hixie> | jgraham: and even many of the tests that don't test combinations will be testing things that are specified across many sections |
| 22:28 | <Hixie> | jgraham: consider any test for 'unload' |
| 22:46 | <jgraham> | Hixie: I don't think that changes my point |
| 22:56 | <annevk> | so when will some decisions be announced? |
| 22:57 | <Hixie> | when i spoke to the chairs a few weeks ago, they said "monday" |
| 22:57 | <Hixie> | but that was last monday |
| 22:57 | <Hixie> | so... |
| 23:02 | <annevk> | "monday" is a great date |
| 23:04 | <Hixie> | they were referring to last monday |
| 23:04 | <Hixie> | 22nd |
| 23:10 | <annevk> | isn't that the Monday before last? |
| 23:10 | <annevk> | not that it matters |
| 23:10 | <Hixie> | "this monday" is yesterday |
| 23:10 | <Hixie> | "last monday" is the monday before |
| 23:10 | <annevk> | it's Wednesday here |
| 23:11 | <Hixie> | it's tuesday until you've slept! :-P |
| 23:11 | <hober> | I wonder when the ISSUE-41 decision will be published. |
| 23:11 | <annevk> | last Monday |
| 23:12 | <hober> | with apologies to markp, I must be new here. :) |
| 23:12 | <annevk> | Hixie, ooh, that can lead to six-day weeks |
| 23:12 | <Hixie> | yeah, i used to live monday,tuesday,wednesday,thursday,friday,weekend back when i was at netscape |
| 23:12 | <Hixie> | and my "friday" started rather late |
| 23:12 | <TabAtkins> | 28-hour days, or just long weekends? |
| 23:13 | <Hixie> | 28 |
| 23:18 | <TabAtkins> | What was the problem in canvas with something having different behavior based on rounding? Something about arcs? |
| 23:18 | TabAtkins | is writing an email. |
| 23:18 | <Hixie> | there was a problem once with 0..2pi being either a full circle or a dot depending on how you rounded |
| 23:18 | <Hixie> | but i think we resolved it |
| 23:19 | <TabAtkins> | Ah, right. |
| 23:19 | TabAtkins | goes and looks it up. |
| 23:19 | <TabAtkins> | Dammit, I keep typing "whatwg.orc/C". At least chrome suggests the correct url to me now. |
| 23:20 | <Hixie> | shouldn't you just be able to type "w" by now |
| 23:22 | <TabAtkins> | Not at work. For reasons I haven't yet gotten the energy to diagnose, Chrome on my work linux machine no longer has permissions to my profile, so autocomplete is totally dead. |
| 23:22 | <Hixie> | lol |
| 23:22 | <Hixie> | good times |
| 23:26 | <TabAtkins> | Ah, the way we solved the arcTo() issue doesn't help here. |
| 23:26 | <TabAtkins> | Darn. |
| 23:26 | TabAtkins | is trying to solve the problem of interpolating colors in hsl space when the hues are 180deg apart. |
| 23:27 | <TabAtkins> | The best I've got so far is (1) Shrug, or (2) when transitioning, always increase/decrease/wrap/don't wrap the hue. |
| 23:27 | <TabAtkins> | (2) solves the problem, but makes other cases bad. So I'm leaning towards (1). |
| 23:28 | <Hixie> | my suggestion is pick your favourite colour, and then when you're in that one edge case, require that the transition go in the direction that would go through your favourite colour |
| 23:28 | <TabAtkins> | That doesn't work when I'm transitioning to/from my favorite color. |
| 23:28 | <Hixie> | and when one of the two ends is that colour, um, do the same with your second-favourite colour, i guess |
| 23:28 | <TabAtkins> | And before you suggest "pick two", what if my two favorites are 180deg apart? |
| 23:29 | <TabAtkins> | Dammit. |
| 23:29 | <Hixie> | or define your favourite colour as something that you can't specify, e.g. if you only accept integers, give a value with a fractional component |
| 23:29 | <Hixie> | also, if your favourite colour is white or black, i can't help you |
| 23:30 | <Hixie> | (or grey) |
| 23:30 | <TabAtkins> | Actually, that doesn't solve the problem anyway. The issue isnt' that 180deg apart is ambiguous (that's solveable), but rather than rounding can make something be in or out of the edge case unpredictably. |
| 23:30 | <Hixie> | aah |
| 23:30 | <Hixie> | can't you define the rounding algorithm? |
| 23:30 | <TabAtkins> | Which was the problem with arcTo(), but you solved that. |
| 23:30 | <TabAtkins> | We don't even define the numeric precision of CSS numbers. |
| 23:30 | <Hixie> | ah |
| 23:30 | <Hixie> | well |
| 23:30 | <TabAtkins> | (We should.) |
| 23:31 | <Hixie> | maybe |
| 23:31 | <Hixie> | with arcTo the solution iirc was to make it so that there was no edge case, right? |
| 23:31 | <TabAtkins> | Yes. |
| 23:31 | <Hixie> | i recommend the same approach. |
| 23:31 | <Hixie> | good luck! |
| 23:31 | Hixie | ducks |
| 23:31 | <TabAtkins> | @_@ |
| 23:32 | <TabAtkins> | The "make it so there's no edge case" approach is my (2), which unfortunately it's great for half of all gradients. |
| 23:32 | <Hixie> | you could always do (3), have the author specify whether to transition clockwise or anticlockwise |
| 23:32 | <TabAtkins> | For example, if the strategy is "never wrap the hue", then you can't actually transition from purple to orange through red. |
| 23:32 | <TabAtkins> | That doesn't solve the problem, Hixie. |
| 23:32 | <Hixie> | why not? |
| 23:33 | <TabAtkins> | Or, well, it does if you mean "do (2), but give the author a choice". |
| 23:33 | <Hixie> | essentially, yeah, make the author pick which solution to use |
| 23:33 | <Hixie> | but that's lame most of hte time |
| 23:33 | <TabAtkins> | But, still not very well. *None* of the choices interpolate well in general. |
| 23:34 | <TabAtkins> | So I'm going with "shrug" as my answer. |
| 23:34 | <Hixie> | boo |
| 23:34 | <TabAtkins> | In animations and gradients, the author can get around it by providing a third color between the two points. |
| 23:35 | <TabAtkins> | You can't do that in Transitions currently, but you will once we support keyframes in transitions. |
| 23:35 | <TabAtkins> | Which'll be like Transitions 4 I guess. |
| 23:35 | <annevk> | yay, the bug feature is still working |
| 23:35 | <Hixie> | (if you don't specify it, some browser will get big adoption and force the rounding of css values to be defined a particular way) |
| 23:35 | <Hixie> | bug feature? |
| 23:35 | <annevk> | on html5.org |
| 23:36 | <annevk> | puts W3C bugs in a separate column |
| 23:36 | <bckenny> | TabAtkins: will this be for any properties specified in hsl? what if you want to author in hsl but interpolate in rgb? |
| 23:36 | <Hixie> | oh on the tracker? |
| 23:36 | Hixie | looks |
| 23:36 | <Hixie> | neat |
| 23:36 | <bckenny> | or is this for approximately the same time as transition-strategy or what have you? |
| 23:36 | <TabAtkins> | bckenny: It would just be an interpolation strategy. It doesn't matter how you specify the endpoints. |
| 23:37 | <bckenny> | ah |
| 23:37 | <TabAtkins> | A color is a color is a color, after all, regardless of the colorspace you use. |
| 23:37 | <Hixie> | annevk: di you need an answer to http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027987.html ? |
| 23:37 | <TabAtkins> | It's just when you try to draw "straigt lines" between colors that the colorspace matters. |
| 23:38 | <Hixie> | you could sidestep the problem then by requiring that the browsers draw wavy lines |
| 23:38 | <TabAtkins> | The nature of the curve varies from space to space as well. |
| 23:39 | <bckenny> | the extra color stop is a fine (eventual) solution |
| 23:40 | <bckenny> | though it is unfortunate that browsers and anyone generating dynamic colors will have to detect that situation |
| 23:40 | <Hixie> | oh, tab, i have another solution! |
| 23:40 | <bckenny> | but it's ambiguous, so what are you going to do |
| 23:40 | <Hixie> | pick your favourite colour again defined as something that can't be specified exactly, and then require that that colour be transitioned to in between each other colour |
| 23:40 | <Hixie> | that way it's never ambiguous, right? |
| 23:41 | <TabAtkins> | Right, that's just another (2) strategy, which is guaranteed to be bad for about half of all transitions. |
| 23:41 | <TabAtkins> | (It's equivalent to "always wrap the hue", with the wrap point being the favorite color rather than 0deg.) |
| 23:42 | <annevk> | Hixie, no, it sort of resolved itself I think |
| 23:42 | <annevk> | still need to update CSSOM View |
| 23:43 | <Hixie> | k |
| 23:43 | <Hixie> | TabAtkins: true |
| 23:43 | <Hixie> | TabAtkins: but it has the advantage of making the web prettier for you |
| 23:43 | <Hixie> | TabAtkins: as you'd see your favourite colour more often |
| 23:43 | <TabAtkins> | This is true. |
| 23:43 | <TabAtkins> | (I don't need to make my favorite color unspecifable if I just specify two favorite colors that aren't 180deg apart.) |
| 23:45 | <Hixie> | well if you have two favourite colours, sure |
| 23:45 | <TabAtkins> | They can be 1deg apart. |
| 23:45 | <bckenny> | ultraviolet |
| 23:45 | <bckenny> | take that, gamut |
| 23:45 | <TabAtkins> | Pretty sure ultraviolet doesn't exist in the sRGB space at all, let alone the sRGB gamut. |
| 23:50 | <bga_> | hi |
| 23:50 | <bga_> | we have found some issue |
| 23:51 | <bga_> | i want auto "lang" attribute |
| 23:52 | <bga_> | if i do not set it manualy |
| 23:52 | <TabAtkins> | What's the problem you're trying to solve? |
| 23:52 | <bga_> | i have static html page |
| 23:53 | <jamesr_> | TabAtkins: is there a www-style IRC channel? |
| 23:53 | <bga_> | i want that it works w/o js |
| 23:53 | <TabAtkins> | jamesr_: Are you already on the w3.org server? |
| 23:54 | <jamesr_> | nope. should i be? |
| 23:54 | <Hixie> | so a while ago aryeh suggested changing th.scope and td.wrap to be limited to known values, which is a change away from every browser, but makes some modicum of sense... any opinions? |
| 23:54 | <TabAtkins> | Yeah. irc.w3.org, port 6665. |
| 23:54 | <TabAtkins> | Then channel #css |
| 23:54 | <bga_> | and i want that this will be multilangage |
| 23:54 | <jamesr_> | are there real people there? |
| 23:54 | <TabAtkins> | Hixie: I support the change. |
| 23:54 | <TabAtkins> | jamesr_: Yes, though we don't pay a ton of attention. We'll see a question eventually, though. |
| 23:55 | <TabAtkins> | jamesr_: It helps if you know who you want to talk to and can target them. |
| 23:55 | <cying> | CSS + HTML5 question... |
| 23:55 | <cying> | what do the width and height attributes mean for images in HTML5? how do they react when styled? |
| 23:55 | <bga_> | <span class="ru">привет</span><span class="en">hi</span> |
| 23:55 | <TabAtkins> | bga_: You haven't described a problem yet. |
| 23:55 | <TabAtkins> | cying: That's defined in the rendering chapter of HTML5. |
| 23:56 | <Hixie> | what they _mean_ is defined in the elements section |
| 23:56 | <Hixie> | what they do is defined in the rendering section |
| 23:56 | <TabAtkins> | cying: Simply, @width and @height are presentational hints for the 'width' and 'height' CSS properties. |
| 23:56 | <bga_> | span{ display:none; } :lang(ru) span.ru { display: inline; }; :lang(en) span.en { display: inline; }; |
| 23:56 | <cying> | TabAtkins: hmmm |
| 23:56 | <cying> | Hixie: cool |
| 23:56 | <TabAtkins> | cying: Pres hints are treated as author-level rules that are less specific than any other rule. |
| 23:57 | <bga_> | do you understand me? :) |
| 23:57 | <jamesr_> | TabAtkins: i'm wondering what people think about -moz-crisp-edges for the image-rendering property. i'm interested in giving it a non-shit name and implementing it |
| 23:57 | <jamesr_> | in webkit |
| 23:57 | <Hixie> | bga_: dir="auto" was added to HTML a few weeks ago, http://www.whatwg.org/specs/web-apps/current-work/complete.html#attr-dir-auto |
| 23:57 | <TabAtkins> | bga_: Your design isn't good. If the page is loaded without CSS, the user will see both the russian and english words. |
| 23:57 | <Hixie> | bga_: oh, wait, you're asking for lang=auto |
| 23:57 | <Hixie> | nevermind |
| 23:57 | <cying> | TabAtkins: so if i were to say: <img width="500" height="500" src="..."> and then style it with { width: 250px; height: auto; } it'll size it to 250px x 250px? |
| 23:57 | <Hixie> | what tab said |
| 23:57 | <TabAtkins> | bga_: If you're wanting to give different languages on the same page and display only one of them, that should be done server-side as you build the page. |
| 23:58 | <TabAtkins> | cying: Yes. |
| 23:58 | <Hixie> | html doesn't support in-page localisation |
| 23:58 | <cying> | TabAtkins: coooool |
| 23:58 | <TabAtkins> | cying: Or, um, whatever height:auto does for replaced elements. It's magic. |
| 23:58 | <cying> | TabAtkins: cool. i like magic :) |
| 23:58 | <bga_> | Hixie :( |
| 23:59 | <Hixie> | bga_: why would you want to send the user multiple copies of the page? just send them the copy that has the language you want |
| 23:59 | <bga_> | i want static page w/o backend |
| 23:59 | <Hixie> | bga_: in practice, localisation requires changing much more than just text, anyway. For example, localising to arabic means moving the scrollbar to a different position. To Japanese might mean having hte entire layout be vertical instead of horizontal. To French will mean different date styles. etc. |