| 00:30 | Hixie | wonders whether to make Storage.setItem() throw or not after all |
| 01:42 | <Hixie> | http://www.hixie.ch/specs/dom/messages/0.9 <-- proposal for a spec for sending messages between end points, including sending end points along |
| 01:56 | <roc> | uh oh |
| 01:56 | <roc> | you've invented the pi calculus! |
| 01:56 | <Hixie> | oops |
| 01:56 | <Hixie> | i didn't mean to invent anything! |
| 01:59 | <Hixie> | oops, behind schedule. gotta go. back in a bit. |
| 02:55 | <AwayEagle> | roc: not enough greek letters |
| 03:58 | <inimino> | what's the reason for target=_blank not being conforming in the current draft? |
| 03:59 | <inimino> | is it to discourage people from trying to open new windows like that? |
| 04:04 | <inimino> | because the consensus in Web-developer-land seems to be that you should use JavaScript to add them back in... |
| 04:20 | <Hixie> | using javascript to add them back in is just as invalid as having them in in thefirst place |
| 04:20 | <Hixie> | the correct thing to do is to not set target="", and let the user decide on his own what to do with links |
| 04:21 | <Hixie> | inimino: ^ |
| 04:21 | <SadEagle> | that sounds awfully polite for a website to do |
| 04:22 | <Hixie> | shocking, i know |
| 04:23 | <inimino> | Hixie: I agree, I'm just seeing people using the JavaScript approach anyway and I'm wondering if that's actually worse than just allowing it |
| 04:24 | <Hixie> | why would it be worse? |
| 04:26 | <inimino> | I was going to say it's harder for the user to configure how it's handled, but that's probably not true |
| 04:27 | <inimino> | though there are people using window.open(), which seems like it might be less configurable |
| 04:28 | <Hixie> | it's all the same code in the browser in the end |
| 04:28 | <inimino> | right |
| 04:29 | <inimino> | too bad people validate the markup and not the DOM ;-) |
| 04:29 | <Hixie> | yeah |
| 04:30 | <Hixie> | would be nice for there to be scripting-aware validators |
| 04:30 | <inimino> | yeah |
| 04:33 | <MikeSmith> | news about a new Webkit-based browser for mobile devices |
| 04:33 | <MikeSmith> | http://torchmobile.com/press/ |
| 04:34 | <MikeSmith> | Iris Browser |
| 04:34 | <MikeSmith> | George Staikos's company |
| 04:35 | <MikeSmith> | product page mentions HTML5 and canvas |
| 04:35 | <MikeSmith> | http://torchmobile.com/products/ |
| 04:35 | <SadEagle> | I don't think people involved in QtWebKit want to mention canvas :-) |
| 04:39 | <MikeSmith> | SadEagle - why's that? implementation of canvas on Qt port not work so good? |
| 04:40 | <SadEagle> | MikeSmith: last I checked, "not so good" would be quite an understatement. |
| 04:42 | <MikeSmith> | damn. I want me some canvas on mobile |
| 04:47 | <SadEagle> | may be someone can make a khtml4.0.1 build of konqueror/embedded :-) |
| 04:50 | <SadEagle> | I am sure it works pretty well. And the basics of canvas will work, too, but not things like arcs and shadows. |
| 05:16 | <Hixie> | so it ironically sucks that we now have multiple implementations of postMessage() |
| 05:16 | <Hixie> | as the ideal way of fixing some of the problems with it would involve minor (but incompatible) changes to how it works |
| 05:18 | <Hixie> | i don't suppose adam barth is here? |
| 05:18 | <Hixie> | jwalden: i assume we consider it too late to dramatically change postMessage() at this point? |
| 05:19 | <jwalden> | Hixie: depends on what "dramatically" means; adding the extra args suggested for better targeting would be simple enough, createMessageReceiver might be harder, reply() would be easy, I think |
| 05:20 | <Hixie> | well my ideal solution would be to change postMessage() from what it is now to being something that creates two endpoints as defined here: http://hixie.ch/specs/dom/messages/0.9 |
| 05:20 | <Hixie> | jwalden: which solves all the problems neatly |
| 05:20 | <Hixie> | but i understand if that's too drastic |
| 05:23 | <Hixie> | i'm tempted to say that we should solve these problems by just waiting til we introduce end points |
| 05:23 | <jwalden> | sec, fighting fire on a tinderbox |
| 05:23 | <Hixie> | hehe |
| 05:24 | <Hixie> | then the solution would be, you postMessage() a hello, then the other side checks the origin and if it likes it, postMessage()s you an ack with an endpoint, and then you check the origin yourself, and if you like it, you use the end points to communicate |
| 05:29 | <jwalden> | so, my first reaction is this interface is waaay too complicated |
| 05:33 | <jwalden> | second, the whole numbering thing just confuses me |
| 05:33 | <jwalden> | and I've implemented Unix pipes before in a toy kernel |
| 05:34 | <jwalden> | I don't think you want to bring the pipe model into the picture here, to be honest |
| 05:36 | <jwalden> | I think there's far more potential for confusion with this API than with one in which it's plain and simple message-passing, perhaps with builtin filtering mechanisms at both ends |
| 05:41 | <jwalden> | and in the end, yes, I'm pretty sure this would be too drastic not just for Mozilla but for Opera and likely WebKit as well |
| 07:00 | <Hixie> | jwalden: yeah i figured it would be too much change at this stage |
| 07:01 | <Hixie> | jwalden: the real question is whether it's a bad idea to use this on the long term as a solution for the issues raised |
| 07:01 | <Hixie> | jwalden: (i'm not sure what's complicated about the proposal, are we talking about the same thing? this is a pretty trivial api) |
| 07:20 | <webben_> | Hixie: re target, I'd tend to agree that websites should let users open links as they want, although sometimes you'd want to open a new browsing context to avoid losing application state (i.e. don't lose the users data opening a link in a multipage tax form). I think there are at least three advantages to target over window.open: it's declarative so you can easily make UI to distinguish such links (iCab does IIRC), it's simpler to author, and if |
| 07:21 | <webben_> | The biggest argument against target in particular (as opposed to against opening new windows in general) is that it shifts application behavior into a document markup layer, but HTML5 does so much of that it hardly seems like a relevant argument. |
| 07:24 | <jeremyb> | also, if i have a legit small popup open and something in the popup or an external app triggers a new page open i want the new tab to be on the main win not the popup. (fe, media player) |
| 07:25 | <jeremyb> | so maybe allow specifying that a window isn't available for new tabs unless explicitly requested by user |
| 07:25 | <webben_> | I guess it's worth remembering that plenty of content will continue to be pulled in via iframe, and need target="_top" if it wants to transition the user away from the host page. |
| 07:25 | <jeremyb> | (no idea if this is already covered by a spec but i've been bitten by it a few times recently with different sites) |
| 07:26 | <webben_> | target's horrible and basically bad practice, but it seems to be useful in certain limited but real circumstances |
| 07:26 | jeremyb | scratches head |
| 07:26 | <jeremyb> | you need to use target=_top for an iframe? |
| 07:26 | jeremyb | makes testcase |
| 07:26 | <webben_> | I think if you have a form in the iframe you do. |
| 07:26 | <webben_> | (at least) |
| 07:27 | <webben_> | it came up in #javascript the other day for someone making a facebook app |
| 07:27 | jeremyb | sees not any reason why a form would make a diff |
| 07:27 | <webben_> | That's why I say "at least". |
| 07:30 | <webben_> | it might be interesting to see if UAs could detect when state is being stored or when they're in a frame/popup context, and use that to determine whether to obey the command to open a new window |
| 07:31 | <webben_> | yep, a quick test shows it applies to A as well as FORM. |
| 07:38 | <jeremyb> | yup, webben_'s right |
| 07:38 | <jeremyb> | data:text/html,<!doctype html><p>lskfjlakj-lskjf</p> <iframe src="data:text/html,<a%2520href=%2522http://www.google.com%2522>lksjflkj</a>"></iframe> |
| 07:53 | <webben_> | ah looks like the current draft actually allows for _top etc: 'The base element can now have a target attribute as well mainly for consistency with the a element and because it was already widely supported. Also, the target attribute for the a and area elements is no longer deprecated, as it is useful in Web applications, for example in conjunction with iframe.' |
| 07:53 | <webben_> | http://www.w3.org/TR/html5-diff/#new-attributes |
| 10:07 | Philip` | sees that http://www.angelfire.com/tx/rangerexes/heritage.htm really doesn't work very well in Opera (9.2 or 9.5) |
| 10:08 | <annevk> | <table> :( |
| 10:08 | <annevk> | oh, and it's not centered in IE |
| 10:11 | <annevk> | so Firefox renders everything before <table> |
| 10:12 | <annevk> | but it's still centered then |
| 11:51 | Philip` | thinks more tree construction tests are needed, given that his code is full of 'XXX' and 'TODO' comments but still passes the current test cases |
| 11:53 | <Dashiva> | Philip`: Maybe there should be a list of such todos somewhere so it's easy to find out which testcases need writing |
| 11:55 | <Philip`> | I'm just trying to fill in the gaps myself at the moment - if I wrote down a list, I'd forget what anything meant by the time I looked at it again :-) |
| 12:00 | <annevk> | Philip`, awesome |
| 12:00 | <annevk> | we wrote our code and later added some tests on top of the 71 hixie made but that's it |
| 12:00 | <annevk> | then henri added some and we fixed some more bugs, mostly in unicode handling |
| 12:01 | Philip` | 's implementation only handles ASCII :-( |
| 12:01 | <annevk> | reminds me of arc |
| 12:12 | <virtuelv> | annevk: :) |
| 12:12 | <annevk> | "SVGSVGTextElement.getNumberOfChars() counts UTF-16 surrogates as separate characters" |
| 12:13 | <roc_> | mmmm |
| 12:13 | <annevk> | given that various languages already have surrogates build in, maybe SVG should follow? |
| 12:13 | <Dashiva> | The SVGSVG prefix seems accident-prone |
| 12:13 | <annevk> | (failure for test 69 in Opera) |
| 12:13 | <annevk> | (in Acid3) |
| 12:43 | <hsivonen> | annevk: the DOM is pretty deeply in the territory of counting UTF-16 code units |
| 12:43 | <hsivonen> | annevk: and too late to fix |
| 12:48 | <Philip`> | http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=%3C!doctype%20html%3E%3Ctable%3E%3Cp%3E%3C/table%3E - the </table> should generate implied end tags, which should imply a </p>, which should cause a table-voodoo error |
| 12:49 | Philip` | doesn't know if that can have a more significant effect than a lack of error |
| 13:11 | <annevk> | hsivonen, right, does it make sense for SVG to be different? |
| 13:12 | <hsivonen> | annevk: oh it's different? no, that doesn't make sense at all |
| 13:41 | <zcorpan_> | hmm. is it defined anywhere in the html5 spec that elements implement appropriate interfaces when put in the dom by the xml processor? or elements created with createElementNS? |
| 13:42 | <zcorpan_> | i note that the html5 parser says that elements should implement the appropriate interfaces |
| 13:43 | <zcorpan_> | perhaps it should be defined in a higher layer? like "when an element is created and it is in the html namespace, it must implement the appropriate interfaces..." or some such |
| 13:45 | <Lachy> | zcorpan_, since HTML5 is defined in terms of the DOM, it doesn't matter where the elements come from, they still implement the DOM APIs |
| 13:46 | <zcorpan_> | Lachy: so why is there a requirement in the parser about elements implementing appropriate interfaces? |
| 13:46 | <Lachy> | I don't know |
| 13:46 | <Lachy> | seems kind of redundant |
| 13:46 | <hsivonen> | zcorpan_: I think the spec needs to say that XML stuff needs to implement the right stuff |
| 14:48 | <annevk> | hsivonen, is there a summary somewhere of how DOM and ECMAScript assume UTF-16? |
| 15:13 | <annevk> | defining it at an intermediate layer seems cleaner to me |
| 16:18 | gsnedders | lets his frustration out at the httpbis wg |
| 16:21 | <gsnedders> | <http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0227.html>; |
| 16:23 | Philip` | now has 2000 lines of generated JavaScript to implement a tree constructor |
| 16:24 | <Philip`> | though unfortunately most of the lines say things like debug("TODO: ReprocessAsIf"); because I haven't implemented them yet :-( |
| 16:25 | <SadEagle> | gsnedders: User-Agents MUST ignore the user preferences? That's a nice one. |
| 16:25 | SadEagle | wonders whether someone has stats on wrong content-type w/in http headers. He surely has seen it with http-equiv |
| 16:25 | <gsnedders> | SadEagle: most of what the HTTPbis WG is working on is totally idealistic and backwards incompatible (well, compatible with conforming impls. of RFC2616, if there are any) |
| 16:26 | <gsnedders> | SadEagle: content-type or charset? |
| 16:26 | <gsnedders> | SadEagle: charset's not that widespread. The issue is with implicit charsets (like on text/xml) |
| 16:27 | <SadEagle> | I meant charset within content-type. |
| 16:27 | <gsnedders> | yeah, if it is explicitly given, it's normally right (except for one or two things, like ISO-8859-1 and GB2302) |
| 16:28 | <gsnedders> | (not GB2302, GB2312) |
| 16:29 | <annevk> | text/xml doesn't have explicit charsets |
| 16:29 | <annevk> | see RFC 3023 |
| 16:29 | <annevk> | (within the file, that is) |
| 16:29 | annevk | -> food |
| 16:30 | <gsnedders> | annevk: I mean on the actual MIME type |
| 16:30 | <gsnedders> | (i.e., parameters on the MIME type |
| 16:31 | <SadEagle> | well, I've seen e.g. <meta http-equiv="content-type:text/html;charset=utf-16"> .... encoded as ASCII. Also koi8/cp1251 messups. Now, w/meta one can claim it's html that defines it anyway, but still, I would expect the sequence in case of a misconfigured server to be: |
| 16:31 | <gsnedders> | SadEagle: that's specific to HTML, though. I'm talking in general HTTP terms. UTF-16 in meta@charset must be ignored |
| 16:32 | <SadEagle> | 1) User open a webpage, sees garbage. 2) User activates encoding auto-detection, which picks the right decoding. 3) The user keeps browsing the webpage with auto-detection (or manualyl chosen charset) "sticky", and has no problem. It seems to me that the proposal would require the user to repeat (2) every time they navigate. |
| 16:33 | <gsnedders> | yeah, it would |
| 17:04 | <zcorpan_> | hsivonen: v.nu says that <p/> is an html4-only error |
| 17:34 | <zcorpan_> | hsivonen: it seems that your encoding declaration warnings have gone amok: http://validator.nu/?doc=http%3A%2F%2Fvalidator.w3.org%2F |
| 17:38 | <Hixie> | webben: target=_top is allowed, it's only _blank that isn't. |
| 17:39 | zcorpan_ | notes that v.w.o has "Group Error Messages by type" |
| 17:39 | <webben> | Hixie: Thanks, I did note that. :) |
| 18:20 | <hsivonen> | zcorpan_: oops. thanks |
| 18:22 | gsnedders | is feeling very naïve at the moment |
| 18:22 | gsnedders | knows nowhere near enough about Python |
| 18:38 | <hsivonen> | zcorpan_: fixed. thanks |
| 19:52 | <Hixie> | jwalden: yt? |
| 19:53 | <jwalden> | Hixie: sorta; you caught me just before a phone conference actually :-) |
| 19:54 | <Hixie> | i just made a change to MessageEvent/postMessage() for security that fixed a separate problem from the one that was raised earlier |
| 19:54 | <Hixie> | i'm about to send mail to whatwg explaining it |
| 19:54 | <Hixie> | annevk: see above also |
| 19:54 | <Hixie> | basically changing message.domain and message.uri to just message.origin |
| 19:54 | <Hixie> | which is what the .uri value used to be, but without the path |
| 19:55 | <jwalden> | hm |
| 19:55 | <jwalden> | I await the explanation! |
| 19:55 | <Hixie> | :-) |
| 19:57 | <Hixie> | sent |
| 20:12 | <jwalden> | nice catch on username/password; I should have thought of that in my testing |
| 20:12 | <jwalden> | I *did* think of it once you summarized the change above, tho :-) |
| 20:12 | <Hixie> | :-) |
| 20:12 | <Hixie> | i think this, as a sideeffect, will simplify addressing one of the other problems |
| 20:13 | <Hixie> | instead of postMessage(message, [domain, [uri]]); we can just have postMessage(message, [origin]); |
| 20:13 | <jwalden> | so everything before the path, *except* for username/password, then |
| 20:13 | <Hixie> | yeah |
| 20:13 | <Hixie> | (and later make it postMessage(message, [endPoint], [origin]), since those two are type-distinguishable) |
| 20:29 | <aroben> | Hixie: what commit did this change occur in? I can't find it in the tracker |
| 20:29 | <jwalden> | I sent my response |
| 20:30 | aroben | is writing a bug report for WebKit and wants to link to the change |
| 20:30 | <jwalden> | I'll note that I originally wanted .domain to always include a port number, which would have avoided the first problem even if I'd never have noticed that we'd avoided it :-P |
| 20:30 | <jwalden> | and I definitely wouldn't have noticed the first problem |
| 20:31 | <jwalden> | I'm still a bit chagrined I missed the second |
| 20:31 | <jwalden> | GAAAAH |
| 20:32 | jwalden | gets bitten by forgetting +whatwg AGAIN |
| 20:36 | gsnedders | bits jwalden |
| 20:36 | <jwalden> | ? |
| 20:36 | <gsnedders> | *bites |
| 20:37 | <gsnedders> | jgraham: I took a good look at the treebuilders today, and I really can't work out how the etree stuff works. |
| 20:37 | <jgraham_> | gsnedders: By magic :) |
| 20:38 | <gsnedders> | :) |
| 20:38 | <gsnedders> | (i.e., I can't get DOM to work in a similar way) |
| 20:38 | <jgraham_> | What do you actually want to know? |
| 20:38 | <gsnedders> | I just don't really understand how the etree stuff works _at all_. |
| 20:39 | <gsnedders> | as in, how it works out what etree impl to use from the second param to getTreeBuilder |
| 20:40 | <jgraham_> | So, from memory, we do something like create a module-like object at runtime with a module-level variable ElementTree set to the module of the Element Tree implementation that we're using |
| 20:41 | <gsnedders> | what does getETreeBuilder() do? |
| 20:41 | jgraham_ | decides looking t the code would help |
| 20:41 | <gsnedders> | what's **kwargs? |
| 20:42 | <gsnedders> | heck, what does *arg and **arg mean? |
| 20:42 | <webben> | it's different ways of passing arguments in Python |
| 20:42 | <webben> | IIRC kwargs is named parameters |
| 20:42 | <webben> | can't remember the difference between *arg and **arg |
| 20:43 | <jgraham_> | *args means take the tuple args and expand its value as a set of arguments to a function |
| 20:43 | <gsnedders> | ah |
| 20:44 | <jgraham_> | so something like func(*(True, 3)) calls func with the args True and 3 |
| 20:44 | <gsnedders> | and ** is reference? |
| 20:44 | <jgraham_> | similarly **kwargs expands a dict kwargs as a set of named parameters to a function |
| 20:44 | <gsnedders> | ah |
| 20:44 | <jwalden> | Hixie: you didn't update initMessageEvent(NS)? |
| 20:44 | <gsnedders> | then how do you pass by reference? |
| 20:45 | <jgraham_> | so func(**{"foo":True, "bar":3}) == func(foo=True, bar=3) |
| 20:45 | <jgraham_> | gsnedders: You don't |
| 20:45 | <gsnedders> | yeah. that makes sense. |
| 20:45 | <gsnedders> | jgraham_: ah. |
| 20:45 | <gsnedders> | jgraham_: that's simple. |
| 20:45 | <jgraham_> | or rather, you always pass by _object_ |
| 20:45 | <gsnedders> | now, back to treebuilders |
| 20:48 | <jgraham_> | so something like "a = [1,2]; func = lambda x:x.append(3);func(a);print a" will print [1,2,3] |
| 20:48 | <gsnedders> | ya |
| 20:51 | <jgraham_> | gsnedders: So, getETreeBuilder is like a function to return a set of functions which are all closures over the value of ElementTreeImplementation |
| 20:52 | <jgraham_> | notice the return locals() at the end |
| 20:52 | <jgraham_> | those functions are turned into a module on the fly in getEtreeModule |
| 20:53 | <jgraham_> | This is kinda icky but I wasn't sure how else to reuse all the code for multiple etree implementations |
| 20:53 | jgraham_ | has to go eat now, will be back later |
| 20:54 | <gsnedders> | Hixie: you have <code title""> in html5, what's this meant to be? |
| 20:54 | <gsnedders> | (or is my in-head parser not got some quirky error handling?) |
| 20:55 | <gsnedders> | Hixie: (see "<p>For the purposes of the interaction of HTML with Selectors' <code") |
| 21:02 | gsnedders | throws this proposal for recreating toc(1) and num(1) out the window for being far too expensive |
| 21:04 | <gsnedders> | Hixie: that is per HTML 5 seemingly an empty title"" attribute. I guess you didn't mean that :) |
| 21:15 | <Philip`> | Is there some way I can construct a DOM element using JS so it has an attribute called something like title"" without throwing exceptions? |
| 21:16 | <Philip`> | I can't make a very good HTML parser if there's no way to construct the things that are parsed :-( |
| 21:16 | <blooberry> | can you use String.fromCharCode? |
| 21:17 | <Philip`> | The problem is just when trying to pass the string into setAttribute |
| 21:17 | <blooberry> | it throws an exception in that case? |
| 21:18 | <Philip`> | In Firefox 2, yes |
| 21:18 | <Philip`> | (In Opera 9.5, no) |
| 21:18 | <Philip`> | (In Safari 3, yes) |
| 21:19 | <Philip`> | presumably because it's a totally bogus attribute name |
| 21:23 | <SadEagle> | It should. |
| 21:24 | <jgraham_> | gsnedders: Did any of that help? |
| 21:24 | <gsnedders> | jgraham_: I'm still in the middle of finishing off an email :P |
| 21:24 | <gsnedders> | (ironically, this one email is probably longer than the total amount of writing I've done at school over the past two days) |
| 21:30 | <jwalden> | hm |
| 21:31 | <jwalden> | isn't this domain hazard also common to document.domain as well? |
| 21:31 | <gsnedders> | OK, now what jgraham_ said |
| 21:51 | <Hixie> | jwalden: as i understand it, doc.domain doesn't allow you to cross ports or schemes |
| 21:52 | <jwalden> | Hixie: I could have sworn Mozilla did differently last time I looked |
| 21:52 | <Hixie> | ah |
| 21:56 | <gsnedders> | jgraham_: OK, that makes sense now. |
| 21:56 | <gsnedders> | (no, it didn't take 20 minutes, I went and procrastinated) |
| 21:57 | <gsnedders> | From the looks of things, it'd be simplest to just do the same as etree does |
| 21:57 | <gsnedders> | Though it looks like the only thing that'll change for each DOM impl is the TreeBuilder class itself |
| 21:59 | <gsnedders> | Or rather, that's the only one that needs to reference the actual impl. |
| 22:11 | <met_> | Has any browser implemented datagrid already? |
| 22:11 | met_ | is trying nigthtly build without success |
| 22:13 | <jgraham_> | met_: not as fr as I know |
| 22:13 | <jgraham_> | s/fr/far/ |
| 22:14 | jgraham_ | wonders how much effort it would be to implement in js |
| 22:14 | <met_> | thx, it looks same for me |
| 22:14 | <met_> | preparing some examples for html5 presentation and some datragrid example should be nice and powerfull 8-) |
| 22:15 | <met_> | but I have nowhere to check it |
| 22:18 | <gsnedders> | jgraham_: would you say just chucking everything in dom.py into a function, like etree.py, would be the best way to go about it? |
| 22:19 | <gsnedders> | brb |
| 22:20 | <jgraham_> | gsnedders: I don't like to make claims about best :) But consistency is good and if we decide the whole design sucks later it's easier to change two similar things than two different things |
| 22:20 | <zcorpan_> | Philip`: no, you can't (re title"") |
| 23:00 | <gsnedders> | jgraham: I'll try and impl it tomorrow |
| 23:41 | <annevk> | Hixie, as far as I can tell event listeners are asynchronous which means that the UA could decide to not run process them directly but instead process some code further on... |
| 23:45 | <Hixie> | event listeners are synchronous. |
| 23:45 | <Hixie> | as in, when you dispatch an event, everything from that point to when it returns is synchronous |
| 23:45 | <Hixie> | see dom2 events |
| 23:45 | <annevk> | i guess i'll admit defeat |
| 23:45 | annevk | wonders why everyone fails |
| 23:50 | <Hixie> | if nobody allows click() to nest, i can remove the test |
| 23:50 | <Hixie> | iirc, at least one browser nested at least once |
| 23:51 | <annevk> | could be |
| 23:54 | Philip` | sees that http://blogs.msdn.com/ie/archive/2008/01/21/compatibility-and-ie8.aspx has reached exactly 666 comments |
| 23:55 | <Philip`> | It seems a bit odd that it's generated more noise than the Acid 2 post |
| 23:55 | <Hixie> | why? |
| 23:55 | <Hixie> | microsoft has an image problem. people aren't going to be pro-ms until they have proven over years of not being evil that they are in fact good. |
| 23:56 | <Hixie> | acid2 is a small step in the right direction. the compatibility meta header is a giant step backwards. |
| 23:56 | <billmason> | I love the suggestion in the thread that any unknown doctype be rendered as XHTML 1.1. I think I'll stop reading the noise now. |
| 23:58 | <Philip`> | Hmm, okay, maybe it's not actually odd :-) |