| 00:03 | <Hixie> | Philip`: it could give the encoding of the TXT chunks, assuming jpeg has those :-) |
| 00:05 | <brodie> | it could have exif data with UserComment tags, but the encoding is defined in the tag |
| 00:24 | <Hixie> | you know, i think we're gonna have to define a wrapper around the xml parser in the html5 spec |
| 00:24 | <Hixie> | to handle things like application="" on the root element, and so forth |
| 00:25 | <Hixie> | oh hey, we could just use a PI and say it has to come before <?xml-stylesheet?> |
| 00:25 | <Hixie> | for XHTML |
| 00:25 | <Hixie> | though yet more differences... that would suck |
| 00:25 | <Hixie> | gah, xml makes things so much more annoying. |
| 01:26 | <Hixie> | the biggest problem with the current offline design i think is that there is a race condition the first time you fetch a page with a manifest |
| 01:26 | <Hixie> | in that as soon as the manifest is fetched, uris that aren't in teh manifest start failing |
| 01:26 | <Hixie> | but before, they work |
| 01:27 | <othermaciej_> | you could make the initial load block on the manifest, but not actually fetching the cache contents |
| 01:28 | <Hixie> | that would slow initial page load |
| 01:28 | <othermaciej> | that would be no worse than what a <script> element causes now |
| 01:28 | <Hixie> | which is unacceptable |
| 01:28 | <othermaciej> | (<script src="..."> that is) |
| 01:28 | <Hixie> | <script> is bad enough that people have mumbled suggestions that browsers should optimistically go ahead and parse past them |
| 01:29 | <Hixie> | (throwing away the results of that if the script ends up doing anything that depends on the dom) |
| 01:29 | <Hixie> | (i don't think it would work well, but that people are considering that is probably an indication that we don't want to add any more blocking things) |
| 01:30 | <othermaciej> | another (crazy) possibility is to keep parsing and even be willing to start loads but don't deliver the actual results of any loads until the manifest has been returned |
| 01:31 | <Hixie> | that could give really weird results on slow connections |
| 01:31 | <Hixie> | it would also interact poorly with the http 2-connectio-per-server limit |
| 01:31 | <Hixie> | s//n/magic |
| 01:32 | <othermaciej> | it could |
| 01:32 | <othermaciej> | I'm just trying to think of possible ways to avoid the race - I'm not sure any of them is actually preferable to the race |
| 01:32 | <Hixie> | yeah me either |
| 01:56 | <Hixie> | Andrew is arguing that google doesn't use sql as a backend and that therefore we shouldn't use sql in html5 |
| 01:56 | <Hixie> | does he realise that one of the main supporters of sql in html5 is google, to the point where google has implemented ua extensions that support sql in browsers? |
| 02:04 | <aa> | fwiw, I argued against putting sql in gears :) |
| 02:04 | <aa> | unsuccessfully |
| 02:04 | <Hixie> | heh |
| 02:04 | <Hixie> | i argued against it in html5, too |
| 02:05 | <aa> | but then, I am frequently wrong |
| 02:05 | <Hixie> | same here :-) |
| 02:05 | <othermaciej> | I don't love it either |
| 02:05 | <othermaciej> | but being there is a pretty compelling advantage vs. the hypothetical wonderfully elegant design |
| 02:05 | <aa> | does nobody love sql? |
| 02:05 | <Hixie> | it's not clear to me what would be better for solving the problem of keeping masses of structured data clientside |
| 02:06 | <othermaciej> | also I have even more distaste for object persistence systems than RDBMs |
| 02:06 | <Hixie> | yeah |
| 02:06 | <Hixie> | the fact that nobody understands object persistence systems, least of all web authors, is a big negative point against them |
| 02:07 | <othermaciej> | in fact I get the impression that most implementors of object persistence systems don't understand them |
| 02:07 | <Hixie> | indeed |
| 02:07 | <Philip`> | Judging by all the web frameworks that hide SQL behind magical object systems, people want to get away from SQL, though I'm not sure if where they're getting away to is a better solution |
| 02:08 | <Hixie> | yeah |
| 02:08 | <othermaciej> | it seems more practical to build a magical object system on top of SQL than vice versa |
| 02:09 | <Philip`> | and it's probably out of scope for an HTML group to design a better database system than what the world has already produced, and to do it in a couple of years and with too much backward-compatibility burden to be allowed a second chance |
| 02:10 | <othermaciej> | and there doesn't seem to be much consensus on how a magical object system should work |
| 02:10 | <Philip`> | That's easy - they should work like magic |
| 02:11 | <Hixie> | to be fair there's not that much consensus on how sql should work either, but i guess that compared to the object systems, there might appear to be unity :-) |
| 02:12 | <Philip`> | SQLite seems particularly consensus-ignoring in deciding that SQL's strong column types are a bug that should be fixed |
| 02:13 | <aa> | yes, who needs types |
| 02:13 | <Hixie> | no comment |
| 02:13 | <aa> | luckily it works well with javascript |
| 02:14 | <Philip`> | Will it be possible to automatically convert JS Date objects into suitable SQL values? |
| 02:15 | <aa> | since there is no 'date' type in sqlite, I don't think it would come back out the same |
| 02:15 | <aa> | but you could certainly store the number |
| 02:16 | <Hixie> | i have to admit to never using sql date types and always just storing integers representing seconds from the epoch |
| 02:16 | <Hixie> | i always seem to just get into problems when i use the sql date/time types |
| 02:16 | <Hixie> | that could say more about me than about sql or mysql, though |
| 02:17 | <Philip`> | http://www.sqlite.org/cvstrac/wiki?p=DateAndTimeFunctions - SQLite uses YYYY-MM-DD HH:MM:SS strings |
| 02:18 | <Philip`> | It's nice when you can do "select * from t where modified > date('now', '-1 day')" |
| 02:19 | <Hixie> | i've always found it more reliable to do "select * from t where modified > ?", now-1*day |
| 02:21 | <aa> | Philip`: but you wouldn't be able to drop it into a variant column and have it come back out as a js date |
| 02:21 | <aa> | which you could do, to some extent, with other js datatypes |
| 02:28 | <Hixie> | ok going for lunch. i've written up a bunch of the offline stuff in the spec, though not all. |
| 02:28 | <Philip`> | It seems you can do "create table x ( y datetime )" and SQLite will happily ignore you and make it a numeric column affinity, and the API can recover the declared column type and do some conversions when passing between SQL and JS, maybe |
| 02:30 | <aa> | oh, cool |
| 02:33 | <Philip`> | (But there's something disturbing about declaring a column as "datetime", having it treated by SQLite like "numeric", then storing "YYYY-MM-DD" text strings in it) |
| 02:39 | <aa> | hey hey chrisp |
| 09:15 | <Hixie> | lordy, now steven f is complaining that in irc chat i laugh at him. http://lists.w3.org/Archives/Public/www-archive/2007Sep/0095.html |
| 09:15 | othermaciej | reads |
| 09:16 | <Hixie> | it's strange to me that the subscribers to html4all keep talking about their being a "divide" between "them" and "us", when personally i don't care who says what, i take input to the spec regardless of its source |
| 09:17 | <Hixie> | this is especially amusing to me, though, given the whole e-mail where John was saying that their goal was "divide and conquer" of the "html5 manglers" http://html4all.org/pipermail/list_html4all.org/2007-August/000054.html |
| 09:17 | Hixie | sighs |
| 09:17 | jgraham_ | finds the email from steve quite strange |
| 09:18 | <othermaciej> | I'm sure you endeavour to do that (and I think you do a good job), but it is almost inevitable human nature to come to trust effective repeat collaborators a bit more, and be potentially a bit more open to their input |
| 09:18 | <othermaciej> | still, trying to position it as an us vs. them battle is unlikely to solve any real or perceived problems of cliquishness |
| 09:18 | <Dashiva> | Hixie: Stop dragging me down with you >:) |
| 09:20 | <jgraham_> | Oh and I'm not sure I've been keeping up with all the out-of-band communication about alt to have a well-informed opinion but the idea of requiring embedded elements that are the sole contents of a link to have textual fallback (where possible i.e. not on <embed>) seems like it might address one of the most serious criticisms of missing @alt |
| 09:21 | <Hixie> | othermaciej: i really try to avoid any bias from who wrote the input, to the point where the issues list, for instance, doesn't list any metadata regarding who wrote the e-mail |
| 09:22 | <Hixie> | othermaciej: i'm sure there is still some bias, of course, but i doubt that the bias is such that it significantly disadvantages steven f to the level that he is suggesting |
| 09:22 | <Hixie> | jgraham_: any idea if that was sent to the whatwg list or put on the htmlwg wiki? |
| 09:22 | <hsivonen> | jgraham_: requiring data that isn't available is going to result in bogus data |
| 09:23 | <jgraham_> | hsivonen: I know. I'm not clear on whether that particular case is special enough to warrant special conformance criteria though |
| 09:24 | <jgraham_> | For example on a photo page having alt="Large size photo" would at least tell you where the link goes in a way that is compatible with existing AT |
| 09:25 | <othermaciej> | I have to admit to a slight tendency to sometimes write off people who seem to be consistently non-constructive but I try to compensate for that as best I can |
| 09:25 | <othermaciej> | jgraham_: do you think a title="" on the link might be an acceptable alternative in such cases? |
| 09:25 | <othermaciej> | also, presumably if alt were required in such cases alt="" would be disallowed |
| 09:26 | <Dashiva> | othermaciej: I think in the end non-constructive people will be written off based on their non-constructive ideas, even if the idea is anonymized |
| 09:27 | <jgraham_> | othermaciej: Yeah, my other thought was to define that in the case where an image was the sole content of a link and the link had a title, the link's title would be the alt text for the image in the absence of any significant alt text (or something to that effect) |
| 09:27 | <hsivonen> | jgraham_: yes, in practice, alt text like that is probably good idea if other text isn't available |
| 09:29 | <Hixie> | hsivonen: btw for the record the significant inline thing will die, i just haven't gotten around to it yet |
| 09:29 | <hsivonen> | Hixie: good. |
| 09:29 | <hsivonen> | Hixie: did my message make sense in your opinion? |
| 09:31 | <Hixie> | hsivonen: all the messages you sent on that thread made sense to me |
| 09:33 | <hsivonen> | Hixie: good |
| 09:34 | <Lachy_> | good evening |
| 09:35 | <Lachy_> | I just got back from the W3C SIG day at Web Directions |
| 09:35 | <jgraham_> | hsivonen: BTW, I added the "Cells that span a column with no heading have no headings" option you wanted to the table inspector smart colspan algorithm |
| 09:35 | <othermaciej> | hello Lachy_ |
| 09:35 | <Lachy_> | the RDF/OWL/Semantic Web talks were interesting... |
| 09:36 | <Hixie> | (the aforementioned www-archive thread has grown) |
| 09:36 | <Lachy_> | especially when they said that they only began considering the application layer and looking for the "killer app" in 2006, and I asked what on earth was everything else developed for before those yet-to-be-developed apps? |
| 09:37 | <hsivonen> | jgraham_: hmm. http://james.html5.org/cgi-bin/tables/table_inspector.py?uri=http%3A%2F%2Fhsivonen.iki.fi%2Fthesis%2Fhtml5-conformance-checker.html&source=&algorithm=smartcolspan changed to worse :-( |
| 09:37 | <hsivonen> | jgraham_: the expected disassociation of the big abstract cell still doesn't happen |
| 09:37 | <jgraham> | hsivonen: I may have got it wrong of course :) |
| 09:37 | <hsivonen> | jgraham: but now the horizontal associations don't work |
| 09:38 | <Lachy_> | I also met Chris Wilson today |
| 09:38 | <jgraham> | hsivonen: The latter is expected as the smart colspan only looks for vertical associations |
| 09:38 | <Hixie> | Lachy_: did anyone explain how the Semantic Web was going to avoid spammers doing metadata-stuffing? |
| 09:38 | <hsivonen> | jgraham: oh. |
| 09:38 | <hsivonen> | jgraham: IIRC, clicking "Computer Science and Engineering" used to highlight "Department:", which was good |
| 09:39 | <Lachy_> | no, that topic never came up. But without any applications for spammers to exploit, there's really no problem anyway. |
| 09:39 | <Hixie> | (cos that and the question of how to get ordinary authors to output triples are the two main problems i have with the SW) |
| 09:39 | <Hixie> | Lachy_: fair enough |
| 09:40 | <jgraham> | hsivonen: I'm reasonably sure that never worked with the smart colspan thing. I'll look into why the cell isn't being disassociated this evening (it worked with your testcase) |
| 09:40 | <Lachy_> | though, one potential app that was discussed later was the use of RDF in some sort of rights policy description framwork. (that turned out to be essentially DRM, but without any kind of enforcement. That's left up to individual vendors) |
| 09:40 | <Hixie> | i thought we were busy moving _away_ from drm |
| 09:42 | <Lachy_> | yeah, some music labels are dropping it, though there are still some people and organisations that can't grasp the concept of treating customers like customers instead of criminals |
| 09:42 | <othermaciej> | so people on IRC can follow the side commentary in email: http://lists.w3.org/Archives/Public/www-archive/2007Sep/0099.html |
| 09:45 | jgraham | thinks that Steve joining IRC would be more straightforward than having a parallel conversation via email but realises this might not be possible for a variety of reasons |
| 09:45 | <Lachy_> | anyway, on a more positive note, Chris' presentation about the HTMLWG, Marcos' Widgets and Dean Jackson's SVG were intereresting |
| 09:58 | <jgraham> | hsivonen: http://james.html5.org/cgi-bin/tables/table_inspector.py?uri=http%3A%2F%2Fhsivonen.iki.fi%2Fthesis%2Fhtml5-conformance-checker.html&source=&algorithm=smartcolspan&no_headings_if_spans_data_col=1 (I think you didn't select the correct option; the UI is abysmal, so I'm not surprised) |
| 10:00 | <othermaciej> | Lachy_: cool, any highlights? |
| 10:01 | <hsivonen> | jgraham: oh. excellent. thank you. (I used the exact same setting I had used before.) |
| 10:01 | <Lachy_> | well, I spoke to Chris during lunch about Microsoft's position on HTML5 and when they would be sending their review to the HTMLWG... |
| 10:02 | <Lachy_> | Chris' biggest problems with the spec is regarding <video> (mostly because of patents) and <canvas>, because he claims that not within the charter. |
| 10:03 | <Lachy_> | he send he would be focussing on reviewing the spec and send it shortly, but couldn't be any more specific about when |
| 10:03 | <othermaciej> | I suppose it would be stating the obvious to point out that these are two areas where proprietary technologies dominate on the web due to inadequacy of current standards-based alternatives |
| 10:05 | <Lachy_> | he also had a problem with the accessibility of canvas, but I didn't get a clear response when I said it was just as accessible as static images - alternate content can and should be provided elsewhere. |
| 10:07 | <othermaciej> | it does seem that scene-graph based solutions could have an advantage in cases where interaction is desired (at least for clicks that do simple activation - not so much for more freeform interaction) |
| 10:08 | <othermaciej> | maybe it would be worthwhile to have something similar to imagemaps to define interactive areas in a canvas |
| 10:08 | <othermaciej> | in a way that could be exposed to assistive technologies |
| 10:09 | <othermaciej> | it couldn't handle complex interaction cases (like the drawing area of a paint program) but it's not obvious if anything reasonable can |
| 10:10 | <Lachy_> | could this work? <canvas map=#foo></canvas> <map id=foo><area onclick=doSomeInteraction()></map> |
| 10:11 | <othermaciej> | you'd want a decent API to programatically alter the <area>s and probably also the ability to define one with a general bezier path |
| 10:12 | <Lachy_> | maybe, but maybe possible that SVG could probably solve those use cases better than canvas, since you can already attach events to any shape or path |
| 10:13 | <othermaciej> | that is true, though you would need role="" or similar to expose those to assistive technologies reasonably |
| 10:15 | <Lachy_> | oh, Dean Jackson showed off a really cool app built with SVG and <video> running in recent internal build of Safari |
| 10:17 | <othermaciej> | we have an html <video> implementation checked in on a branch in the open source webkit tree but we haven't really publicized it much yet |
| 10:17 | <Lachy_> | yeah, that's what he told me |
| 10:17 | <othermaciej> | which reminds me that I need to wrangle up our implementation feedback because we have some changes to suggest |
| 10:18 | <hsivonen> | Desktop platforms don't ban direct-draw 2D graphics APIs for accessibility reasons. Instead, they provide low-level accessibility APIs. |
| 10:19 | <hsivonen> | Likewise, HTML shouldn't ban direct-draw 2D graphics but should provide a low-level accessibility API (<canvas> subtree with ARIA) |
| 10:19 | <Lachy_> | I'd prefer to find something simpler than ARIA if possible |
| 10:21 | <othermaciej> | extending image maps seems potentially easier to use and also possibly useful for other reasons in addition to accessibility |
| 10:21 | <othermaciej> | (and could also be used in conjunction with ARIA) |
| 10:23 | <othermaciej> | I guess it depends on whether trying to actually manage the clickable areas is more likely helpful or annoying |
| 10:24 | <hsivonen> | forcing people to use a scene-graph-based solution (SVG) solves very little if the author doesn't make an effort to take care of accessibity (using ARIA, etc.) |
| 10:24 | <othermaciej> | SVG at least lets you use <a> elements in your scene graph so you could get built-in link semantics |
| 10:25 | <othermaciej> | but of course this would not cover other forms of interaction |
| 10:26 | <hsivonen> | yeah, the main benefit of the scene graph is that doing VoiceOver-style correlation of the visual point of interest and the aural point of interest comes "for free" |
| 10:27 | <hsivonen> | whereas walking the <canvas> subtree could give a JAWS-like result that doesn't highlight the corresponding part of the visual <canvas> |
| 10:27 | <othermaciej> | which an image map style approach could hypothetically solve at least for simple cases |
| 10:27 | <othermaciej> | though unclear if authorability would be acceptable |
| 10:42 | <Hixie> | it's not clear to me how the use cases of <canvas> (as opposed to SVG) can really be made accessible at all |
| 10:42 | <Lachy_> | I think we need to document the use cases for interactive canvas that could possibly be made accessible. Yahoo Pipes would be one, since, AFAIK, there's no way to draw pipes and add components without a mouse. |
| 10:42 | <Lachy_> | though I'm not entirely sure how that could be done without a complete separate UI |
| 10:42 | <Hixie> | those being graphical games, graphical image manipulation, and things like fractal visualisation |
| 10:43 | <Hixie> | the pipes in yahoo pipes could be trivially done using some simple text with links inside the canvas, as far as i can tell |
| 10:43 | <Hixie> | but yeah, seems like you'd want a separate ui for that |
| 10:45 | <Lachy_> | I doubt something like CanvasPaint could be made accessible to a blind user, since one needs to see in order to paint. Though, it could be made accessible to a keyboard user using cursor keys |
| 10:46 | <Hixie> | that doesn't require anything to do with aria |
| 10:46 | <Hixie> | just requires OS-level mousekeys support |
| 10:46 | <Lachy_> | indeed, cursor keys are provided by the OS |
| 10:46 | <hsivonen> | Hixie: the main accessibility problem with <canvas> is that it can be used to implement the visual part of use cases that theoretically should be done in SVG. |
| 10:46 | <Hixie> | hsivonen: just like <table> elements can be used to implement the visual part of use cases that theoretically should be done in CSS |
| 10:47 | <hsivonen> | Hixie: that is, <canvas> is low-level, and low-level APIs make it easier to do the wrong thing |
| 10:47 | <Hixie> | except maybe not quite as harmful |
| 10:47 | <Hixie> | yup |
| 10:47 | <karlUshi> | opening pandora's box |
| 10:47 | <Hixie> | just look at how ajax is used to replace static sites |
| 10:47 | <Hixie> | by loading pages dynamically |
| 10:47 | <Hixie> | man that is annoying |
| 10:48 | <hsivonen> | karlUshi: however, if there's enough demand for pandora's box to be opened, competing proprietary technologies will open it |
| 10:49 | <hsivonen> | (or have opened it already) |
| 10:50 | <karlUshi> | oh yes, for sure. But it doesn't mean you have to go down the path with everyone. Only a few people care about ecology that doesn't mean we should stop fighting massively used technologies which create global warming. :) There is a tension between the two, find the right balance is the key. |
| 10:51 | <Lachy_> | yeah, it's better to provide authors with the keys to open the box instead of letting them break it open with a crowbar |
| 10:51 | <othermaciej> | it does seem that most uses of canvas are either non-interactive or not fixable with scene-graph type solutions |
| 10:51 | karlUshi | wonders where Lachy has grown up ;) |
| 10:54 | <othermaciej> | but if there are cases where it's called for, I think the right solution would be to add some suitable low-level accessibility mechanism rather than drop canvas |
| 10:55 | <hsivonen> | any ideas how to prevent people from abusing "show source" as an open proxy? |
| 10:56 | <hsivonen> | in an online validator, that is |
| 10:57 | <Lachy_> | what's the problem with that and why would authors try to anyway? |
| 10:57 | <Lachy_> | s/authors/uses/ |
| 10:57 | <Lachy_> | *users |
| 10:57 | <othermaciej> | does that show the source as source, or attempt to render it? |
| 10:58 | <hsivonen> | Lachy_: for all the reasons why people seek open proxies: to cover their tracks accessing contraband |
| 10:59 | <hsivonen> | othermaciej: it dumps the source as content, but a smallish script could be written to feed the result as renderable to a browser |
| 11:02 | <Lachy_> | hsivonen, add a rights policy written in RDF that expresses using triples that users are not allowed to use the service as an open proxy ;-) |
| 11:11 | <Steve_> | hi all just lurking |
| 11:12 | <hsivonen> | hi |
| 11:13 | <Steve_> | its steve faulkner btw |
| 11:14 | <Steve_> | now i am able to talk i porbably won't ever get any work done :-) |
| 11:15 | <Lachy> | Hi Steve |
| 11:18 | <hsivonen> | validator.nu now supports &out=xml |
| 11:18 | <hsivonen> | expect bugs |
| 11:18 | <hsivonen> | in particular, I haven't yet bullet-proofed it against non-XML chars |
| 11:21 | <othermaciej> | hi Steve_ |
| 11:23 | <Lachy> | hsivonen, any idea why Firefox doesn't show the XML tree when I load the xml output? http://validator.nu/?doc=http%3A%2F%2Fannevankesteren.nl%2F2007%2F09%2Falt&out=xml |
| 11:23 | <hsivonen> | Lachy: the XHTML namespace |
| 11:23 | <Lachy> | oh |
| 11:28 | <krijnh> | Is it okay for a JS for in loop to return the objects in a different order than they were put in? |
| 11:28 | <krijnh> | Opera seems to do that |
| 11:29 | <Lachy> | hsivonen, why does the xml output declare xmlns:h="..." and then use <code xmlns="...">? |
| 11:30 | <hsivonen> | Lachy: I thought I'd be helping the serializer with the former but the serializer chose to do the latter |
| 11:31 | <hsivonen> | Lachy: apparently, the the Xalan serializer prefers not to alter prefixes instead of preferring to avoid new namespace declarations |
| 11:31 | <hsivonen> | krijnh: JS objects behaving as hashtables are unordered, IIRC |
| 11:32 | <hsivonen> | krijnh: at least I remember reading that JSON objects should have HashMap as opposed to LinkedHashMap semantics in Java |
| 11:37 | <Hixie> | hey Steve_ |
| 11:38 | <Steve_> | hi ian hope that our email exchange has not fixed our opinions of each other |
| 11:39 | <krijnh> | hsivonen: ah, okay |
| 11:39 | <Hixie> | steve: not on my end at least :-) |
| 11:39 | <Hixie> | Steve_: like i said in the thread, i really don't take into account where data is coming from when writing the spec |
| 11:40 | <Steve_> | hixie: me neither i would much prefer to be on good terms with people |
| 11:41 | <Steve_> | hixe: (i know i brought it up) but wanted to clear the air, anyway i didn't join the irc to continue the discussion, but to read and learn hopefully :-) |
| 11:42 | <Hixie> | :-) |
| 11:55 | <othermaciej> | krijnh: the ECMAScript spec lets for..in return the properties in any order |
| 11:55 | <othermaciej> | krijnh: however, there are sites that depend on returning them in original insertion order, at least for author-defined properties |
| 11:55 | <othermaciej> | krijnh: because that is what IE and Mozilla do |
| 11:56 | <othermaciej> | (and also Safari now too, though it didn't originally) |
| 11:56 | <othermaciej> | krijnh: so if Opera doesn't do that it is likely a bug, though not a standards-compliance bug |
| 11:57 | <hsivonen> | hmm. looks like I need to know about JS reserved words in order to sanitize callback names :-( |
| 11:58 | <hsivonen> | hmm. I wonder if real-world JS interpreters know about astral character categories... |
| 11:58 | <hsivonen> | having to know about Unicode categories in order to parse identifiers seems wasteful |
| 12:12 | <Hixie> | right, nn |
| 12:37 | <virtuelv> | Hm. I've found a site where the author actually writes sensible content that could be used with longdesc |
| 12:38 | <virtuelv> | (Meaning he writes meaningful longdesc, but doesn't provide an attribute, or a URL for the longdesc content -- he displays it in search results, though) |
| 12:41 | <Lachy_> | virtuelv, URI? |
| 12:42 | <virtuelv> | see the output of http://www.ohnorobot.com/index.pl?comic=56&s=Hypotheticals&search=Search and compare it to http://xkcd.com/248/ |
| 12:43 | <virtuelv> | Lachy_: or try searching for the title of http://xkcd.com/135/ |
| 12:44 | <Lachy_> | virtuelv, is that search actually maintained by the author of xkcd or just someone else who does it for him? |
| 12:44 | <virtuelv> | Lachy_: dunno |
| 12:44 | <Philip`> | I believe readers submit transcriptions of the comics |
| 12:45 | <Philip`> | http://www.ohnorobot.com/letsbefriends.pl - "By adding a small bit of code to your comics pages, you make it possible for yourself and your readers to transcribe each comic, quickly and accurately building your own personalized comic search engine!" |
| 12:45 | <Lachy_> | http://www.ohnorobot.com/archive.pl?comic=56&show=1&page=11 |
| 12:45 | <Lachy_> | "[untranscribed - please consider transcribing this comic!]" |
| 12:45 | <Lachy_> | see the last one listed |
| 12:46 | <virtuelv> | their idea is neatish, though |
| 12:47 | <virtuelv> | I don't, for one second, believe that web authors will ever bother with longdesc |
| 12:47 | <virtuelv> | but allowing people to transcribe and upload transcription data for an image, and put it somewhere on the web seems feasible |
| 12:48 | <Lachy_> | indeed. It's evidence that the community-based alternative content approach may work for other sites, perhaps photo sites like Flickr |
| 12:48 | <Lachy_> | and also that SEO really is an incentive for providing alt text |
| 12:48 | <hsivonen> | Lachy_: my expectations with Flickr are low |
| 12:49 | <hsivonen> | Lachy_: I've solicited tags on my photos from stranges for 14 months |
| 12:49 | <Lachy_> | yeah, I wouldn't expect a large proportion of users to contribute |
| 12:49 | <hsivonen> | Lachy_: no one has tagged my photos so far |
| 12:49 | <hsivonen> | Lachy_: my photos aren't as interesting as xkcd |
| 12:49 | <Lachy_> | where's your photo stream? |
| 12:50 | <hsivonen> | Lachy_: http://www.flickr.com/photos/hsivonen/ |
| 12:50 | <Lachy_> | hmm. that was predictable. |
| 12:50 | <krijnh> | othermaciej: Yeah, okay, but it's better not to assume any order :) |
| 12:50 | <hsivonen> | Lachy_: community work only works when the subject matter is interesting enough to create a community |
| 12:50 | <hsivonen> | the photos of a random guy generally aren't |
| 12:51 | <Lachy_> | yeah, but there are communities in flickr and popular photographers who would have a lot more viewers than yourself. |
| 12:56 | <virtuelv> | Heh. I found myself on one of hsivonen's photos |
| 12:58 | <Steve_f> | i don't hold much hope for sites like flickr to provide alt texts in many cases, i was checking the just uploaded files page on flcikr and only about 5% had soemthing in the alt that could be considered of any use |
| 12:59 | <Steve_f> | but certain tagged photo section appear to be better |
| 13:18 | <Steve_f> | hsivonen: the alts on your photos aren't too bad :-). I know that they are just a replication of the title text, but for users of AT who navigate the page via tabbing or use a keystroke (example G in JAWS) to move through images or use a links list (as all the photos arecontained within links), they don't get that replication or the association between text and the image. |
| 13:21 | <Lachy_> | I wonder, in the case of <figure><a href="large-image"><img src="thumbnail"></a> <legend>Caption</legend></figure>, ATs should probably fallback to reading the caption as the link text even though it's technically not part of the link. |
| 13:21 | <Lachy_> | I wonder if that would be possible |
| 13:22 | <zcorpan> | should be possible |
| 13:24 | <Steve_f> | if there is a relationship between them there should be no problem |
| 13:26 | <Steve_f> | i this case as the image has a functional role it should describe the traget of the link e.g larger image caption |
| 13:27 | <Steve_f> | or frontloading the unique info "caption larger image" |
| 13:56 | <Lachy_> | Hixie, yt? |
| 15:40 | <Philip`> | http://xtech06.usefulinc.com/schedule/paper/58 says "This is <span property="foaf:name">Jo Lambda</span>'s home page." - are there languages where that doesn't work, because possessives aren't just a suffix/prefix on the name? |
| 19:06 | <zcorpan> | http://www.madwebskills.net/2007/09/26/wds07-workshop-day-two/ |
| 19:12 | <Hixie> | Lachy: here |
| 19:20 | <Hixie> | zcorpan: your spec does more to explain aria than anything i have ever seen from the aria advocates in the last 3 years |
| 19:21 | <Hixie> | zcorpan: assuming you can resolve the two main big issue boxes in that spec (the ones that say what the values and attributes are and what they mean), we might actually have something that can be useful to the html5 spec. |
| 19:25 | <zcorpan> | Hixie: yeah. |
| 19:25 | <zcorpan> | Hixie: i started writing it three days ago. :) |
| 19:26 | <Hixie> | yeah |
| 19:27 | <zcorpan> | i think i'll leave the spec to rest for a bit; i have some other things to work on |
| 19:27 | <zcorpan> | but i plan to spec everything that's needed to implement it in due course |
| 19:31 | <markp> | url to said spec? |
| 19:31 | <zcorpan> | http://simon.html5.org/specs/aria-proposal |
| 19:31 | <markp> | thx |
| 19:32 | <markp> | sigh |
| 19:32 | <markp> | aaa:clusterfuck="true" |
| 19:41 | <hsivonen> | Philip`: how did you generate the SVG formulas from LaTeX? |
| 19:43 | gsnedders | wonders how to mark-up a graph |
| 19:44 | <Hixie> | zcorpan: as it stands, it's still useless, since it doesn't define what any of the values and attributes mean, which is the main problem with aria. It's certainly a step in the right direction though. |
| 19:44 | <zcorpan> | Hixie: indeed |
| 19:44 | Hixie | tries to understand the w3c's obsession with scheduling the unschedulable |
| 19:45 | <gsnedders> | MathML makes no provisions for graphs, SVG wouldn't really work with cubic graphs… |
| 19:45 | <Hixie> | regardless of what answers i give for the question of when xbl2 will exit cr, someone says it's unacceptable. |
| 19:45 | <gsnedders> | Hixie: tomorrow. kthxbai. |
| 19:47 | <hsivonen> | http://developer.mozilla.org/en/docs/ARIA_to_API_mapping |
| 19:47 | <hsivonen> | that doc seems to define the semantics by reference to MSAA |
| 19:49 | <zcorpan> | yep, i will need to research that part. i also think some things should happen in response to focus and changes to the dom, etc |
| 19:51 | bewest | is surpised no one has mentioned couchDB in the course of "why sql" re offline web apps |
| 19:58 | <Philip`> | hsivonen: From a menu item in Inkscape, which renders LaTeX to PS normally then uses pstoedit (with the '-dt' option to make fonts work, I think) to get SVG |
| 20:01 | <Philip`> | gsnedders: <canvas><table>...data...</table></canvas> and then you can even use canvas3d and get shiny reflective texture-mapped rotating graphs :-) |
| 20:01 | <gsnedders> | Philip`: oh yuck. |
| 20:04 | <Philip`> | I kind of like the automatic table-to-graph conversion in http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/index except it's not fancy enough :-( |
| 20:08 | <gsnedders> | Philip`: my physics teacher was calling bar charts the second worse type of graphs :P |
| 20:09 | <Philip`> | How else are you meant to represent frequencies of discrete values? |
| 20:10 | <Philip`> | ...apart from pie charts, which I'd guess are the first worst type of graph :-) |
| 20:11 | <gsnedders> | no, stack charts were, IIRC |
| 20:21 | Philip` | wonders if you could do something with the table header association algorithm to determine a table's structure, then automatically feed the data into PlotKit to get graphs of it |
| 20:24 | <hsivonen> | Philip`: thanks |
| 20:51 | <Hixie> | this app cache thing is going to make things SO confusing to people who list more than they should in their manigest |
| 20:51 | <Hixie> | manifest |
| 20:58 | jgraham | notes that #7 in DanC's list of things to do with RDFa is happening without RDFa and even without the author having to insert the data |
| 21:01 | <gsnedders> | can someone create GraphML? :P |
| 21:02 | <gsnedders> | (possibly as a delta spec on top of MathML) |
| 21:02 | <gsnedders> | possibly start at version 5? |
| 21:02 | <jgraham> | e.g. http://www.cl.cam.ac.uk/~aac10/escience/sciborg.html |
| 21:02 | <jgraham> | gsnedders: GraphML would be tough |
| 21:03 | <Philip`> | gsnedders: Use cases? I'm not quite sure what you want it for :-) |
| 21:07 | <gsnedders> | Philip`: graphing things like f(x) and f'(x) (for the same function). Just thinking about typing up all of my Higher Maths notes :P |
| 21:08 | <gsnedders> | Philip`: and then things in physics like the relation between pressure and the multiplicative inverse of the volume |
| 21:09 | <gsnedders> | jgraham: surely all you need to do is specify some method to link up some graphing software to MathML? |
| 21:11 | <Philip`> | What's wrong with existing solutions, like using gnuplot and outputting PNG or SVG? |
| 21:14 | <gsnedders> | Philip`: surely any export to SVG of something like an exponential curve will rely on setting points, which will therefore lessen quality somewhat? |
| 21:14 | <Philip`> | Also, it's far easier to just scan hand-written notes rather than type them in :-p |
| 21:15 | <Philip`> | s/in/up/ |
| 21:15 | <gsnedders> | Philip`: but harder to read :P |
| 21:15 | gsnedders | has hellish handwriting |
| 21:17 | <Philip`> | Just put error bars on the exponential-approximated-by-Beziers curve, since that'll be proper and physicsy |
| 21:18 | <gsnedders> | the more I think about doing it, the less easy it seems to do :P |
| 21:18 | <Philip`> | (Actually, I'd guess gnuplot always approximates with straight lines, but the same concept applies) |
| 21:19 | <gsnedders> | I got some homework for next Monday. I can't remember what. |
| 21:19 | <gsnedders> | s/next/this/ |
| 21:21 | <Hixie> | jgraham: in fact, all of 1 through 5 are... |
| 21:41 | <jgraham> | "Finally, though Ursula may not know what to make of the paul:audience predicate, she can quickly find out what this predicate means using typical RDF navigation." I have no idea what "typical RDF navigation" is... |
| 21:43 | <hsivonen> | jgraham: download some OWL? |
| 21:43 | <jgraham> | and? |
| 21:44 | <othermaciej> | meta is like cowbell |
| 21:44 | <othermaciej> | no matter how much you have, you clearly need more |
| 21:45 | jgraham | knows nothing about RDF except that most things using RDF seem to have been written under the assumption that everyone using it is exceptionally bright and into markup-based categorisation |
| 21:51 | <jgraham> | gsnedders: If all you want is a function plotting language, content MathML might get you most of the way there. If you want to do data plots as well things get harder |
| 21:57 | <hsivonen> | hmm. these XML and JSON formats I have designed waste an insane propertion of bytes in repeated element, attribute and JSON object key names |
| 21:58 | <hsivonen> | proportion even |
| 21:58 | <hsivonen> | perhaps I should investigate gzip |
| 21:59 | <kingryan> | hsivonen: or bencode? |
| 21:59 | <kingryan> | Bencode |
| 21:59 | <kingryan> | rather http://en.wikipedia.org/wiki/Bencode |
| 21:59 | hsivonen | looks |
| 21:59 | <kingryan> | like a compact less readable json |
| 22:00 | <Philip`> | Just pack all the data into a custom binary stream |
| 22:00 | <hsivonen> | kingryan: I take it that it doesn't have the off-the-shelf tool benefits nor the mindshare benefits of JSON |
| 22:01 | <kingryan> | hsivonen: correct |
| 22:02 | <hsivonen> | figuring out how to enable gzip filtering in Jetty seems more like something that software at the other end of the pipe might support |
| 22:03 | <kingryan> | yeah |
| 22:03 | <kingryan> | http://jetty.mortbay.org/xref/org/mortbay/jetty/servlet/DefaultServlet.html |
| 22:03 | <kingryan> | "gzip If set to true, ...." |
| 22:03 | Philip` | converted a game engine to use XML instead of a custom binary format for its map files, which was alright until people started making maps with thousands of trees, at ~170 bytes of XML per tree vs ~20 bytes of binary data |
| 22:03 | <kingryan> | wait, that's not an on-the-fly gzipper |
| 22:05 | <Lachy> | ha! "Use Case #9 — Publishing a RDF Vocabulary" - how does that qualify as a use case for RDF? |
| 22:05 | <Hixie> | huh, bencoding is quite nice |
| 22:05 | <Philip`> | Lachy: It's a use case for RDFa, not for RDF |
| 22:06 | <kingryan> | Hixie: it is nice, but doesn't have the popular tool support of json+gzip |
| 22:06 | <kingryan> | which gets you pretty close in terms of space savings |
| 22:06 | <Hixie> | kingryan: yeah but since it would take all of 10 lines in most languages to write a decoder... |
| 22:06 | <kingryan> | Hixie: writing the decoder isn't hard, it's getting people to install it |
| 22:06 | <Hixie> | kingryan: i like that it has bijection between values and encoded data |
| 22:07 | <kingryan> | yeah, that's nice |
| 22:07 | <Hixie> | though i can't find any definition anywhere of error handling for bencoded strings |
| 22:07 | <kingryan> | we'll looked at it for an internal project at Technorati, but ended up going with json+gzip instead |
| 22:07 | <kingryan> | there is no error handling, there is no spec |
| 22:08 | <kingryan> | other than http://wiki.theory.org/BitTorrentSpecification |
| 22:08 | <Hixie> | that's unfortunate |
| 22:08 | <Hixie> | i'm looking for a format for the manifest of offline application caches |
| 22:09 | <kingryan> | json seems like a good candidate |
| 22:09 | <Hixie> | i don't want to use json or xml, both have way too many ways of going wrong and json doesn't define error handling |
| 22:09 | <kingryan> | given that browsers tend to support i already |
| 22:09 | <Hixie> | and json is really heavy weight (though not as much as xml) |
| 22:10 | <Hixie> | i'm thinking of just having one uri per line, with # for comments, and maybe some annotation support of some kind to list the various other things we have to include |
| 22:10 | <kingryan> | so is HTML, maybe we should make a binary version? |
| 22:10 | <Hixie> | html has defined error handling now |
| 22:10 | <Hixie> | and yes, it's far too heavy weight for a manifest format |
| 22:10 | <hsivonen> | looks like my JSON serializer produces parseable JSON. yay |
| 22:11 | <Hixie> | i didn't even consider using html :-) |
| 22:11 | kingryan | points an obligatory finger at http://microformats.org/wiki/xoxo |
| 22:13 | <Philip`> | What kind of structure does the manifest need? |
| 22:13 | <Dashiva> | It seems like RDF(a) has hijacked all claims to sharing vocabularies |
| 22:14 | <Hixie> | Philip`: a list of URIs, a list of URI-prefix to URI mappings, another list of URIs distinguishable from the first, and user comments for documentation and so there is a way to force the file contents to change without changing their semantics. |
| 22:16 | <hsivonen> | validator.nu now supports &out=json |
| 22:16 | <hsivonen> | (the spec on the wiki isn't up-to-date yet) |
| 22:16 | <hsivonen> | callbacks aren't supported yet, either |
| 23:22 | <Hixie> | so |
| 23:22 | <Hixie> | if i have an opportunistic caching namespace of "http://example.com/data/"; |
| 23:23 | <Hixie> | then if i go to "http://example.com/data/a"; it'll get cached |
| 23:23 | <Hixie> | but what if i go to "http://example.com/data/";? |
| 23:23 | <Hixie> | should that match it too? |
| 23:23 | <Dashiva> | I would say yes, since it's likely to be http://example.com/data/index.html or similar in the background |
| 23:24 | <Hixie> | k |
| 23:27 | <hsivonen> | validator.nu now supports &out=json&callback=foo to get a JS callback instead of pure JSON |
| 23:28 | <hsivonen> | with IdentifierName and reserved word checks |
| 23:38 | hsivonen | wonders why Gecko and WebKit accept gzip, deflate but Opera acceps deflate, gzip |
| 23:38 | <hsivonen> | isn't gzip just deflate plus magic & CRC? |
| 23:43 | Hixie | slowly gets rid of red boxes in his work-in-progress offline section |
| 23:45 | <kingryan> | Hixie: out of curiosity, what do you use that has red boxen? |
| 23:48 | <Hixie> | i mean the red boxes in the spec |
| 23:48 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#offline |
| 23:48 | <Hixie> | (not checked in yet) |
| 23:49 | <Hixie> | nice! the silly pipes thing i have that takes a word from my blog entries and then gets a flickr picture for that word to render next to my blog picked a picture of zibibbo's! |
| 23:50 | <hsivonen> | rfc 2616 is being friendly by defining the whole q value thing for content-encodings instead of just listing the order of preference... |
| 23:52 | <kingryan> | Hixie: ah |
| 23:52 | <Dashiva> | hsivonen: Yeah, it's really intuitive and never confused anyone |
| 23:57 | <hsivonen> | opera makes use of the q facility: Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 |