| 00:00 | <webben> | "just" |
| 00:04 | <Dashiva> | Well, the anime I watch in mkv manages to handle multiple audio tracks and multiple subtitle tracks in a single file |
| 00:07 | <greghouston> | With VobSub there are several options for the subtitles, position on the screen, opacity, fadein/out ... It also looks like you can probably add more subtitle tracks to the file, though there is only one in this file that I am looking at. |
| 01:24 | <webben> | am I right in a vague recollection that we have text/html html5 parsers that are faster than xml parsers? |
| 01:36 | <Philip`> | webben: I don't think that's currently true |
| 01:38 | <Philip`> | (unless I'm misremembering what hsivonen has said in the past) |
| 01:38 | <Hixie> | i don't think we have any html5 parsers that aren't paying some sort of VM tax yet do we? |
| 01:39 | <Philip`> | takkaria has been writing one in plain C |
| 01:39 | <webben> | just saw the XML parsing is faster claim on an internal mailing list and seemed to remember that actually not necessarily being the case from a claim here |
| 01:40 | <webben> | (of course, it's difficult to tell anything in theory from actual implementations, but still) |
| 01:40 | <Philip`> | It seems the only real difference is that XML parsers are more mature and more heavily optimised than HTML5 parsers |
| 01:41 | <Hixie> | how is takkaria's, performance-wise? |
| 01:43 | Philip` | has no idea |
| 02:15 | <Hixie> | hsivonen: did you get any response to your feedback on WCAG2? |
| 02:30 | <Hixie> | i wonder where MikeSmith is |
| 02:30 | <Hixie> | haven't seen him in a while |
| 02:45 | <takkaria> | Hixie: about half as fast as libxml2's html parser |
| 02:45 | <takkaria> | Hixie: IIRC it parses the HTML5 spec in about 1.3s |
| 02:46 | <Hixie> | not bad, not bad |
| 02:46 | <Hixie> | what platforms does it run on? |
| 02:47 | <takkaria> | anything that runs C99 |
| 02:47 | <takkaria> | though there are some unresolved crasher bugs on RISC OS at the moment |
| 02:48 | <takkaria> | runs on Linux fine, though, and I assume it'll cross-compile to Windows fairly easily |
| 02:48 | <Hixie> | could it be retrofitted into libxml2 to expose the same API but with the html5 parser? |
| 02:48 | <takkaria> | yeah, the browser it's being used in (NetSurf) does exactly that |
| 02:50 | <Hixie> | cool |
| 02:50 | <Hixie> | you should get gsnedders to use it |
| 02:50 | <Hixie> | :-) |
| 02:50 | <Hixie> | in spec gen |
| 02:50 | <Hixie> | is there any optimisation work planned? |
| 02:51 | <takkaria> | well, the tokeniser is pretty well optimised already but there are a couple of places it could be improved |
| 02:51 | <takkaria> | the treebuilder is pretty much unoptimised in any way whatsoever |
| 02:51 | <takkaria> | and there are some nice low-hanging fruit there |
| 02:53 | <takkaria> | problem with people using it at the moment is that it's a build-from-svn thing. when we have out a release with versioning and built as a shared library and things using it in things like spec-gen becomes plausible |
| 02:53 | <Hixie> | ah ok |
| 02:53 | <Hixie> | it's so cool that you're doing this stuff |
| 02:54 | <takkaria> | well, I got summer of code funding, so I've been having a pretty good time writing it :) |
| 02:54 | <Hixie> | :-D |
| 02:55 | <takkaria> | my laptop broke the other day though so atm I'm somewhat offline and I've forgotten all my todolist items and things, and the profiling data I have |
| 02:55 | <takkaria> | but I think about 25% of the time in the treebuilder can be shaved off without much work |
| 02:56 | <Hixie> | nice |
| 02:56 | <Hixie> | you should get jgraham, Philip`, hsivonen to help you out, their experience with optimising parsers is bound to suggest some things you could do |
| 02:57 | <Hixie> | henri in particular has done some pretty fancy things with buffers that might have unexpected benefits |
| 02:58 | <takkaria> | amusingly we found the same things with buffers |
| 02:58 | <Hixie> | yeah? nice |
| 02:58 | <takkaria> | Hubbub used to try and buffer only the things that needed buffering and use offsets the rest of the time but it made the code simpler and faster to just always use buffers |
| 02:59 | <Hixie> | heh |
| 02:59 | <takkaria> | we discovered this roughly in parallel I think |
| 02:59 | <Hixie> | cool |
| 03:00 | <takkaria> | I've been keeping an eye on the v.nu parser for optimisations to steal, too |
| 03:00 | <takkaria> | but I've not touched the code for a week and a half and it's getting a bit hazy again :) |
| 03:04 | <Hixie> | :-) |
| 03:15 | <takkaria> | the alt thread makes me cry, I really did hope it would stop at some point in the last few days |
| 03:18 | <takkaria> | mainly because it becomes more and more obvious that the accessibility people haven't been taking anything other people have been saying in |
| 03:23 | <takkaria> | so much rhetoric, so little argument |
| 04:00 | <Hixie> | man watching usability studies is depressing |
| 04:11 | <Hixie> | so... depressing... |
| 04:13 | <othermaciej> | is it the quality of the software that's depressing or the quality of the users? |
| 04:14 | <Hixie> | hard to say |
| 04:15 | <Hixie> | i mean it's always the software's fault |
| 04:16 | <Hixie> | but what's depressing is the utter failure of many interactions |
| 04:37 | <Hixie> | i think blind users might just be desensitised to the sheer amount of repetition they hear |
| 04:43 | <Hixie> | good lord |
| 07:08 | <Dashiva> | Is it bad that my attention just drifts away whenever someone mentions search engine indexing as a benefit of RDF? |
| 07:11 | <roc> | what I don't understand is how search engines and browser are supposed to do magic things with this data while there is no central authority |
| 07:12 | <roc> | is each of N user agents supposed to independently discover all M namespaces and implement their semantics? |
| 07:12 | <Dashiva> | I just want to yell "It's the SEO, stupid" |
| 07:13 | <Dashiva> | roc: You just download the internet and walk the graph, it's simple enough :) |
| 07:22 | <Hixie> | roc: i'm always baffled as to how these people think search engines are going to use this data, given that if they did use this data, it would immediately be utterly unusable due to spammers |
| 07:22 | <Hixie> | roc: i'm especially amused though when people tell me something is needed for search engines |
| 07:22 | <Hixie> | hello |
| 07:22 | <Hixie> | i work for google |
| 07:23 | <Hixie> | how about _i_ tell you what we need, and you tell me what _you_ need |
| 07:24 | <roc> | heh |
| 07:25 | <Hixie> | Lachy: so i've found a huge problem with requiem |
| 08:41 | <Hixie> | if anyone wants to see the new draft alt="" regime before i commit it, it's at http://www.whatwg.org/specs/web-apps/current-work/#alt |
| 08:44 | <hsivonen> | Philip`: I thought DVD subtitles were bitmaps |
| 08:46 | <hsivonen> | Hixie: I got a reply for my ATAG feedback. I didn't get feedback on my WCAG feedback (from the WG that is). |
| 08:48 | <Hixie> | what was the ATAG feedback and what did they reply? |
| 08:49 | <hsivonen> | Hixie: well, if people think they know what Google needs, people think they know what CC needs :-) |
| 08:50 | hsivonen | looks up the ATAG mail urls |
| 08:50 | <hsivonen> | http://lists.w3.org/Archives/Public/public-atag2-comments/2008Aug/0000.html |
| 08:51 | <hsivonen> | http://lists.w3.org/Archives/Public/w3c-wai-au/2008JulSep/0072.html |
| 08:51 | <hsivonen> | http://lists.w3.org/Archives/Public/w3c-wai-au/2008JulSep/0073.html |
| 08:51 | <hsivonen> | http://lists.w3.org/Archives/Public/w3c-wai-au/2008JulSep/0074.html |
| 08:51 | <hsivonen> | http://lists.w3.org/Archives/Public/w3c-wai-au/2008JulSep/0075.html |
| 08:51 | <hsivonen> | those are the URLs for the ATAG thread |
| 08:52 | <Hixie> | man, these guideline docs are almost as vague as scripture |
| 08:52 | <hsivonen> | like I said in one of the emails, I was unable to verify an interpetation of the draft by reading the draft |
| 08:56 | <hsivonen> | sometimes I suspect that the guidelines are vague because the experts couldn't agree, so what got written down is something that each WG participant can see their own opinion in |
| 08:57 | <Hixie> | again like scripture then... |
| 08:57 | <hsivonen> | or at least I've gotten mixed interpretation from former editor and current editor |
| 09:17 | <Hixie> | ok. |
| 09:17 | <Hixie> | alt="" debate reply sent. |
| 09:17 | <Hixie> | for me to consider further new feedback, it has to say something that hasn't been said before. |
| 09:22 | <Philip`> | hsivonen: Oh, okay, you're right |
| 09:38 | <Dashiva> | Hixie: Implement robot9000 for the list :) |
| 09:42 | <Hixie> | hah |
| 09:42 | <Hixie> | steven's recent complaints are even more insane |
| 09:42 | <Hixie> | now he's complaining about my decisions before i even make them |
| 09:45 | <Dashiva> | Why doesn't he just stop pussyfooting around and talk to the chairs? |
| 09:46 | <annevk> | heh |
| 09:51 | <Dashiva> | Is that museum artifact example for real? |
| 09:51 | hsivonen | tries the million URL exercise again. this time with the output going to a dedicated hard disk and gzipped on the fly |
| 09:51 | <Dashiva> | Because more than anything else it just demonstrates the madness of dereferencing namespace URIs |
| 09:51 | <annevk> | stop hating distributed extensibility so much |
| 09:52 | <hsivonen> | Dashiva: museum people use RDF |
| 09:52 | <hsivonen> | Dashiva: a friend of mine was on a research group that created an ontology for museums |
| 09:53 | <Dashiva> | hsivonen: Sure, but did they go around downloading random pages? |
| 09:53 | <hsivonen> | I don't know. |
| 09:54 | <Dashiva> | hsivonen: More specifically, Charlie deciding to dereference is the unreal part, not people putting tuples in their pages |
| 09:54 | <hsivonen> | what I've heard about the ontology creation process corroborated my own guess about the process from my time at the National Archives |
| 09:54 | virtuelv | recalls the awesome presentation about rijksmuseum.nl from Dublin earlier this year |
| 09:55 | <virtuelv> | (awesome, as in, someone actually did something cool with RDF) |
| 10:00 | <hsivonen> | Hixie: I wish someone answered my question on how well the CC URI upgrade worked with tools that existed at the time |
| 10:02 | <Philip`> | "A somewhat strained analogy would be bringing |
| 10:02 | <Philip`> | in representatives from all of the cultures of the world and having them |
| 10:02 | <Philip`> | agree on a universal vocabulary." |
| 10:02 | <Philip`> | That sounds kind of similar to agreeing on a universal character encoding, rather than having everyone invent their own independent ones |
| 10:03 | <hsivonen> | Philip`: but that's not decentralized |
| 10:05 | <hsivonen> | though as far as universal vocabuliaries between cultures go, English is doing pretty well with decentralized extensibility |
| 10:06 | <Philip`> | hsivonen: Why not? People can decentralisedly invent and use their own character encodings, and they just need to convince their favourite tool vendors to support it, which seems easy enough for governments to do |
| 10:07 | <hsivonen> | Philip`: even the Chineses government can't make software developers change the way text is represented in RAM |
| 10:07 | <hsivonen> | Philip`: but the Unicode folks were able to |
| 10:14 | <Hixie> | hsivonen: got any early numbers regarding the validity study? |
| 10:26 | <hsivonen> | Hixie: no |
| 10:26 | <jgraham> | Good lord it's getting bad when Rob Burns is producing more useful comments on accessibility than the "accessiility experts" |
| 10:27 | <jgraham> | hsivonen: Thanks for the bug report yesterday. Score namespaces 1 james 0 |
| 10:29 | <Hixie> | only 1? :-) |
| 10:30 | <Dashiva> | namespaces 1.<xsd:integer> |
| 10:31 | hsivonen | expects the gzipped dump of validation worker output to go to somewhere around 60 GB |
| 10:32 | <hsivonen> | even though I suppress duplicate messages per URL before writing out |
| 10:32 | annevk | beat the namespaces spec a few times by getting it revised |
| 10:37 | <hsivonen> | Hixie: at this rate, it will take 34 hours to get even the preliminary data dump |
| 10:37 | <Hixie> | what's your rate? |
| 10:38 | <Philip`> | hsivonen: You could try looking at fewer pages, which would make it go faster and probably wouldn't make things significantly less statistically significant :-) |
| 10:38 | <hsivonen> | 465 urls per minute |
| 10:38 | <Hixie> | validator.w3.org apparently deals with millions of requests per day, so you need to get to the point of being able to do the whole sample from the network in less than 24 hours. :-) |
| 10:39 | <hsivonen> | now that I think about it, I started the process on the wrong HotSpot version... |
| 10:39 | <Hixie> | oh that's not too bad, i thought you meant a small sample when you said "preliminary data dump" |
| 10:39 | <hsivonen> | I could throw away 47 minutes now and restart it with a better JIT |
| 10:39 | <Hixie> | seems wise |
| 10:40 | <Hixie> | also if you're doing any console I/O, hide it, that ends up being a massive cost when i'm doing debugging runs |
| 10:40 | <Hixie> | dunno if it applies to you |
| 10:40 | <hsivonen> | it applies to me |
| 10:42 | <hsivonen> | I print progress every 100 urls though, to avoid spending too much time printing |
| 10:42 | <Hixie> | that helps |
| 10:46 | <zcorpan> | Hixie: the current spec text on alt makes sense to me |
| 10:46 | <Hixie> | woot! |
| 10:47 | <Hixie> | i have 100% support from all those who have commented! |
| 10:47 | Hixie | does a little dance |
| 10:47 | <zcorpan> | :) |
| 10:47 | <Hixie> | sadly it can only go down from here :-( |
| 10:47 | <zcorpan> | it could stay at 100% |
| 10:47 | <Hixie> | that seems unlikely |
| 10:47 | hsivonen | is considering how productive it would be to rain on the parade at this point |
| 10:47 | <Hixie> | :-) |
| 10:47 | <zcorpan> | yes, at least if you get further comments |
| 10:47 | <Hixie> | well, if i missed something important, do say |
| 10:50 | <hsivonen> | aargh. NPE in class loading code on the other JVM |
| 10:51 | Philip` | read the end of the email first, to see what the decision was, but that just said it was "option F", so he had to read the top of the email, which only went to option E, and so he had to end up reading the entire email to find the actual chosen solution :-( |
| 10:51 | <Hixie> | Philip`: heh - you could have just read the spec diff :-P |
| 10:51 | Hixie | admits that that was partially intentional |
| 10:51 | <zcorpan> | Hixie: i wonder if the captcha case could have a caption in the form of <fieldset><legend> or <th> instead |
| 10:52 | <Hixie> | ooh, that's not a bad idea |
| 10:52 | <Philip`> | Hixie: The spec diff looks longer than the email |
| 10:52 | <Hixie> | Philip`: heh maybe |
| 10:52 | <Hixie> | zcorpan: we'll see what other feedback i get, but that seems reasonable on the face of it |
| 10:53 | <Hixie> | though we'd have to decide on a priority order |
| 10:53 | <Hixie> | i guess it could be nearest-enclosing |
| 10:54 | <hsivonen> | new this is *weird* the code that works on Sun Java 1.6 and OpenJDK 6 has broken classloader behavior on Apple's port of JDK 6 |
| 10:54 | <hsivonen> | aargh |
| 10:54 | <zcorpan> | Hixie: yeah... and i'm sure there are cases where it wouldn't make sense |
| 10:54 | <hsivonen> | Class loader issues suck |
| 10:54 | <hsivonen> | NPE sucks |
| 10:54 | <hsivonen> | now I have NPE in class loading |
| 10:54 | hsivonen | goes out to lunch |
| 10:54 | <Hixie> | NPE? |
| 10:54 | <hsivonen> | NullPointerException |
| 10:56 | <Hixie> | oh |
| 10:56 | <zcorpan> | Hixie: editorial: in the example listing images, i'd say " <tr> <th> Image <th> Description" (in singular) |
| 10:57 | Hixie | sends himself an e-mail saying that |
| 10:59 | <MikeSmith> | hsivonen: found what seems to be another discrepancy in HTML5 schema vs. the spec |
| 10:59 | <MikeSmith> | spec says that col element can have a span attribute |
| 11:00 | <MikeSmith> | but schema does not allow span on col |
| 11:00 | <zcorpan> | hey i tested <col span> in v.nu the other day |
| 11:00 | <cyclist> | pls help. In the HTML5 spec it sais that block level elements inside stricly inline level elements are "not allowed". |
| 11:00 | <zcorpan> | wonder why i didn't catch that it didn't validate |
| 11:01 | <cyclist> | If somebody does that nontheless, what is the browser supposed to do? |
| 11:01 | <cyclist> | Break the inlines around the block perhaps? |
| 11:01 | <zcorpan> | cyclist: rendering-wise it's defined in css |
| 11:02 | <zcorpan> | cyclist: you can even get that with conforming markup: <span>x<span style=display:block>y</span>z</span> |
| 11:02 | <annevk> | cyclist, you're reading an old version of HTML5 |
| 11:02 | <cyclist> | yes indeed. |
| 11:02 | <annevk> | cyclist, try http://whatwg.org/html5 or http://html5.org/spec |
| 11:02 | <cyclist> | the newer version defines action to be taken on the "not allowed"? |
| 11:03 | <Philip`> | The newer version allows it |
| 11:03 | <cyclist> | ah. ok |
| 11:03 | <Philip`> | in some cases, I think |
| 11:03 | <annevk> | cyclist, the newer version doesn't have block or inline level elements |
| 11:03 | <Philip`> | unless I'm misremembering |
| 11:03 | <Philip`> | Oh, okay |
| 11:04 | <MikeSmith> | hsivonen: I see why now.. col.attrs.span is defined but not referenced -- because the schema is missing "col.attrs &= col.attrs.span" |
| 11:04 | <zcorpan> | Philip`: it doesn't allow non-phrasing flow content in phrasing content |
| 11:04 | <Hixie> | cyclist: what's the exact case you are trying to do? |
| 11:05 | <zcorpan> | wow the spec's terminology won't be understandable to J. Author |
| 11:05 | <cyclist> | write a web browser :) |
| 11:05 | <cyclist> | or at least render pages |
| 11:05 | <Hixie> | oh you're looking for UA behaviour, ok |
| 11:05 | <Hixie> | well the parsing is defined in the parsing section of HTML5 |
| 11:05 | <Hixie> | and the rendering is defined by CSS |
| 11:05 | <zcorpan> | "the spec doesn't allow block content in inline content" would be more understandable |
| 11:06 | <Hixie> | annevk: any idea if opera has any feedback on the workers stuff? (in particular the latest proposal) |
| 11:06 | <Hixie> | (not what the latest spec says) |
| 11:07 | <Philip`> | zcorpan: I was thinking of the <a><div>... thing which I think changed, but I have no idea what terminology the spec uses for that kind of thing |
| 11:07 | <cyclist> | OK. I had a really old version of HTML5. The new version passes the ball to css it seems. thanks |
| 11:07 | <zcorpan> | Philip`: oh right |
| 11:08 | <Hixie> | cyclist: np |
| 11:09 | Hixie | watches his cat pull down the kitten-sized cat furniture |
| 11:10 | <Hixie> | she really needs to stop leaping on it |
| 11:10 | <annevk> | Hixie, no, other than the feedback you already got I think we don't have anything new (nor have we debated this much) |
| 11:12 | <zcorpan> | Hixie: could the spec use the terminology "inline content" and "flow content" (and "block content" which would be flow excluding inline) instead of "phrasing"? it'd be closer to what authors use and could still be distinguished from css ("content" vs "-level") |
| 11:12 | <Philip`> | You could put metal spikes on top of the furniture to keep the cat off |
| 11:21 | <Hixie> | zcorpan: i don't want to use the word "inline" |
| 11:21 | <Hixie> | Philip`: it's cat furniture! she's welcoem to use it :-P |
| 11:21 | <Hixie> | just wish she'd not pull the whole thing over each time she leaps at it :-P |
| 11:24 | <Hixie> | ok julian is clearly just trolling me |
| 11:24 | <annevk> | and missing the point |
| 11:27 | <hsivonen> | Hixie: regarding the throughput competitiveness of Validator.nu as a back end to the W3C Validator: |
| 11:27 | <hsivonen> | the online version should have better throughput than this offline version |
| 11:27 | <hsivonen> | the online version doesn't build a tree |
| 11:27 | <hsivonen> | this offline worker does |
| 11:30 | <Hixie> | ah ok |
| 11:30 | <Hixie> | why the difference? |
| 11:31 | <hsivonen> | what the online version does yield better throughput and is acceptable for cases where an author is using it as a tool and even tries to keep the markup sane |
| 11:32 | <Hixie> | (btw if anyone read my response to manu, did it seem right? or am i insane?) |
| 11:32 | <hsivonen> | however, to discover all the craziness that's going on out there, I don't want to stop at the first non-streamable error in the offline research tool |
| 11:32 | <Hixie> | hsivonen: oooh, cunning |
| 11:32 | <Hixie> | can't wait to see this data |
| 11:32 | <Hixie> | i actually just want to see the % of pages that have zero errors :-) |
| 11:43 | <hsivonen> | Hixie: want to see what pages have zero parser-level errors and are in stardards mode and then I want to see what we could do to make the validation layer errors go away on those pages |
| 11:44 | <hsivonen> | (zero parser level errors with legacy doctype errors ignored) |
| 11:45 | <annevk> | maybe legacy doctypes should become conforming HTML5 doctypes |
| 11:46 | <annevk> | though this could be controversial |
| 11:47 | <hsivonen> | fwiw, I'm running the parser in the survey mode, which suppresses tree builder -level doctype errors |
| 11:48 | <hsivonen> | I consolidate the kind of messages that cite attribute values |
| 11:48 | <hsivonen> | then I consolidate duplicate messages per URL |
| 11:49 | <hsivonen> | then I log tuples that have URL, quirkiness, layer and message |
| 11:49 | <hsivonen> | where quirkiness is HTML5, other Standards, almost standards or quirks |
| 11:49 | <hsivonen> | and layer is parser layer or validation layer |
| 11:50 | <zcorpan> | Hixie: why not? |
| 11:50 | <hsivonen> | also, when an URL didn't have errors on a given layer, I log a special NO ERRORS message |
| 11:52 | <annevk> | hmm, I'm going to "North Korean Flying Circus" tonight, it seems to be so new that there's no wikipedia page yet... |
| 11:54 | <Lachy> | annevk, it could mean that it's just not notable enough, regardless of how new it is. |
| 11:54 | hsivonen | tries to resist a rant about the pointlessness of non-notability deletionism |
| 11:54 | <Lachy> | or that it just doesn't have a page on the english wikipedia, since it's korean |
| 11:55 | <annevk> | all kinds of small Dutch villages have English Wikipedia entries |
| 11:55 | <zcorpan> | hsivonen: what v.nu calls "legacy doctype" can trigger standards mode; are you counting those? |
| 11:55 | <hsivonen> | zcorpan: I'm counting them as non-HTML5 Standards mode |
| 11:56 | <hsivonen> | zcorpan: I'm counting quirkiness from the DocumentModeHandler--not from messages |
| 11:56 | <zcorpan> | hsivonen: ok |
| 11:56 | Lachy | agrees the notability rules for wikipedia are a bit strict and arbitrarily applied sometimes |
| 11:57 | <annevk> | I think it's just that it's quite new and so far only shown in the Netherlands |
| 11:57 | <annevk> | apparently the World Premier was August 1 |
| 11:59 | <Hixie> | zcorpan: i want to completely avoid confusion with css |
| 12:00 | <Hixie> | holy crap, 2/2 on feedback, and one of them was an accessibility person |
| 12:02 | <hsivonen> | Hixie: a person creates a new document in Nvu, drags a JPEG from Finder to the blank document and saves. What does Nvu do to make the output pass a machine-administered syntax check? |
| 12:03 | <hsivonen> | assuming an HTML5 version of Nvu under the new spec text |
| 12:03 | <annevk> | was Hixie's "Great!" just now a disguised "+1"? :p |
| 12:04 | <zcorpan> | Hixie: i understand that, but i think that authors in the wild simply aren't going to use the current spec's terminology |
| 12:04 | <zcorpan> | Hixie: so it's not helping, it's just adding to the confusion |
| 12:05 | <Hixie> | hsivonen: i do not believe the current spec allows the editor in such a scenario to output conforming markup without further input from the user. |
| 12:05 | <zcorpan> | Hixie: also, try looking up "phrasing" in wikipedia or a dictionary |
| 12:05 | <Hixie> | annevk: no, i wasn't agreeing with him, i was expressing happiness. :-) |
| 12:06 | <Hixie> | zcorpan: i think given time, authors will begin to use the new terminology. there's no rush here. i'm open to other terms of "phrasing" isn't any good though. |
| 12:06 | <hsivonen> | Hixie: do you expect glazou to go along with either putting up a modal prompt or writing non-conforming output? |
| 12:06 | <zcorpan> | Hixie: how about "text-level content"? |
| 12:07 | <hsivonen> | class loading is such a PITA |
| 12:07 | <Hixie> | hsivonen: depends. If this happens for a lot of images on the page, then Nvu could probably assume empty alt="" and just put that in, with the argument that the UI allows the user to specify the alternative text but defaults to assuming decorative images, and that it's the user's fault if the user doesn't give the right data. |
| 12:08 | <Hixie> | hsivonen: if it's just a single image, but the user gives alt="" for the other images explicitly, then i'd say that for that image, maybe nvu should see if there is a header or legend that follows what the spec says now, and if not, could include an apologetic title="" attribute |
| 12:09 | <Hixie> | hsivonen: or the editor could warn on output that the content isn't valid |
| 12:09 | <zcorpan> | Hixie: "why doesn't this validate?" "it's not allowed to have block children of inline elements" is a common conversation. how would you say that using the spec's terminology? |
| 12:09 | <Hixie> | hsivonen: (either way, accessibility is screwed if the author, as in this case, is actively avoiding helping even when they really should and could) |
| 12:10 | <Hixie> | zcorpan: "You can't put a <div> in a <span>." |
| 12:10 | <Hixie> | zcorpan: (or whatever) |
| 12:10 | <hsivonen> | Hixie: an editor that hides the HTML file format from the user should always be able to write output that passes a machine-admistered syntax check |
| 12:10 | <hsivonen> | adiministered |
| 12:10 | <hsivonen> | doh |
| 12:10 | <zcorpan> | Hixie: but that would only give him a fish, not teach him to fish |
| 12:10 | hsivonen | can't spell today |
| 12:10 | <Hixie> | zcorpan: or "phrasing content can only contain other phrasing content, and you're putting elements in your phrasing content that aren't phrasing content" or some such |
| 12:11 | <hsivonen> | Hixie: if you want writing output to proceed despite a check failing, that check belongs in a different class of checks |
| 12:12 | <Hixie> | hsivonen: i think it's quite reasonable for an editor to assume images are decorative unless told otherwise, assuming the ui makes that clear |
| 12:12 | <hsivonen> | so we're back to emitting alt="" silently |
| 12:13 | <Hixie> | i haven't spent any time trying to cater for the case of editors where the user is actively hostile to making accessible content |
| 12:14 | <Hixie> | for certain images you can do things like OCR, there's been some research in that same (q.v. e.g. webinsight) |
| 12:14 | <Hixie> | s/same/area/ |
| 12:14 | <hsivonen> | that OCR really should be on the client side |
| 12:15 | <Hixie> | certainly would be nice for reader-side uas to have ocr, yes, and that's what webinsight does actually |
| 12:16 | <Hixie> | for images that are sole content of links, alt="" text can be synthesised by grabbing the title of the target page, too |
| 12:16 | <Hixie> | there are various things that editors can do to silently handle hostile authors |
| 12:16 | <Hixie> | but fundamentally i don't think there's a great solution. assumin decorative images will handle most images, frankly. |
| 12:16 | <Philip`> | <a href="logout.cgi"><img src="logout.png"></a> - grabbing the target page's title won't work so well there |
| 12:17 | <Hixie> | it doesn't work in all cases, no |
| 12:17 | <Hixie> | webinsight's data suggests you can fill about 40% of images and get about a 90% success rate on those images |
| 12:17 | <Hixie> | which is better than nothing |
| 12:17 | <Philip`> | It doesn't just not work in all cases - it fails badly with negative consequences in some cases, so it's not safe to do it at all |
| 12:17 | <hsivonen> | Hixie: my point is that you have an abstaction leak if an agent can let user input or lack thereof break the syntax of the output file format |
| 12:17 | <Hixie> | this is just like these editors assuming that when you hit bold you mean bold, as opposed to important, and that when you hit font-size+1 you mean to change the style sheet, not change to a <h1>, or whatever |
| 12:18 | <Hixie> | Philip`: going from no alt text to crap alt text 0.4*5% of the time and good alt text 0.4*95% of the time is better than staying with no alt text always. |
| 12:19 | <Hixie> | hsivonen: i'm saying you don't have to break the syntax. you can make assumptions, just like editors do for all their other features. |
| 12:19 | <Philip`> | Hixie: It's not just affecting the usefulness of the alt text, if it's silently making unexpected extra HTTP requests and accidentally logs you out of the site you're on or deletes pages |
| 12:19 | <hsivonen> | Hixie: this is not just like that. If the author makes a semantic error, a machine-administered check doesn't catch it |
| 12:20 | <hsivonen> | Hixie: I'm saying that editors programmed by people who object to abstraction leaks will plug the machine-detectable leaks so that they can't be machine-detected |
| 12:20 | <Hixie> | Philip`: i'm not suggesting sending cookies or http auth credentials with these requests |
| 12:21 | <hsivonen> | and that plugging will occur in the program code in case the user is hostile, so the code will run even when the user isn't hostile |
| 12:21 | <Hixie> | hsivonen: i'm not sure which case you're referring to |
| 12:22 | <Hixie> | hsivonen: why is assuming the user meant alt="" not the same as assuming the user meant font-size: 2em? |
| 12:22 | <Hixie> | (as opposed to alt="Logout" or <h1>) |
| 12:22 | <Hixie> | (which we presume would both be better) |
| 12:22 | <hsivonen> | Hixie: I mean that if the user uses <h1> to make text bold, that's not the kind of problem programmers will plug |
| 12:23 | <hsivonen> | Hixie: if the validator whines about a piece of syntax being absent, (some) programmers will make it present |
| 12:23 | <Hixie> | what syntax would be absent? |
| 12:23 | <hsivonen> | Hixie: alt, or legand, or <hn> |
| 12:24 | <Hixie> | why would alt="" be absent? I'm saying to include it always. |
| 12:24 | <Hixie> | i'm saying it seems legitimate to have the UA assume that images are decorative unless told otherwise, and so to give them empty alt="". |
| 12:24 | <hsivonen> | Well, then you move the autogenerated junk problem to <h1> |
| 12:24 | <Hixie> | (with different behaviour for images in links, e.g. fetching target page titles.) |
| 12:25 | <Hixie> | wysiwyg editors with hostile authors will output pages with poor accessibility, yes |
| 12:25 | <Hixie> | why is this surprising? |
| 12:25 | <hsivonen> | Hixie: if you'd specified that the chain goes from <h1> to <title>, this would reduce to empty <title></title> being there |
| 12:26 | <hsivonen> | Hixie: it's not |
| 12:26 | <Philip`> | Hixie: That wouldn't solve the problem with <a href="logout.cgi?s=1910764e1a0f1976d"><img src="logout.png"></a> |
| 12:26 | <Hixie> | hsivonen: i really don't understand |
| 12:26 | <Philip`> | (...where the ?s is the session identifier) |
| 12:26 | <Philip`> | (for sites that don't want to rely on cookies) |
| 12:26 | <Hixie> | Philip`: why would the page author include a session identifier in a link he is putting in a wysiwyg editor?? |
| 12:27 | <Hixie> | oh you're talking about the client-side thing |
| 12:27 | <hsivonen> | Hixie: what's surprising is that you seem to join accessibility advocates in asking lack of accessibility to be flagged by introducing an error on another layer |
| 12:27 | <Philip`> | Hixie: They wouldn't, but a UA can't tell whether the link came from a WYSIWYG editor, so it's a problem if the UA tries to request the page in situations which the author didn't expect |
| 12:28 | <Hixie> | Philip`: well, tell the webinsight people. i'm only suggesting it here for the editor side, the spec doesn't even suggest it for the browser side. |
| 12:28 | <Philip`> | Hixie: Oh, if it's just in the editor then I guess that's safer |
| 12:29 | <Hixie> | hsivonen: this isn't new |
| 12:29 | <Hixie> | hsivonen: the spec has always required alt="" for all images that could posibly have it. |
| 12:30 | <Hixie> | hsivonen: just like it requires using <h1> for headers, or not having a headers="" attribute point to something outside the table, or whatever |
| 12:30 | <hsivonen> | making Apple's Java 6 work is too much trouble. I'l go back to Apple's Java 5 |
| 12:30 | <hsivonen> | now having lost more than 47 minutes of processing time |
| 12:31 | <hsivonen> | Hixie: you know that those are different from the point of view of programming a WYSIWYG editor |
| 12:31 | <Philip`> | hsivonen: You should make your processor incremental, so it can carry on from where it left off if it's interrupted or crashes :-) |
| 12:32 | <hsivonen> | Philip`: it didn't seem worth the trouble at firts |
| 12:32 | <Hixie> | hsivonen: i honestly can't see the difference between an editor assuming that something should be a style="" attribute instead of an <h1> attribute and an editor assuming something should say alt="" instead of alt="W3C". |
| 12:32 | <hsivonen> | first |
| 12:32 | <Hixie> | er, <h1> element |
| 12:32 | <Hixie> | in both cases it is syntactically ok either way, and in both cases it is bad for accessibility. |
| 12:33 | <hsivonen> | Hixie: when you select text and choose "Heading 1", it becomes a <h1> in an operation that's atomic in a GUI |
| 12:33 | <hsivonen> | Hixie: inserting an image and entering alt isn't atomic without modal dialogs |
| 12:34 | <annevk> | you could have several insert image operations |
| 12:34 | <annevk> | insert decorative image, insert content image, etc. |
| 12:34 | <Hixie> | hsivonen: so? inserting a link is also not "atomic without modal dialogs". |
| 12:35 | <Hixie> | hsivonen: i'm not saying that you need to ask for alt="" or href="" when you insert the image or link |
| 12:35 | <Hixie> | hsivonen: i'm just saying that it's fine for the UA to make assumptions as part of its UI |
| 12:35 | <Hixie> | hsivonen: e.g. that images are decorative unless told otherwise |
| 12:35 | <Hixie> | hsivonen: or taht font size changes mean style="" attributes and not <h1> or <h2> or <small>, unless told otherwise |
| 12:35 | <Philip`> | You could have a modeless dialog box that requires you to select an image and type in some alt text, before clicking or dragging or something to insert it into the page, and there's no need to modally block all other interaction while you're doing that |
| 12:35 | <hsivonen> | Hixie: when a user inserts a link, the user would fail the primary goal of the operation if the URL wasn't supplied |
| 12:36 | <Hixie> | hsivonen: let's back up. what is your fundamental objection? |
| 12:37 | <Hixie> | because right now i'm agreeing with everything you say, so we're clearly off the controversy. |
| 12:37 | <hsivonen> | My fundamental objection is that given the current state of HTML generating programs, there's a case where a user can put a program in a state that can't be serialized without either violating the file format syntax or without stuffing junk |
| 12:39 | <hsivonen> | unless, of course, we assume that the UI should block users from inserting images without there being a heading |
| 12:39 | <Hixie> | so you believe it is inappropriate for an editor to assume that images are decorative unless told otherwise? |
| 12:39 | <hsivonen> | or from removing a heading if there are images |
| 12:39 | <hsivonen> | Hixie: yes |
| 12:39 | <Hixie> | hsivonen: why? |
| 12:40 | <Hixie> | (note: statistically, most images are decorative) |
| 12:40 | <Hixie> | (according to some studies i was looking at earlier, anyway.) |
| 12:40 | <hsivonen> | because then users who don't see images aren't alerted about relevant presence of non-decorative images authored with such UI |
| 12:42 | <Hixie> | do you therefore also think it is inappropriate for an editor to assume that when the user says "font size bigger", he wants a style="font-size:2em" attribute instead of an <h1> element, even if the user is really changing the font size of his headers? |
| 12:42 | <hsivonen> | otoh, if the conclusion is that users don't need to be alerted about that, and the distinction in current UAs between empty alt and no alt is useless, then this has been a rather veiled conclusion |
| 12:42 | <Hixie> | i do not believe that the distinction in current UAs between empty alt and no alt is useless |
| 12:42 | <hsivonen> | I think it is inappropriate to map UI that says "bigger" in words or icons to <h1> |
| 12:43 | <Hixie> | but surely if we don't mark up these headers as headers, then users who don't see css aren't alerted about relevant presence of headers authored with such UI |
| 12:44 | <Hixie> | and based on the usability studies i was looking at earlier, users of ATs navigate using headers far more than they look for images. |
| 12:44 | <hsivonen> | yes |
| 12:44 | <Hixie> | i don't understand the difference. |
| 12:45 | <hsivonen> | the presence of the text doesn't get hidden when marked up as big |
| 12:45 | <hsivonen> | the presence of the image gets hidden when marked up as alt="" |
| 12:46 | <Hixie> | for all intents and purposes, the presence of headers gets hidden when marked up as big. AT users don't just read the page, they navigate by headers and then spot read around them. |
| 12:46 | <hsivonen> | as far as I can tell, we've now gotten back to where HTML 4.01 was |
| 12:46 | <Hixie> | they only very rarely read the whole page through. |
| 12:47 | <Hixie> | we are where HTML4 was, except that it is possible for flickr and your image report tool to be conforming, yes. |
| 12:47 | <zcorpan> | " Line 1, Column 24: RCDATA element nu.validator.htmlparser.impl.ElementName@1c1ace8 contained the string </, but this did not close the element.." |
| 12:47 | <Hixie> | (and except for the spec having examples of good alt text. a lot of examples.) |
| 12:47 | <hsivonen> | and with HTML 4.01, we don't have ATAG 2.0 (comprehensibly) telling generator agent developers to emit alt="" |
| 12:48 | <Philip`> | Authoring tools don't know whether the author intended text to be a header or intended it to just be bigger, so they can't indicate the difference in the markup; but they do know whether the author intended an image to be decorative or just didn't think about it at all, so they could indicate that in the markup, except they can't because HTML5 doesn't allow that distinction, so information is lost |
| 12:49 | <Philip`> | which seems to be a difference between those cases |
| 12:49 | <Hixie> | they only know that the user didn't bother because they give the option to the user of saying decorative vs not decorative, but they also give the user the option of saying header vs paragraph, so i don't think the distinction is valid |
| 12:50 | <hsivonen> | zcorpan: thanks |
| 12:51 | <hsivonen> | Hixie: anyway, I'm too tired to keep insisting that the distinction be made |
| 12:51 | <Hixie> | fair enough |
| 12:52 | <hsivonen> | Hixie: I would like to see comprehensible and honest guidance for generator agent authors, though, saying that they should rather do alt="" than junk like alt="file/path.jgp" |
| 12:52 | <Hixie> | imho it is quite possible to make non-modal ui that encourages alternative text to be given, e.g. by having text inputs hover over images where alt text is not yet given, with a little button to be used if hte image is really decorative |
| 12:52 | <Hixie> | yeah adding suggestions for this would be useful |
| 12:54 | <hsivonen> | if the ATAG people as a WG agreed with this conclusion, though, one would think they'd written it down comprehensibly |
| 12:55 | <hsivonen> | Hixie: that is, "if the markup generator does not have a text alternative available, it should generate ..." |
| 12:56 | <hsivonen> | where I assume "..." ends up being "alt=''" |
| 12:57 | <Hixie> | noted |
| 12:57 | <Hixie> | me sleep now |
| 12:57 | <Hixie> | nn |
| 13:15 | <zcorpan> | am i the only one getting tired of garret smith? |
| 13:18 | <annevk> | no |
| 13:23 | <hsivonen> | Hixie: your reply to Manu Sporny made sense from the Google point of view |
| 13:24 | <hsivonen> | Hixie: however, if state of the art was the same on handheld devices (i.e. without a lot of processing against a large repository of previous data), surely we could do away with <h1>? |
| 13:43 | <zcorpan> | hsivonen: you could use aria-describedby instead of <label> for your select box (that replaces the label "Document") to avoid the focus problem |
| 13:45 | zcorpan | notes that aria keywords are in the opposite direction of accessibility api keywords |
| 13:45 | <zcorpan> | e.g. aria-labelledby vs RELATION_LABEL_FOR |
| 13:46 | <zcorpan> | hsivonen: oops, i meant aria-labelledby, not aria-describedby |
| 13:48 | <hsivonen> | zcorpan: ok. |
| 13:48 | <hsivonen> | I don't have a way to test though. I can't get Orca to work with my keyboard |
| 14:12 | <BenMillard> | damn, I just noticed the purpose of <address> and the difference between <ul> and <ol> has been discussed here in recent days but I missed it all :( |
| 14:14 | <zcorpan> | hsivonen: hmm. multiline <script> doesn't work in livedom in opera. wonder why |
| 14:15 | <hsivonen> | zcorpan: could it be that Opera puts CRLF in the DOM but Gecko and WebKit put an LF there? |
| 14:16 | <annevk> | could be |
| 14:16 | <hsivonen> | if so, it could be my bug |
| 14:16 | <annevk> | well, browser incompat is a bug too |
| 14:17 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cscript%3Efoo%0D%0Abar%3C%2Fscript%3E%3Cscript%3Ew(document.getElementsByTagName('script')%5B0%5D.textContent.replace('%5Cr'%2C'%5C%5Cr').replace('%5Cn'%2C'%5C%5Cn'))%3C%2Fscript%3E |
| 14:17 | <zcorpan> | that's it |
| 14:18 | zcorpan | files a bug on opera |
| 15:03 | Philip` | sees that http://blogs.msdn.com/ie/archive/2008/08/25/privacy-beyond-blocking-cookies-bringing-awareness-to-third-party-content.aspx links to the #whatwg IRC logs |
| 15:10 | <annevk> | MS is watching you :D |
| 15:13 | <Xenos> | Hm :p |
| 15:30 | <zcorpan> | i wonder when we get a bug saying that doesn't work with an "-//W3C//DTD XHTML+RDFa 1.0//EN" doctype |
| 15:31 | <hsivonen> | I'm seeing mixed messages about the expected future browser-sensitivity of RDFa by RDFa proponents |
| 15:35 | <hsivonen> | I've learned various things from trying to validate a million documents |
| 15:35 | <hsivonen> | 1) Jing leaks memory |
| 15:35 | <hsivonen> | 2) parser bugs get exposed |
| 15:36 | <hsivonen> | 3) the results take more space than expected |
| 15:36 | <hsivonen> | 4) HFS+ sucks |
| 15:36 | <hsivonen> | 5) Time Machine is brittle |
| 15:37 | <hsivonen> | 6) Apple's Java 6 has a weird classloader bug |
| 15:46 | <Dashiva> | "In this scenario Charlie is making a mistake, and treating strings that look like URIs as if they had other properties of URIs." |
| 15:46 | <Dashiva> | How is this any different for namespace URIs? |
| 15:57 | <gsnedders> | Hixie: That'd be easier if I had any knowledge of C :) |
| 15:59 | <Philip`> | gsnedders: C is just like JavaScript - it's got curly braces and everything |
| 15:59 | <gsnedders> | Philip`: :) |
| 15:59 | <gsnedders> | OK, I was exaggerating. |
| 15:59 | <gsnedders> | I have some knowledge of C. |
| 15:59 | <gsnedders> | Just almost none. |
| 16:01 | <Dashiva> | Just use something that compiles to C |
| 16:02 | gsnedders | notes he already has an almost release-ready version in Python, and doesn't care to rewrite it |
| 16:02 | <Philip`> | Use JavaScript with a JIT and then extract the compiled code from memory and disassemble it and decompile it to C |
| 16:03 | <Dashiva> | Use parrot |
| 16:03 | Philip` | made a C-to-Parrot compiler once |
| 16:03 | <Philip`> | (called Carrot) |
| 16:03 | <Philip`> | (but never released since I got bored before it worked quite properly) |
| 16:04 | <Philip`> | (but it was able to compile somebody's Coke-to-Parrot compiler which was written in C, and run that in Parrot) |
| 16:19 | <Lachy> | does anyone here have experience with ruby? |
| 16:19 | <Lachy> | I need to install libxml-parser-ruby1.8 on Mac, but I can't figure out how? |
| 16:56 | <codedread_> | Hixie: quick question - is it better for me to raise a bug with the HTML spec by using the W3C Bug / Issue Tracking Service, or is an email ok ? |
| 16:58 | <gsnedders> | codedread_: If anything, he'd prefer email |
| 16:58 | <codedread_> | ok, thanks |
| 16:58 | <zcorpan> | codedread_: i believe he's said that he'll guarantee response if sent to bugzilla or the whatwg mailing list, and that he prefers email |
| 16:59 | <codedread_> | zcorpan - thanks |
| 16:59 | <gsnedders> | (He didn't say how soon that response would be, though) |
| 17:01 | <zcorpan> | gsnedders: statistically of all issues i've raised, the issues i've raised in bugzilla have been addressed a lot quicker than those i've raised in email :) |
| 17:02 | <gsnedders> | Lies, damned lies and statistics! |
| 17:07 | <Philip`> | zcorpan: If your issues have been addressed quicker, that means hundreds of other people's issues have been delayed, so it is very selfish of you, and you should instead work out how to raise issues so that it will take two or three years before they're addressed |
| 17:10 | <zcorpan> | Philip`: i'm a selfish person |
| 17:27 | <Philip`> | http://developer.yahoo.net/blog/archives/2008/08/rdf_xslt_and_the_monkey_makes_3.html - "<dc:identifier>http://www.nytimes.com/2008/05/26/business/media/26link.html?_r=1&oref=slogin</dc:identifier>"; - alas for ampersands |
| 17:28 | <zcorpan> | Philip`: markup is hard |
| 17:29 | <Philip`> | Hmm, and the second half of that blog post is in fixed-width font, presumably because they forgot a </code> somewhere :-( |
| 17:30 | zcorpan | rests his case |
| 18:06 | <Philip`> | krijnh: Do you know where all the search.live.com referrers to the IRC logs are coming from? They claim to have URLs like http://search.live.com/results.aspx?q=joins which is weird since your page isn't high in a search for that term and since it's less crufty than real search URLs would be |
| 18:11 | <gsnedders> | If you want weirdness, look at what my site gets. |
| 18:11 | <gsnedders> | :) |
| 18:14 | <Philip`> | gsnedders: That's just weird people, which is different to weird URLs :-) |
| 18:14 | <gsnedders> | Philip`: "32" — that found my site. |
| 18:16 | Philip` | sees a page that uses <!--googleoff: snippet-->...<!--googleon: snippet-->, and wonders if that's something that should be addressed by HTML properly |
| 18:17 | <Philip`> | Hmm, looks like it's only used by the Google Search Appliance, so it's not really a web thing |
| 18:58 | <takkaria> | hsivonen: did you use my dmoz.org fetcher thing at all or did you roll your own? |
| 19:58 | <jruderman> | aboodman! |
| 19:58 | <jruderman> | <3 greasemonkey |
| 20:41 | <billyjack> | hsivonen: you around? |
| 21:08 | <BenMillard> | gsnedders, did you talk to smedero? |
| 21:08 | gsnedders | looks innocent |
| 21:08 | <gsnedders> | No. |
| 21:08 | smedero | waves |
| 21:08 | <gsnedders> | smedero: Decide when you're going to be at the TPAC! |
| 21:08 | <smedero> | I'll be in France for the entire week. |
| 21:08 | <BenMillard> | smedero, I take it you and gsnedders will be sharing a room? |
| 21:09 | <smedero> | hrm, that seems to be the plan so far. What is the occupancy size of the room? |
| 21:09 | <smedero> | I'm all for cutting costs. |
| 21:09 | <gsnedders> | smedero: Yay! You've decided! |
| 21:10 | <jmb> | decisiveness is overrated |
| 21:10 | <BenMillard> | smedero, if it's OK I'd like to tag along with you two from Wedesnday to Friday |
| 21:10 | <BenMillard> | the form has a "Number of persons" field so I imagine there are 3-person rooms? http://www.w3.org/2008/03/TPAC2008-hotelform.html |
| 21:10 | <smedero> | of course. |
| 21:10 | <gsnedders> | BenMillard: I'm sure we can give you the floor. |
| 21:11 | <gsnedders> | Molly said there were three person rooms, FWIW |
| 21:11 | <BenMillard> | cool |
| 21:11 | <BenMillard> | I can bring a PS2 (PAL) with Gran Turismo games to sweeten the deal :) |
| 21:11 | <gsnedders> | I can bring some games too |
| 21:11 | <smedero> | That was my somewhat shoddy memory of the rooms situation as well... |
| 21:11 | gsnedders | has no memory of any TPAC :D |
| 21:11 | <BenMillard> | hotels usually have a TV and, since it's europe, I expect they'll have that 3-cable connection system |
| 21:11 | <BenMillard> | s/hotels/hotel rooms/ |
| 21:12 | <gsnedders> | or SCART |
| 21:12 | <gsnedders> | who knows? |
| 21:12 | <smedero> | I stayed with friends at the last TPAC.... yay free. |
| 21:12 | <BenMillard> | I stayed in a hotel for the November 2007 one...paid for by Google :P |
| 21:12 | <gsnedders> | I couldn't get anywhere to stay last year :( |
| 21:12 | <gsnedders> | (Due to being under 18) |
| 21:12 | <gsnedders> | And everyone already having arrangements |
| 21:13 | <smedero> | I think we only met briefly Ben.... I saw your presentation on the table data and we we're probably in a few hallway chats... but I doubt you'd remember me. |
| 21:13 | <gsnedders> | If you want a room with three beds, which box do you tick? |
| 21:13 | <gsnedders> | smedero: What day are you arriving? |
| 21:14 | <BenMillard> | smedero, have you a photo online? that might job my memory... |
| 21:14 | <smedero> | Ideally Sunday... still working out Flights. |
| 21:15 | smedero | looks for the usual scruffy photo.... |
| 21:15 | <gsnedders> | smedero: I'll just stay in Cannes for a day or two before I arrive |
| 21:16 | <BenMillard> | smedero & gsnedders, this is somewhat out of date but I've not changed much: http://projectcerbera.com/me/me.jpg |
| 21:16 | <smedero> | well, there's this I guess: http://www.gravatar.com/avatar/d527b871fc097b317f7993bdac0d349e?s=128 |
| 21:16 | <gsnedders> | http://flickr.com/photos/tags/gsnedders/ |
| 21:16 | <gsnedders> | Take your pick. |
| 21:16 | <BenMillard> | semedero, you look like Zane Lowe! |
| 21:16 | <zcorpan> | i've found a number of bugs in the validator.w3.org front-end of validator.nu |
| 21:17 | <gsnedders> | jgraham's is probably the best recent one |
| 21:17 | <smedero> | BenMillard: hahahaha |
| 21:17 | <gsnedders> | Expect my hair to be even crazier by October though. |
| 21:17 | <BenMillard> | gsnedders, ah the curly one |
| 21:18 | <smedero> | Ooers, to get the w3c discount I've got send that form soon. |
| 21:18 | <BenMillard> | I've not sent mine yet |
| 21:19 | <gsnedders> | BenMillard: your what? |
| 21:19 | <BenMillard> | the form smedero is talking about (I think): http://www.w3.org/2008/03/TPAC2008-hotelform.html |
| 21:19 | <gsnedders> | Ah |
| 21:19 | <smedero> | indeed |
| 21:19 | <gsnedders> | How do we deal with that? |
| 21:20 | <gsnedders> | Do we just send one, or…? |
| 21:20 | <BenMillard> | the homepage for the meeting is here: http://www.w3.org/2008/10/TPAC/Overview |
| 21:21 | <BenMillard> | smedero, I agree we should get this done sooner rather than later...I just saw "The discounted room rates are available until 8 September 2008." |
| 21:23 | <gsnedders> | hmm¬ |
| 21:23 | <gsnedders> | *hmm… |
| 21:23 | <gsnedders> | "Rooms at this hotel can accommodate up to 2 person" |
| 21:23 | <BenMillard> | oh, where does it say that? |
| 21:23 | <gsnedders> | Trying to book a room directly at <http://www.pullmanhotels.com/pullman/fichehotel/gb/pul/1168/fiche_hotel.shtml>; |
| 21:24 | <BenMillard> | Find in Page doesn't pick that text up for me.. |
| 21:25 | <gsnedders> | Start to try and make a booking |
| 21:25 | <gsnedders> | Look at the first page |
| 21:25 | <BenMillard> | aha |
| 21:25 | <BenMillard> | http://www.pullmanhotels.com/gb/reservation/rooms-dates.jshtml |
| 21:26 | <gsnedders> | Hmm… |
| 21:26 | <BenMillard> | so much for that idea, then :( |
| 21:26 | <gsnedders> | "Unfortunately, no room with twin beds is available at this date. We suggest you consult the rates for a room with double bed." |
| 21:27 | <gsnedders> | Oddly, cheapest average room rate per night for six nights starting on the 19th, 149EUR, less than the W3C rate :\ |
| 21:28 | <smedero> | heh |
| 21:28 | <gsnedders> | But that doesn't include breakfast |
| 21:28 | <Xenos> | And W3C breakfasts must be experienced to be believed ;-) |
| 21:28 | <gsnedders> | Inc. breakfast we're up to 189EUR |
| 21:29 | <gsnedders> | Still less than the W3C rate. |
| 21:29 | <Xenos> | They're totally worth 80 euros |
| 21:29 | <Xenos> | (The chef doesn't spit in those) |
| 21:30 | <gsnedders> | Xenos: :P |
| 21:30 | <BenMillard> | €362.33 per night (€1,089.40 total) is the best I can find for Wedesday 23rd to Friday 25th :( |
| 21:30 | <BenMillard> | directly at the hotel, that is |
| 21:31 | <gsnedders> | eeek. |
| 21:32 | <Xenos> | Man. If politics were as easy as getting "Insightful" on Slashdot I'd be world dictator in a week. |
| 21:32 | <zcorpan> | aaronlev: i tried to send an email to aria-ua-impl but it bounced |
| 21:33 | <Xenos> | ... But then, so would everyone else, and we'd have to fight it out with tanks and nukes and stuff. So it might be just as well |
| 21:37 | <BenMillard> | gsnedders, good news is I have an adaptor for their plug type |
| 21:37 | <BenMillard> | train links seem adequate, so that's probably who I'll get there |
| 21:37 | <BenMillard> | *how |
| 21:37 | <BenMillard> | my mobile phone was brilliant in the USA, so I expect that will Just Work |
| 21:38 | <BenMillard> | and in Germany, too |
| 21:41 | <gsnedders> | BenMillard: It's not Britain, so of course train links are sane. |
| 21:45 | <Hixie> | hsivonen: i think it makes sense to have a middle ground with widely understood vocabularies where lying and abusing the structure can't cause much damage |
| 21:53 | <Hixie> | the responses in http://groups.google.com/group/microformats/browse_thread/thread/bd08f236b5dd1d13/08ea9b2b9f6dd911?hl=en&q=html5#08ea9b2b9f6dd911 are accurate |
| 21:58 | <gsnedders> | Does @id on input serve any use? |
| 21:59 | <BenMillard> | gsnedders, <label for>? |
| 22:00 | <gsnedders> | Ah. |
| 22:00 | <gsnedders> | I thought I was forgetting something obvious :) |
| 22:00 | <BenMillard> | sometimes as a styling hook in the absence of certain selectors in IE |
| 22:01 | <BenMillard> | or a scripting hook, equally |
| 22:03 | <gsnedders> | <textarea name="content" id="content"> |
| 22:03 | <gsnedders> | weeee… |
| 22:03 | <gsnedders> | Taking advantage of the dumbness of spam-bots :) |
| 22:03 | <webben> | That may be over-optimistic. |
| 22:03 | <Xenos> | And making it real easy for people using screen readers :p |
| 22:03 | <BenMillard> | character reference munging is effective since spambots really *are* that dumb |
| 22:04 | <gsnedders> | webben: It isn't. |
| 22:04 | <BenMillard> | Nikita the Spider had a study on it, IIRC, trying to find it |
| 22:05 | <BenMillard> | aha: http://nikitathespider.com/articles/IngenReklamTack.html |
| 22:05 | <BenMillard> | "Obfuscation using Numeric Character References" |
| 22:05 | <gsnedders> | I don't know why I'm even bothering. form@action should be enough. |
| 22:06 | <webben> | BenMillard: interesting. last time I looked into obfuscation, I could swear I was reading about it failing. |
| 22:06 | <webben> | better than nothing either way though |
| 22:06 | <rubys> | Tiny nit, section 8.1.1; the doctype is case-insensitive in html5, but not in xhtml5. |
| 22:07 | <gsnedders> | rubys: 8.1 is specific to text/html |
| 22:08 | <Hixie> | i thought we said that explicitly somewhere, but i see we don't. i'll make a note to add a note saying that the section is for text/html only and xml rules are defined in xml. |
| 22:08 | <gsnedders> | smedero: When are you leaving? |
| 22:09 | <smedero> | Saturday, 10/25 |
| 22:10 | <gsnedders> | smedero: ditto. |
| 22:10 | <BenMillard> | I anticipate sending my W3C reservation form tomorrow |
| 22:10 | <BenMillard> | (by plain text e-mail...ftw) |
| 22:12 | <gsnedders> | I take it it is one form per room, not per person? |
| 22:17 | <BenMillard> | gsnedders, there's a "sharing with" field and a "number of persons field" so that impression seems correct |
