| 00:16 | <mcarter__> | Hello |
| 00:17 | <mcarter> | In the Server-Sent-Events specification, the 301 Moved Permanently response says that the UA must reconnect to the new URI. What URI should be provided to the removeEventSource function to disconnect it? the original URI, or the redirected URI? |
| 00:19 | <Hixie> | mcarter: good question. send mail. :-) |
| 00:20 | <mcarter> | ok, will do |
| 00:21 | <Hixie> | (probably the origin one) |
| 00:21 | <mcarter> | Hixie, something else I need to mention on the list is that the terminology is a bit confusing. On the one hand you have the "event-source" dom element, but then you can call addEventSource on an event-source |
| 00:21 | <Hixie> | er, original |
| 00:22 | <Hixie> | you can call addEventSource on anything |
| 00:22 | <mcarter> | so when I see something like "(It doesn't affect other event sources with the same URI unless they also receive 301 responses, and it doesn't affect future sessions, e.g. if the page is reloaded.)" I don't know if "event sources" means the dom element, or one of the event sources attached to that dom element |
| 00:22 | <Hixie> | it means the event sources unless it is spelt event-sourcen orange |
| 00:22 | <Hixie> | er |
| 00:22 | <Hixie> | man i suck at typing today |
| 00:22 | <Hixie> | "it means the event sources unless it is spelt event-sourc in orange" |
| 00:23 | <mcarter> | Hixie, hmm, then that sentence seems to imply that you can call addEventSource(url) multiple times on the same event-source element with the same url |
| 00:25 | <Hixie> | yes |
| 00:26 | <Hixie> | <event-source> as an element is the same as <span> |
| 00:26 | <Hixie> | except for one thing |
| 00:26 | <Hixie> | which is that its src="" attribute causes addEventSource() and removeEventSource() to be called |
| 00:26 | <Hixie> | on itself |
| 00:26 | <Hixie> | we could in fact remove <event-source> altogether, it's just there for convenience |
| 00:28 | <mcarter> | well, what I'm getting at is that the spec seems to imply that a dom element that implements the RemoteEventTarget interface can have its addEventSource function called twice with an identical url. I'm not sure what that would mean -- that you make two connections to the same URI? how would you close a particular one? |
| 00:30 | <Hixie> | the spec doesn't provide a way to remove a particular one |
| 00:30 | <Hixie> | it'll remove one each time you call removeEventSource(), but you can't control which one |
| 00:31 | <mcarter> | ok |
| 00:49 | <Hixie> | so much for a non-confidential xhtml2 wg |
| 00:49 | <Hixie> | http://lists.w3.org/Archives/Member/w3c-html-wg/2008AprJun/ |
| 00:49 | <andersca> | ha |
| 00:50 | <Hixie> | oh ok it was a mistake |
| 00:50 | <Hixie> | nevermind |
| 00:51 | <Hixie> | (http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0404.html) |
| 01:02 | Philip` | wonders if it's intentional that HTML5 almost always uses the passive voice, like in "The values of the data array may be changed", instead of saying something like "Authors may change the values of the data array" that is often less ambiguous |
| 01:08 | <Dashiva> | Maybe to avoid overspecifying |
| 01:08 | <Dashiva> | Like, is it possible to change the value without being an author? |
| 01:09 | <Philip`> | Treat it as an abbreviation of "authors may write documents which cause scripts to execute which change the values of the data array" (and define that abbreviation somewhere global) |
| 01:10 | <Philip`> | It's underspecified now, because the UA might decide to arbitrarily change the data array at some random point in time, and argue that that's allowed because the spec says 'the values may be changed' |
| 01:11 | <Philip`> | (ignoring the issue that "may" is inappropriate here - pretend I'm talking about a different case that uses "must" or something :-) ) |
| 01:12 | <Philip`> | (like "ImageData objects must be initialised so that ..." - who must do that? There's only one possible answer given the context, but you shouldn't have to deduce the meaning that's implicit in the context) |
| 01:13 | <Philip`> | Anyway, I'm not sure if I'm just being uselessly picky here - it's not going to cause problems in practice, it's just a bit unclear when trying to read the spec in detail, and maybe there are reasons to write it like how it's written now (e.g. 'it looks ugly and hard to read otherwise') |
| 01:14 | <Philip`> | ...and those reasons could be more significant than the trivial problems |
| 02:01 | <Philip`> | Hmm, maybe I shouldn't focus so much on testing the ability to draw solid lime green rectangles - WebKit seemed to be doing really quite well on my ImageData tests, until I accidentally found that it actually totally breaks if you draw some data with alpha!=1 and more than one colour of pixels... |
| 02:08 | <Hixie> | Philip`: see if you can track down teh bug that causes teh whatwg issues graph to change colour when you hover over it |
| 02:08 | <Hixie> | and the spec using the passive voice is just that my style, it's probably not ideal |
| 02:09 | <Hixie> | if there are cases where it is genuinely ambiguous let me know |
| 02:28 | <Philip`> | Hixie: I don't see what you mean about it changing colour |
| 02:28 | <Hixie> | originally the bars in the background are yellow |
| 02:28 | <Hixie> | after the putImageDate(), the turn gray |
| 02:29 | <Philip`> | Hixie: I don't think I've seen any cases where it's actually ambiguous, so I'm only moaning about it on IRC for now :-) |
| 02:29 | <Hixie> | :-) |
| 02:29 | <Philip`> | Hixie: In which browser(s)? |
| 02:29 | <Hixie> | webkit trunk |
| 02:30 | <Philip`> | Looks like it could be the same issue as I found, if you're putImageDataing things with transparent pixels |
| 02:30 | <Philip`> | https://bugs.webkit.org/show_bug.cgi?id=18821 |
| 02:30 | <Hixie> | k |
| 02:30 | <takkaria> | MikeSmith: ping |
| 02:31 | <Philip`> | (It seems to copy the colour data from the leftmost pixel, and mixes it with the alpha from the proper pixels) |
| 02:31 | <Philip`> | (and if the leftmost pixel is transparent then it'll be black/grey) |
| 02:32 | <Philip`> | (I haven't got a clue how they could have implemented such a bug) |
| 02:33 | <Hixie> | off by one byte? |
| 02:34 | <Philip`> | It's not just one byte - the colour from the leftmost pixel propagates infinitely far rightwards |
| 02:35 | <Hixie> | oh |
| 02:35 | <Hixie> | wtf |
| 02:35 | <Hixie> | actually that's easier |
| 02:35 | <Hixie> | probably a misinitialised variable |
| 02:35 | <Hixie> | as in, something that is scoped to a different scope than they realise |
| 02:35 | <Philip`> | It's also odd that it only happens when alpha != 1 |
| 02:36 | <Philip`> | since I don't see why there'd be any point in special-casing that case on purpose |
| 02:37 | <Philip`> | But I'll bet they fixed it six days ago anyway, and just haven't got a new nightly build out since then :-) |
| 02:38 | <Hixie> | heh |
| 02:55 | <MikeSmith> | takkaria: wanted to ask you about progress (if any) on your html5lib porting |
| 02:59 | <takkaria> | MikeSmith: well, it's not porting, but not started yet, no |
| 02:59 | <MikeSmith> | OK |
| 05:14 | <MikeSmith> | takkaria: you still around? |
| 05:16 | <takkaria> | MikeSmith: yes |
| 05:17 | <MikeSmith> | takkaria: wanted to ask if you're on the whatwg implementors mailing list |
| 05:17 | <takkaria> | MikeSmith: yup |
| 05:17 | <MikeSmith> | ah, OK |
| 05:17 | <takkaria> | have been since it started, I think |
| 05:20 | <takkaria> | actually I'm waiting on ink cartridges to arrive so I can print out the relevant chunks of the spec and read them through with marker pen |
| 05:20 | <takkaria> | then I intend to start coding |
| 05:21 | <MikeSmith> | I just asked about the list because I noticed messages from Edward Yang |
| 08:16 | <Hixie> | http://juicystudio.com/article/html5-alt-text-authoring-tools.php |
| 08:16 | <Hixie> | apparently my attempts at improving accessibility are seen as an attempt to make html5 appear successful |
| 08:16 | <Hixie> | and our attempts at doing and working based on real research is seen as misdirection |
| 08:20 | <othermaciej> | Hixie: I apologies for turning the icon size discussion into a bikeshed |
| 08:21 | <Hixie> | no worries |
| 08:21 | <Hixie> | my working model handles bikesheds very easily :-) |
| 08:27 | Hixie | comments on that link |
| 09:36 | <jgraham_> | Wow, Gez's article is surprisingly uninteresting given how much publicity it's had (well one link in IRC and 2 emails on public-html) |
| 09:38 | <jgraham_> | I was expecting new arguments, instead it was just the same stuff but with the accusation that people who don't agree that alt should be mandatory are being disingenuous |
| 09:45 | <Lachy> | wow, he seems to be arguing that alt should still be omitted when an authoring tool has nothing useful to put in it, but that it should be considered invalid. |
| 09:47 | <Philip`> | Why is that a bad idea? |
| 09:48 | <jgraham_> | Philip`: Because it encourages people to stuff alt with meaningless values to make their pages valid |
| 09:49 | <Philip`> | It encourages people to set alt values to make their pages valid - some of those may be meaningless, but others may be meaningful and worthwhile |
| 09:50 | <Philip`> | (assuming "people" means "authors") |
| 09:50 | <Philip`> | (If "people" means "authoring tool developers", then they're not capable of meaningful text, in which case it is a problem) |
| 09:51 | <othermaciej> | requiring software to generate nonconforming content in some situations does not make sense as a conformace requirement |
| 09:51 | <jgraham_> | It's not quite clear which way that one would swing but, with a site like flickr, if there was an option to set alt text, I would expect the values to be harmful more often than they were helpful |
| 09:52 | <jgraham_> | (assuming flickr provided the box out of a desire to allow pages to be conforming) |
| 09:52 | <othermaciej> | I have been trying to use VoiceOver more lately to play with some of WebKit's new accessibility stuff |
| 09:53 | <othermaciej> | perhaps I will get a sense of how annoying repeated or bad alt values are |
| 09:53 | <othermaciej> | (by "repeated" I mean repeats something in the real page content) |
| 09:53 | <othermaciej> | jgraham_: it probably would get used a fair bit less than the title or description fields |
| 09:53 | <othermaciej> | I would guess a minority of photos have both title and description set |
| 09:54 | <jgraham_> | othermaciej: I would expect that at best people would just copy the description into the field |
| 09:54 | <jgraham_> | s/field/alt field/ |
| 09:55 | <othermaciej> | well I think on flickr gallery pages, "go to photo page" may be better alt text than a description in any case |
| 09:55 | <othermaciej> | open question whether more description would help a substantive portion of the individual photo pages |
| 09:56 | <jgraham_> | Yeah, on the gallery page "go to photo $photo_title" might be the best alt text |
| 09:56 | <jgraham_> | I was thinking of the individual photo pages |
| 10:06 | <jgraham_> | I can't help but think the required alt thinking is tied to the idea that accessibility only happens as a result of people wielding a stick to make it happen. Therefore taking away anything that can be used as a stick is perceived as bad even if that change also has the potential to create an environment where accessibility is better in the default no-stick case. |
| 10:07 | <jgraham_> | But I should stop thinking such things until I get around to finishing the data collection tool thing |
| 10:07 | <jgraham_> | :) |
| 10:41 | <htmlfivedotnet> | Outsiders opinion: Someone who knows what their doing will use the alt tag correctly, many people don't even know its purpose, which is why garbage gets jammed in. No alt tag should be valid html, but not considered accessible... which may cause someone to figure out what that means, and fix it. |
| 10:42 | <htmlfivedotnet> | *missing alt tag, rather. |
| 13:47 | <Philip`> | http://www.adobe.com/openscreenproject/developers/ - SWF and FLV specs now with no licensing restrictions |
| 13:58 | <othermaciej> | hmm, I can't actually tell how f4v differs from m4v from this |
| 14:00 | <roc> | that's cool |
| 14:03 | <Philip`> | Sounds mostly like F4V is just a profile of MP4 |
| 14:08 | <othermaciej> | I think I would need to be an expert on MPEG to understand if what they are describing is different |
| 14:09 | <othermaciej> | I think they are redefining parts of the various MP4 container format specs |
| 14:09 | <Philip`> | It'd be useful if there was an MPEG experts group that could be asked that kind of thing |
| 14:09 | <othermaciej> | but I can't tell if it is actually compatible with real mpeg 4 |
| 14:10 | <othermaciej> | some sort of Motion Picture Experts Group maybe? |
| 14:10 | <Philip`> | Yeah, someone should form one of those |
| 14:22 | <Philip`> | http://www.kaourantin.net/2007/10/new-file-extensions-and-mime-types.html seems to indicate that Flash ignores the filename and ignores the ftyp=F4V field, and treats them the same as any other MP4 file |
| 19:20 | <Hixie> | htmlfivedotnet: that's what the spec says at the moment :-) |
| 19:58 | <Hixie> | jgraham_: btw i'm happy to help with the "choice of sites" problem |
| 19:59 | <Hixie> | jgraham_: i can trivially get you a list of urls for pages that satisfy a particular criteria |
| 19:59 | <Hixie> | just tell me how many, and what criteria |
| 20:07 | <Hixie> | aw man, i fell into the trap |
| 20:08 | <Hixie> | and i was being so careful |
| 20:09 | <Philip`> | When near a trap, 'being careful' usually means getting as far away as possible, rather than thoughtfully and slowly and delicately poking it until it rips your arm off |
| 20:10 | <Hixie> | i had been just not replying to the e-mails |
| 20:11 | <maikmerten> | Hixie: do you happen to have a spare minute or two? ;-) |
| 20:11 | <Hixie> | sure |
| 20:11 | <maikmerten> | ah, thanks |
| 20:11 | <maikmerten> | well, I am pretty curious what you meant with your blog comment reading as follows: "The Theora codec isn't unencumbered, despite popular opinion; it just hasn't had anyone claim patents on it publicly yet." |
| 20:12 | <maikmerten> | this sounds like patents actually *surfaced* |
| 20:12 | <Hixie> | i don't know of any specific patents myself |
| 20:12 | <maikmerten> | and that you're just leaning back to see the train wreck ignite ;) |
| 20:12 | <maikmerten> | so you were referring to the "usual" submarine threat |
| 20:12 | <maikmerten> | (I assume?) |
| 20:12 | <Hixie> | but i am told by video experts that the "submarine" threat is not really hypothetical in the case of theora |
| 20:12 | <Hixie> | er |
| 20:12 | <Hixie> | note that theora |
| 20:13 | <Hixie> | note that theora hasn't been designed in a way to avoid patents or anything |
| 20:13 | <Hixie> | (unlike vorbis) |
| 20:13 | <maikmerten> | that's not quite true, On2 makes a living out of evading patents |
| 20:13 | <maikmerten> | it's their business model |
| 20:13 | <Hixie> | i can't speak to that |
| 20:13 | <Hixie> | i'm just saying that from a patent point of view, theora isn't clean enough |
| 20:14 | <Hixie> | not that anything else is any better |
| 20:14 | <Hixie> | but theora isn't the silver bullet people make it out to be |
| 20:14 | <maikmerten> | well, I wonder why those "video experts" don't just speak out |
| 20:14 | <Hixie> | because there are legal implications to claiming knowledge of patents |
| 20:14 | <maikmerten> | *if* there are problems they should just go public with it |
| 20:14 | <jgraham_> | Hixie: Great. I need to find a little time to work on it... |
| 20:15 | <Hixie> | e.g. if you know that a patent exists and then you violate it, your liability triples, as i understand it |
| 20:15 | <maikmerten> | nobody benefits from Theora adopters getting hurt *if* there are problems |
| 20:15 | <maikmerten> | and it would be interesting to see who those experts are anyway |
| 20:15 | <Hixie> | the law around patents are non-intuitive |
| 20:15 | <Hixie> | you can get in trouble just for knowing things |
| 20:15 | <maikmerten> | note that "audio experts" claimed the same for Vorbis |
| 20:15 | <Hixie> | it's pretty ridiculous |
| 20:15 | <Hixie> | again, i can't speak to that |
| 20:16 | <Hixie> | the long and short of it is that theora is just as bad as everything else, except for being vendor-specific (not a standard) and not quite as technically good as H.264 |
| 20:16 | <Hixie> | Sun's H.261 work looks interesting though |
| 20:16 | <Hixie> | if that goes anywhere |
| 20:17 | <maikmerten> | well, if they change anything about H.261 they're facing the same threat |
| 20:17 | <maikmerten> | but it's interesting, yes |
| 20:17 | <maikmerten> | (what makes them different is that people assume they *have* lawyers) |
| 20:18 | <maikmerten> | and as for being vendor-specific: The spec is in the public domain, so how much more libre can it go anyway |
| 20:18 | <Philip`> | (They also have liability if their lawyers make the wrong decisions, so there's a significant incentive for them to be cautious) |
| 20:18 | <Hixie> | well, it could be an ISO standard :-) |
| 20:19 | <maikmerten> | and for not being as good as H.264 - well, that's not the reference to compare to when talking about royality free standards |
| 20:19 | <maikmerten> | just like OOXML? ;-) |
| 20:19 | <maikmerten> | well, HTML could also be an ISO standard |
| 20:19 | <Hixie> | it is |
| 20:19 | <maikmerten> | so, and what does that change ;) |
| 20:19 | <Hixie> | ISO/IEC 15445:2000(E) |
| 20:19 | <maikmerten> | yup |
| 20:20 | <Hixie> | i'm just saying that a public domain spec by one vendor is not the same as an internationally recognised standard |
| 20:20 | <Philip`> | The existence of ISO-HTML doesn't suggest that ISO has extremely high standards of detailed interoperable specifications |
| 20:20 | <Hixie> | i agree that H.264 has known patent claims made on it |
| 20:21 | <Hixie> | though they may expire in the coming years, possibly before html5 is complete, even |
| 20:21 | <Hixie> | (at least for 264 baseline) |
| 20:21 | <maikmerten> | one could argue that being an ISO standard can in some cases just be a "checkbox feature", without real practical consequences |
| 20:21 | <Hixie> | one could |
| 20:21 | <Hixie> | but tell me |
| 20:21 | <Philip`> | By the time H.264's patents have expired, it'll be as technically worthless as H.261 |
| 20:22 | <Hixie> | did you prefer <canvas> when it was apple's thing, or when it got added to html5? |
| 20:22 | <maikmerten> | ISO doesn't guarantee quality, nor does it imply that everybody can implement it |
| 20:22 | <Hixie> | Philip`: most of the important baseline patents may expire within a couple of years |
| 20:22 | <maikmerten> | however, there are policies in many organizations calling for ISO standards, so that's why it definately is a "good thing" to use one |
| 20:23 | <Philip`> | Hixie: Unfortunately people can still be sued over a single barely-important patent in an optional feature that everyone happens to rely on |
| 20:23 | <Hixie> | maikmerten: people will always be suspicious of vendor-controlled "standards" |
| 20:23 | <maikmerten> | too bad the ISO video coding standards fall short somewhere else |
| 20:23 | <hsivonen> | (work hat off): I'd be interested in pointers to criteria for evaluating standards for goodness in a way that doesn't involve checking for organizational logos |
| 20:24 | <Hixie> | Philip`: yeah, the idea would be to use baseline only |
| 20:24 | <Philip`> | hsivonen: You could ask some guys on IRC what they think of it |
| 20:25 | <hsivonen> | Philip`: so far the best criteria I have seen are Sam's from http://www.intertwingly.net/blog/2007/01/25/Pro-Choice |
| 20:25 | <hsivonen> | "A standard is one that has multiple, inter-operable, independent implementations. An open standard, at least in the software world, is one where at least one of those implementations is open source." |
| 20:25 | <Hixie> | that seems like a dodgy definition |
| 20:26 | <Hixie> | but ok |
| 20:26 | <hsivonen> | Philip`: (I think I should write something that can be given to politicians. and for that use case, telling them to ask on IRC isn't good) |
| 20:26 | <maikmerten> | Hixie: well, I just don't see how being public domain qualifies as "vendor-controlled" |
| 20:26 | <maikmerten> | however, it may be a case of "not enough control" |
| 20:27 | <Hixie> | maikmerten: who decides what the spec says? |
| 20:27 | <hsivonen> | Hixie: I think the definition should also require that you can write the next interoperable independent impl. by following the spec |
| 20:27 | <Hixie> | maikmerten: public domain means that anyone can copy it, not that the official version is under anyone's control |
| 20:27 | <Hixie> | hsivonen: indeed |
| 20:27 | <maikmerten> | Hixie: the official Theora spec: Xiph.org (which is a 403 organization) |
| 20:28 | <Hixie> | 403 Forbidden? :-) |
| 20:28 | <hsivonen> | Forbidden? :-) |
| 20:28 | <hendry> | heh |
| 20:28 | <Hixie> | maikmerten: and who changes it? |
| 20:28 | <Philip`> | Hixie: Sounds like that still wouldn't be technically competitive with whatever the state-of-the-art would be, and technical competitiveness is still important for video (since it's low quality and high bandwidth and therefore worth optimising), which is kind of a pain in terms of convincing people it's worth using |
| 20:28 | <Hixie> | maikmerten: who decides what an error is, etc? |
| 20:28 | <Philip`> | s/that/H.264 baseline/ |
| 20:28 | <maikmerten> | err... 403... dammit... I meant 501(c)(3) |
| 20:29 | <Hixie> | Philip`: yes, i don't think you'll be able to have a patent unencumbered or royalty-free state of the art video codec before international patent reform. |
| 20:29 | <maikmerten> | Hixie: "the xiph.org community" - which, however, is as open as it can get |
| 20:30 | <maikmerten> | Hixie: however, the point you may be pointing at is "so, how transparent is this?" |
| 20:30 | <maikmerten> | and sure, that's where it may look not as nice as ISO, no doubt about that |
| 20:32 | <maikmerten> | and, no doubt about that: If ISO would have a standard with fitting licensing we wouldn't have all these problems |
| 20:32 | <Philip`> | Before such reform, hopefully browsers will start plugging into their platform's media functionality so I can watch high-quality video (in any browser, in any practical OS, with only a trivial cost added to the purchase of the computer for codec licensing) and the browser vendors won't have to worry about the patents |
| 20:32 | <maikmerten> | (and Theora wouldn't even exist) |
| 20:32 | <Hixie> | maikmerten: so what happens if microsoft comes along and asks for something to change in the spec? |
| 20:32 | <maikmerten> | but apparently there *is* no international standards body really intersted in royality free standards |
| 20:32 | <Hixie> | Philip`: yeah that seems to be happening |
| 20:33 | <Philip`> | (Sadly my version of Vista doesn't even include DVD codecs, so I guess it'll be a while before H.264 is available as standard) |
| 20:33 | <maikmerten> | Hixie: well, what if Microsoft wants a nicely crafted standard to become an ISO standard? ;-) |
| 20:34 | <Philip`> | (but that's okay because people can just write a Flash implementation of <video>) |
| 20:34 | <Hixie> | maikmerten: believe me, i'm as upset as anyone over the debacle that was ooxml |
| 20:34 | <maikmerten> | Hixie: and believe me, if there were a free ISO standard I'd be all for it |
| 20:34 | <maikmerten> | Hixie: I can see the benefits of ISO standards |
| 20:35 | <maikmerten> | more transparency |
| 20:35 | <Hixie> | i dunno about transparency |
| 20:35 | <Hixie> | but yeah |
| 20:35 | <maikmerten> | less dependency on single entities |
| 20:35 | <Hixie> | i'd love to use theora, and indeed the spec used to require it |
| 20:35 | <maikmerten> | well, at least for members, I guess |
| 20:35 | <Hixie> | it's just not a practical option |
| 20:35 | <Hixie> | big vendors won't implement it |
| 20:35 | <Hixie> | at the end of the day it doesn't matter what their reason |
| 20:35 | <Hixie> | is |
| 20:36 | <Hixie> | if the big vendors don't implement it, we don't get interop, and we've failed |
| 20:36 | <maikmerten> | that's very true, I guess |
| 20:36 | <maikmerten> | well, too bad nobody actually discloses anything |
| 20:36 | <Hixie> | as i keep telling people, we spec writers are only powerful so long as we tell the vendors to do what they want to do anyway :-) |
| 20:36 | <Hixie> | yeah |
| 20:36 | <Hixie> | the video thing is a pain |
| 20:37 | <Hixie> | but there is progress being made, albeit very slowly |
| 20:37 | <Hixie> | very, very slowly |
| 20:37 | <maikmerten> | if somebody actually *knew* flaws in the Theora spec it would help to communicate this |
| 20:37 | <Philip`> | Hixie: That's not necessarily failure - the big vendor could become a small vendor, because all their users leave for browsers that do implement the spec, and then it'd be a success |
| 20:37 | <maikmerten> | so the spec can be revised and adoption of the flawed iteration can be discouraged |
| 20:38 | <Hixie> | Philip`: also, god could exist |
| 20:38 | <maikmerten> | all what is visible is information from "video experts" leaking, which could very well just be staged (nah, that doesn't mean you Hixie) |
| 20:38 | <Hixie> | Philip`: i'm not praying for either :-) |
| 20:39 | <Hixie> | maikmerten: yeah, i wish people were more forthcoming |
| 20:39 | <Hixie> | maikmerten: but like i said, there are legal reasons why people can't say what they know |
| 20:39 | <hsivonen> | btw, the Finnish public broadcaster is switching from WMV9 to H.264 now that Flash does H.264 |
| 20:39 | <maikmerten> | Hixie: yeah, and it's sad the whole system is that broken |
| 20:39 | <Hixie> | maikmerten: i've been in meetings about stuff like this where everyone knows something but everyone is under different NDAs about it and so everyone pretends to everyone else not to know it |
| 20:40 | <maikmerten> | Hixie: anyway, thanks alot for taking the time and elaborating |
| 20:40 | <Hixie> | maikmerten: and despite the fact that each person in the room has privately told me that they know of it, they can't speak of it |
| 20:40 | <Hixie> | maikmerten: bugs the hell out of me |
| 20:40 | <Hixie> | maikmerten: np |
| 20:40 | <maikmerten> | I see |
| 20:40 | <maikmerten> | scary |
| 20:40 | <Hixie> | yeah |
| 20:40 | <Lachy> | JohnResig, yt? |
| 20:40 | <Philip`> | Hixie: If HTML5 drags on for as long as you say it will, there's no chance that the current big vendors will still be the big vendors by that time, and probably not a great chance that they'll all even exist :-) |
| 20:41 | <Hixie> | Philip`: i don't think microsoft, nokia, apple, and other such companies are likely to quit being relevant in the next 20 years |
| 20:43 | <Lachy> | JohnResig, re your selectors api feedback, I'm not convinced it's a good idea to change the spec so significantly as you suggest. I designed it the way it is for a reason. |
| 20:43 | <Philip`> | Hixie: It's not about being generally relevant, it's about being relevant in the context of developing web browsers, which is a much more fragile thing since it won't survive when an organisation tries to significantly reposition itself in the market |
| 20:44 | <Lachy> | JohnResig, however, I'm am convinced we need to define :scope sooner rather than later, which would solve all use cases you presented without sacrificing any features |
| 20:44 | <Hixie> | Philip`: the only way e.g. microsoft is getting out of the browser game is if they beat us with one of their own proprietary platforms |
| 20:44 | <Hixie> | Philip`: in which case, it doesn't matter what we say |
| 20:46 | <Philip`> | Hixie: They got out of the browser game after IE6, and that wasn't after having beaten the web platform |
| 20:46 | <Hixie> | they didn't get out of the browser game, they had the entire market |
| 20:47 | <Hixie> | indeed, arguably, it _was_ after having beaten the web platform |
| 20:47 | <Hixie> | though not in the sense i meant earlier |
| 20:47 | <Philip`> | Stopping all development doesn't sound particularly like being in the game |
| 20:47 | <Hixie> | it's a funny way to play the game |
| 20:47 | <Hixie> | it worked for them for several years |
| 20:49 | <Philip`> | If you're playing a game and then press the Pause key for several years, are you still playing it all that time? |
| 20:49 | <Philip`> | If so, I've played far too many games while I've been asleep in bed :-( |
| 20:49 | <jgraham_> | Philip`: They were still in the game, they just thought they didn't need to play anymore. I guess they regret that now |
| 20:52 | <Philip`> | Anyway, I still really very much hope we won't still be using IE and Firefox and Safari and Opera in 2028 :-) |
| 20:54 | <Hixie> | i see no evidence to suggest we'll be using anything else |
| 20:55 | <Philip`> | You could look at what web browsers we were using in 1988, and assume (in the absence of evidence otherwise) that things will change just as significantly in the future |
| 20:55 | <jgraham_> | Philip`: Not a fair comparison. But it's reasonable to say we're not using much of the Netscape 1 codebase anymore |
| 20:55 | <Hixie> | IE, Netscape, and Opera? |
| 20:55 | <Philip`> | jgraham_: Why is that unfair? |
| 20:55 | <Hixie> | there's one new browser |
| 20:56 | gsnedders | tries to remember 1988 |
| 20:56 | gsnedders | fails |
| 20:56 | <Hixie> | oh, 1988 |
| 20:56 | <Hixie> | not 1998 |
| 20:56 | <Philip`> | Comparing to 1998 would be unfair :-) |
| 20:56 | <Philip`> | and would destroy my argument |
| 20:56 | <jgraham_> | 1988 was before the web existed, so the legacy didn't exist at all |
| 20:56 | <Hixie> | the first few years of any technology is radical |
| 20:56 | <Hixie> | we're in a much more mature stage now |
| 20:56 | <Hixie> | compare word processors now to 20 years ago |
| 20:56 | <Hixie> | there's not much difference |
| 20:56 | <Hixie> | word perfect got replaced by pages |
| 20:57 | <Hixie> | that's about it |
| 20:57 | <Philip`> | Compare floppy disks now to 20 years ago |
| 20:57 | <Lachy> | Hixie, sure there is. MS Word is a lot more bloated now. |
| 20:57 | <Hixie> | still big companies, etc |
| 20:57 | <Hixie> | Lachy: :-) |
| 20:57 | <Hixie> | ok for canvas text my proposal is: |
| 20:57 | <Philip`> | Floppies have gone past the mature stage and died out, despite the legacy of billions of disks with software and data on them |
| 20:57 | <Philip`> | (where "billions" is an utterly made up number) |
| 20:57 | <hsivonen> | including data in WriteNow files |
| 20:57 | <Hixie> | drawHString(x, y, maxWidth, textAlign, s); and drawHString(x, y, maxHeight, textAlign, s); |
| 20:57 | <Philip`> | (but it's a reasonable extrapolation from how many I have at home) |
| 20:58 | <Hixie> | er |
| 20:58 | <Hixie> | drawVString(...) for the second one |
| 20:58 | jgraham_ | chooses COBOL and mainframes as his legacy technologies |
| 20:58 | <jgraham_> | (that still exist as they did 20 years ago) |
| 20:58 | <Hixie> | Philip`: we'll see :-) |
| 20:58 | <Hixie> | Philip`: i don't think designing html5 with the assumption that the current players will be replaced would work, though (c.f. xhtml2) |
| 20:59 | <Hixie> | comment on drawHString() and drawVString() while i go have lunch. :-D |
| 20:59 | <Hixie> | bbl |
| 21:00 | <Lachy> | what's the difference between them? drawVString for vertical stings where the letters are stacked on top of each other, and not just rotated 90 deg? |
| 21:01 | hsivonen | finds http://www.legacyj.com/lgcyj_perc1.html |
| 21:01 | <Philip`> | Hixie: They look complex and hard to use :-p |
| 21:01 | <Philip`> | compared to e.g. translate(x,y);drawString(s) |
| 21:02 | <Philip`> | Anyway, it'd be useful to know what use cases they're meant to be handling |
| 21:05 | <Lachy> | Philip`, labelling graphs would be a typical use case for text, which is currently achieved by positioning elements over the canvas |
| 21:05 | <Philip`> | and the interesting bits are in fonts and styles and sizes and measuring |
| 21:06 | <Philip`> | which are currently unspecified and therefore hard to comment on :-) |
| 21:06 | <Lachy> | the problem it solves is that it makes the text actually part of the image, and so it can be exported and saved without losing the text labels |
| 21:07 | <Philip`> | Lachy: Simplicity of implementation sounds like a more relevant concern in that case - I've heard people complaining that they need complicated hacks to do text, but I don't think I've ever heard them complaining that it makes exporting images hard |
| 21:08 | <Lachy> | complexity is just another problem it solves |
| 21:09 | <Lachy> | (assuming the solution we creation isn't too complex) |
| 21:09 | <Lachy> | *create |
| 21:12 | <Philip`> | My semi-practical use case is displaying characters' names above their heads in an FPS game, with the name being obscured by closer walls (hence it's not possible to overlay an HTML element, except with horribly evil clipping hacks) |
| 21:13 | <Philip`> | What are the use cases for writing large unformatted chunks of wrapped text? |
| 21:17 | <Philip`> | (Oh, I suppose I also want text for an FPS game's HUD, mostly just with big numbers for the health and ammo counts in a nice font) |
| 21:44 | <JohnResig> | Lachy: you should probably say as much on the mailing list, so we can discuss it there |
| 21:57 | <htmlfivedotnet> | Hixie: What about: drawString(s, x, y, (align='horizontal'), (maxSize='null'), (textAlign='left') ) - if that even makes sense... |
| 22:20 | <Hixie> | lachy: drawVString() would be for vertical text (e.g. some CJK) |
| 22:21 | <Hixie> | htmlfivedotnet: yeah, i considered that, but i didn't want to have the author have to put in a long keyword for the direction |
| 22:22 | <Hixie> | also you're not going to be switching between them, really |
| 22:22 | <Hixie> | Philip`: the x and y arguments are in line with how the rest of the API takes coordinates |
| 22:22 | <Hixie> | Philip`: you don't translate then rect(width, height), e.g. |
| 22:23 | <Philip`> | Hixie: Ah, yes, that's a confusing part of the mozDrawText API |
| 22:23 | <Philip`> | so I'll modify my proposal to drawString(s, x, y) :-) |
| 22:24 | <htmlfivedotnet> | my thought was just that certain properties would be used more frequently, and having defaults would keep it cleaner unless it needed to be more complex. |
| 22:24 | <Philip`> | (plus a couple of properties that I'm not mentioning now) |
| 22:24 | <Hixie> | well, there are three things we want to avoid |
| 22:24 | <Hixie> | one is lack of support for vertical text :-) |
| 22:24 | <htmlfivedotnet> | and i personally hate having 3 functions that do essesntially the same thing... ala PHP |
| 22:24 | <Philip`> | One is complexity, given that graph axis labelling is about the only use case |
| 22:24 | <Hixie> | another is text being affected by different font metrics and being unviewable |
| 22:25 | <Hixie> | and the other is making sure graph axes can be lined up correctly (so we need left/right/center alignment) |
| 22:25 | <Hixie> | i don't think drawHString(x, y, width, 'left', 'text') is really that complex |
| 22:26 | <Philip`> | For graphs you need top/center/bottom too (measured at 'sensible' points like ascent height / median / baseline, not on the bounding box) |
| 22:26 | <Hixie> | hmm |
| 22:26 | <Hixie> | yes |
| 22:26 | <Hixie> | good point |
| 22:27 | <Philip`> | I'd like to see a labelled graph using vertical CJK... |
| 22:27 | <Hixie> | no idea how to search for that |
| 22:28 | <Philip`> | Look at lots of graphs. If you don't find any vertical CJK ones, it's not a "95% of use cases" situation and isn't worth the complexity :-) |
| 22:29 | <Hixie> | i have no idea how to avoid sample bias |
| 22:29 | <Hixie> | for this case |
| 22:29 | <Philip`> | (I'd guess they'd use LTR decimal numbers anyway) |
| 22:33 | <Philip`> | How do you suggest setting font family/style/weight/size? |
| 22:33 | <htmlfivedotnet> | http://www.honda.co.jp/PARTNER/SP/environment/image/bargraph_image.gif |
| 22:33 | <Hixie> | Philip`: .fontStyle = '' |
| 22:33 | <Hixie> | htmlfivedotnet: ooo |
| 22:33 | <htmlfivedotnet> | lol |
| 22:33 | <Philip`> | What happens when text is wider than 'width'? |
| 22:34 | <Hixie> | Philip`: ua tries condensing the font, first using actual condensed fonts, then using horizontal scaling, and if a reasonable amount of that doesn't help either, shrinks the font size |
| 22:35 | <Philip`> | Can I set width == Infinity when I don't want the browser to mess with things? |
| 22:35 | <Hixie> | why would you ever want it to go off the side of the viewport |
| 22:35 | <Hixie> | ? |
| 22:36 | <Hixie> | http://www.osaka-gaidai.ac.jp/houzinnsosiki_kakudai.html has vertical text in a chart |
| 22:36 | <Hixie> | http://www.lac.co.jp/img/siodome_j.gif too, i think |
| 22:37 | <Hixie> | the rightmost blue block (train stop?) looks like it has vertical glyphs |
| 22:37 | <Hixie> | though they are rotated to the point of almost being horizontal :-/ |
| 22:37 | <Philip`> | Hixie: I'd want that when writing Google Maps in <canvas>, where text is off the side of the screen and the user can scroll or zoom to read it |
| 22:37 | <svl> | /join #ubuntu |
| 22:37 | <svl> | urgh |
| 22:38 | <Hixie> | Philip`: even with google maps i'd wager we always want the text to be within a sane bounding box |
| 22:39 | <Philip`> | Hixie: That siodome_j.gif would need both max-width and max-height, else the text might end up overlapping its containing box in an ugly way |
| 22:39 | <htmlfivedotnet> | Hixie: so the 'width' property is a maximum, not an absolute? |
| 22:39 | <Dashiva> | It's a suggestion |
| 22:40 | <Philip`> | Hixie: Google Maps lets me go hundreds of thousands of kilometres sideways, and the text always stays static in relation to the background |
| 22:40 | <Hixie> | Philip`: well you set the font size, so you know the likely width (given that they're square and there's no line wrapping) |
| 22:40 | <Hixie> | htmlfivedotnet: max width, right |
| 22:40 | <Hixie> | Philip`: so? |
| 22:42 | <Philip`> | Hixie: Why is it sufficient to know the likely width given the font size in that case, whereas it's not sufficient in the normal drawHString case for authors to know the likely width and choose sizes/positions appropriately themselves (hence requiring the max-width parameter)? |
| 22:43 | <htmlfivedotnet> | Phlip: I think he's saying you would still want to set the maxwidth to say.... 100px. if it ends up off the field of view, fine, but if there is a town like "html5landvilleshiretownsylvania", it would take up half the screen if it wasn't made smaller. |
| 22:44 | <Hixie> | Philip`: i'm arguing that it's always normal to have a reasonable idea of your glyph extents in the block progression direction but not reasonable to guarentee that you'll fit in the inline progression direction. |
| 22:45 | <Hixie> | because given a font-size, your font metrics in the block progression direction are usually around the same as the font size but in the inline progression direction can vary considerably, and will vary in a way that is compounded with every glyph. |
| 22:45 | <Hixie> | (your typical iii vs www case for non-monospace text) |
| 22:46 | <Philip`> | Okay, sounds reasonable |
| 22:47 | <Hixie> | i wonder how to handle your case of wanting to line up text relative to the ascent top rather than the baseline |
| 22:50 | <Philip`> | Would it be feasible to use @font-face { src: ... } to define a font that could be used in the canvas? |
| 22:51 | <Hixie> | i expect we could define that to work, yes |
| 22:51 | <Hixie> | in fact i was planning on hooking straight into the css render model for this |
| 22:52 | <Philip`> | Presumably a problem is that it has to wait until after the font has been downloaded |
| 22:53 | <Hixie> | font download presumably will be defined to delay onload |
| 22:53 | <Hixie> | hmm |
| 22:58 | <Philip`> | (By the way, I'd probably want graph labels to be aligned to what http://en.wikipedia.org/wiki/Image:Typography_Line_Terms.svg calls 'cap height' instead of 'ascender height', since fancy cursive fonts shouldn't get placed so far down that there's space for all their large ascenders, since that'd look ugly) |
| 23:00 | <Hixie> | there's another problem, similar to the issue you raised about needing to align to the top, which is that to support Devanagari, Gurmukhi, Bengali, and other hanging indic scripts that want to render multiple font sizes we need to be able to tell the drawHText() method to use a hanging baseline instead of the alphabetic baseline |
| 23:00 | <Hixie> | yes, i meant the top of the em box actually |
| 23:00 | <Hixie> | not the top ascent height |
| 23:00 | <Hixie> | my bad |
| 23:01 | <Dashiva> | We need a typography5 to make line-height and other font stuff make sense to regular people... |
| 23:01 | <Philip`> | Reinventing CSS sounds like a bad idea |
| 23:02 | <Dashiva> | Wouldn't need to. Just add enough syntactic sugar around it so it's possible to use :) |
| 23:02 | <Philip`> | It seems easier and more powerful to have a drawElement() method (which marks the canvas as origin-unclean if it draws anything dodgy likes images or iframes or visited-vs-unvisited links) |
| 23:02 | <Philip`> | and then people don't have to learn lots of new API |
| 23:03 | <Hixie> | easier? no. |
| 23:03 | <Philip`> | (learn/define/implement) |
| 23:03 | <Hixie> | there are so many issues with that that i don't even want to go there. |
| 23:05 | Philip` | wonders what some of the issues are |
| 23:07 | <Hixie> | plugins, rendering off-screen, defining what it means to render an element at all (e.g. what about backgrounds of elements that contain it), what happens with floats near the element in the document, what happens if the element isn't in a document, rendering elements that have 'display' of none, table-column, table-row, etc, compact, run-in, etc, working out where the top-left of an element is, etc etc etc |
| 23:07 | <Hixie> | not to mention that it relies on css being implemented |
| 23:10 | <Philip`> | Define it as deep-cloning the element, moving it into an empty new HTML document, then rendering that document in a viewport of size w*h, then copying the output back. Easy :-) |
| 23:10 | <Philip`> | (and you can probably do that already in Mozilla, with iframes and drawWindow) |
| 23:11 | <Philip`> | ((except for drawWindow not being web-accessible)) |
| 23:11 | <Hixie> | uh huh |
| 23:11 | <Philip`> | Reliance on CSS seems like only a theoretical concern, given where this is going to be implemented |
| 23:12 | <Hixie> | yeah, the css issue is a real issue but one we could ignore |
| 23:12 | <Philip`> | Well, maybe there's some minor details I omitted :-p |
| 23:20 | <Hixie> | anyone here speak japanese, chinese, or korean, even just a little bit? |
| 23:21 | <Hixie> | i want to pick a CJK character for an example without offending native speakers... |
| 23:22 | <Hixie> | wikipedia to the rescue! |
| 23:36 | Philip` | hopes Hixie accidentally picks a piece of rude CJK wiki-vandalism |
| 23:44 | <myakura> | Hixie: i do speak japanese so might help you |
| 23:45 | <Dashiva> | Hixie: Just take the 'symbol' symbol :) |
| 23:50 | <Hixie> | myakura: i ended up picking the 私 character |
| 23:50 | <Hixie> | is that ok? |
| 23:52 | <myakura> | yeah, that means "I" the first person in japanese |
| 23:53 | <Hixie> | right |
| 23:53 | <Hixie> | is there a good glyph i could use that very clearly is lined up on the ideographic baseline? |
| 23:54 | <Dashiva> | 国 maybe? |
| 23:55 | <myakura> | yeah, that's a nice pick |
| 23:56 | <Hixie> | ooh that works |
| 23:56 | <Hixie> | what does it mean? |
| 23:57 | <Hixie> | actually that one seems has a line on the alphabetic baseline, so it is misleading |
| 23:58 | <Hixie> | or maybe that's just the font i'm using |
| 23:58 | <Dashiva> | Where is the ideographic baseline? |
| 23:58 | <Dashiva> | Between the bottom of the king and the bottom of the square? |
| 23:59 | <Hixie> | (king?) it's below the alphabetic baseline and above the bottom of the em square |
| 23:59 | <Hixie> | just below the alphabetic baseline |
