| 00:02 | <Philip`> | Hixie: I'm here now |
| 00:02 | <Philip`> | Hixie: I don't know; what do browsers do there? :-) |
| 00:02 | <Hixie> | forget the earlier thing, i just sent new mail on a different topic |
| 00:02 | <Hixie> | actually, same topic, different issue |
| 00:02 | <Hixie> | i hope the change i made to the spec still applies |
| 00:02 | <Hixie> | it's what you suggested in january |
| 00:05 | <Philip`> | Hmm, I've got no idea what the stroke.prune.arc test is doing |
| 00:07 | <Hixie> | yeah i wasn't too sure either |
| 00:07 | <Philip`> | Hixie: The spec change sounds plausible to me, except for the bit that says "then, then" |
| 00:08 | <Hixie> | i don't know what you're talking about *fixy fixy* |
| 00:08 | Philip` | tries to remember what arcTo's arguments are |
| 00:09 | <Hixie> | there's an authoring section bit now that explains it nice and friendlyly |
| 00:09 | Philip` | looks at the non-nice and unfriendly section instead |
| 00:09 | <Hixie> | i'm sure someone will send me diagrams and stuff explaining what they all do at some point and then the spec will have diagrams too |
| 00:11 | <Philip`> | Ah, right - the arcTo bit in stroke.prune.arc is causing a line to be drawn from (50,25) to (50,25) and then to (50,25), and then it should (according to my brain when I wrote the test, which may or may not match the spec or reality or sanity) collapse all the zero-length lines so there's just a single point |
| 00:11 | <Philip`> | and then the stroke() won't do anything, and particularly won't draw the round caps/joins |
| 00:12 | <Philip`> | And the bit with arc is doing the same, except that it's drawing a curved line between (50,25) and (50,25) |
| 00:14 | <Philip`> | Ooh, excellent, "Zero-length line segments must be pruned before stroking a path." and "Subpaths with fewer than two points are ignored when painting the path." makes it sounds like those paths should indeed be not drawn |
| 00:18 | <Philip`> | Anyway, changing the spec for the stroke.prune.arc thing seems like a lot of effort to introduce a weird glitch that nobody's going to care about at all |
| 00:20 | <Philip`> | So I guess I'd suggest waiting until browsers pass 99% of the tests and want to get 100%, and they'll either fix their handling of this one or they'll complain that it's needlessly hard and the spec should change, and something can be sorted out then |
| 00:21 | <Philip`> | (It's quite a spectacularly pointless feature to bother testing, I think) |
| 00:21 | <Philip`> | (So I suppose a third possible outcome is that the test could be deleted) |
| 00:23 | <Hixie> | nooo don't delete the test |
| 00:24 | <Philip`> | I won't delete it in the near future, because my test deployment process requires far too much effort |
| 00:24 | <Philip`> | I haven't even got around to uploading fixes for some blatant bugs in a couple of test cases |
| 00:26 | Philip` | goes back to playing Braid, and getting annoyed that the princess keeps exploding |
| 00:43 | <Hixie> | shepazu: dude you're talking to yourself on twitter. :-P |
| 00:54 | <Hixie> | Philip`: you still there? |
| 00:54 | <Hixie> | Philip`: does http://damowmow.com/temp/miter make any sense to you? |
| 00:55 | <Philip`> | I'm not here, but will be soon |
| 01:17 | <Philip`> | Hixie: Hard to tell without seeing the test case |
| 01:21 | <Philip`> | Hixie: But I'm pretty sure the spec is correct |
| 01:21 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Ccanvas%20id%3Dc%3E%3C%2Fcanvas%3E%3Cscript%3Eonload%3Dfunction()%7Bvar%20ctx%3Ddocument.getElementById('c').getContext('2d')%3Bctx.lineWidth%3D20%3Bctx.miterLimit%3D1.41%3Bctx.moveTo(10%2C10)%3Bctx.lineTo(50%2C10)%3Bctx.lineTo(50%2C50)%3Bctx.stroke()%7D%3C%2Fscript%3E |
| 01:22 | <Philip`> | If you change the 1.41 to 1.42 then it starts drawing the miter |
| 01:22 | <Philip`> | and the miter length (from where the lines meet, to the corner of the miter) is lineWidth/2 * sqrt(2) |
| 01:23 | <Philip`> | so the relevant factor in the miter limit ratio is lineWidth/2 |
| 01:24 | <Philip`> | unless I'm horribly mistaken |
| 01:30 | <Philip`> | (It's odd that all APIs seem to not mention the half) |
| 01:30 | <Philip`> | (but I can't see how I'm wrong) |
| 01:34 | <Hixie> | Philip`: so where the spec says the "inside of the join" it should say "the point where the join occurs"? |
| 01:38 | <Philip`> | Hixie: I interpret both those phrases in the same way, i.e. the point where the infinitesimally-thin lines intersect |
| 01:39 | <Philip`> | Looks like the spec used to say "the point of the join itself (where the lines touch on the inside of the join)" |
| 01:39 | <Philip`> | but someone must have changed it |
| 01:42 | <Hixie> | i'll strike "inside of the join" |
| 01:42 | <Hixie> | i don't understand what it means |
| 01:44 | <Philip`> | Hmm, I guess if the miter length was defined as being between the points where the edges of the (thick) stroke intersect, instead of between one of those points and the midpoint, then that'd remove the need to say 'half the line width' instead of 'the line width' |
| 01:45 | <Philip`> | but that seems a more complex definition |
| 01:46 | <Hixie> | walk me through how you get lineWidth/2 * root-2. i keep getting lineWidth/root-2. |
| 01:47 | <Hixie> | the miter length is the square root of (lineWidth/2) times two, right? |
| 01:47 | <Hixie> | maths is hard. |
| 01:47 | <Hixie> | :-P |
| 01:49 | <Philip`> | http://canvaspaint.org/57ce.png |
| 01:49 | <Philip`> | The red lines are the two lines being drawn; the blue lines are the outlines of their strokes |
| 01:49 | <Philip`> | (so the blue lines are lineWidth/2 away from the red lines) |
| 01:49 | <Hixie> | that diagram is exactly what i have on my pad here :-) |
| 01:50 | <Philip`> | The green triangle is the miter triangle |
| 01:50 | <Philip`> | The yellow line is the miter length |
| 01:50 | <Philip`> | The yellow line is the diagonal of a square that's lineWidth/2 x lineWidth/2 |
| 01:50 | <Philip`> | so its length is sqrt(2) * lineWidth/2 |
| 01:52 | <Hixie> | yeah apparently my ability to take roots of fractions is, ah, rusty |
| 01:52 | <hsivonen> | so I broke visual Hebrew accidentally |
| 01:53 | <hsivonen> | I wonder which spec defines it... |
| 01:53 | Philip` | didn't take roots of fractions, he just scaled sqrt(2) by the size of the square :-) |
| 01:53 | <Hixie> | clearly i need to take a basic algebra refresher :-P |
| 01:53 | <Hixie> | anyway |
| 01:53 | <Hixie> | thanks |
| 01:54 | <Philip`> | It'd be possible to draw the yellow line twice as long, so it reaches the intersection of the blue lines, which might be how other people define the miter length so that they don't need the divide-by-two |
| 01:55 | <Philip`> | Actually, I'm not sure that's true |
| 01:55 | <Philip`> | Actually, I think it is |
| 02:01 | <MikeSmith> | hsivonen: what's visual Hebrew? |
| 02:02 | <Philip`> | Is there non-visual Hebrew? |
| 02:06 | <Philip`> | Oh, I suppose there's spoken Hebrew |
| 02:06 | Philip` | completely forgot about that |
| 02:17 | <takkaria> | Philip`: too long on IRC. :) |
| 03:59 | <Hixie> | Philip`: having eaten dinner i worked out why i was having issues earlier. for some reason it escaped my attention that 1/(root2) == (root2)/2 |
| 03:59 | <Hixie> | i feel better now |
| 04:13 | <boblet> | Hi all, I’m wondering about how to mark up several images with captions which are linked. In HTML4 I’d use a <ul> and wrap the img and text in an <a>. In HTML5 <figure> can’t be inside an <a>. Would I have to wrap the image and legend in separate links? |
| 04:15 | <Hixie> | you mean you have several different captioned images, each of which is a link? |
| 04:15 | <Hixie> | or you have one captioned link consisting of several images? |
| 04:16 | <boblet> | wow, Hixie. I’m honored :) the first. you can see here (at the bottom): http://oli-studio.com/work/wde/200905-html5/ |
| 04:17 | <Hixie> | hmm |
| 04:17 | <boblet> | I figured to just wrap each image/legend in <figure> then wrap the text in <legend>, but that’s invalid: http://oli-studio.com/work/wde/200905-html5+/ |
| 04:17 | <boblet> | am I over-semanticising? :D |
| 04:18 | <Hixie> | i'm not sure those are really <figure>s per se, i'd just use <nav><ul><li><a href="..."><img src="..." alt=""> ...</a></li> ... </ul></nav> personally |
| 04:19 | <boblet> | aah I thought as much. so <figure> is more pullquote-style images (in a magazine sense)? |
| 04:19 | <Hixie> | yeah |
| 04:19 | <Hixie> | more like the kind of thing you'd expect to be labelled "Figure 1." somewhere |
| 04:20 | <boblet> | sorted. Thanks for that! OK off to see what else I can HTML5-ify |
| 04:21 | <Hixie> | :-) |
| 04:21 | <Hixie> | btw the alt="" texts on the "John" images at the top are probably wrong |
| 04:21 | <Hixie> | those look decorative, probably best to have title="(what you have now in alt)" with alt="" (blank) |
| 04:22 | <boblet> | ooh thanks! I need to read up on alt text recommendations, so thanks for the prompt |
| 04:24 | <Hixie> | one way to test is simply to turn off images in firefox |
| 04:24 | <Hixie> | and to see whether it still looks like the page you'd wanted it to be |
| 04:24 | <Hixie> | basically "what would you do if you weren't allowed to have images" |
| 04:26 | <boblet> | hah, cute! the rotated images turn into shrink-wrapped rotated text boxes in FF3.5b |
| 04:50 | <Hixie> | anyone have any opinions on <input type=tel>? |
| 04:51 | <takkaria> | the only practical use I could see for it would be autofill or maybe on OS X integration with the address book |
| 04:52 | <takkaria> | opinion over. :) |
| 05:17 | <zcorpan> | Hixie: "+ <h2>Games</h2> <!-- this starts a second subsection -->" -- s/second/third/ |
| 05:32 | <Hixie> | zcorpan: thanks |
| 05:32 | <Hixie> | takkaria: ta |
| 05:32 | <hsivonen> | MikeSmith: visual Hebrew is Hebrew ordered left to right with forced line breaks |
| 05:32 | <MikeSmith> | Hixie: I see |
| 05:33 | <Hixie> | what do you see? |
| 05:40 | <MikeSmith> | I see bursts of color all around me |
| 05:40 | <MikeSmith> | with forced line breaks |
| 05:40 | <MikeSmith> | I do wonder why that is called "visual Hebrew" |
| 05:41 | <MikeSmith> | seems like it should be called reverse-ordered Hebrew or something |
| 05:42 | <hsivonen> | MikeSmith: it's a hack that gives the right visual effect but is logically wrong |
| 05:43 | <MikeSmith> | hsivonen: how come it broke? |
| 05:44 | <MikeSmith> | could it affect other writing systems? |
| 05:48 | <hsivonen> | MikeSmith: I don't know why it broke |
| 05:49 | <hsivonen> | MikeSmith: visual Hebrew is unique, so I doubt anything else is affected by this particular bug |
| 05:49 | <hsivonen> | I suppose I'm responsible for setting a bidi override flag somewhere |
| 06:00 | <boblet> | Philip`: I subset the M+ font; “Original font: 586040 bytes (3985 glyphs), Optimized font: 21968 bytes (94 glyphs), Saved 96.3%!” 586KB -> 22KB. Wow |
| 06:00 | boblet | <3 Philip` |
| 06:00 | <boblet> | hehe |
| 06:01 | <MikeSmith> | Hixie: sorry, that "I see" before was to hsivonen |
| 06:01 | <MikeSmith> | I just took the first "h" that completed in my client |
| 06:19 | <Hixie> | heh |
| 06:35 | <zcorpan> | Philip`: you should make your font optimizer be keyboard accessible |
| 07:13 | <Hixie> | heycam: what is it that exceptions implement, if not an interface? |
| 07:14 | <heycam> | Hixie, in Web IDL exceptions are distinct from interfaces |
| 07:14 | <heycam> | in the ecmascript binding, they're pretty similar though |
| 07:14 | <Hixie> | sure but what's the right terminology? |
| 07:15 | <Hixie> | bla bla these exceptions implement the SQLException ...what? |
| 07:15 | <heycam> | i'd say "bla bla these exceptions are SQLExceptions" |
| 07:15 | <Hixie> | hm interesting |
| 07:16 | <Hixie> | okie dokie |
| 07:16 | <Hixie> | thanks |
| 07:16 | <heycam> | it's not possible for an object to be more than on exception, as currently written |
| 07:16 | <heycam> | *than one |
| 07:16 | <heycam> | ok but i find this in web idl: "A host exception object is a host object that implements a given exception. The behavior of a host object that implements more than one exception, or an exception as well as an interface, is not defined." |
| 07:17 | <heycam> | so go ahead and say it implements the exception if you want =) |
| 07:17 | <Hixie> | i prefer to call the object the exception |
| 07:17 | <Hixie> | otherwise we can't throw exceptions |
| 07:17 | <Hixie> | but only objects that implement exceptions |
| 07:17 | <Hixie> | and that's just confusing :-) |
| 07:18 | <heycam> | sure. |
| 07:18 | <heycam> | i might reword that bit about implementing exceptions |
| 07:18 | <zcorpan> | Philip`: by hiding the radio buttons in some way other than display:none (that preferably works sensibly with spatnav), and then input:focus + span { color:red } |
| 07:18 | <Hixie> | heycam: k |
| 08:27 | <Hixie> | zcorpan: oh, i misunderstood the svg thing. i thought it was an <img> pointing to svg, not an <svg>. |
| 08:29 | <zcorpan> | Hixie: "A class value instead of an align value doesn't seem especially more complex, especially given that it also enables a lot more than alignment (like padding, colours, fonts, etc)." -- td[align=right] { color:green } |
| 08:29 | <Hixie> | zcorpan: td.numeric { color: green; } is no more complex |
| 08:30 | <zcorpan> | Hixie: but td.numeric { align:right } <td class="numeric"> is more complex than <td align="right"> |
| 08:30 | <zcorpan> | Hixie: and the former doesn't enable anything that you can't do with the latter |
| 08:31 | <Hixie> | by that argument we should allow <font> and bgcolor="" and so on |
| 08:32 | <zcorpan> | i'm not necesserily arguing that align should be allowed, i'm just saying your argument against it was moot :-) |
| 08:33 | <zcorpan> | align="right" could represent numeric like <small> represents small print |
| 08:33 | <Hixie> | *shrug* |
| 08:34 | <zcorpan> | (and equally <font color> could represent emphasis) |
| 08:34 | <Hixie> | the argument was that there is value to be had from being hardline no-presentational-markup, and that it wasn't notably more complex to use css for this |
| 08:35 | <Hixie> | bed time now though |
| 08:36 | <Hixie> | nn :-) |
| 08:36 | <zcorpan> | nn |
| 09:07 | <Philip`> | boblet: I hope that subsetted font doesn't crash any browsers :-) |
| 09:08 | <Philip`> | zcorpan: Hmm, good point |
| 09:08 | <Philip`> | zcorpan: (I probably need to redesign the whole UI anyway, particularly to support non-English languages sensibly, though I've currently got no idea how to do that) |
| 09:08 | <boblet> | Philip`: now he tells me! Testing in progress… |
| 09:09 | <Philip`> | boblet: (Actually it's probably more about OSes than about browsers) |
| 10:14 | <zcorpan> | annevk5: your blog is broken |
| 10:20 | <MikeSmith> | <annevk> @DreamHost. WTF. My site has gone haywire. |
| 10:20 | <MikeSmith> | (on twitter) |
| 10:26 | <Lachy_> | wtf is <hgroup> for and what problem does it solve?! |
| 10:29 | <jgraham> | Lachy: <hgroup> is the new name for <header> |
| 10:29 | <jgraham> | It is solving the problem that <header> as previously defined would have been useless in practice |
| 10:29 | <jgraham> | Because people would have used it incorrectly too often |
| 10:29 | <Lachy> | why would it have been useless? |
| 10:30 | <Lachy> | <header> is still in there, and I don't see how the introduction of <hgroup> solves that problem |
| 10:31 | <jgraham> | <header> now means something different |
| 10:31 | <Lachy> | IIRC, the problem was that people did silly things like <section><header>headings</header><section>content</section></section> |
| 10:32 | <jgraham> | Lachy: That was a slightly different problem |
| 10:33 | <Lachy> | ok, then I don't remember what the problem with header was. Can you clarify? |
| 10:43 | <jgraham> | Lachy: http://lists.w3.org/Archives/Public/public-html/2009Mar/0663.html The problem was that authors assumed <header> was for page-wide header sections |
| 10:43 | <jgraham> | or as a generic replacement for <hx> |
| 10:47 | <jgraham> | Hixie: FWIW I'm not convinced that making <header> only take <hx> elements is sufficiently liberal |
| 10:47 | <jgraham> | s/header/hgroup/ |
| 10:47 | <jgraham> | :) |
| 10:50 | <annevk5> | zcorpan, I know, krijnh was nice enough to sms me |
| 10:51 | <annevk5> | zcorpan, haven't looked into fixing it yet |
| 10:51 | <annevk5> | zcorpan, we had this party and all |
| 10:51 | <krijnh> | Smoesjes :) |
| 16:23 | <gsnedders> | Wow. Next time I go into town it'll be for the ball. Scary. |
| 16:24 | <hsivonen> | gsnedders: which dances have you practiced? |
| 16:25 | <gsnedders> | hsivonen: Well, I want |
| 16:25 | <gsnedders> | *I went to a ceilidh two weeks ago |
| 16:26 | gsnedders | tries to write in his diary to catch up on the last month before getting read for a night which he'll likely have a fair bit to write about |
| 16:26 | <hsivonen> | Celtic ballroom dances? |
| 16:27 | <gsnedders> | Gorgeous photos of me in a suit will undoubtedly appear |
| 16:27 | <gsnedders> | Well, they aren't really ballroom dances… |
| 16:27 | <gsnedders> | But you left your sense of logic at the door, right? |
| 17:06 | jgraham | notes that in modern britian "ball" rarely means something in which actual ballroom dancing takes place |
| 17:07 | <Philip`> | Normally it means something spherical |
| 17:07 | <Philip`> | and only very tiny people could dance inside them |
| 18:01 | <annevk5> | http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ is pretty neat |
| 23:39 | <Hixie> | hsivonen: no need to change anything for getElementsByTagName(), right? (case-sensitivity issue with svg in text/html) |
| 23:46 | <annevk5> | it should prolly be moved to Web DOM Core in due course |
| 23:59 | gsnedders | collapses |
