| 00:00 | <heycam> | for <desc> i think it's fine, since that's meant to be like a long description of the content, so including HTML in there would be handy |
| 00:00 | <heycam> | even if it doesn't actually render or do anything |
| 00:00 | Hixie | never understood what <desc> and <title> were really for |
| 00:00 | Hixie | has a sneaking suspicion they're a (successful) way to shut accessibility people up |
| 00:01 | <heycam> | i don't think that's the intention of them, though i wasn't there at the start of course |
| 00:01 | <heycam> | i mean, i think having <title> (or <desc>) annotated elements could help with ATs navigating around a diagram |
| 00:02 | <heycam> | Hixie, i see your point around <title> being an element sort of implying that the intention is to allow <bdo> or other i18n things that you can't get in attributes |
| 00:03 | <heycam> | maybe <title> could allow HTML but have conformance requirements so that it doesn't include crazy stuff like the above /me'd example |
| 00:03 | <Hixie> | i would be really impressed if i ever saw a blind or text mode user actually successfully navigating an svg file using <title> or <desc> |
| 00:03 | <heycam> | in fact i don't know if any ATs actually support SVG at all, i'd be interested to know |
| 00:04 | heycam | wonders why AT vendors don't participate in HTML and SVG WGs |
| 00:05 | <Hixie> | i've approached several of them trying to get them involved in html5 |
| 00:05 | <Hixie> | unsuccessfully |
| 00:06 | <heycam> | i wonder if there is some level of self-interest in not getting better? if all of the ATs are mediocre (which is my impression; correct me if i'm wrong) then maybe they are happy staying at that level. |
| 00:06 | <Hixie> | it is sad that in their absence their position is instead argued for them by... other people |
| 00:07 | <heycam> | it'd be great if a major org (like google) could put resources into one of the open source ones |
| 00:07 | <heycam> | (orca, is it?) |
| 00:07 | <Hixie> | the firevox guy works for google |
| 00:07 | <Philip`> | Might it be more an issue of limited resources (due to limited market)? |
| 00:07 | <heycam> | Philip`, could be. AT software is expensive though. |
| 00:08 | <Hixie> | i don't understand why AT software hasn't improved much over the years |
| 00:08 | <Hixie> | i'm also confused as to why most accessibility advocates seem to defend accessibility software |
| 00:08 | <heycam> | it seems unfortunate to be speccing various accessibility related stuff that may not get implemented for many years in ATs (or at all) |
| 00:09 | <Hixie> | yeah, well, that's one reason i want to drop the more useless stuff, so that AT vendors don't waste their time on that and instead focus on the big bang for the buck features |
| 00:09 | <heycam> | do the AT vendors participate in the WAI groups? |
| 00:10 | <tantek> | Hixie, the defending may be coming from thinking something is better than nothing. |
| 00:11 | <Hixie> | you'd think they'd be campaigning for quality |
| 00:11 | <Hixie> | rather than being thankful for dirt |
| 00:11 | <Hixie> | as it were |
| 00:11 | <Hixie> | but maybe you're right |
| 00:47 | <Hixie> | 52% |
| 00:47 | <Hixie> | just did <input> |
| 00:48 | <Hixie> | i wonder how many dangling links are going to be left in the author version |
| 00:48 | <Hixie> | i bet i've used terms in the author prose whose definitions i've hidden |
| 00:50 | <Hixie> | i wish people wouldn't cross-post to lists that bounce non-subscriber e-mails |
| 00:50 | <Philip`> | You mean like the WHATWG list? |
| 00:58 | <Hixie> | Philip`: yeah, specifically people cross-posting to public-html and whatwg |
| 00:58 | <Hixie> | Philip`: it results in fragmented threads when people who are only in one group reply |
| 00:59 | Philip` | has often noticed Hixie cross-posting to public-html and whatwg |
| 00:59 | <Hixie> | recently? |
| 00:59 | <Hixie> | if i do, i usually do so because the feedback threads were cross-posted, and i ask people not to do this when replying |
| 01:02 | <Philip`> | Maybe not recently |
| 05:09 | jwalden | gets the impression, from reading a few <time> posts, that if there is a problem html5 should address, rdfa will be proposed as the solution to it |
| 08:19 | <Lachy> | apparently polyglot documents can now come in HTML, XHTML and Haiku :-) http://xkcd.com/554/ |
| 08:35 | <Lachy> | re the <time> thread, it seems the use cases for imprecise dates (YYYY or YYYY-MM) seem reasonable and warrant further investigation into the problems being solved. |
| 08:35 | <Lachy> | but as far as historical dates and alternative calendars are concerned, that just seems like massive scope creep |
| 09:17 | <annevk> | Hixie, how do you calculate the percentage? number of lines? |
| 09:25 | <Lachy> | Hixie, "My thinking when I made <title> switch to the HTML mode was that this was necessary for supporting <ruby>" -- http://lists.w3.org/Archives/Public/public-html/2009Mar/0219.html |
| 09:26 | <Lachy> | Am I missing something, cause AFAIK, <ruby> is not supported with HTML <title> either, since it's parsed as RCDATA |
| 10:01 | <hsivonen> | Do WebKit and Gears have any kind of abstraction layer between Web authors and SQLite? |
| 10:02 | hsivonen | is reading http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/49aa555219df43ae/a34f54cb5db3db70#msg_a54d77a22ec606ca |
| 10:06 | <jgraham> | hsivonen: Good luck with that (OK so it's not you doing it but…). If Mozilla turns out to be much more strict than Webkit it seems pretty likely to have problems with sites that mainly care about the iPhone |
| 10:10 | <annevk> | I agree we need Web SQL |
| 10:11 | <annevk> | I think there is some layer between authors and SQLite (e.g. to prevent COMMIT), but I'm not sure about the details |
| 10:11 | <jgraham> | annevk: Yeah totally but Webkit has both the important deployment platform (iPhone) and the first mover advantage to effectively define what WebSQL is |
| 10:12 | <roc> | I don't think the iPhone is the only important platform here |
| 10:13 | <jgraham> | roc: OK, iPhone and Android :) |
| 10:13 | <roc> | I don't think phones are the most important platform here eitehr |
| 10:14 | <jgraham> | Really? I imagine Google doing their Gmail thing (which seems like the killer app) to make it run on those platforms and others basically having to be compatible with whatever Google did |
| 10:15 | <roc> | we'll see |
| 10:15 | <annevk> | is the platform you're thinking about the desktop roc? |
| 10:15 | <roc> | I think a lot of people would like and use offline support in their desktop/laptop/netbook browser too |
| 10:16 | <roc> | it may be true that Webkit has locked the Web into (some version of) SQLite already |
| 10:16 | <roc> | that would be sad |
| 10:17 | <jgraham> | roc: You particularly dislike SQLite or? |
| 10:17 | <roc> | it seems unwise to tie the Web to one randomly-chosen engine and SQL dialect |
| 10:18 | <roc> | SQLite happens to be the only major SQL engine that lets you stick values of any type in columns declared as other types |
| 10:18 | <roc> | for instance |
| 10:18 | <jgraham> | Oh, well most things about the web are unwise and usually unfortunate. It seems to work pretty well for all that |
| 10:18 | <roc> | "The Web sucks, doesn't matter if we make it suck more" does not make me happy |
| 10:19 | <annevk> | Is there any other option? |
| 10:19 | <roc> | what option? |
| 10:19 | <annevk> | short of inventing a new SQL language and requiring everyone to implement their own database |
| 10:19 | <roc> | it's not obviously too late to try the Web SQL approach |
| 10:20 | <roc> | it seems worth trying |
| 10:20 | <roc> | I hope we'll try it ASAP |
| 10:20 | <annevk> | oh, yeah, though it seems it will pretty much have to be compatible with SQLite for ease of impl |
| 10:21 | <roc> | that may be OK |
| 10:26 | <hsivonen> | are there live demos of Ubiquity XForms on the Web? I already googled. |
| 10:27 | <hsivonen> | if WebKit exposes SQLite without a query sanitization layer, it seems scary even from a security POV of exposing something intended for trusted developers to untrusted code |
| 10:27 | annevk | finds https://bugzilla.mozilla.org/show_bug.cgi?id=414102 throught that thread |
| 10:27 | annevk | sighs |
| 10:28 | <annevk> | I guess it was naive to assume that SQL was a relatively constrained problem space |
| 10:29 | hsivonen | finds http://ubiquity-xforms.googlecode.com/svn/branches/new_samples/samples/ |
| 10:29 | <annevk> | I sure hope we're not going to require stemming algorithms and the like for implementing full text search... I mean, doing it just for English is relatively easy (depending on how far you go), but once you go beyond that... |
| 10:31 | <roc> | yeah, that sucks |
| 10:31 | <roc> | I built a nice i18n-capable text indexing system once that was based on 4-grams |
| 10:32 | <annevk> | hsivonen, loading just input-color.html takes ages and a lot of HTTP requests... |
| 10:32 | <roc> | woah, someone's even been maintaining it |
| 10:32 | <roc> | http://linux.die.net/man/8/squatter |
| 10:38 | <jgraham> | roc: My feeling about SQLite is that, for all it gets complained about, it is used an awful lot in actual quality products |
| 10:38 | <jgraham> | So it is not obviously the worst possible thing |
| 10:39 | <annevk> | it's public domain |
| 10:39 | <roc> | it's not the worst possible thing, sure |
| 10:39 | <jgraham> | annevk: I doubt that is the reason it is used in e.g. Lightroom |
| 10:39 | <roc> | we already ship it in Firefox so exposing it to the Web is fairly low resistance |
| 10:41 | <roc> | but taking some arbitrary version of SQLite and saying, without really analyzing it, "hey let's make this the database API for the Web for all time" seems irresponsible |
| 10:43 | <jgraham> | roc: It seems to me that, at best, having any significantly different outcome will require us to move rather fast at this point |
| 10:44 | <jgraham> | Otherwise it will end up like every other part of the web platform |
| 10:44 | <jgraham> | i.e. dictated by the behaviour of an early version of IE or Netscape |
| 10:44 | <jgraham> | (or, in this case, Webkit) |
| 10:44 | <roc> | indeed |
| 10:49 | <annevk> | might be worth studying http://www.datatables.net/ if we are to revive <datagrid> one day |
| 10:51 | <jgraham> | http://blog.mozbox.org/post/2009/03/10/video-tag-and-subtitles |
| 10:54 | <roc> | yeah that titles hack is cool |
| 10:54 | <roc> | although the execution of arbitrary script from the .srt files in the context of the page is not cool |
| 10:56 | <jgraham> | roc: Indeed. But it lends weight to the idea that people want subtitle-like things with embedded HTML |
| 10:57 | <roc> | people want all kinds of flashy crazy stuff that doesn't make a lot of sense :-) |
| 15:02 | <Lachy> | with the ElementTree API in python, how do I check the node type of a node to make sure it's an Element and not a comment? |
| 15:04 | <Lachy> | the reason I need that is that I'm using html5lib's parseFragment to parse in a source file, and this returns an array of elements and comments. I then need the script to ignore the comments and process the elements |
| 15:05 | <jgraham> | you could use isinstance(node, etree.Element) |
| 15:06 | <Lachy> | in what package is the isinstance method defined? |
| 15:07 | Dashiva | figured ElementTree would only have Elements |
| 15:07 | Philip` | discovers (too late) that upgrading one's LaTeX installation while simultaneously writing a paper in LaTeX is probably a bad idea |
| 15:07 | <Dashiva> | isinstance is a builtin |
| 15:07 | <jmb> | Philip`: hell yes :) |
| 15:08 | <Lachy> | Dashiva, it does, but it treats comments as a special type of element, and so it makes the etree.iselement() method useless is this case. |
| 15:08 | <Lachy> | if (isinstance(node, etree.Element)): |
| 15:08 | <Lachy> | TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types |
| 15:08 | <Philip`> | (particularly when this is Gentoo, and so it spends a long time compiling code and regenerating font files and everything) |
| 15:09 | <karlcow> | Lachy: xml.etree.ElementTree.iselement(element) |
| 15:09 | <Lachy> | karlcow, see my comment above to Dashiva |
| 15:09 | <karlcow> | ah just read ;) |
| 15:09 | <Dashiva> | Lachy: Well, do all comments have the same tagname? E.g. #comment |
| 15:10 | <jgraham> | Lachy: Ah I forgot Element is a constructor |
| 15:10 | <Lachy> | all the comments look like <!-- The foo Element --> |
| 15:10 | <jgraham> | You use node.tag == etree.Comment |
| 15:10 | jgraham | remembers doing this now |
| 15:10 | <jgraham> | I admit that is not quite obvious |
| 15:11 | <Philip`> | Lachy: Use re.replace('<!--.*?-->', '', markup) before passing it to the parser, and then you know they're not comments |
| 15:11 | <jgraham> | Philip`: Just because you did something stupid with LaTeX doesn't mean that you shouldn't play nice with the other children |
| 15:12 | <Lachy> | jgraham, that worked. |
| 15:12 | <Lachy> | (except I used != instead of ==) |
| 15:12 | <karlcow> | Philip`: huh? |
| 15:13 | <Lachy> | now I'm trying to use the element.find() method, but the documentation is really poor. http://effbot.org/zone/pythondoc-elementtree-ElementTree.htm#elementtree.ElementTree.ElementTree.find-method |
| 15:13 | <jgraham> | (you could also use not isinstance(node, etree._Comment) but that seems more like a hack |
| 15:13 | <jgraham> | Lachy: What do you want to do? |
| 15:13 | <jgraham> | in lxml you should just use .xpath instead for almost everything |
| 15:13 | <Lachy> | oops, I linked to the wrong one... |
| 15:14 | <Lachy> | http://effbot.org/zone/pythondoc-elementtree-ElementTree.htm#elementtree.ElementTree._ElementInterface.find-method |
| 15:14 | <jgraham> | (iirc .find is like .xpath but with less features) |
| 15:14 | <Lachy> | it doesn't define what syntax the path needs to use though |
| 15:15 | <jgraham> | Lachy: Originally it only searched children |
| 15:15 | <jgraham> | So it would just be .find(tagname) |
| 15:15 | <jgraham> | iirc |
| 15:15 | <jgraham> | Now I think you can do desendants too |
| 15:15 | <karlcow> | jgraham: did you look at lxml for writing html5lib http://codespeak.net/lxml/ |
| 15:16 | <Lachy> | How do I do descendants, because node.find("code") doesn't work, because the <code> elements I'm looking for aren't children of the node |
| 15:16 | <karlcow> | Lachy: the find use a classical path |
| 15:17 | <jgraham> | Lachy http://effbot.org/zone/element-xpath.htm documents the syntax |
| 15:17 | <jgraham> | karlcow: I don't understand the question. html5lib can use lxml as the tree representation but it implements a parser |
| 15:17 | <karlcow> | Lachy do you want to find all descendants ? |
| 15:18 | <jgraham> | Lachy: By far the easiest thing to do is node.xpath("//code") |
| 15:18 | <jgraham> | .xpath accepts any xpath 1.0 |
| 15:18 | <jgraham> | .find accepts some subset |
| 15:18 | <karlcow> | for ph in content.findall(".//{http://www.w3.org/1999/xhtml}code";): in XHTML ;) |
| 15:19 | <karlcow> | for ph in content.findall(".//code"): in HTML ;) |
| 15:19 | jgraham | mutters something about the XML tax |
| 15:19 | <karlcow> | hehe |
| 15:20 | karlcow | has no problem with it |
| 15:20 | <karlcow> | in my code I declare it at the start, and then I do not have to worry about it |
| 15:20 | <Philip`> | We should cut the XML tax by 2.5% and allow people to use the shorter namespace http://www.w3.org/1999/html to stimulate the XML economy |
| 15:21 | <jgraham> | Lachy: In general, if you don't care about compat. with non-lxml etree implementations then you should jsut use .xpath for pretty much all cases like this. It is blazing fast and well documented to the extent that xpath is well documented |
| 15:22 | <jgraham> | karlcow: Unless you don't know whether the document was parsed as XHTML or HTML up front |
| 15:23 | <karlcow> | jgraham: what do you mean? you know it if you parse it |
| 15:24 | <Lachy> | jgraham, does xpath return a single element or a list of elements? |
| 15:24 | <jgraham> | Lachy: a list |
| 15:24 | <Lachy> | good, that's what I need |
| 15:25 | <Lachy> | I need a list so I can deal with the way elements like h1 to h6 are defined together in the spec |
| 15:25 | <karlcow> | I wonder if Fredrik is in the process of porting to Python 3.0 |
| 15:25 | <Lachy> | fwiw, this is the source document I'm working from http://dev.w3.org/html5/html-author/utils/elements.html (which is itself, generated from the spec using another script) |
| 15:25 | <karlcow> | because ElementTree 1.3 is in beta for a very long time |
| 15:26 | <Lachy> | anyway, the script I'm writing now is using the data in that to build the table of elements and their associated categories. |
| 15:27 | <karlcow> | Lachy: do you detect specific class or id? |
| 15:28 | <jgraham> | karlcow: You could have a system that accepts both XML and HTML and parses them both to etrees. But the differences between the two formats mean that you always need to keep a record of which format you parsed in and use the correct tag names for each case |
| 15:28 | <jgraham> | Python 3.0rc1+ (py3k, Oct 28 2008, 09:23:29). |
| 15:28 | <jgraham> | >>> from xml.etree import ElementTree |
| 15:28 | <jgraham> | >>> |
| 15:28 | <karlcow> | ah cool |
| 15:29 | karlcow | installed ElementTree 1.3 alpha locally http://effbot.org/zone/elementtree-13-intro.htm |
| 15:30 | <jgraham> | karlcow: Does 1.3 have parent pointers? |
| 15:31 | <karlcow> | hmm I don't know. I installed it, specifically for ET.register_namespace() |
| 15:32 | <karlcow> | but at first sight it doesn't seem |
| 15:38 | <Lachy> | karlcow, what class or id are you referring to? |
| 15:40 | <karlcow> | Lachy: I don't know. You said you were building a list, and I was wondering how you were scoping the right elements. In my code usually I subscope by id or class |
| 15:41 | <karlcow> | example |
| 15:41 | <karlcow> | for ph in billet.findall(".//{http://www.w3.org/1999/xhtml}meta";): |
| 15:41 | <karlcow> | if ph.attrib.has_key('name') and ph.attrib['name'] == 'keywords': |
| 15:41 | <karlcow> | keywords = ph.attrib['content'] |
| 15:41 | <karlcow> | return keywords |
| 15:44 | jgraham | barely remembers that has_key exists |
| 15:44 | <jgraham> | 'in' ftw |
| 15:45 | gsnedders | stretches |
| 15:47 | <gsnedders> | Is there any way to avoid having to prefix everything with {http://www.w3.org/1999/xhtml}? |
| 15:47 | <hsivonen> | gsnedders: but namespaces FTW! |
| 15:50 | <Lachy> | karlcow, no, I'm just relying on the fact that I know the structure of the markup |
| 15:52 | <Lachy> | wtf?! The result I'm getting is not making any sense at all |
| 15:52 | <jgraham> | gsnedders: Not sure. Maybe using the Namespace API somehow but I'm not sure |
| 15:52 | <Lachy> | node.xpath("//table//tr[1]//li") is returning li items that are not descendants of node! |
| 15:52 | <jgraham> | In case you didn't realise I'm not sure |
| 15:54 | <jgraham> | Lachy: try node.xpath(".//table//tr[1]//li") |
| 15:54 | <Lachy> | ah, it works if I use a "." to match the current node. But it still makes no sense why it's searching the other nodes too node.xpath(".//table//tr[1]//li") |
| 15:54 | jgraham | is guessing |
| 15:55 | <jgraham> | Lachy: AIUI xpath treats // at the start of the expression as mean "search from the document root" |
| 15:55 | <gsnedders> | Lachy: It makes perfect sense! |
| 15:55 | <gsnedders> | Yeah |
| 15:55 | <Hixie> | my feeling that it's way too early doesn't bode well for tomorrow when i have to get up even earlier |
| 15:55 | <Lachy> | but I don't have a document node. I'm using html5lib's parseFragment which is returning a list of Element nodes |
| 15:56 | <jgraham> | Lachy: Guess again |
| 15:56 | <Lachy> | jgraham, no. |
| 15:56 | <jgraham> | lxml has no concept of a node without a document |
| 15:56 | <Lachy> | ah, well, that's just confusing |
| 15:56 | <jgraham> | I guess s/lxml/libxml2/ probably |
| 15:56 | <Lachy> | I really wish lxml had selectors api support so I didn't have to work with this xpath nonsense |
| 15:57 | <smedero> | http://codespeak.net/lxml/dev/cssselect.html |
| 15:57 | <jgraham> | smedero: I was going to say that |
| 15:57 | <jgraham> | meanie |
| 15:57 | <jgraham> | ;) |
| 15:57 | smedero | shuffles back to his cave |
| 15:58 | <jgraham> | Lachy: Bonus points if you get it to run the selectors api testsuite :) |
| 15:59 | <Lachy> | awesome |
| 16:00 | <Philip`> | Lachy: You should write you code in JS in a browser, rather than in Python |
| 16:04 | <Lachy> | Philip`, if I had a JavaScript engine avaialble with DOM support that would let me run javascripts from the command line and write to standard output, then I would |
| 16:09 | <jgraham> | http://www.croczilla.com/jssh |
| 16:09 | <jgraham> | It sounds like more effort than just writing the python though |
| 16:13 | <Lachy> | nice. I will look at that later |
| 16:19 | <karlcow> | gsnedders: you can create a variable for the namespace, so you can shorten the typing ;) |
| 16:26 | smedero | wonders when Hixie is planning on doing a check-in for the authoring stylesheet work... |
| 16:27 | <Hixie> | when i reach the bottom :-) |
| 16:27 | <smedero> | (the multipage and w3c versions seem to be quite a bit out-of-sync with the whatwg single page... maybe it is no big deal.) |
| 16:27 | <Hixie> | about 51% in so far, by line |
| 16:27 | <Philip`> | smedero: I assume it's when he's reached 110% |
| 16:27 | <Philip`> | Hixie: I hope you're going to annotate the acknowledgements section so it only lists people who have contributed to the author-relevant sections of the spec |
| 16:28 | <Hixie> | Philip`: i do intend to annotate the acknowledgements section though not along those lines |
| 16:29 | <jgraham> | Just personal insults about the contrbuters? |
| 16:29 | <Hixie> | nah |
| 16:29 | <Hixie> | just hiding one paragraph that makes no sense to the author section |
| 16:29 | <Philip`> | The $10,000 one? |
| 16:30 | <Philip`> | I'd prefer a version with insults |
| 16:30 | <Philip`> | as long as they're entertaining ones |
| 16:32 | <Lachy> | Philip`, use the annotation system to insert notes into the spec :-) |
| 16:32 | <Lachy> | s/notes/insults/ |
| 16:34 | <Philip`> | Lachy: I can't, because I've set my browser to block access to the status script |
| 16:34 | <Lachy> | is that because it's slow? |
| 16:35 | <Lachy> | it no longer freezes Opera |
| 16:35 | <Philip`> | No, it's because it was slow |
| 17:22 | <sayrer_> | Lachy, if you build Firefox you get a thing called XPCShell |
| 17:22 | <sayrer_> | it has all the DOM stuff |
| 17:22 | <gavin> | you mean XPCOM stuff? |
| 17:22 | <gavin> | I guess that includes some DOM stuff |
| 17:23 | <sayrer_> | I think all the DOM works now |
| 17:23 | <sayrer_> | someone finally fixed it to work in there |
| 17:23 | <sayrer_> | Maybe some globals are missing |
| 17:23 | <gavin> | still accessed via xpcom though? |
| 17:24 | <sayrer_> | gavin, you have to use XPCOM to get a DOMParser, I think. But once you have that, I think it works right, with all the shortcuts. |
| 17:26 | <sayrer_> | oh wait, no it doesn't |
| 17:27 | <sayrer_> | cause my hack to let it do text/html isn't in the tree |
| 17:34 | <jcranmer> | hmm |
| 17:34 | <jcranmer> | on the /. article about MS possibly dumping Trident |
| 17:35 | <jcranmer> | I see several wildly different figures for non-IE market share |
| 17:35 | <Philip`> | jcranmer: How many of those figures have at least two decimal places in their percentages? |
| 17:35 | <jcranmer> | |
| 17:35 | <jcranmer> | they're all to 1 significant figure |
| 17:36 | <sid0> | jcranmer: link? can't see it on /. |
| 17:36 | <jcranmer> | http://tech.slashdot.org/article.pl?sid=09/03/10/1942232 |
| 17:36 | <sid0> | oh, heh, no wonder I didn't see it -- i removed kdawson from my authors list |
| 17:37 | <jcranmer> | FF has ~20% market share, Safari ~ 2-3%, IE ~ 70-75%, Others <1%, IIRC |
| 17:37 | <jcranmer> | I sure hope MS continues to develop its own engine for IE |
| 17:38 | <Philip`> | I think Safari people like to quote the numbers from http://marketshare.hitslink.com/browser-market-share.aspx?qprid=1 which says Safari is at 8% |
| 17:39 | <jcranmer> | I am recalling from early-to-mid 2008, so my Safari may be underrepresented |
| 17:39 | <Philip`> | That page says 6% in mid-2008 |
| 17:40 | <jcranmer> | WP seems to be quoting 8% for Safari |
| 17:40 | <jcranmer> | based on Net Applications |
| 17:40 | <jcranmer> | oh, same site |
| 17:41 | <jcranmer> | most of the other sites show lower numbers for Safari |
| 17:41 | <Philip`> | On Canvex, with ~800 visitors in the past few weeks, I see 56% Firefox, 17% IE, 11% Safari, 7% Chrome, 6% Opera |
| 17:41 | <Philip`> | which I guess is not exactly following the typical distribution of users |
| 17:42 | <jcranmer> | market share is tricky business |
| 17:42 | <Philip`> | Defining markets is a tricky business |
| 17:43 | <gsnedders> | Philip`: 17% for IE is fun |
| 17:43 | <jcranmer> | the only thing I can say with certainty is my school's intranet statistics |
| 17:43 | <gsnedders> | Like, with IE's well-known support for canvas |
| 17:43 | <Philip`> | gsnedders: The game page is application/xhtml+xml, too |
| 17:43 | <Philip`> | (These stats are just for the front page) |
| 17:45 | <jcranmer> | 53% IE 6, 13% IE 7+, 23% FF (~20% FF 3+), 5% Safari, ~2.5% Chrome, 0.3% Opera |
| 17:45 | <sayrer_> | numbers from a friend's architecture + design blog: |
| 17:45 | <sayrer_> | 45.89% Firefox, 29.66% IE, 19.06% Safari, 2.94% Chrome, 1.19% Opera |
| 17:45 | <gsnedders> | Lies, damned lies and statistics! |
| 17:46 | <sayrer_> | US skewed, but pretty popular |
| 17:46 | <jcranmer> | the high FF 2.0.0.6 + IE 6 numbers comes from school computers |
| 17:46 | <gsnedders> | But while we're at it, numbers for SimplePie's website: |
| 17:46 | <gsnedders> | (over past 72 hours) |
| 17:47 | <gsnedders> | 67% Firefox, 16% Safari, 12% IE, 3% Opera, nothing else reaches 1% |
| 17:47 | <jcranmer> | if you exclude school computers (i.e., look at a weekend's statistics), you get something more like 20% IE and 50-60% FF |
| 17:47 | <Philip`> | gsnedders: Is Chrome <1%, or are you just failing to count it? |
| 17:48 | <gsnedders> | Dunno |
| 17:50 | <jcranmer> | in any case, I really hope MS doesn't use Webkit in IE 9+ |
| 17:50 | <Philip`> | Hmm, Google has a mobile bot? |
| 17:50 | <jcranmer> | that would force the market into a duopoly again |
| 17:51 | <gsnedders> | I agree with Hixie that it would be highly unlikely after putting so much work into IE8 |
| 17:51 | <jcranmer> | it seems too speculative |
| 17:51 | <Philip`> | SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) |
| 17:51 | <jcranmer> | if IE 8 is as good as reports claim it is, Trident wouldn't be worth scrapping |
| 17:52 | <Philip`> | jcranmer: Belief in the authenticity of the speculation is not helped by it talking about Gazelle as if it were a new browser engine |
| 17:52 | sid0 | wonders what reports jcranmer has been reading |
| 17:53 | <jcranmer> | Philip`: I imagine it would be a revamp in surrounding sandboxing issues |
| 17:55 | <Philip`> | jcranmer: That's kind of what Gazelle is, but the article linked from Slashdot seemed to be entirely unaware of that |
| 17:56 | <jcranmer> | I figured it was misinformation |
| 17:57 | <Philip`> | (hence me not putting much faith in their speculation) |
| 23:29 | <MikeSmith> | dglazkov: congrats on becoming a reviewer |
| 23:33 | <dglazkov> | MikeSmith: thanks! |
| 23:34 | <MikeSmith> | dglazkov: so you doing some work on Web Inspector? |
| 23:34 | <dglazkov> | yep. |
| 23:35 | <dglazkov> | but nothing dramatic, no features |
| 23:35 | <dglazkov> | just cleaning up |
| 23:35 | <MikeSmith> | great |
| 23:35 | <MikeSmith> | it's a great tool |
| 23:35 | <MikeSmith> | I love that thing |
| 23:35 | <dglazkov> | indeed |
| 23:37 | <MikeSmith> | dglazkov: speaking of features, I wonder if there's a bug open for implementing support for examining AppCache/manifest in Web Inspector |
| 23:38 | <dglazkov> | I don't know |
| 23:38 | <dglazkov> | sounds like a useful thing |
| 23:38 | <dglazkov> | you should file it |
| 23:39 | <MikeSmith> | yeah, I will |