| 00:00 | <Hixie> | 匮 is more obviously aligned on the baseline |
| 00:02 | <Hixie> | 遺 even more |
| 00:03 | <myakura> | or 辺? |
| 00:04 | <Hixie> | yes |
| 00:04 | <Hixie> | is that one good? |
| 00:04 | <myakura> | that means "border" or "edge" |
| 00:05 | <Hixie> | so "私辺" isn't rude or anything then? :-) |
| 00:06 | <Hixie> | meaningless is fine, the alphabetic part of this example at the moment reads "Á ÿ f Ω" |
| 00:06 | <Dashiva> | 私達 |
| 00:06 | <myakura> | "私辺" is meaningless, so fine :) |
| 00:07 | <myakura> | ah, 私達 ("we" or "us") is nice |
| 00:08 | <Hixie> | cool, i'll use that |
| 00:09 | <Hixie> | hey Dashiva did i add you to the acknowledgements yet? |
| 00:09 | <Dashiva> | Hehe. I don't think so. |
| 00:10 | <Hixie> | what's your name? |
| 00:11 | <Philip`> | (Dashiva: Make up an amusing joke name!) |
| 00:11 | <Dashiva> | (Philip`: Do you think he'll add it out of spite?) |
| 00:12 | <Dashiva> | I sent it in a private message so our log watchers won't find out! |
| 00:12 | <Philip`> | (Dashiva: Shh, he might hear us) |
| 00:12 | <Dashiva> | (Not that it can't be found in 5 minutes via google) |
| 00:12 | <Philip`> | The log watches could just look at the HTML5 diff |
| 00:12 | <Philip`> | *watchers |
| 00:14 | <Dashiva> | I'm gonna have to make an actually pseudonymous pseudonym |
| 00:15 | <Dashiva> | On the other hand, it's convenient to have a recognizable handle too |
| 00:20 | <Hixie> | how about someone who speaks Devanagari? :-) |
| 00:21 | Hixie | hopes that the Devanagari? letter "AA" isn't rude |
| 00:21 | <BenMillard> | I can't even pronounce "Devanagari"... |
| 00:21 | <Dashiva> | Can't help you on that one. My quaternary and quinary languages are German and Latin |
| 00:21 | <Philip`> | I can't even read the Devanagari page on Wikipedia - it's just full of boxes |
| 00:22 | <Philip`> | This is where you need the i18n expertise of the relevant W3C WGs :-) |
| 00:22 | <Hixie> | yeah |
| 00:23 | <jgraham_> | http://krijnhoetmer.nl/irc-logs/whatwg/20070428 |
| 00:23 | <Hixie> | luckily i've spent too many csswg meetings exposed to the i18n people :-P |
| 00:23 | <Hixie> | jgraham_: hah |
| 00:23 | <Hixie> | must've been the acid3 acks |
| 00:23 | <Dashiva> | jgraham_: That was for acid3 |
| 00:24 | <Dashiva> | I was in the credits in the directory containing the unfinished test :) |
| 00:32 | <Hixie> | http://junkyard.damowmow.com/317 |
| 00:34 | <BenMillard> | I'm off for lunch, bye all. |
| 00:34 | <Philip`> | Hixie: The font's too small |
| 00:34 | <Philip`> | Er, at least the small label font is - the others are probably large enough |
| 00:34 | <Hixie> | hmm |
| 00:39 | <Philip`> | (You should make it SVG and then I could zoom in and couldn't complain that it's too hard to read :-p ) |
| 00:40 | <Hixie> | be my guest |
| 00:40 | <Hixie> | the original is pixel-aligned HTML :-D |
| 00:40 | <Hixie> | is http://junkyard.damowmow.com/318 ok ? |
| 00:41 | <Philip`> | It's easier to read than 317, but it would still make me unhappy if my eyesight was worse |
| 00:42 | <Hixie> | sure |
| 00:43 | <Philip`> | Could the labels be moved up by one pixel, so they don't merge with the similarly-coloured lines below them? |
| 00:44 | <Dashiva> | Hixie: What if you made the image like 5 times bigger and then scaled it down in regular display? |
| 00:44 | <Philip`> | (You could ignore me because I'm just being too picky now :-) ) |
| 00:45 | <Philip`> | Dashiva: The nice sharp straight lines would disappear or go all smudgy |
| 00:45 | <Philip`> | and the text would be ugly since it wouldn't have the right hinting |
| 00:46 | <Hixie> | Philip`: http://junkyard.damowmow.com/320 |
| 00:47 | <Dashiva> | Hey, that's practically readable when I zoom in |
| 00:47 | <Philip`> | Hixie: That looks better again |
| 00:47 | <Philip`> | The important question is, what's a suitable alt text for this image? |
| 00:48 | <Hixie> | a very long paragraph |
| 00:48 | <Hixie> | which i would include anyway |
| 00:48 | <Hixie> | and thus the alt will be alt="" |
| 00:51 | <othermaciej> | drawing an element into the canvas would be handy functionality |
| 00:51 | <othermaciej> | computing what is "origin-unclean" in there would be complex |
| 00:52 | <Hixie> | drawing an element into the canvas would be handy functionality, but i'm not doing it instead of text drawing functions |
| 00:55 | <Philip`> | If drawElement isn't impossible for implementors, I'd kind of like to have the simple text-drawing API (single font, single colour, single line, etc) and keep it as simple as is possible for labelling graphs, then have drawElement for full flexibility (mixing various font styles in a single piece of text, line-wrapping, word-spacing, line-spacing, etc) |
| 00:56 | <Philip`> | I wouldn't particularly like to have only one, since one is too simple and the other is too complex |
| 00:57 | <roc_> | oh, that again |
| 00:58 | <Hixie> | Philip`: there are many reasons to have a drawing api, i just don't want to go down that rathole just yet |
| 00:58 | <Hixie> | i agree that we shouldn't go overboard with the text drawing api |
| 00:59 | <roc> | othermaciej: there are also issues like drawing the contents of file upload controls, which you may not want the page to 'see' |
| 01:00 | <Philip`> | roc: You can set the canvas as origin-unclean whenever something potentially unsafe is drawn to it (which, in the crudest approximation, is whenever drawElement is used at all), and then the page can't use toDataURL/getImageData to recover any information from it |
| 01:01 | <Philip`> | It'd be nice if using drawElement didn't disable toDataURL/etc, but in any case it's still better than not having drawElement at all |
| 01:01 | <roc> | yeah, that's what I did when I proposed canvas.drawWindow as a Web API |
| 01:01 | <roc> | one problem with drawElement is that if you pass an element that's not in a document, you have no style data so you can't really draw it |
| 01:02 | <roc> | drawWindow avoids that problem |
| 01:02 | <roc> | but it's not a biggie |
| 01:03 | <Philip`> | Hixie: If it's plausible that an HTML-element drawing API could be added in a future version, it seems like that'd be worth mentioning somewhere, so that people don't get worried by thinking that the simple text-drawing API is all they're ever going to get and start trying to jam all possible features into it |
| 01:03 | <Hixie> | since all the features have to go through me, there is little chance of any jamming going on :-) |
| 01:04 | <Hixie> | but if i don't include such a note, remind me to add one once i do the checkin |
| 01:04 | <Hixie> | i'm still researching at the moment |
| 01:04 | <Philip`> | That's why it's only "trying", by sending emails with elaborate proposals, which will get ignored and cause misery to the proposers |
| 01:04 | <Hixie> | right now i'm trying to work out how much of the alignment information should be in the method call and how much should be in out-of-band style |
| 01:05 | <Philip`> | I think everything (except string and position) should be out-of-band (in attributes), because that's how the rest of the canvas API works |
| 01:05 | <Hixie> | makes sense i guess |
| 01:06 | <Philip`> | Also the arguments have no natural ordering, so nobody will remember whether it's drawText(..., maxWidth, textAlign, ...) or drawText(..., textAlign, maxWidth, ...) |
| 01:08 | <Hixie> | true |
| 01:08 | <Philip`> | Also the string argument should come before the position arguments, to be consistent with drawImage and putImageData |
| 01:09 | <Hixie> | .baseline = 'top' 'hanging' 'middle' 'alphabetic' 'ideographic' 'bottom'; .textAlign = 'start' 'middle' 'end'; ? |
| 01:10 | <Hixie> | i hate start/middle/end |
| 01:10 | <Philip`> | .textPosition = '(top|hanging|...) (start|...)'; ? Nobody's going to want to read the values back, and nobody's going to want to set one without setting the other, so they might as well be one attribute |
| 01:11 | <Philip`> | Is anything wrong with left/center/right? |
| 01:11 | <Hixie> | most people will rarely set .baseline |
| 01:11 | <Hixie> | or at least never set it to anything but top or bottom |
| 01:11 | <Hixie> | people in other locales will set it once to set their baseline |
| 01:11 | <Hixie> | left/center/right doesn't work for drawVText() if you're passing vertical text |
| 01:12 | <Hixie> | (i guess it does work if you're passing latin text, since then it renders inline sideways) |
| 01:12 | <Philip`> | Ah, okay |
| 01:12 | <Philip`> | (about both things) |
| 01:12 | <Philip`> | It should be .textBaseline rather than .baseline because otherwise it's not clear that it's related to text drawing |
| 01:12 | <Hixie> | yeah |
| 01:13 | <Philip`> | Could allow left/start/top as aliases, and center/middle and right/end/bottom |
| 01:13 | <Philip`> | though maybe that'd just be horribly confusing |
| 01:13 | <Hixie> | i wonder what css3 does |
| 01:14 | <Hixie> | "In vertical text, 'left' aligns to the edge of the line box that would be the start edge for left-to-right text." |
| 01:14 | <Hixie> | i wonder what the start edge for left-to-right text is |
| 01:15 | <Philip`> | Horizontal text seems (based on my reading a Wikipedia article) more common than vertical text, even in CJK (at least in the computer world), so it makes sense to optimise for the common case |
| 01:15 | <Hixie> | yes |
| 01:15 | <Hixie> | totally |
| 01:15 | <othermaciej> | this is starting to sound scary complicated |
| 01:15 | <Hixie> | othermaciej: it's actually not that bad |
| 01:15 | <othermaciej> | I hope it does not require implementing a third text layout engine |
| 01:16 | <Hixie> | othermaciej: i'm explicitly going to make this require the use of the css engine |
| 01:16 | <othermaciej> | (in WebKit, although we share as much code as we can, we effectively have two for CSS and SVG) |
| 01:16 | <othermaciej> | ok |
| 01:16 | <Hixie> | and i'm thinking of not including drawVText() for now |
| 01:16 | <Philip`> | Would it be sensible to forbid newlines? (e.g. replace \n with ' ') |
| 01:16 | <othermaciej> | as long as all the state translates readily to CSS parameters |
| 01:16 | <Hixie> | but i want to make sure it's specced sanely first, then just have it commented out |
| 01:16 | <Philip`> | since presumably newlines make layout harder |
| 01:16 | <Hixie> | Philip`: newlines will just be stripped |
| 01:16 | <Philip`> | Okay |
| 01:20 | <Hixie> | hm, seems that we just want different alignment stuff for HText and VText |
| 01:22 | <Hixie> | well it seems css handles it by having complicated rules (different complicated rules in each draft) but i guess we can just leverage those |
| 01:23 | Philip` | notes that mozDrawText seems to just not bother with bidi text at all |
| 01:24 | <Hixie> | that's ok for a demo experimental api, but the i18n guys, while less aggressive than the accessibility guys, still bite |
| 01:24 | <Philip`> | The users are a more important consideration than the i18n guys |
| 01:25 | <Hixie> | to you maybe! i don't want to be bitten! |
| 01:25 | <Philip`> | but if the i18n guys are aligned with the interests of the users then it doesn't make that much difference in practice, so hopefully that's the case :-) |
| 01:25 | <Hixie> | :-) |
| 01:25 | <Hixie> | i18n is far more complex than accessibility, but also far less subjective |
| 01:26 | <Philip`> | It also affects far more users |
| 01:26 | <Hixie> | it affects all of them :-) |
| 01:28 | <Philip`> | Text is hard, I want to stay with pictures and colours |
| 01:30 | <Philip`> | Could one argue that the text drawing API is intentionally designed to not harm accessibility, by being so limited (to a single line of text with no markup) that it won't encourage people to move any significant text from out of their HTML and into their inaccessible canvas? |
| 01:31 | <Philip`> | Maybe it's safer to omit the "intentionally", but otherwise that seems true |
| 01:32 | <Philip`> | (e.g. if you have a caption for a graph, you'd write it as HTML below the canvas, where it's easy for everyone to read, because it's too painful to try to print it all directly in the canvas) |
| 01:33 | <Hixie> | i'm not even going to go near that |
| 01:33 | <othermaciej> | text drawing on canvas is bad for more than just accessibility |
| 01:33 | <othermaciej> | you can't select the text, copy it, do text find in it... |
| 01:34 | <othermaciej> | but of course people already do images of text which create the same problems |
| 01:34 | <Philip`> | Browsers could still offer text-selection features |
| 01:34 | <Philip`> | They just need to be a tiny bit cleverer about it |
| 01:34 | <Philip`> | (and will break if people use putImageData) |
| 01:36 | <othermaciej> | offer text selection features how? |
| 01:36 | <Philip`> | Keep a vector approximation of the canvas, to remember the positions of the text boxes, and clip that against every other shape that gets drawn, and you'd end up with a way of mapping from any pixel back to the text that is visible under that point |
| 01:36 | <othermaciej> | by making the canvas backing store a scene graph? |
| 01:37 | <Philip`> | You only need to store the visible extents of each text box, and don't have to worry about remembering any of the other shapes |
| 01:37 | <Hixie> | ocr |
| 01:37 | <Hixie> | then it would work for other images too |
| 01:37 | <othermaciej> | maybe you could keep an SVG DOM as the <canvas> backing store |
| 01:37 | <Hixie> | the spec does suggest that already :-D |
| 01:38 | <othermaciej> | that would sort of defeat the point of canvas as an immediate-mode graphics API |
| 01:38 | <Hixie> | i didn't say it made sense |
| 01:38 | <Philip`> | The point of the immediate-mode API is that it's an immediate-mode API, not that it happens to be implemented on top of a bitmap |
| 01:39 | <Hixie> | actually the spec iirc just mentions it in an aside as a hypothetical way to support toDataURL("image/svg+xml") |
| 01:39 | <Philip`> | The IE VML canvas emulation is still an immediate-mode API, even though the implementation is totally not |
| 01:40 | <Philip`> | Then again, in real life people care about performance, and the performance characteristics of bitmaps and vector scene graphs are very different |
| 01:40 | <othermaciej> | and that makes it lack the actual technical advantages of immediate mode (e.g. no RAM explosion when you draw a huge number of shapes) |
| 01:41 | <roc> | supporting bidi wouldn't be that hard as long as you don't have to support styled text runs |
| 01:41 | <roc> | I mean multiple styles in the same string |
| 01:41 | <Hixie> | indeed, none of that in this api |
| 01:44 | <othermaciej> | for cases where you want to apply bitmap-level effects to characters or otherwise use glyphs as graphical elements, a straight drawing API makes sense |
| 01:44 | <othermaciej> | but for use cases like chars, a convenient way to have a text layer on top of the canvas containing real text would be superior |
| 01:44 | <othermaciej> | *charts |
| 01:45 | <othermaciej> | because then select/copy/find works on your chart ticks |
| 01:45 | <othermaciej> | you can sort of do this now by positioning other elements over the canvas but that is hard to do right |
| 01:45 | <othermaciej> | it would be unfortunate if the only easier path led to a worse user experience |
| 01:47 | <Hixie> | i'm open to ideas |
| 01:47 | <othermaciej> | my "text layer on top" suggestion is not even a quarter baked |
| 01:47 | <othermaciej> | but I could try making a more detailed proposal |
| 01:48 | <Hixie> | sure |
| 01:49 | <Hixie> | i expect most people just want the text in the bitmap though |
| 01:49 | <Hixie> | so they can do things like layer crosshairs over the top or whatever |
| 01:50 | <othermaciej> | you mean for charts? |
| 01:50 | <Hixie> | yeah |
| 01:50 | <Hixie> | consider http://www.whatwg.org/issues/data.html |
| 01:51 | <othermaciej> | the chart on this page would clearly be better if the text was real: <http://arstechnica.com/news.ars/post/20080317-firefox-3-goes-on-a-diet-eats-less-memory-than-ie-and-opera.html>; |
| 01:51 | <Hixie> | well for that kind of static thing i'd recommend using svg, not canvas |
| 01:51 | <othermaciej> | sure, but you could make similar charts from live data |
| 01:52 | <othermaciej> | like a stock price graph |
| 01:52 | <Hixie> | yep |
| 01:52 | <othermaciej> | or web site traffic stats |
| 01:53 | <Hixie> | why does the safari line just stop on that chart |
| 01:53 | <Hixie> | and is safari any better now? :-) |
| 01:53 | <Philip`> | Use a static SVG graph template, and then dynamically modify one of its <path>s to have d="M $x[0] $y[0] L $x[1] $y[1] ..." |
| 01:53 | <Philip`> | "Safari 3 and Internet Explorer 8 could not be benchmarked because they crashed during the test." |
| 01:54 | <othermaciej> | I think Safari for Windows crashed on that benchmark when the Firefox guys ran it |
| 01:54 | <othermaciej> | not for us though, on the latest SafariWin |
| 01:54 | <othermaciej> | and yes, memory use is better now |
| 01:55 | <Hixie> | cool |
| 01:55 | <Hixie> | someone should redo that graph |
| 01:55 | <othermaciej> | in this case Ars Technica did not rerun the benchmark they just posted Pav's results |
| 01:55 | <othermaciej> | which is lazy reporting |
| 01:55 | <othermaciej> | I think we'll post some memory use benchmark results eventually |
| 02:02 | Philip` | tries to think of a use case for applying transformations to text |
| 02:02 | <Philip`> | If you've played Unreal Tournament, in DM-Morpheus there's that bit where it has a scrolling text display along one wall of a building to say who's currently winning the game |
| 02:02 | <Philip`> | I want one of those in my canvas 3D FPS, because they look cool |
| 02:03 | <Hixie> | the baseline values make no sense for drawVText |
| 02:03 | <Hixie> | for drawVText() we'd just want left, middle, right |
| 02:03 | <jruderman> | othermaciej: "eventually" = "when we catch up with gecko"? :P |
| 02:03 | <Philip`> | Is vertical text ever drawn left/right aligned, instead of middle-aligned? |
| 02:04 | <othermaciej> | jruderman: not necessarily, I'm not philosophically opposed to posting benchmarks we don't win yet |
| 02:04 | <Hixie> | Philip`: well |
| 02:04 | <Hixie> | Philip`: you always want it middle aligned |
| 02:04 | <Philip`> | othermaciej: Are there no marketing people controlling what benchmarks you publish? :-) |
| 02:05 | <Hixie> | Philip`: but you might want it anchored using a point on the left or right |
| 02:05 | <Philip`> | Hixie: Oh, right |
| 02:05 | <Hixie> | i guess you always know the em height, since you set it using 'font' |
| 02:05 | <Hixie> | so really this will always just offset your x by +/-0.5em |
| 02:05 | <othermaciej> | Apple publishes benchmark results and controls what goes on the apple.com/safari page |
| 02:06 | <othermaciej> | the WebKit blog is mainly about technical information and not as influenced by marketing concerns |
| 02:06 | <othermaciej> | though obviously we prefer to post when we have good news |
| 02:20 | <Hixie> | ooh, first actual casualty of the way canvas doesn't have separate path objects |
| 02:20 | <Hixie> | you can't draw text along a path to a path |
| 02:20 | <Hixie> | or rather you can't draw two pieces of text along two different paths to the same path |
| 02:25 | othermaciej | is not following |
| 02:25 | <othermaciej> | two different paths to the same path? |
| 02:26 | <Hixie> | path3.addTextToPath("foo", path1); path3.addTextToPath("bar", path2); |
| 02:26 | <Hixie> | no way to do that in <canvas> without adding path objects |
| 02:26 | <Philip`> | Can you use text as a path to draw text around? |
| 02:26 | <Hixie> | i am considering both drawing text to a path and drawing text on a path |
| 02:26 | <Philip`> | You could make a neat fractal pattern like that |
| 02:26 | <Hixie> | but i wished to do both |
| 02:27 | <Hixie> | see e.g. the demos at the bottom of http://developer.mozilla.org/en/docs/Drawing_text_using_a_canvas in ff3 |
| 02:28 | <jruderman> | Philip`: ooh, that sounds neat |
| 02:28 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#text (see the idl block earlier in that section for more details for the api i'm looking at so far) |
| 02:28 | <Hixie> | (this is just for drawing text straight to the canvas using 'fill' so far |
| 02:29 | <Hixie> | but i might either add to or replace this with an api that does path stuff) |
| 02:30 | <othermaciej> | I hope drawing text on a path has SVG-compatible text layout semantics |
| 02:31 | <Hixie> | believe me, i have every intention to take every possible shortcut in defining this |
| 02:31 | <othermaciej> | it sounds like the Mozilla API does not |
| 02:31 | <Hixie> | which means relying heavily on css and svg |
| 02:33 | <Philip`> | Hixie: drawHText should be called drawText, because many people will only ever do horizontal text and won't even think about the existence of vertical text, so they won't understand what the H is for. The H just makes things confusing for those people, and harder to type even for people who understand the reasoning, and it doesn't benefit anyone to keep the H in there |
| 02:33 | <Hixie> | i guess that makes sense, since the opposite doesn't apply to users of drawVText() |
| 02:34 | <Hixie> | othermaciej: dude, you're replying to yourself now on that bikeshed? :-) |
| 02:34 | <Philip`> | People who write vertical text seem to be equally familiar with horizontal text, so presumably they can cope fine with the differences between them |
| 02:34 | <othermaciej> | Hixie: I had another random idea |
| 02:34 | <Hixie> | othermaciej: (btw, rel values are "or"ed, not "and"ed) |
| 02:35 | <Hixie> | othermaciej: (so rel="icon 20x20" means it's two links, one for an icon, and one for a 20x20) |
| 02:35 | <Philip`> | Also the canvas API, and the whole of HTML5, and the whole web standards community, are strongly biased towards English (because e.g. all the method names and specs are written in English), so it's too late to be politically correct by balanacing drawVText and drawHText :-) |
| 02:35 | <othermaciej> | Hixie: "alternate stylesheet" is a counterexample to that (though perhaps a special exception) |
| 02:35 | <Philip`> | s/a// |
| 02:35 | <othermaciej> | Hixie: I like my sizes idea best, just wanted to jot that one down |
| 02:35 | <Philip`> | Oh, also it should be drawVerticalText instead of drawVText, so that people can work out what it means from the name |
| 02:35 | <Hixie> | Philip`: i don't buy that, i have no intention of biasing new apis against the majority of web users just because the standard is written in english |
| 02:36 | <othermaciej> | Hixie: it would be handy for Safari/WebKit purposes to have a ruling on this btw to spare us having to make something up |
| 02:36 | <Hixie> | othermaciej: for the icon thing? i didn't realise it was important for you too |
| 02:37 | <othermaciej> | Hixie: that is why I am telling you now :-) |
| 02:37 | <Hixie> | othermaciej: if i can ask, is this for iphone use, or for something else? |
| 02:38 | <Hixie> | othermaciej: (just trying to get an idea of what the use cases are) |
| 02:38 | <othermaciej> | Hixie: well, iPhone already has an iPhone-specific proprietary rel value to specify an iPhone-sized icon for use on the home screen |
| 02:38 | <Philip`> | Hixie: In terms of method naming, "drawVText" is already totally biased towards English, because it's using English words and abbreviations, which is unavoidable |
| 02:38 | <othermaciej> | it would be preferable for it to adopt a common thing |
| 02:38 | <Hixie> | othermaciej: k |
| 02:39 | <othermaciej> | I would also like apps like Fluid and Prism to be able to use proper OSX-compliant icons, thus the multisize thing |
| 02:39 | <othermaciej> | as for Apple's future plans, I am not at liberty to be specific |
| 02:39 | <Hixie> | sure |
| 02:39 | <Hixie> | Philip`: sure, but i try to keep that to a minimum |
| 02:39 | <Hixie> | Philip`: anyway, in this case it doesn't matter |
| 02:40 | <othermaciej> | tagging scalable/anysize icons is more for completeness but they could be a good alternative to multisize in many cases |
| 02:40 | <Hixie> | Philip`: as vertical text isn't as common as horizontal anyway |
| 02:40 | <othermaciej> | (if you provide vector art, the UA could always render it down to a multisize bitmap if that is what the OS wants) |
| 02:40 | <Hixie> | othermaciej: yeah |
| 02:40 | <Hixie> | right, dinner time |
| 02:40 | <Hixie> | bbl |
| 02:41 | <Philip`> | Hixie: I think maxWidth should be optional - it's only useful if it's used correctly, and it's actively harmful if it's used incorrectly (because authors will get confused about why some of their text keeps getting squashed), and it's not trivial to use it correctly, so people should not be forced to supply a value for it |
| 03:36 | <Philip`> | Hmm, getting into the IE8 Technical Beta program (which offers the privilege of being able to report bugs) is surprisingly easy |
| 03:51 | Philip` | sleeps |
| 07:57 | hsivonen | thinks Hixie is asking the wrong question when he asks if anyone "speaks" Devanagari |
| 09:45 | <Hixie> | hsivonen: i say "speak perl" etc, too |
| 09:47 | <hsivonen> | ok. |
| 09:50 | <Philip`> | It's slightly painful when you have to speak Perl over the phone to a non-programmer for them to type it in |
| 09:50 | <Hixie> | i actually had to do that the other day |
| 09:50 | <Hixie> | though it was over video iChat |
| 09:50 | <Hixie> | so instead i just asked to use screen sharing and did it manually |
| 09:51 | <Hixie> | i wish there was an option in iChat "ask to open ssh connection" |
| 09:52 | <hsivonen> | I need to learn some way to shield my mood from the negativity of bikeshedding |
| 09:54 | hsivonen | does some therapeutic tokenizer hacking |
| 10:00 | <Hixie> | i recommend blowing shit up in gta4 |
| 10:00 | Hixie | fires up his console |
| 10:18 | <Philip`> | http://www.w3.org/QA/2008/05/canvas-text-and-cjk.html |
| 10:23 | <krijn> | alt="Japanese Typography" |
| 10:23 | <krijn> | Yay \o/ |
| 10:31 | <Hixie> | hm |
| 10:31 | <Hixie> | i had good hopes for the doc he links to |
| 10:31 | <Hixie> | but it turns out to not say anything especially useful |
| 10:31 | <Hixie> | it's mostly abotu layout |
| 10:31 | <Hixie> | which doesn't affect us |
| 10:47 | <Lachy> | It's interesting though. I didn't realise they mixed verically stacked letters and rotated letters like that, each for different purposes. |
| 10:50 | <Hixie> | sure |
| 10:50 | <Hixie> | that's what "full width" characters are for, basically, as i understand it |
| 11:14 | <takkaria> | http://www.marcozehe.de/2008/05/01/social-bookmarking-feature-added-to-blog/ terrifies me. people with screenreaders have 45 images to skip over with near-identical alt text |
| 11:16 | <Philip`> | Don't screenreaders have a "skip to next paragraph" key, that would let you avoid all those images easily? |
| 11:16 | <Lachy> | oh, wow. I had hoped the silly craze of putting subscription links like that would be over by now. |
| 11:17 | <takkaria> | Philip`: we can hope |
| 11:18 | <hsivonen> | that's sad |
| 11:18 | <hsivonen> | all those icons are useless |
| 11:18 | <hsivonen> | I have a bookmarklet for the social bookmarking service I actually use |
| 11:18 | <Philip`> | When I last used Links (a few days ago), I was looking at a page that happened to have a "skip to content" link at the top before all the navigation menu stuff, but the browser just complained "cannot find #content" when I tried using the link :-( |
| 11:19 | <takkaria> | as far as I can tell, it's mainly done by people who aren't very popular but who really want to be and think that by including those links they'll becoming more so |
| 11:19 | <krijn> | Philip`: could've been a site I've built :$ |
| 11:20 | <krijn> | That happens a lot, when making templates for some backend company who just doesn't care |
| 11:22 | <roc> | takkaria: Marco is blind, for what it's worth |
| 11:22 | <roc> | so if it sucks for screenreaders, he'd probably know |
| 11:23 | <hsivonen> | at least it sucks visually |
| 11:23 | <roc> | it's his revenge! |
| 11:24 | <krijn> | Gheh |
| 11:24 | <othermaciej> | roc: is that really a safe assumption? many sighted people design UIs that are unbelievably bad for sighted users |
| 11:25 | <takkaria> | roc: oh, ok. interesting |
| 11:25 | <mpt> | It's begging for a parody |
| 11:26 | <roc> | othermaciej: true. But still, he cares about this stuff more than most of us |
| 11:27 | <takkaria> | mpt: I actually thought it /was/ a parody when I first saw it... |
| 11:27 | <mpt> | http://web.archive.org/web/19970205051143/www.stale.com/cmp/options.html#printable |
| 11:28 | <roc> | that was such a great site. |
| 11:30 | <mpt> | What was that Weblog that Mark Pilgrim did anonymously? Something about platypuses That had huge amounts of administrivia, too |
| 11:30 | mpt | stares at his "." key |
| 11:32 | <hsivonen> | www.ragingplatypus.com ? |
| 11:32 | <mpt> | oh, that was syndication buttons |
| 11:32 | <mpt> | http://web.archive.org/web/20030313032419/http://www.ragingplatypus.com/#metaplat |
| 11:32 | <Hixie> | gta4 has internet cafes where you can "browse the web" |
| 11:32 | <Hixie> | is it bad that my first thought was to try to go to see how it does on the acid3 test |
| 11:33 | <hsivonen> | Hixie: how did it do? |
| 11:33 | <Hixie> | "page not found" |
| 11:35 | <Hixie> | wow |
| 11:35 | <Hixie> | this web is like a total parody of the real one |
| 11:37 | <roc> | I assume if you get frustrated with your Web browsing experience you can blast the computer to smithereens |
| 11:37 | <Hixie> | and then firebomb the internet cafe, seems likely |
| 11:38 | <othermaciej> | are you browsing on the iFruit? |
| 11:38 | <Lachy> | wikipedia says "There are over 100 accessible, fictitious websites within the game" |
| 11:38 | <Lachy> | http://en.wikipedia.org/wiki/Grand_Theft_Auto_IV |
| 11:38 | <roc> | crazy |
| 11:39 | <Hixie> | wow, there are possibly more porn sites on the gta4 web than the real one |
| 11:39 | <Lachy> | LOL |
| 11:39 | <othermaciej> | no way |
| 11:40 | <Lachy> | Hixie, I think you may be seriouly underestimating the amount of porn on the real web. :-) |
| 11:40 | <roc> | they should just stick a real browser in there with real internet access |
| 11:41 | <roc> | also, they should support video chat with the outside world |
| 11:41 | <Hixie> | Lachy: well, i mean, relative to the total size, not in absolute numbers, obviously :-) |
| 11:41 | <roc> | so you can call your friends from in-game and they'll see your avatar |
| 11:41 | <roc> | then they'll watch you get blown up because you're not paying attention |
| 11:42 | <Hixie> | this fake web is remarkably true to the real one |
| 11:42 | <Lachy> | any well known sites included within it? |
| 11:43 | <Hixie> | there's a page antfarmcam.net that claims to have a webcam of an antfarm, except the camera is down |
| 11:43 | <Hixie> | and there are three comments on this blog |
| 11:43 | <Hixie> | first is "WTF! This lame cam has been down for months! [...]" |
| 11:43 | <Hixie> | second is full of swear words |
| 11:44 | <Hixie> | and the last is from "5 months ago" and says "I hop ur antz is ded/ LOL Ants stink" |
| 11:44 | <Lachy> | what, no "first post" troll? |
| 11:48 | <Hixie> | ok let's see if i really can blow up these computers |
| 11:48 | <Hixie> | HAHAHAHA |
| 11:48 | <Hixie> | oh yeah |
| 11:48 | <Hixie> | hm i scared the other customer |
| 11:49 | hsivonen | awaits out-of-context IRC log quotes to show up on mailing lists |
| 11:50 | <deltab> | http://arstechnica.com/journals/thumbs.ars/2008/05/01/grand-theft-auto-iv-story-time-with-ben-and-frank |
| 12:17 | <Philip`> | Seems like GTA4's developers have registered all their virtual-internet domain names on the real internet, but they haven't even got DNS records, which seems like an odd waste of a marketing opportunity |
| 12:18 | <Hixie> | some do |
| 12:18 | <Hixie> | the jazz station in gta4 is better than most real jazz stations i've listened to |
| 12:22 | Philip` | has always wondered how much it cost to license all the music that's used in the games |
| 12:27 | <hsivonen> | what are XHTML compact forms? http://krijnhoetmer.nl/irc-logs/xhtml/20080430#l-108 |
| 12:29 | <Philip`> | hsivonen: Probably http://www.w3.org/MarkUp/2008/ED-xhtmlmime-20080423/#C_10 |
| 12:30 | <Philip`> | s/Probably/Maybe/ |
| 12:30 | <hsivonen> | Philip`: thanks |
| 14:19 | <hsivonen> | How is "foo<!--->bar" supposed to parse in [R]CDATA? |
| 14:24 | <hsivonen> | hmm. I suppose the second hyphen turns escape on and > turns it off |
| 15:02 | <hsivonen> | the html5lib test cases rock |
| 15:17 | Philip` | wonders if "hash backet" is a common term, or if it's just a spelling mistake in this hash table implementation that nobody has bothered to fix |
| 15:18 | <hsivonen> | oh yeah, still only 7925 bytecodes |
| 15:20 | <Philip`> | Can you get bytecode optimisers to make it smaller? |
| 15:20 | <hsivonen> | Philip`: I don't have one |
| 15:20 | <hsivonen> | Philip`: If I need to make it smaller, I'll move string concatenation for error messages into another method |
| 15:21 | <Philip`> | Invalid HTML is the most common case, so you should be optimising the generation of error messages :-) |
| 15:21 | <hsivonen> | heh |
| 15:40 | <hsivonen> | getting rid of the content model flag and the escape flag wasn't as big a win as I expected, but now HEAD beats the latest release even on PPC Client VM |
| 15:41 | <Philip`> | How fast does it parse now, in megabits per second? |
| 15:42 | <hsivonen> | http://about.validator.nu/htmlparser/perf3.zip |
| 15:42 | <hsivonen> | Philip`: I haven't measured it that way |
| 15:48 | <Philip`> | Hmm, it can parse a 53KB file about 30K times in one minute, so it's around 200Mbit/s |
| 15:48 | <Philip`> | which is faster than the network interface on that machine |
| 15:48 | <Philip`> | so it seems unlikely to be the bottleneck in the kinds of thing I'd use it for |
| 15:49 | <Lachy> | http://www.bestkungfu.com/archive/date/2008/05/alt-and-the-flickr-defense/ |
| 15:49 | <Lachy> | ... seems to be more of the same. |
| 15:52 | <Philip`> | (XML=55301, methods=26961, switch=27660, Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-b105, mixed mode)) |
| 15:52 | <Philip`> | (running for 1 minute) |
| 15:53 | <Philip`> | (since I'm too lazy to leave it for longer) |
| 16:25 | <Lachy> | Interesting statistics http://www.456bereastreet.com/archive/200804/validation_statistics_from_nikita_the_spider/ |
| 16:25 | <Lachy> | I would have though unescapted & would rate higher than missing alt though, but it seems not |
| 16:27 | <Lachy> | though it seems the results are limited to pages where authors explicitly validated their page, rather than a general web crawl. So it's possible the results could be a bit biased in some ways. |
| 16:29 | <Philip`> | That's total number of occurrences, not number of pages, which is slightly dodgy since a few pages with thousands of images could distort the results |
| 16:30 | <Philip`> | They got 55K altless images out of 10K pages, i.e. 5.5 per page; I got 69K out of 8K pages, i.e. 9 per page |
| 16:31 | <Philip`> | Out of all pages with <img>, I saw 20% of those pages never using alt |
| 16:32 | <Philip`> | Out of all pages in total, I saw 30% with unencoded ampersands |
| 16:32 | <Philip`> | (but I don't know how many unencoded ampersands per page) |
| 20:38 | <mcarter> | hello |
| 21:53 | <Philip`> | Does anyone happen to know if CSS3 Color drafts have changed since the 2003 CR in a way that would affect (to pick a totally arbitrary example) canvas fill/stroke colours? |
| 21:53 | <Philip`> | (All I've noticed so far is the dropping of flavor) |
| 22:10 | <Hixie> | dbaron: 23:12 < Philip`> Does anyone happen to know if CSS3 Color drafts have changed since the 2003 CR in a way that would affect (to pick a totally arbitrary example) canvas fill/stroke colours? |
| 22:11 | <dbaron> | All the changes are described in http://csswg.inkedblade.net/spec/css3-color |
| 22:11 | <Hixie> | Philip`: ^ |
| 22:11 | <Hixie> | dbaron: thanks |
| 22:11 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/images/baselines.png is the image i was talking about btw |
| 22:11 | <dbaron> | I think some of those technically do affect things |
| 22:11 | <Hixie> | in case you spotted any problems |
| 22:12 | <dbaron> | e.g., handling of out-of-range values for hsl(), hsla(), and rgba() was undefined. |
| 22:12 | <Hixie> | was undefined and is now defined, or was un-defined? |
| 22:12 | <Hixie> | i assume the former! :-) |
| 22:12 | <dbaron> | the former |
| 22:12 | <dbaron> | mostly |
| 22:12 | <Hixie> | heh |
| 22:12 | <dbaron> | it's now mostly but not completely defined |
| 22:13 | <Philip`> | dbaron: Aha, thanks |
| 22:17 | <Philip`> | Hixie: Would there be any point in producing an SVG version of that image? It would seem nicer than the current PNG with 5-pixel tall characters since you could zoom in to read it, but it'd probably be a waste of time if the spec just wants to stick with PNG for browser compatibility |
| 22:27 | <Hixie> | Philip`: i'm certainly happy for you to create an svg image and would be happy to link the png to the svg image |
| 22:28 | <Hixie> | Philip`: but i expect i'll stick to png as the main one |
| 23:11 | <Hixie> | man i wish anne would provide an obvious link to the editor's copies of his drafts on the TR versions |
| 23:11 | <Hixie> | i can never find the latest versions of his specs |
| 23:14 | <Hixie> | christ dev.w3.org is such a mess |
| 23:14 | <Hixie> | how am i supposed to guess that access-control is a waf spec, and how am i supposed to guess the waf was created in 2006? |
| 23:18 | <Hixie> | hrm |
| 23:18 | <Hixie> | did we remove the ability to opt-in to certain methods? |
| 23:19 | <Hixie> | i guess we did |
| 23:20 | <Lachy> | Hixie, have you been following the selectors api thread about :scope vs. other methods? |
| 23:20 | <Hixie> | yeah |
| 23:20 | <Lachy> | what's your opinion on the issue? |
| 23:21 | <Hixie> | i don't understand the issue |
| 23:21 | <Hixie> | i mean, i understand what is being requested |
| 23:21 | <Hixie> | i don't understand the use case |
| 23:22 | <Lachy> | there are several use cases that need to be addressed. |
| 23:22 | <Hixie> | i agree that a pseudo-class that matches the context node might be useful, but it seems like a v2 thing |
| 23:22 | <Lachy> | yeah, that was the original plan |
| 23:22 | <Hixie> | i don't agree with changing selectors to only look at nodes at the context plan or lower |
| 23:22 | <Hixie> | that seems silly |
| 23:23 | <Lachy> | yeah, that's what I think. But it is the behaviour of current JS library versions |
| 23:23 | <Hixie> | so? this doesn't stop them existing |
| 23:23 | <Hixie> | not my fault they are all buggy... |
| 23:23 | <Lachy> | yeah, I guess. |
| 23:25 | <Lachy> | JohnResig, yt? |
| 23:26 | <JohnResig> | Lachy: what's up? |
| 23:28 | <Lachy> | I don't see what problem is being solved by changing the API, that won't be solved by adding :scope in the near future |
| 23:28 | <Hixie> | (:scope is a terrible name btw) |
| 23:28 | <Hixie> | (imho!) |
| 23:28 | <Lachy> | Hixie, any better suggestion? |
| 23:28 | <Hixie> | sadly not |
| 23:28 | <Hixie> | so i'm afraid i'm not much help |
| 23:28 | <Hixie> | :-) |
| 23:28 | <Lachy> | so far the options are :self, :this, or :scope |
| 23:28 | <Hixie> | :context-node |
| 23:28 | <Hixie> | :current |
| 23:29 | <Lachy> | yeah, they could work |
| 23:29 | <Hixie> | :query-root |
| 23:29 | <Hixie> | i dunno |
| 23:29 | <Hixie> | i guess it doesn't matter that much |
| 23:29 | <Hixie> | i do like the :query-root name, since this is similar to :root in many ways |
| 23:29 | <Hixie> | indeed some people suggested just using :root |
| 23:29 | <Hixie> | which i disagree with |
| 23:29 | <Hixie> | but i see the logic |
| 23:30 | <Lachy> | naming debates are fun :-) |
| 23:30 | <Hixie> | the final decision is up to you obviously |
| 23:30 | <Lachy> | that's what I thought the last time I was in a naming debate |
| 23:30 | <Hixie> | i'm just throwing in my twopence or however you spel that |
| 23:30 | <Hixie> | yeah well |
| 23:30 | <JohnResig> | Lachy: so you're perfectly happy with Safari, Opera, Firefox, and Internet Explorer all shipping with no way of finding child (or adjancent) elements and returning inconsistent results? and everyone being stuck with using that broken method for years to come? |
| 23:31 | <Hixie> | the w3c hasn't quite caught up with the 21st century yet |
| 23:31 | <Lachy> | JohnResig, why couldn't we spec and ship with support for :scope, in the same time it would take to change the API? |
| 23:31 | <Hixie> | why would they be inconsistent results? |
| 23:32 | <Hixie> | and how is there no way to find child or adjacent elements? |
| 23:32 | <Hixie> | i guess it would help to see the use cases |
| 23:32 | <JohnResig> | Hixie: note the examples that I provided in the thread - finding elements that are globally-rooted rather than contextually-rooted goes against all previous implementations |
| 23:33 | <Hixie> | JohnResig: sure, but like i said, it's not my fault all those implementations are buggy |
| 23:33 | <JohnResig> | Hixie: define "buggy" - "buggy" seems to be "we have better control over the selectors that we can provide" |
| 23:33 | <Hixie> | buggy as in they don't implement selectors correctly |
| 23:33 | <Hixie> | selectors aren't rooted at a different tree |
| 23:33 | <Lachy> | it's easier to add contextually-rooted support later (or at the same time), than it is to add globally-rooted selectors |
| 23:34 | <Hixie> | but anyway that's not a use case |
| 23:34 | <Hixie> | that's just past implementations |
| 23:34 | <othermaciej> | JohnResig: old Safari versions fall to infinitesimal market share pretty quickly |
| 23:34 | <Lachy> | in fact, it would be impossible to do the latter without introducing a whole new method |
| 23:34 | <Hixie> | use cases are what i'd like to see |
| 23:34 | <othermaciej> | JohnResig: at least as to WebKit, I think your concern about old versions is overblown |
| 23:34 | <JohnResig> | othermaciej: I'm not worried about Safari at all - I'm crazy-concerned about IE |
| 23:35 | <JohnResig> | if browsers are released that don't implement :scope then, effectively, developers won't be able to use Element.querySelectorAll in them |
| 23:35 | <Hixie> | it's trivial to fake :scope |
| 23:35 | <JohnResig> | oh, is this the fun "add an ID to the element then remove it later" - yeah, that' BS |
| 23:35 | <JohnResig> | *that's |
| 23:35 | <Lachy> | yeah, it can be done with an ID selector (even if that ID is temporarily auto-generated by the API |
| 23:36 | <Lachy> | I know it's not optimal |
| 23:36 | <Hixie> | it's no more BS than the idea that we need it in the first place :-) |
| 23:36 | <JohnResig> | except that's something that should be done by the implementation in the first place |
| 23:36 | <Hixie> | but like i said, i'd need use cases to work out what the actual discussion point is |
| 23:36 | <Hixie> | arguing about an API design in the absence of use cases is meaningless |
| 23:37 | <Hixie> | it could be that the best anchor point is the parent's previous sibling for all i know |
| 23:37 | <Lachy> | JohnResig, do you have some example pages that use the JS libraries in the way you describe? |
| 23:37 | <JohnResig> | Lachy: using contextual selectors? how many do you want? |
| 23:37 | <Hixie> | 5 would be nice |
| 23:43 | <jwalden> | Hixie: 'If the scheme is "file:", then the user agent may return a UA-specific origin.' -- there shouldn't be a colon in "file", methinks |
| 23:44 | <Hixie> | you sure? |
| 23:45 | <Hixie> | i forget if scheme includes the colon or not |
| 23:45 | <Hixie> | ah it does not |
| 23:45 | <Hixie> | ok |
| 23:45 | <Hixie> | i have removed it |
| 23:45 | <Hixie> | thanks! |
| 23:45 | <Hixie> | (won't appear in the spec for a while) |
| 23:46 | <Philip`> | Are contextual selectors in jQuery done with thing.filter('selector')? |
| 23:46 | <JohnResig> | Here's about 200, give or take, http://www.google.com/codesearch?hl=en&lr=&q=jquery+\.find+-%22New+Wave+JavaScript%22+file%3Ajs%24&btnG=Search |
| 23:47 | Lachy | looks... |
| 23:47 | <JohnResig> | Philip`: those are filters - contextual selectors are done with .find() |
| 23:47 | <Philip`> | JohnResig: Ah, thanks |
| 23:47 | <JohnResig> | Lachy: those are only the ones that use .find() - there's a bunch that do jQuery("selector", element) |
| 23:48 | <JohnResig> | this is also ignoring the ones that are used in jQuery directly - and ones that are used by other frameworks |
| 23:49 | <JohnResig> | some of these queries won't be applicable to querySelectorAll (unless, of course, it's made to work on document fragments) |
| 23:49 | <Lachy> | what's the difference between .find() and jQuery("selector", element)? |
| 23:49 | <JohnResig> | Lachy: there is none - they're identical |
| 23:50 | <JohnResig> | doing jQuery("selector", element) just maps to jQuery(element).find("selector") |
| 23:50 | <Philip`> | The first few I find via dmoz.org are ... |
| 23:50 | <Philip`> | http://www.dorez.com/ - $(this).find("+ ul") |
| 23:50 | <Philip`> | http://www.queens.edu/athletics/wvolleyball/home.asp - $("#nav").superfish(...).find(">li[ul]") |
| 23:50 | <Philip`> | http://www.fortdalles.com/ - $(this).find("a") |
| 23:50 | <Philip`> | (plus another dozen or so) |
| 23:50 | <JohnResig> | the second one is using an old version of jQuery - but the other two are applicable |
| 23:51 | <JohnResig> | the second one would be written .find("> li:has(ul)") |
| 23:51 | <JohnResig> | Philip`: what's the search that you used? |
| 23:52 | <Lachy> | .find("+ ul") one couldn't work even with :scope, or any other proposed solution, since .querySelector only returns descendant nodes |
| 23:53 | <JohnResig> | as the spec is written, that is |
| 23:55 | <Lachy> | I'm not even sure how it could be rewritten to add the ability, and doing so would add a significant amount of development time for both the spec and implementations |
| 23:55 | <Philip`> | Hmm, I also found one duplicate of the superfish script, and two of the find("a") script, and the rest are: |
| 23:55 | <Philip`> | http://cafe.daum.net - $(this).find("CONTENT") |
| 23:55 | <Philip`> | http://www.abenteuer-reisen.de/wg/ph/ http://www.abenteuer-reisen.de/wg/cv/wg_cv__rf00__index.htm - $(this).find("option:selected") |
| 23:55 | <Philip`> | http://www.mat.uni.torun.pl/wosp2001/ - portlet.find('.portlet-content-container') |
| 23:55 | <Philip`> | http://www.rodgersinstruments.com/ - $(this).find("a[@class='active']") |
| 23:55 | <Philip`> | http://www.dostavka.ru/ - $node.find("div.node_ajax") |
| 23:55 | <Lachy> | $(this).find("a") works with the current API |
| 23:56 | <Philip`> | (or at least that's what they were two months ago - at least the last of those sites has changed now) |
| 23:56 | <Philip`> | JohnResig: I downloaded ~130K pages that were listed on dmoz.org a couple of months ago, then grepped for /\.find\(["']/ |
| 23:57 | <JohnResig> | Philip`: ah, neat |
| 23:57 | <Lachy> | so the proposed changes are only relevant when one wants to acquire either a child node of the context node (":scope>*") or using descendant combinators, such that all parts of the selector only match elements within the context (":scope foo bar") |
