| 00:01 | <TabAtkins> | jwalden: Yup. There were several nice threads about it (or more properly, about the problems still inherent in the current approach). |
| 00:02 | <jwalden> | heh |
| 00:02 | <jwalden> | I might have noticed sooner if html5.validator.nu were fully up to date (not actually a complaint, more of a wink wink nudge nudge ;-) ) |
| 00:03 | jwalden | is fully aware he gets what he pays for |
| 00:37 | <roc> | what's the right mailing list to ask CORS questions? |
| 00:38 | roc | goes with public-webapps |
| 00:55 | <othermaciej> | roc: that would be the right list |
| 00:55 | <roc> | ta |
| 03:16 | <miketaylr> | was there ever an <eventsource> element? |
| 03:18 | miketaylr | is not sure why it's in remy's html5 shiv script |
| 03:19 | <inimino> | it's not supposed to have content anyway right? |
| 03:21 | <miketaylr> | yeah |
| 03:22 | <inimino> | and it was event-source |
| 03:22 | <inimino> | http://www.whatwg.org/specs/web-apps/2007-10-26/multipage/section-scripting0.html#the-event-source |
| 03:22 | <miketaylr> | aha, thx inimino |
| 07:58 | <hsivonen> | Does SPDY work with http: URLs via some triggers in a plain initial GET? or does it require a new URL scheme? |
| 08:04 | <othermaciej> | I asked the Google folks about it some time ago and they said their intention was to allow some form of negotiation (so you could use http: URLs) but that wasn't implemented yet; not sure what the current state is |
| 08:05 | <othermaciej> | one thing I don't understand is whether SPDY is symmetrically bidirectional and therefore whether it could address some of the use cases for the WebSocket protocol |
| 08:05 | <MikeSmith> | the whitepaper doesn't seem to mention anything about it either way |
| 08:06 | <othermaciej> | some people in the HyBi list seemed to think it had some sort of bidirectional nature, which seemed surprising to me, but I don't understand it in enough detail to comment |
| 08:07 | <MikeSmith> | othermaciej: it is bidirectional |
| 08:09 | <hsivonen> | It seems to me that the chances of success would be greater if it used an existing URL scheme and upgraded somehow |
| 08:09 | <othermaciej> | the server can create a stream, but I imagine that would not arise in the course of normal HTTP processing and there's no clear suggestion for how the client would reflect such a thing |
| 08:10 | <hsivonen> | though they are using SSL, so to avoid a lot of overhead, it would need to bootstrap from https: |
| 08:10 | <othermaciej> | yes, I think that is a potentially important deployment issue |
| 08:10 | <othermaciej> | otherwise, if some clients support SPDY and others do not, sites would have to duplicate their content to use it |
| 08:11 | <hsivonen> | also to cut through firewalls, you'd want to bootstrap from an existing port |
| 08:11 | <othermaciej> | worse yet, they would have to duplicate all links in the outside world, which is not possible |
| 08:11 | <hsivonen> | duplicating outside links seems like a fatal flaw if SPDY has the flaw |
| 08:11 | <hsivonen> | I'm surprised it isn't in their FAQ |
| 08:11 | <hsivonen> | it's the first question that pops to my mind |
| 08:12 | <othermaciej> | it was one of the first questions that popped into my mind too |
| 08:20 | <hsivonen> | interesting. the captioning at http://www.spreadfirefox.com/5years/en-US/ is can move away from the browser-native video controls but the captions don't show up when loading the video in a stand-alone browsing context |
| 08:21 | hsivonen | wonders if moving away is a mouseover trick with hard-coded Firefox native controls size |
| 08:21 | <hsivonen> | looks like a scripted overlaid HTML element |
| 08:50 | <hsivonen> | hmm. so the XStandard guy chose html4all as the forum for promoting his 'Why do WYSIWYG editors hate HTML5' article... |
| 08:51 | <hsivonen> | (as opposed to, say, posting about problems to public-html) |
| 08:54 | <zcorpan_> | "Each element, or in some cases the attribute of an element, requires a button or a list box on a WYSIWYG editor toolbar." - don't see any reason for that |
| 08:55 | <zcorpan_> | would probably make a pretty bad UI |
| 08:57 | <zcorpan_> | on my mom's site's admin UI, i have three "buttons": paragraph, heading, image |
| 08:57 | <zcorpan_> | actually i think i have link too but she hasn't used it |
| 08:59 | <zcorpan_> | the <footer>s are in the hand-written templates, not in the wysiwyg toolbar |
| 09:02 | <zcorpan_> | <time pubdate> is also in the template, with the date autogenerated when an article is written |
| 09:50 | <MikeSmith> | hsivonen, zcorpan_ - I added checking for all obsolete attributes to v.nu |
| 09:50 | <MikeSmith> | checked in, and synced up http://qa-dev.w3.org:8888/ |
| 09:50 | <MikeSmith> | so can test there |
| 09:51 | <MikeSmith> | I did not test every single attribute |
| 09:51 | <MikeSmith> | because there are so many of them |
| 09:52 | <MikeSmith> | but I smoke-tested it and it seems to be working as expected |
| 09:52 | <hsivonen> | MikeSmith: thanks. I'll redeploy |
| 09:52 | <gsnedders> | MikeSmith: Smoking is bad for you, have you not learnt? |
| 09:52 | <MikeSmith> | heh |
| 09:52 | <MikeSmith> | hsivonen: thanks |
| 09:54 | <zcorpan_> | MikeSmith: <a coords> gives two errors |
| 09:55 | <zcorpan_> | MikeSmith: <table bgcolor> doesn't give an obsolete message |
| 09:55 | <MikeSmith> | damn.. |
| 09:57 | <MikeSmith> | zcorpan_: thanks -- I'll take a look at it in a bit and see what I muffed up |
| 09:57 | <MikeSmith> | need to get some dinner first |
| 09:57 | <MikeSmith> | hsivonen: the diff for the Assertions.java change is here: |
| 09:58 | <MikeSmith> | http://whattf.browse.cvsdude.com/syntax/trunk/non-schema/java/src/org/whattf/checker/schematronequiv/Assertions.java?r1=475&r2=482 |
| 09:59 | <MikeSmith> | I'm not sure that's the ideal way to do it, so I'm happy to change it if you see any issues with doing it that way |
| 09:59 | <MikeSmith> | ah geez, looking at the diff I see what I missed |
| 09:59 | <gsnedders> | n00b |
| 09:59 | <MikeSmith> | heh |
| 10:00 | <MikeSmith> | well, I see why there's no error message from bgcolor at least |
| 10:00 | <hsivonen> | MikeSmith: instead of Arrays.asList, I suggest using Arrays.binarySearch on the raw array |
| 10:00 | <MikeSmith> | hsivonen: I figured you might say that :) |
| 10:00 | <MikeSmith> | hsivonen: OK, I will change that later |
| 10:01 | <MikeSmith> | hsivonen: I guess that should be significantly faster? |
| 10:01 | <hsivonen> | MikeSmith: other than that, looks good |
| 10:01 | <hsivonen> | MikeSmith: yes |
| 10:01 | <MikeSmith> | OK |
| 10:01 | <MikeSmith> | thanks |
| 10:01 | <hsivonen> | I ran the deployment script, but it seems the new version didn't actually replace the old process |
| 10:01 | <hsivonen> | I'll look into that after lunch |
| 10:02 | <MikeSmith> | hai |
| 10:08 | <zcorpan_> | <body alink> now validates |
| 10:09 | <zcorpan_> | <a methods> uses the relaxng error message |
| 10:10 | <zcorpan_> | <embed name> too |
| 10:11 | <zcorpan_> | <a urn> too |
| 10:11 | <zcorpan_> | <input usemap> too |
| 10:13 | <zcorpan_> | <object archive> |
| 10:14 | <zcorpan_> | <object code> |
| 10:16 | <zcorpan_> | <embed align> |
| 10:17 | <zcorpan_> | <input align> |
| 10:17 | <zcorpan_> | <img align src=x> now validates |
| 10:18 | <zcorpan_> | hspace and vspace on img validate too |
| 10:20 | <zcorpan_> | on object too |
| 10:21 | <zcorpan_> | and lots of other attributes that now validate |
| 10:24 | <zcorpan_> | test case http://tinyurl.com/yjvmofs |
| 11:21 | jgraham | hopes Mozilla plan to take http://limi.net/articles/resource-packages to a standards body |
| 11:23 | <gsnedders> | Does HTTP pipelining not solve most of the issues? |
| 11:24 | <jgraham> | If by solve you mean "theoretically solve but not actually work in the real world" then yes |
| 11:24 | <gsnedders> | jgraham: We do HTTP pipelining today. |
| 11:24 | <gsnedders> | jgraham: And have been shipping it for years. |
| 11:25 | hsivonen | wonders how resource packages and SPDY compare for real-world scenarios |
| 11:25 | <jgraham> | Yeah but I wonder how complex our heuristics have to be for detecting broken proxies / servers / etc. |
| 11:25 | <hsivonen> | in performance, in deployment ease, in maintenance ease and in implementability |
| 11:25 | <jgraham> | Or if we just break in those cases |
| 11:25 | <Philip`> | Why do they want a separate manifest file, rather than making browsers a bit cleverer so they download the file table at the end of the zip? |
| 11:25 | <hsivonen> | and backwards compat |
| 11:25 | <gsnedders> | We have heuristics. I could never find out/work out what they are when I was working on HTTP parsing. |
| 11:26 | <jgraham> | Philip`: Possibly an encoding issue? Or streamability? |
| 11:26 | <jgraham> | gsnedders: Right, and having [magic goes here] as part of a solution is bad |
| 11:27 | <gsnedders> | jgraham: The problem is more old severs that are dying out, AFAIK |
| 11:28 | <gsnedders> | ZIP means relying upon content-type magic, which seems bad |
| 11:28 | <gsnedders> | Also ZIP seems bad seeming most HTTP clients already have GZIP impls |
| 11:29 | <jgraham> | gsnedders: gzip only works on single files |
| 11:29 | annevk | wonders how to spec CaretPosition |
| 11:30 | <Philip`> | jgraham: Hmm, encoding sounds fun, given that zip doesn't require UTF-8 or anything |
| 11:30 | <Philip`> | and (if I remember correctly) different OSes and zip programs encode names in different ways |
| 11:30 | <Philip`> | (I think this was an issue with widgets, or something?) |
| 11:30 | <jgraham> | Philip`: You do remember correctly |
| 11:30 | <gsnedders> | Philip`: Yes |
| 11:30 | <Philip`> | gsnedders: Zip and gzip use the same compression algoritm |
| 11:31 | <Philip`> | gsnedders: Zip just adds a load of headers |
| 11:31 | <jgraham> | (yes it is an issue with widgets which suggests that there is at least prior art for solving it)\ |
| 11:31 | <gsnedders> | Philip`: Ah true, I always forget that Zip uses deflate |
| 11:34 | Philip` | never forgets, since after months of fruitless investigation he happened to realise that Age of Empire's main data file looked very much like the content of a zip file, and eventually realised they were using zlib to deflate it |
| 11:37 | <Philip`> | s/Empire's/Empires'/ |
| 12:02 | <gsnedders> | http://rebuildingtheweb.com/en/why-do-wysiwyg-editors-hate-html5/ |
| 12:09 | <hsivonen> | also from the same site: http://rebuildingtheweb.com/en/is-html5-good-for-app-developers/ |
| 12:09 | <hsivonen> | http://rebuildingtheweb.com/en/html-spec-failure/ |
| 12:10 | <Philip`> | Some of the comments don't sound very sympathetic |
| 12:10 | <hsivonen> | also from the same author: http://xhtml.com/en/future/x-html-5-versus-xhtml-2/ |
| 12:11 | <gsnedders> | Indeed, I did remember that last article |
| 12:17 | annevk | is not too impressed with the more features = more buttons |
| 12:17 | <hsivonen> | looks like the issue of "our language is more important than yours, your language needs to change" is a central part of the DE/XML5 discussion |
| 12:18 | <hsivonen> | judging from Jirka's response |
| 12:18 | <hsivonen> | but Sam told me and Liam not to pursue discussing that aspect |
| 12:18 | <Lachy> | the more features = more buttons approach is complete crap, considering about half the buttons on that toolbar he showed should be dropped anyway |
| 12:18 | <annevk> | I'm not sure why Jirka thinks I want XML namespaces |
| 12:19 | <gsnedders> | Because XML namespaces are the hot hot sex. |
| 12:19 | <Lachy> | and it's ironic how he's whinging about the alt attribute mess, considering that much of the debate about why alt should be optional centered around making it easier for authoring tools to cope with bad or missing user input |
| 12:20 | <Lachy> | although, admittedly, the spec did get pushed into an overly complex state where conformance is dependant on a range of factors |
| 12:21 | <hsivonen> | I thought I commented on the authoring tool complexity aspect |
| 12:21 | <hsivonen> | but I didn't track if Hixie changed the spec based on my feedback |
| 12:24 | <hsivonen> | maybe I should have filed a bug for improved trackability |
| 12:24 | <hsivonen> | but I try to avoid poking the alt discussion too much. it might flare up again |
| 12:35 | <jgraham> | The fundamental problem with authouring tools is that no one has made a usable (for the average Word user) UI that rewards the correct use of elements rather than just rewarding the right presentation |
| 12:35 | <jgraham> | I don't think this situation is any worse for HTML5 |
| 12:36 | <annevk> | so far it hasn't really been shown to be possible either |
| 12:37 | <jgraham> | Indeed. That's what I mean |
| 12:37 | <jgraham> | It is beyond the state of the art in UI design. It may in fact be impossible (though I would not like to bet either way) |
| 12:37 | <Philip`> | It sounds like Vlad Alexander's goal is not to make a usable document-editing UI for average users that happens to output HTML, but to make a UI specifically for editing arbitrary HTML documents |
| 12:38 | <Philip`> | (hence needing UI features for all HTML features, etc) |
| 12:39 | <zcorpan> | i thought xstandard was supposed to be plugged into a cms, which in my world doesn't need to and shouldn't have ui for all features |
| 12:40 | <jgraham> | Philip`: A text editor is a UI for editing arbitary HTML documents |
| 12:40 | <jgraham> | It doesn't need to have any specific buttons |
| 12:42 | <jgraham> | (the article totally ignores the need for backward compatibility. Given a green field it is surely possible to design something more elegant. But we don't have a green field) |
| 12:43 | <Philip`> | We don't need backward comatibility for <time>, and could design that more elegantly |
| 12:44 | <annevk> | hmm, nuking views |
| 12:44 | <annevk> | yumyum |
| 12:44 | <hsivonen> | jgraham: the "fundamental problem" is the fundamental problem of "semantic" markup |
| 12:44 | <Philip`> | s//p/ |
| 12:44 | <jgraham> | Philip`: Yes we do, to the extent that it must not be disruptive in legacy browsers |
| 12:45 | <jgraham> | hsivonen: Indeed |
| 12:45 | <annevk> | also, caretRangeFromPoint is now caretPositionFromPoint in http://dev.w3.org/csswg/cssom-view/ |
| 12:45 | <Philip`> | jgraham: Okay, but that's fairly easy to satisfy since new elements are ignored in legacy browsers, and complex conformance requirements are irrelevant to compatibility |
| 12:46 | <jgraham> | Philip`: So if you have a better design that fufils the constraint, I suggest proposing it |
| 12:46 | <jgraham> | (the suggestions in the article mainly seem to be missing or ignore back-compat) |
| 12:47 | <annevk> | I think I'll nuke AbstractView and DocumentView (though not their members) and define things as extensions to Document and Window instead |
| 12:48 | <Philip`> | I don't have a proposal myself; I just think the issues identified with <time> in the article are not required by backward compatibility, and so the problem is that he's not proposing an alternative (not that he's ignoring backward compatibility there) |
| 12:50 | <Philip`> | (although where he does propose an alternative (for headings) he's ignoring backward compatibility, since <heading> won't be a heading in old UAs) |
| 12:51 | Philip` | thinks he is probably agreeing with jgraham |
| 12:58 | annevk | wonders why some stuff is dom-location and others dom-window-toolbar |
| 12:58 | annevk | thought there was naming scheme |
| 14:19 | <annevk> | XHR content-type fixup is a mess :/ |
| 14:20 | <hsivonen> | s/XHR// |
| 14:21 | <Philip`> | s/content-type fixup/everything/ |
| 14:29 | <annevk> | there's less to spec on the greater mess for me specifically |
| 15:27 | <annevk2> | hmm, the problem with treating text/plain resources as text/html resources is that fragment identifiers for text/plain resources will not function |
| 15:27 | <annevk2> | at least in theory |
| 15:27 | <annevk2> | the same goes (in theory again) for video resources etc. loaded directly |
| 15:27 | <annevk2> | or images |
| 15:27 | <annevk2> | hmm |
| 15:35 | <Philip`> | "Already then we knew that for dissenting opinions usually a good solution is to include both ways things can work and a switch." |
| 15:35 | <Philip`> | (about the design of XML) |
| 16:45 | <Lachy> | the parse="lax" idea doesn't seem particularly useful. It should be left entirely up to the needs of the application to determine whether to use draconian error handling, or more graceful recovery |
| 16:47 | <Lachy> | also, adding <?xml parse="lax"?> would cause a well-formedness error in XML 1.0 parsers |
| 16:49 | <jgraham__> | Yeah that part of the proposal doesn't really fly |
| 16:52 | <annevk2> | letting content authors decide seems like a bad idea |
| 16:53 | <annevk2> | except maybe in the case where you can get some perf benefits as is the case with "use strict" in ES5, but even that seems dubious |
| 18:38 | <hsivonen> | yeah, letting authors decide draconian vs. not makes no sense, as demonstrated by pages that opt into XML only in Firefox but have later added ill-formed stuff and apparently have only been tested in other browsers for the additions |
| 19:35 | <roc> | hang on |
| 19:36 | <roc> | W3C XML fans are explicitly advocating that browsers implement lax XML parsing, and furthermore that 1990s-HTML "everyone does their own thing" error recovery is just fine? |
| 19:37 | <othermaciej> | kinda weird, isn't it? |
| 19:37 | <othermaciej> | but I think if you have non-well-formed XML you are supposed to show an error somewhere |
| 19:37 | <roc> | I'm reeling |
| 19:53 | <Philip`> | othermaciej: Do you mean where it says "fatal error: An error which a conforming XML processor MUST detect and report to the application"? |
| 19:53 | <Philip`> | which is different from saying you need to make the user aware of the error |
| 19:53 | <othermaciej> | Philip`: I'm talking about interpretations of the XML spec, not the XML spec itself |
| 19:53 | <Philip`> | Oh, okay |
| 19:54 | <othermaciej> | I didn't really understand the interpretations though |
| 19:54 | <Philip`> | Following specs is clearly overrated |
| 19:54 | <Philip`> | XML would be much better if those pesky browsers went and did their own thing instead of dragging XML down with them |
| 19:57 | <hsivonen> | roc: as I understand it, the logic is that after the first WF error, it's not XML, so XML rules don't apply and anything goes |
| 19:57 | <hsivonen> | rather revisionist |
| 19:58 | <Philip`> | I don't think it's about "after" - if the document is not well-formed XML then it's not XML, regardless of whether a parser has parsed it and found the WF error |
| 19:59 | <Philip`> | If you could magically detect well-formedness errors without parsing the document, you wouldn't have to start parsing it with an XML-compliant parser |
| 19:59 | <Philip`> | and could process it in whatever non-XML way you fancy |
| 20:00 | <Philip`> | "They are free to do *almost* whatever they want -- they can't claim it was well-formed XML." - hmm, so what if I write <html xmlns="http://www.w3.org/1999/xhtml"><script>alert('This document is well-formed XML');</script><bogus markup></html>? |
| 20:00 | <othermaciej> | that would be the document, not the browser, claiming that |
| 20:01 | <roc> | I understand the position, but it's nonsense |
| 20:02 | <roc> | I don't understand the change in psychology that seems to have occurred here |
| 20:02 | <othermaciej> | it seems to go against what appeared to be the stated intent of the XML WG at the time |
| 20:03 | <hsivonen> | othermaciej: like I said, revisionist |
| 20:03 | <roc> | I have always assumed that implementing lax XML parsing in browsers would bring the wrath of W3C gods down upon our heads |
| 20:04 | <Philip`> | I imagine the gods are divided |
| 20:04 | <hsivonen> | wrath if you do, wrath if you don't |
| 20:05 | <Philip`> | You should write a patch and put it in an alpha release just to see what side people end up on |
| 20:05 | <roc> | I wonder if these lax parsing advocates understand that if browsers start accepting lax XML then there will be a race to the bottom where many or most XML processors will be forced to follow suit |
| 20:06 | <roc> | whether or not browsers claim "this is well-formed XML", authors and users who see it rendered on their screens will assume it is |
| 20:06 | hsivonen | prefers race to XML5 rather than "bottom" :-) |
| 20:08 | <Philip`> | That sounds like it would only matter if people used XML parsers to parse web pages |
| 20:08 | <Philip`> | They could instead use non-XML parsers, like they have to do today to parse web pages |
| 20:08 | <Philip`> | so it doesn't seem worse than now |
| 20:11 | <roc> | it would affect anything that browsers can render |
| 20:11 | <roc> | SVG for example |
| 20:12 | <roc> | yes, of course we should race to XML5 |
| 20:19 | <othermaciej> | if XML already gives you the freedom to do lax parsing then it seems like there should be no problem with a spec that defines a way to do it |
| 20:19 | <Philip`> | "Having unified error recovery will be excuse for content producers and can lead to producing more and more non-well-formed content." - certainly, if you have non-unified error recovery then producers will be very careful to produce valid content to guarantee interoperability, just like in HTML |
| 20:20 | <Philip`> | If HTML had always had unified error recovery rules then maybe 98% of content would be invalid, rather than merely 95% |
| 20:34 | <jgraham> | It is slightly bemusing that the official line seems to be that interoperability isn't a problem as long as you don't dare call anything malformed XML |
| 20:37 | <roc> | off-label XML |
| 20:38 | <Philip`> | Interoperability between things that don't claim to be XML processors is not a problem for XML to solve |
| 20:40 | <Philip`> | (or for things that contain an XML processor but don't claim to be using it for that document) |
| 20:41 | <Philip`> | If it's not well-formed XML, it's as irrelevant as HTML or PNG as far as the XML spec is concerned |
| 21:19 | <Lachy> | of course, that position is utter nonsense. It's just a cop out to avoid conceding the fact that well-defined error recovery for XML is needed. |
| 21:22 | <Philip`> | AryehGregor: "there would be an algorithm to make it into XML" - that's not compatible with what XML5 does |
| 21:22 | <Philip`> | e.g. for <!-- -- --> it produces a DOM that could never be produced by parsing XML |
| 22:46 | annevk2 | is meanwhile happy jgraham took over the whether-or-not-to-specify-compat-crap thread |
| 22:50 | <jgraham> | I guess I should have mentioed that Mozilla's perspecive might be somewhat influenced by the fact that they have a relatively high marketshare and a relatively mature engine |
| 22:51 | <jgraham> | So theissues I mentioned wouldn't be so much of a problem unless they ditched tracemonkey and started over |
| 22:51 | <jgraham> | (which they might want to do one day of course) |
| 22:51 | <jgraham> | anyway, time for sleeping now I think |
| 22:56 | <annevk2> | I totally agree with Brendan you can reverse engineer too much |
| 22:56 | <annevk2> | and I think Opera has done that in some cases |
| 22:57 | <annevk2> | well, we reverse engineered the wrong evil |
| 22:57 | <annevk2> | in the beginning; we're doing a lot better the last couple of years |
| 22:59 | <othermaciej> | it does seem like Mozilla is feeling their market power and therefore working with somewhat different motivations |
| 22:59 | <othermaciej> | it also seems to me like Brendan was a bit hasty to tar everything on the wiki page with the same brush |
| 23:03 | <annevk2> | You'd think that Mozilla of all organizations out there would like to make it as easy as possible to let other players enter the market, yet I see surprisingly little effort in that direction from them... |
| 23:03 | <roc> | well |
| 23:04 | <roc> | the whole thing about video codecs is about making it possible for anyone to implement |
| 23:04 | <roc> | if we didn't care, we'd just buy an H.264 license and move on |
| 23:08 | <annevk2> | True, though I suspect that's also because of the "free" angle attached to it |
| 23:09 | <roc> | I also think that out of all the major browsers, we have been the most resistant to adding random hacks for IE compat, which I like to think is because we prefer to push Web authors in the right direction |
| 23:10 | <annevk2> | I meant more in the area of properly specifying legacy features everyone has to implement (e.g. DOMParser), converging on details of legacy features (e.g. XMLHttpRequest)... |
| 23:10 | <roc> | ok |
| 23:10 | <annevk2> | We're reverting our IE hacks and replace them with Gecko hacks :) |
| 23:10 | <roc> | I will also point out we took significant pain to get rid of getBoxObjectFor |
| 23:11 | <annevk2> | I noticed that, much appreciated! |
| 23:11 | <roc> | I don't seem to be subscribed to wherever your discussion is, so I can't really comment on what Brendan said |
| 23:12 | <annevk2> | It's on public-script-coord |
| 23:12 | <annevk2> | http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/ |
| 23:12 | <annevk2> | bedtime for me though, ttyl |
| 23:12 | <roc> | ta |