| 00:00 | <AryehGregor> | MediaWiki has a pretty nice one. |
| 00:00 | <TabAtkins> | Of course, how can you *possibly* spend any significant amount of time hand-constructing queries? |
| 00:00 | <TabAtkins> | It's horrible. |
| 00:02 | <TabAtkins> | I've been thinking of switching to a chaining-based api just so I can implement joins without gobs of horrible nesting. |
| 00:05 | <Lachy> | in microdata, can someone clarify for me how I'm supposed to use the "fn" and "n" properties in the vcard vocabulary? |
| 00:06 | <Lachy> | I don't get why both "fn" and "n" exist, or why "fn" must be present if "n" is present |
| 00:08 | <TabAtkins> | I think it's legacy constraints from the original vcard format. |
| 00:08 | <TabAtkins> | The microformats wiki page should explain their use pretty well. |
| 00:08 | <TabAtkins> | It was sensical enough for me to use it on my pages, at least. |
| 00:11 | <Lachy> | But if I use <span itemprop="fn n">, then "n" actually needs to be an item, so that would become <span itemscope itemprop="fn n">, but "fn" is supposed to be a string, not an item, so then I would have to split them into two separate elements. |
| 00:11 | <Lachy> | or otherwise rely on the implied "n" optimisation |
| 00:13 | <TabAtkins> | Hrm. Yeah, I think you can't use them together in Microdata, and have to either put both of them in or use the implied "n" optimizations. |
| 00:14 | <Hixie> | i'm baffled by the number of people who don't want the spec to encourage user agents to try to make things better for AT users in the face of authoring mistakes |
| 00:14 | <Hixie> | why do people want to pubish users for authoring mistakes? |
| 00:15 | <Hixie> | it's like the whole draconican parsing thing all over again |
| 00:16 | <othermaciej> | Hixie: I think people are either misreading the spec, or buying into a subtle argument about giving authors incorrect expectations |
| 00:16 | <AryehGregor> | Hixie, I think they're mostly asking to rephrase to be vaguer at this point, aren't they? |
| 00:16 | <Lachy> | I don't think people are opposed to ATs providing a better user experience. They seem to be opposed to the spec setting seemingly unrealistic requirements and somehow giving authors unrealistic expectaions and choosing not to give alternative text |
| 00:17 | <TabAtkins> | +1 to Lachy. |
| 00:18 | <Lachy> | and since the purpose of the statement in the spec is to give implementations permission to use alternative techniques, it seems reasonable to say so without indicating what those techniques may be, especially when it could be misconstrued as referring to futuristic technologies |
| 00:18 | <TabAtkins> | That is, I certainly don't want to punish users because authors were bad. It totally makes sense that image-reading heuristics, when they exist and are practical, should be used in the absence of @alt. |
| 00:19 | <Hixie> | OCR is not a futuristic technology |
| 00:19 | <othermaciej> | I think it would probably fine to say that if alt is missing, UAs can present any other information they are able to get in lieu of a text alternative |
| 00:19 | <Lachy> | I don't think it's clear to everyone that "image analysis heuristics" refers to things like OCR. |
| 00:19 | <othermaciej> | and if specific examples are listed at all, they should be clearly realistic examples like using the filename or performing OCR |
| 00:20 | <Lachy> | people seem to be thinking it refers to some kind of futuristic AI, that can look at a picture and determine what it is and what it means in context |
| 00:20 | <Hixie> | there is shipping technology today that does painting recognition, OCR, landmark recognition, etc, on arbitrary images |
| 00:20 | <Hixie> | which would really help users who can't see images |
| 00:20 | <TabAtkins> | "User agents may also apply image analysis heuristics…" does seem to imply that such heuristics exist, when outside of OCR they don't reliably. |
| 00:21 | <Lachy> | yes, but those things, like Google Goggles, require large collections of sample images with which to compare the subject image with |
| 00:21 | <othermaciej> | there are in fact heuristics that can recognize all kinds of images other than images of text |
| 00:21 | <TabAtkins> | Outside of images of text, though, you run into the intent problem. A description of the image may not be valid alt text. |
| 00:21 | <Hixie> | sure |
| 00:21 | <othermaciej> | mostly either research projects, or somewhat experimental, and often requiring a huge corpus |
| 00:21 | <Hixie> | but it's better than nothing! |
| 00:22 | <othermaciej> | it's not even that clear to me how I'd use the shipping Google Goggles to build an accessibility feature for a UA - uploading every image that lacks alt text seems like a bad idea for both bandwidth and privacy reasons |
| 00:23 | <Lachy> | Hixie, I just think you should try to find a way that makes the intent of the statement clear, without making people think the spec is setting unrealistic expectations |
| 00:23 | <othermaciej> | that being said, it seems like a much more general statement would both be less objectionable, and more broadly applicable |
| 00:23 | <Hixie> | well i'd be happy to make the text even vaguer so long as we still explicitly allow such behaviour |
| 00:24 | <Hixie> | (no bug was ever filed for this as far as i know, btw) |
| 00:25 | <Lachy> | personally, I thought image analysis heuristics was a rather general statement already, and I don't agree with most of the rationale that was given in the change proposal |
| 00:25 | <Hixie> | yeah i'm not exactly sure how to make it vaguer |
| 00:25 | <Lachy> | maybe use less jargon |
| 00:28 | <Lachy> | Change it to "User agents may also utilise any other available techniques or technologies to help the user make sense of the image when the user is unable to make direct use of the image, ..." |
| 00:29 | <Hixie> | well it's not _any_ other |
| 00:29 | <Hixie> | e.g. iirc we explicitly discourage use of the filename |
| 00:29 | <Hixie> | since that has been shown to hurt more than help |
| 00:30 | <Lachy> | that's an implementation decision though. There's no reason to have the spec explicitly disallow it |
| 00:31 | <othermaciej> | I think it might also help to say "get information about the image" instead of "make sense of the image" |
| 00:31 | <othermaciej> | since the latter seems to be what makes people think the technology described is science-fictional |
| 00:31 | <Lachy> | also, the file name is not always useless. It is when it's a bunch of random letters or numbers, but if the AT recognises the file name as being readable words (e.g. by checking a dictionary), then why not use the file name as a last resort? |
| 00:32 | <othermaciej> | yeah, many filenames are bad, but not all - the best thing would be for AT to use heuristics to determine if the file name is human-understandable |
| 00:32 | <Hixie> | i could live with that |
| 00:34 | <Lachy> | Here the suggested text again with some changes: "User agents may also utilise any other available techniques or technologies to help the user obtain information about the image when the user is unable to make direct use of the image, ..." |
| 00:35 | <Hixie> | sounds wishy washy |
| 00:35 | <Lachy> | yep |
| 00:35 | <Hixie> | we should just come out and say what we mean |
| 00:35 | <othermaciej> | if you can find text that people find satisfactory then I'd be happy to try to put this one through as an amicable resolution |
| 00:39 | <Hixie> | the amount of time i spend each day just dealing with new e-mail is getting ridiculous |
| 00:41 | <othermaciej> | Hixie: Sam and I are both trying hard to curtail threads that don't seem to be going anywhere, and to kick process debates off the list |
| 00:42 | <othermaciej> | (as of now, anyway) |
| 00:42 | <Lachy> | I was quite pleased when I saw both you and sam put a stop to process threads today :-) |
| 00:43 | <Hixie> | othermaciej: sadly public-html ain't hte half of it these days |
| 00:43 | <othermaciej> | Hixie: well, that's the only part I can really help with :-) |
| 00:44 | <Lachy> | yeah, whatwg has been difficult to keep up with too sometimes |
| 00:44 | <Lachy> | I'm still behind on that by about 1500 messages |
| 00:49 | <Hixie> | my problem is it's lots of little amounts of e-mail on lots of lists |
| 00:50 | <Lachy> | you have to learn to ignore more lists. |
| 00:50 | <Lachy> | Like how I ignore pretty much most internal mailing lists within opera, and only skim those that I do read |
| 00:51 | <Lachy> | I figure if it's important information, I'll hear about it some other way |
| 00:52 | <othermaciej> | I have a pretty small set of lists I read constantly, a somewhat larger set of daily reading, a few I read about weekly, and then a lot that I only read occasionally when I have spare time |
| 00:54 | <Hixie> | Lachy: none of this is internal google mail, which is a whole other mailbox with even more mail... |
| 00:55 | <Hixie> | TabAtkins: re the thread with the guy who wants to do concatenation with microdata |
| 00:55 | <Hixie> | TabAtkins: it's a bad idea for us to make <div itemscope itemtype="http://example.com/"><span itemprop="a/b"/></div> mean the same as <div itemscope itemtype="http://example.com/a/"><span itemprop="b"/></div> |
| 00:56 | <Hixie> | which is why microdata goes to such lengths to make sure that can't happen |
| 00:56 | <Hixie> | he should just use owl:equivalentProperty if he's using RDF, the same way the work vocabulary does |
| 01:04 | <Lachy> | does such concatenation work in RDFa? e.g. is <span xmlns:dc="http://purl.org/dc/terms/"; property="dc:title"> the same as <span xmlns:dc="http://purl.org/dc/"; property="dc:terms/title">? |
| 01:10 | <Philip`> | Lachy: That's just CURIEs, not anything specific to RDFa |
| 01:11 | <Philip`> | RDFa just gets full URIs from its CURIE processor, it doesn't care how they're split up |
| 01:11 | <Philip`> | (in theory) |
| 01:11 | <Lachy> | so, then both of those would be semantically identical for RDF? |
| 01:12 | <Hixie> | yes |
| 01:12 | <Hixie> | that's one of the biggest problems with RDFa, imho |
| 01:21 | <Hixie> | 5:30pm and I'm done with mail. |
| 01:21 | <Hixie> | sheesh. |
| 02:09 | <Hixie> | i think i might settle on srcdoc="" |
| 02:09 | <Hixie> | names are hard. |
| 03:42 | <paul_irish> | what's the name of this feature? http://dev.w3.org/html5/webdatabase/ |
| 03:42 | <paul_irish> | like if you were saying X browser had _____ support. |
| 03:42 | <paul_irish> | "web database" ... "opendatabase" .. "sqlstorage" ? |
| 03:44 | <Hixie> | Web SQL Database |
| 03:45 | <paul_irish> | had a feeling you'd give me the h1 of the page.... :) thx hix |
| 03:45 | <paul_irish> | ie |
| 04:05 | <Hixie> | hsivonen: i assume you want <iframe srcdoc=""> to be async? |
| 04:06 | <Hixie> | i have some notes from the chrome team that say they want it to be sync |
| 04:06 | <Hixie> | i wonder if they still believe that |
| 04:11 | othermaciej | suspects the Chrome team sometimes overstates the case on what things need to be async |
| 04:11 | <othermaciej> | but I won't have much basis to question until we have process separation working directly in the WebKit tree |
| 04:58 | <Hixie> | <iframe src="a" srcdoc="b"> |
| 04:58 | <Hixie> | support the srcdoc attribute is removed |
| 04:58 | <Hixie> | should the UA navigate to "a"? |
| 05:01 | <Hixie> | i'll go with "no" |
| 05:07 | <Hixie> | i wonder what URL to use for these docs |
| 05:07 | <Hixie> | about:blank maybe |
| 05:07 | <Hixie> | or about:srcdoc |
| 05:43 | <Hixie> | ok srcdoc="" first draft is in |
| 05:43 | <Hixie> | let the flames begin |
| 05:44 | <Hixie> | or continue, i guess, since apparently the complaints start as soon as i mention an idea |
| 05:44 | <Hixie> | actually to be fair it's only a very few people who complain |
| 05:49 | <cardona507> | url? |
| 05:49 | <Hixie> | http://whatwg.org/html5 ? :-) |
| 05:49 | <cardona507> | I just searched current work |
| 05:51 | <cardona507> | hmmm - I still don't see it |
| 05:55 | <Hixie> | odd |
| 05:55 | <Hixie> | should be in the iframe section |
| 05:58 | <cardona507> | ok - I see srcdoc now |
| 06:11 | Hixie | tries to work out exactly what it means for history.back() to be async |
| 06:12 | <Hixie> | i wonder where in the algorithm darin wants it to go async |
| 06:39 | <Hixie> | sweet kittens, this box has IE8 beta on it |
| 07:28 | <hsivonen> | Hixie: I don't have enough data right now to say if I want doc='' to be sync or async |
| 07:28 | <hsivonen> | currently, the HTML5 parser in Gecko has no way of parsing a full document from an UTF-16 string |
| 07:29 | <hsivonen> | it can only parse a full doc (in an async way) from a byte stream or a fragment (in a sync way) from an UTF-16 string |
| 07:30 | <Dashiva> | Does sync load include waiting for external stylesheets/scripts blocking? |
| 07:31 | <hsivonen> | Dashiva: well, if doc='' can load stylesheets, scripts or XBL, making it sync would be bad |
| 07:32 | <hsivonen> | I haven't yet examined the dependencies of doc='', hence not enough data |
| 08:25 | <erlehmann> | hsivonen, i think there may be something wrong with the content model in validator.nu. the figure part looks weird to me http://validator.nu/?doc=http%3A%2F%2Fblog.dieweltistgarnichtso.net%2Fhtml5-cc-plugin-fur-wordpress-version-0-6 |
| 08:30 | <hsivonen> | erlehmann: the figure stuff is waiting for the HTML WG Decision Process to run its course |
| 08:31 | <erlehmann> | hsivonen, no its more like: the description in the validator doesn't match the checked content model. |
| 08:31 | <erlehmann> | at least that is what i assume |
| 08:31 | <hsivonen> | erlehmann: the description comes from the spec |
| 08:32 | <hsivonen> | erlehmann: what's actually checked comes from the schema |
| 08:32 | <hsivonen> | erlehmann: and they are out of sync while waiting for the Decision Process |
| 08:32 | <erlehmann> | i see. excuse me for bothering you. |
| 08:33 | <erlehmann> | and thanks for the explanation. |
| 08:33 | <hsivonen> | the situation sucks and causes bad UI |
| 08:35 | <MikeSmith> | we are at the moment having the first face-to-face meeting of the HTML5 Japanese Interest Group |
| 08:35 | <MikeSmith> | almost 100 people here |
| 08:35 | <erlehmann> | MikeSmith, live stream it using <video> ;) |
| 08:36 | <hsivonen> | MikeSmith: nice |
| 08:37 | <MikeSmith> | we have presenters here from Opera, Mozilla, Microsoft IE team, Google Chrome |
| 08:40 | <JonathanNeal> | All major layout rendering engines. |
| 08:40 | <JonathanNeal> | How are the trident folks? |
| 08:41 | <MikeSmith> | he's speaking about 1 hour or so from now |
| 08:41 | <MikeSmith> | but likely will mostly be speaking about IE8 |
| 08:41 | <virtuelv> | MikeSmith: who from Opera? |
| 08:41 | <MikeSmith> | virtuelv: Daniel Davis |
| 08:41 | <JonathanNeal> | What's this I hear about IE6 support getting extended to 2014, man. |
| 08:42 | <JonathanNeal> | Luckily I heard Cisco is finally gonna upgrade. |
| 08:42 | <MikeSmith> | virtuelv: Tatsuki is here in the audience as well |
| 08:42 | <JonathanNeal> | IE8 is all right, just has some display issues which I hope get patched, but ah hell probably won't. |
| 08:43 | <JonathanNeal> | It sucks when you need to hit a browser like you do a broken stereo, .style.opacity = 0; .style.opacity = 1; just to get the thing to show a change. |
| 08:43 | <JonathanNeal> | I wish they could get a release cycle going like Chrome, Firefox, and Opera have been able to. |
| 08:44 | <Dashiva> | They're getting closer |
| 08:44 | <Dashiva> | The 7-8 cycle was much shorter than 6-7 :) |
| 08:44 | <JonathanNeal> | Good. |
| 08:44 | <JonathanNeal> | Yes, it was. |
| 08:45 | <hsivonen> | I guess the problem is the principle of supporting the browser they shipped bundled with a given Windows release for the support life time of that Windows release |
| 08:45 | <JonathanNeal> | But 6 to 7 was like the longest one of them all |
| 08:46 | <Dashiva> | Couldn't they just do some version number magic? |
| 08:46 | <JonathanNeal> | 97, 99, 2000, 01, 06. |
| 08:46 | <hsivonen> | I imagine supporting Iceweasel for the lifetime of a Debian system release is challege |
| 08:46 | <Dashiva> | Say that 9 is actually 8.1 |
| 08:46 | <Dashiva> | And make 8.1 a mandatory upgrade from 8.0 |
| 08:46 | <JonathanNeal> | Dashiva, I wish they would do stuff like that. |
| 08:47 | <hsivonen> | Dashiva: as I understand it, it's not about numbers but about not changing behavior unless a security or legal (see Eolas) problem can't be fixed without a behavior change |
| 08:47 | <JonathanNeal> | Then they could add some performance perks and bring some actual competition to the other browsers --- plus I wouldn't mind ie supporting some css3 |
| 08:48 | <Dashiva> | Hum |
| 08:48 | <hsivonen> | JonathanNeal: and if a perk breaks the Boeing intranet? |
| 08:48 | <Dashiva> | In that case they'd need to cut down the OS release cycle to something like what Apple does I guess |
| 08:49 | <hsivonen> | to their credit, Microsoft (and Linux distros) communicate about OS release life cycles more clearly than Apple |
| 08:49 | <JonathanNeal> | hsivonen, no point if they'll lose the contract in 10 years to Firefox or Chrome, because they weren't making these advances. |
| 08:49 | <hsivonen> | I don't recall Apple ever communicating anything about OS life cycle |
| 08:49 | <JonathanNeal> | And 10 years is a grossly larger number than I imagine it could be. |
| 08:50 | <hsivonen> | Safari 4 security patches shipped for OS X 10.4 |
| 08:50 | <Hixie> | hsivonen: they did once communicate their OS release cycle at a WWDC talk ahead of Snow Leopard |
| 08:50 | <Hixie> | thought that may have been accidentally |
| 08:50 | <hsivonen> | Hixie: oh. so when are they stopping security patch support for 10.4? |
| 08:50 | <Hixie> | as it was more in passing, in a talk about something else |
| 08:50 | <hsivonen> | what about 10.5? |
| 08:50 | <Hixie> | and had minimal details |
| 08:51 | <Hixie> | but it was something! |
| 08:51 | <Dashiva> | So I'm making this little online game, and I need a TCP port to use. But if I use one of the ports I'm supposed to use, some ISPs flag it as a torrent and start packet shaping |
| 08:51 | <hsivonen> | and 10.3 presumably no longer gets updates, but has Apple ever said so? |
| 08:52 | <hsivonen> | Hixie: so if I want to make security decisions about my dad's Luxo iMac running 10.4, which Apple talks do I need to listen through for tea leaves? |
| 08:53 | <Philip`> | Dashiva: What do you mean by "supposed to"? |
| 08:53 | <JonathanNeal> | I think IE8 is moving in the right direction for the browser. |
| 08:53 | <Dashiva> | I always thought apple's life cycle was "until the next version is out, then you're on your own" |
| 08:53 | <Hixie> | hsivonen: you are preaching to the choir |
| 08:53 | <Dashiva> | Philip`: One of the 49152+ ones or what it is |
| 08:54 | <JonathanNeal> | Just hopefully not too little too late, I don't mind having multiple browsers, especially if they get easier to write cross compatibly for. |
| 08:54 | <hsivonen> | Hixie: about improving accessibility: if Google contributed open source OCR to Orca and NVDA today, and Apple cloned it for Voice Over tomorrow, people would freak out over authors not writing alt text for JAWS users |
| 08:54 | <Dashiva> | And if JAWS added it, they would freak out over not writing alt text for JAWS 4 users |
| 08:55 | <Philip`> | Dashiva: Nobody cares about registration or anything, just pick an arbitrary number that nobody significant is using and it'll be fine :-) |
| 08:55 | <Hixie> | hsivonen: they've already freaked out, see public-html |
| 08:56 | <Dashiva> | Philip`: That's what I'll end up doing, yeah. So much for IANA. |
| 09:05 | <MikeSmith> | Makoto Kato from Mozilla Japan is presenting now |
| 09:05 | <MikeSmith> | his title is Technical Advisor |
| 09:06 | <MikeSmith> | he said he doesn't know what that title is supposed to mean |
| 09:07 | <MikeSmith> | Kato-san has a powerful voice.. had to turn down the volume a bit |
| 09:08 | <MikeSmith> | talking about File API, CSS Gradients, WOFF, WebGL |
| 09:10 | Hixie | peers strangely at the browsers he is testing |
| 09:10 | <Hixie> | some of them don't seem to be letting history.back() affect the history of iframes... |
| 09:10 | <Hixie> | browsers are weird |
| 09:11 | <Hixie> | man i wish someone had specced this crap in the 90s |
| 09:12 | <gsnedders> | Hixie: How about saying something more interesting, that we don't already know? :P |
| 09:12 | <MikeSmith> | it's becoming more and more clear that we just need to scrap it all and start from scratch |
| 09:12 | <MikeSmith> | a clean slate |
| 09:12 | <gsnedders> | Web 2.0! |
| 09:12 | <gsnedders> | Oh, wait. |
| 09:13 | <MikeSmith> | we also need to scrap HTTP, and TCP |
| 09:13 | <workmad3> | we'll get web 3.0 out the door and then move to a versionless web upgrade model? ;) |
| 09:14 | <MikeSmith> | the Web should have been based on Display PostScript |
| 09:14 | <MikeSmith> | or maybe TeX |
| 09:15 | <Hixie> | is TCP that bad? |
| 09:15 | <MikeSmith> | SCTP is better |
| 09:15 | <Hixie> | I thought TCP was actually pretty reasonable, as a protocol |
| 09:15 | <workmad3> | MikeSmith: if it had been, I doubt it would have taken off in the same way |
| 09:15 | <Hixie> | a bit dated at this point, but the spec i thought was ok |
| 09:15 | <MikeSmith> | TCP is seriously pretty good but has significant limitations in high packet-loss networks |
| 09:15 | <workmad3> | MikeSmith: and clean slate is great from an academic and developer perspective, but the biggest driver (business) would resist it like the plague, for fairly good reasons |
| 09:16 | <MikeSmith> | like mobile-phone networks |
| 09:16 | <workmad3> | unless you keep it backwards compatible that is... and then you keep the mess around longer :) |
| 09:17 | <MikeSmith> | not that I know anything about TCP |
| 09:18 | <workmad3> | MikeSmith: you're pretty much spot on there :) |
| 09:19 | <workmad3> | TCP fails when a network that needs speed more than reliability, and performs atrociously over a low reliability network |
| 09:19 | <MikeSmith> | Hey, I got something right |
| 09:19 | <MikeSmith> | I think it's the first time this week |
| 09:19 | MikeSmith | pats himself on the back |
| 09:20 | Philip` | saw some people saying how TCP fails sometimes in data center networks because it has hundreds-of-milliseconds timeouts on packet loss even if the latency is far less than that |
| 09:20 | <workmad3> | but then, that's why networks that need speed implement their own reliability mechanisms (using a different model than TCP) on top of raw UDP packets :) |
| 09:21 | <workmad3> | e.g. game servers |
| 09:21 | <Philip`> | Games sometimes use UDP simply to get around NATs |
| 09:22 | <workmad3> | that said, TCP works, it works pretty well for what it does and is, and I don't think it's going anywhere anytime soon |
| 09:22 | workmad3 | waits to be proven wrong |
| 09:24 | <erlehmann> | MikeSmith, in mobile phone networks with high packet loss, i often get packet duplicates, weird. is it that what you mean ? |
| 09:24 | <workmad3> | erlehmann: that's one of the problems |
| 09:24 | <workmad3> | that'll happen when your ACK packet gets lost or takes too long to get to the server :) |
| 09:24 | <MikeSmith> | I think most mobile phone networks basically don't use TCP over the air |
| 09:25 | <MikeSmith> | they use WTCP or something |
| 09:25 | <erlehmann> | yeah, they use another transport layer and fake packet loss or something ? |
| 09:25 | <MikeSmith> | something like that |
| 09:25 | <Hixie> | MikeSmith: i think there's a huge difference between specs needing improvement, and specs needing to be written from scratch because the specs themselves are inadequate (as in the case of HTML, DOM, etc). |
| 09:28 | <MikeSmith> | Hixie: true, and there's big difference between a technology that was fundamentally sound of the use cases it was intended for and specced out for at time, and one for which the spec was inadequate/ambiguous to the point where implementers ended up implementing it in non-interoperable ways |
| 09:32 | <Hixie> | does this crash safari trunk? http://www.hixie.ch/tests/adhoc/dom/level0/history/sync-vs-async/007.html |
| 09:32 | <Hixie> | (it crashes safari 4 on windows) |
| 09:32 | <Hixie> | MikeSmith: yeah |
| 09:36 | <Hixie> | othermaciej: does this crash safari trunk? http://www.hixie.ch/tests/adhoc/dom/level0/history/sync-vs-async/007.html (it crashes safari 4 windows) |
| 09:36 | <Hixie> | (i can't get webkit to run on this windows machine) |
| 09:37 | <othermaciej> | Hixie: did not crash in a recent Mac debug build |
| 09:37 | <othermaciej> | I do not have Windows readily available |
| 09:38 | <Hixie> | k |
| 09:38 | <othermaciej> | let me check if it crashes Safari 4.0.4 on Mac |
| 09:38 | <othermaciej> | answer: yes |
| 09:39 | <othermaciej> | so this is probably a fixed bug, not a platform-specific bug |
| 09:40 | <Hixie> | yeah i didn't think it was platform specific |
| 09:40 | <Hixie> | thanks |
| 09:40 | <othermaciej> | we have fixed a lot of crashers lately |
| 09:40 | <othermaciej> | including super weird ones from fuzz testing |
| 09:41 | <othermaciej> | yay for fixed bugs |
| 10:01 | <MikeSmith> | Masao Goto from IE team speaking here now |
| 10:02 | <MikeSmith> | hash tag on twitter is #jaig5 |
| 10:05 | <MikeSmith> | his current slide quotes Santayana: Those who cannot remember the past are condemned to repeat it. |
| 10:07 | <MikeSmith> | Mozilla's Kato-san's slides from today: |
| 10:07 | <MikeSmith> | http://www.slideshare.net/djraven/web-technology-features-with-firefox-36-gecko-192-and-later |
| 10:20 | <gsnedders> | Hixie: Calling location.replace("#foo") after the load event has fired, should it add a page to the history? |
| 10:20 | <gsnedders> | (That is Op's current behaviour) |
| 10:20 | <gsnedders> | i.e., treats it the same as location.hash |
| 10:20 | <virtuelv> | and chrome's behavior is to do the same as Opera |
| 10:20 | <othermaciej> | I though location.replace() was not supposed to ever add to the history |
| 10:20 | <virtuelv> | _except_ the first time location.replace is called |
| 10:21 | <Hixie> | gsnedders: no idea, but that's a good thing to add to the thread i just sent an e-mail on |
| 10:21 | <Hixie> | gsnedders: so i can make sure to spec it |
| 10:21 | <virtuelv> | Hixie: then spec what Firefox and IE does |
| 10:22 | <virtuelv> | which is to never ever add to the history |
| 10:26 | <Hixie> | virtuelv: send mail |
| 10:28 | <Hixie> | ok time to sleep |
| 10:28 | <Hixie> | nn |
| 10:37 | <Lachy> | Hixie, othermaciej, I had another go at rewriting the image analsis heuristics text |
| 10:37 | <Lachy> | --- |
| 10:37 | <Lachy> | When the user is unable to make direct use of the image, e.g. due to a visual disability or because they are using a text terminal with no graphics capabilities, user agents may also provide the user with the ability to obtain any other information about the image that may assist the user in understanding the content or purpose of the image, utilising any available repair technique. |
| 10:37 | <Lachy> | Such techniques may be based on information from any relevant source including, but not limited to, the following suggestions: |
| 10:37 | <Lachy> | * Obtaining the file name from the URL reference or HTTP headers supplied with the resource, such as the Content-Location or Content-Disposition header fields. |
| 10:37 | <Lachy> | * Extracting human readable metadata embedded within the resource. e.g. EXIF or RDF embedded within the resource. |
| 10:37 | <Lachy> | * Referring to alternative text associated with another instance of the same resource on the page, |
| 10:37 | <Lachy> | * Applying OCR techniques to recognise and extract textual content that is graphically represented on the image. |
| 10:37 | <Lachy> | For more information, refer to the User Agent Accessibility Guidelines techniques for repairing missing content ([UAAG10-TECHS], section 2.7). |
| 10:37 | <Lachy> | --- |
| 10:38 | <othermaciej> | Lachy: post it to the list I guess and see if people like it |
| 10:38 | <Lachy> | ok. What do you think of it? |
| 10:40 | <othermaciej> | Lachy: should XMP metadata be mentioned? |
| 10:40 | <othermaciej> | Larry cited it |
| 10:40 | <othermaciej> | I'm not sure if it actually consists of RDF or not |
| 10:40 | <othermaciej> | Lachy: looks good to me in general though |
| 10:43 | <Lachy> | I don't know either. But UAAG mentioned RDF embedded in the resource, so I figured that and EXIF would be enough for examples |
| 10:48 | <jgraham> | The file name is bad unless human readable. |
| 10:49 | <jgraham> | >So it should either say "the human readable part of the file name" or (perhaps better) we shouldn't bother enumerating all these techniques |
| 11:04 | <othermaciej> | yeah, I am not sure enumerating some techniques is an improvement over not listing any |
| 11:10 | <Lachy> | I don't really care either way. |
| 11:15 | <hsivonen> | to me, talking about human-readable data in RDF in images is wishful |
| 11:15 | <hsivonen> | as is talking about human-readable data in EXIF |
| 11:16 | <jgraham> | hsivonen: Some EXIF has human readable data |
| 11:16 | <jgraham> | But it is typically not a replacement for an image in context |
| 11:17 | <zcorpan__> | alt -- as found on the web -- is typically not a replacement for an image in context |
| 11:17 | <jgraham> | hsivonen: e.g. http://www.flickr.com/photos/carpeicthus/4291505464/meta/ |
| 11:17 | <hsivonen> | jgraham: I don't have numbers, but I'd expect human-readable data that isn't either the photographer name or keywords derived from coordinates using geonames to be exceedingly rare |
| 11:18 | <hsivonen> | jgraham: does any EXIF spec formalize the <a href> stuff seen there? |
| 11:18 | <jgraham> | hsivonen: I think that typical photo editing software allows you to add a description to the exif |
| 11:18 | <zcorpan__> | hmm, <input type=image> coordinates either changed in implementations since last i tested or my testing was bogus last time |
| 11:19 | <hsivonen> | also, that data seems something that anyone who'd write it in the first place would want to present as part of the HTML page to all readers |
| 11:19 | <jgraham> | hsivonen: I doubt it; that is for flickr's benefit |
| 11:19 | <jgraham> | hsivonen: It is, in this case |
| 11:19 | <hsivonen> | as it is presented on http://www.flickr.com/photos/carpeicthus/4291505464 for all users |
| 11:19 | <jgraham> | But if the photo were reused in another context it might not be |
| 11:20 | <hsivonen> | jgraham: so does anyone do it for purposes other than making Flickr extract it and show it as part of the photo page as HTML to all users? |
| 11:20 | <jgraham> | Of course it wouldn't tell you much about the photo apart from "it has a female model", "it was taken in nashville" and :it has complex lighting" |
| 11:20 | <hsivonen> | jgraham: I know that the sole reason I bother with scripts that generate human-readable strings into EXIF is that Flickr extracts those on the photo page |
| 11:20 | <jgraham> | hsivonen: No idea |
| 11:21 | <jgraham> | I guess people only do things when they get an immediate benefit from it so perhaps not |
| 11:22 | <jgraham> | Maybe if the photo tags were embedded in the EXIF that would be more helpful than the description |
| 11:23 | <jgraham> | Since people might add tags for their personal use (helping them manage their photo collection) and the information would typically also be helpful in understanding the image |
| 11:23 | <hsivonen> | whoa. the Chromium team goes on record on what they consider to be the Web Platform: http://dev.chromium.org/developers/web-platform-status |
| 11:24 | hsivonen | expects a blog post from shepazu |
| 11:25 | <zcorpan__> | could not find the text "svg" |
| 11:26 | <jgraham> | Why is it so hard to find a Free HTTP debugging proxy? |
| 11:27 | <jgraham> | This feels like the type of software that attracts open source implementations |
| 11:28 | <hsivonen> | what features would an "HTTP debugging proxy" have? |
| 11:29 | <jgraham> | The ability to rewrite content, cache certian files on the proxy irrespective of HTTP headers, the ability to return a local file as if it were the remote resource |
| 11:29 | <jgraham> | Obviously the ability to log and inspect what is going on |
| 11:30 | <hsivonen> | Lachy: it seems like a bad idea to introduce an RDF dependency to the browser platform just in case once in a blue moon an image has human-readable text in RDF |
| 11:30 | <hsivonen> | Lachy: frankly, talking about RDF there looks like wishful metadata handwaving |
| 11:30 | <hsivonen> | Lachy: see also the IRC log about EXIF |
| 11:31 | <hsivonen> | othermaciej: XMP is RDF but not all RDF is XMP |
| 11:31 | <hsivonen> | othermaciej: I *think* XMP places restrictions on what kind of RDF you can have, but I don't know what those restrictions are |
| 11:34 | <Lachy> | hsivonen, they were only suggestions, not requirements |
| 11:40 | <Lachy> | jgraham, hsivonen, I don't think anyone expects any embedded human readable metadata to provide ideal replacement text in context, but that's not the point of it. The point is to give more information about the user that may help the user infer some meaning based on the context. |
| 11:40 | <Lachy> | s/about the user/about the image/ |
| 12:04 | <hsivonen> | I feel like tosting to the ISSUE-66 thread that I think JF's reasoning has two bugs, but that would be unproductive, because I agree with his conclusion |
| 12:18 | <Lachy> | it's nice that Vimeo has now adopted <video> |
| 12:18 | <Lachy> | Not so nice that they only offer h.264, but I suppose that was to be expected |
| 12:25 | <hsivonen> | Lachy: nice even though it puts Opera at a disadvantage relative to Chrome? |
| 12:30 | <Lachy> | I meant nice in the sense that they're starting to remove their dependence on flash. |
| 12:31 | <Lachy> | but AIUI, it doesn't put Opera on Linux at a disadvantage, since we use gstreamer for that which supports h.264 |
| 12:31 | <gsnedders> | We use GStreamer on all platforms, it's just we expect it to already be installed on Linux anyway and just use the system copy (with plugins, if installed) |
| 12:32 | <Lachy> | I didn't know gstreamer was ported to other platforms |
| 12:32 | <Lachy> | I've never installed it on any of my machines |
| 12:32 | <hsivonen> | Lachy: having not work on Linux with pristine distro plus Opera and having it not work on Windows or Mac doesn't seem so great |
| 12:32 | <gsnedders> | Never had anything that depended upon it installed? |
| 12:33 | <Lachy> | I don't think so, unless it's installed as part of VLC or MPlayer |
| 12:34 | <Lachy> | anyway, I must get to the airport very soon. I'm off to Prague for the weekend. |
| 12:37 | <hsivonen> | to me, it seems that the English translation of the requests to support H.264 via GStreamer is: "We want to trade badly-performing closed-source software to patent-encumbered better performing software" |
| 16:20 | <AryehGregor> | "What’s New Under the Hood for Developers: Support for the latest HTML5 specification, including the File API for local file handling"https://developer.mozilla.org/devnews/index.php/2010/01/21/firefox-3-6-is-now-available-for-download/ |
| 16:20 | <AryehGregor> | That makes it sound like they support the whole thing. |
| 16:21 | <Dashiva> | That's what marketing is for |
| 16:21 | <TabAtkins> | Woo, -moz-linear-gradient()! |
| 16:23 | <Philip`> | HTML5, including the File API? |
| 16:29 | <jgraham> | Philip`: Sshhh or someone in the htmlwg will realise that when non-spec-junkies say "HTML5" they don't pay much attention to which document the technology is in |
| 16:31 | gsnedders | should stop being such a spec junkie and stop smoking all that paper and ink |
| 16:31 | <TabAtkins> | I take it in my veins. |
| 16:43 | <jgraham> | I didn't choose life. I chose something else. I chose specs. |
| 16:44 | <gsnedders> | I thought you said a few weeks ago you'd never read nor seen that |
| 16:44 | <jgraham> | Actually I saw it the other day |
| 17:42 | <JonathanNeal> | Hello Hello |
| 18:09 | AryehGregor | finds it fascinating that two different anonymous users changed "[[Ian Hickson]], editor of the HTML5 specification, expects the specification to reach . . . W3C Recommendation in the year 2022 or later" to read "2012" instead of "2022" |
| 18:09 | <AryehGregor> | In the Wikipedia article on HTML5, I mean. |
| 18:10 | <TabAtkins> | Well, if it doesn't reach REC by 2012, it clearly won't have the chance to reach REC at all. |
| 18:10 | <AryehGregor> | Haha. |
| 18:23 | <Dashiva> | AryehGregor: Check if those same users changed other articles to set years to 2012? |
| 18:23 | <AryehGregor> | Dashiva, interesting thought. I assumed it was just misunderstanding, but maybe people are randomly changing years to 2012. |
| 18:24 | <AryehGregor> | Nope, they seem to have just assumed it must be wrong. |
| 18:24 | <AryehGregor> | http://en.wikipedia.org/wiki/Special:Contributions/70.62.29.131 |
| 18:24 | <AryehGregor> | http://en.wikipedia.org/wiki/Special:Contributions/99.51.105.249 |
| 18:24 | <AryehGregor> | Both gave edit summaries that suggest that, too. |
| 18:28 | <Dashiva> | So people have strong faith |
| 23:37 | <Hixie> | huh, the - key on this keyboard also hits f12 |
| 23:37 | <Hixie> | how odd |
| 23:43 | <Hixie> | i should seriously consider putting this keyboard through the dishwasher |
| 23:43 | <Hixie> | it's ridiculously dirty |
| 23:57 | <shepazu> | hsivonen: I never blog anymore :( |
| 23:57 | <shepazu> | no time, sadly |
| 23:59 | <shepazu> | Google is schizophrenic about SVG... they have some projects that use and promote it, but put little effort into browserside or mobile development |