| 00:29 | AryehGregor | doesn't understand what annevk's latest blog post means |
| 00:38 | <jwalden> | it seems like the sort of post sayrer would make in its style (perhaps its content as well) (ohai, sayrer, if you get pointed at this in logs ;-) ) |
| 01:21 | <AryehGregor> | That prompted me to start reading through sayrer's blog history. Interesting how many of the features he lists here did actually get removed: http://blog.mozilla.com/rob-sayre/2008/02/19/bloaty-parts-of-the-whatwg-html5-specification-that-should-be-removed/ |
| 02:26 | <othermaciej> | AryehGregor: 6/17 it looks like |
| 09:23 | <hsivonen> | MikeSmith: I blogged: http://hsivonen.iki.fi/html5-parser-improvements/ |
| 09:29 | <MikeSmith> | hsivonen: cool |
| 09:29 | MikeSmith | reads |
| 09:30 | <MikeSmith> | hsivonen: I will try to write up a whatwg blog entry tomorrow about other recent changes (non-parser ones) |
| 09:30 | <MikeSmith> | the warnings stuff etc. |
| 09:31 | <MikeSmith> | I guess it's mostly minor stuff as far as the end-user experience goes |
| 09:31 | <hsivonen> | MikeSmith: I'll deploy the parser changes to V.nu and update the post with a mention that the changes are on V.nu, too |
| 09:31 | <MikeSmith> | great |
| 09:35 | <MikeSmith> | hsivonen: so the parser changes will potentially change some v.nu behavior a bit, right? |
| 09:36 | <MikeSmith> | I mean for <title> and <script>, etc. |
| 09:36 | <MikeSmith> | especially script |
| 09:37 | <hsivonen> | MikeSmith: yeah, script, title, <table><form>, the ol/ul stuff, <frameset> |
| 09:37 | <MikeSmith> | Ok |
| 09:39 | <MikeSmith> | hsivonen: no changes to attribute parsing? |
| 09:39 | <MikeSmith> | or rather tokenizing |
| 09:39 | <hsivonen> | MikeSmith: none that I could recall |
| 09:39 | <MikeSmith> | OK |
| 09:39 | <hsivonen> | (after actually looking at the change log messages) |
| 09:42 | <MikeSmith> | I think for my own edification I'll probably take a look at the change log and diffs, try to learn a bit more about the parser code |
| 09:42 | <MikeSmith> | though I guess it's a probably a pretty big set of diffs |
| 09:45 | <hsivonen> | MikeSmith: the tokenizer diffs are big |
| 09:45 | <hsivonen> | MikeSmith: the tree builder diff not so big |
| 09:46 | <MikeSmith> | OK |
| 09:46 | <hsivonen> | MikeSmith: deployed |
| 09:46 | <hsivonen> | MikeSmith: including your recent changes |
| 09:47 | <MikeSmith> | ah great |
| 09:48 | <MikeSmith> | hsivonen: btw, about the xml-stylesheet checking |
| 09:48 | <MikeSmith> | the <!DOCTYPE x[<?xml-stylesheet href="x"?>]><x/> case |
| 09:48 | <MikeSmith> | I did what you suggested |
| 09:48 | <MikeSmith> | in CheckerValidator |
| 09:49 | <hsivonen> | MikeSmith: did it work as expected? |
| 09:49 | <MikeSmith> | partly |
| 09:49 | <hsivonen> | what didn't work? |
| 09:49 | <MikeSmith> | I changed the return null on getDTDHandler to return (checker instanceof DTDHandler) ? (DTDHandler)checker : null |
| 09:50 | <MikeSmith> | and I can see that's working as expected |
| 09:51 | <MikeSmith> | but in my subclass of the checker, it's not yet having any effect |
| 09:51 | <hsivonen> | MikeSmith: no effect as in not getting any DTDHandler calls? |
| 09:51 | <MikeSmith> | I think there's something I'm missting |
| 09:51 | <MikeSmith> | *missing |
| 09:52 | <MikeSmith> | I added notationDecl |
| 09:52 | <MikeSmith> | and unparsedEntityDecl methods |
| 09:52 | <MikeSmith> | to my Checker subclass |
| 09:52 | <hsivonen> | I wonder if the stream splitters forward DTDHandler correctly |
| 09:53 | <MikeSmith> | I'm you can give my some guidance on where to troubleshoot, I will take a look |
| 09:53 | <MikeSmith> | but I dropped some System.err stuff into those message |
| 09:53 | <MikeSmith> | *methods |
| 09:53 | <hsivonen> | hmm. CombineValidator handles DTDHander OK |
| 09:54 | <hsivonen> | MikeSmith: oops. Sorry. DTDHandler is useless for this. |
| 09:54 | <MikeSmith> | ah, OK |
| 09:55 | <MikeSmith> | I was beginning to wonder.. running out of places to check :) |
| 09:55 | <hsivonen> | you need LexicalHandler |
| 09:55 | <MikeSmith> | aha |
| 09:55 | <hsivonen> | sorry about giving bogus advice and wasting your time |
| 09:55 | <MikeSmith> | OK |
| 09:55 | <MikeSmith> | no problem man |
| 09:55 | <MikeSmith> | everything is still a learning experience for me at this point |
| 09:55 | <MikeSmith> | so it's honestly not wasted time |
| 09:55 | <hsivonen> | now, the problem is the Jing stuff doesn't pass the LexicalHandler stuff along |
| 09:56 | <MikeSmith> | OK |
| 09:56 | <hsivonen> | so you can't do this as a class that pretends to be a Jing Validator instance |
| 09:56 | <hsivonen> | instead, you need to hook it to the pipeline as a special case |
| 09:56 | <MikeSmith> | oh |
| 09:56 | <MikeSmith> | is there an example of a class where you've already done that? |
| 09:57 | <hsivonen> | yes. I'll take a look |
| 09:57 | <MikeSmith> | cool |
| 09:57 | <hsivonen> | MikeSmith: look for |
| 09:57 | <hsivonen> | reader = new IdFilter(xmlParser); |
| 09:58 | <hsivonen> | in VerifierServletTransaction |
| 09:58 | <hsivonen> | I think you need to add yours as a filter on top of that |
| 09:58 | hsivonen | checks the filter mechanism to see if it can deal with LexicalHandler |
| 09:58 | <MikeSmith> | OK, I'll take a look there |
| 09:59 | <hsivonen> | aargh |
| 09:59 | <hsivonen> | it doesn't |
| 09:59 | <hsivonen> | all this infrastructure assumes that the app wants to do things that don't violate layering |
| 09:59 | <hsivonen> | let's try again |
| 10:00 | hsivonen | checks if the parser support LexicalHandler |
| 10:01 | <hsivonen> | it does |
| 10:01 | <hsivonen> | good |
| 10:01 | <MikeSmith> | oh good |
| 10:01 | <MikeSmith> | yeah |
| 10:01 | <hsivonen> | so |
| 10:01 | <hsivonen> | as long as the validator has only one LexicalHandler, you could keep your ContentHandler part as a Checker subclass |
| 10:01 | <hsivonen> | and also make it implement LexicalHandler |
| 10:02 | <MikeSmith> | OK |
| 10:02 | MikeSmith | takes a look at LexicalHandler docs |
| 10:03 | <hsivonen> | and then in validatorByUrl in VerifierServletTransaction |
| 10:03 | <hsivonen> | have a special case for your Checker |
| 10:03 | <hsivonen> | that also sets your Checker as the LexicalHandler of the parser in addition to returning it |
| 10:04 | <hsivonen> | except it has to dig out the Checker object from the Validator |
| 10:04 | <hsivonen> | hmm. |
| 10:05 | <hsivonen> | hmm. this is annoying |
| 10:06 | <hsivonen> | ok. here's what to do |
| 10:06 | <hsivonen> | call getContentHandler() on the Validator |
| 10:06 | <hsivonen> | then check if it's an instanceof LexicalHandler |
| 10:06 | <hsivonen> | and if it is, set it as the lexicalHandler of the parser |
| 10:06 | MikeSmith | nods |
| 10:07 | <hsivonen> | which will break once more than one Validator have a contenthandler that is also a lexicalhandler |
| 10:07 | <hsivonen> | hmm. |
| 10:07 | <hsivonen> | perhaps it's safer to do the instanceof against your particular class name |
| 10:07 | <MikeSmith> | OK, yeah |
| 10:07 | <hsivonen> | to make the setup less brittle than trusting that nothing else implements LexicalHandler as a stub |
| 10:09 | <MikeSmith> | understood |
| 10:10 | <MikeSmith> | the call to getContentHandler() the Validator, I need to do that within the validate() method, right? |
| 10:10 | <MikeSmith> | *on the Validator |
| 10:11 | <hsivonen> | MikeSmith: I suggest putting the hack in the validatorByUrl method |
| 10:11 | <hsivonen> | MikeSmith: assuming you are going to make the checker URL-identified |
| 10:12 | <MikeSmith> | yep, I've already got it URL-identified |
| 10:12 | <MikeSmith> | so that should work fine |
| 10:14 | <hsivonen> | in other news, it's scary to discover how many test cases rely on about:blank loading synchronously. |
| 10:15 | <hsivonen> | yet, the HTML5 parser works quite well for dogfooding even if about:blank doesn't always load synchronously |
| 10:15 | <MikeSmith> | test cases from which suite? |
| 10:15 | <hsivonen> | MikeSmith: Mozilla Mochitests |
| 10:15 | <MikeSmith> | ah |
| 10:15 | <hsivonen> | (the test cases don't need to say about:blank. Having an <iframe> with src means the same thing.) |
| 10:16 | <hsivonen> | s/with/without/ |
| 10:16 | <MikeSmith> | so how come the HTML5 parser still works for those cases? |
| 10:16 | <hsivonen> | it doesn't |
| 10:16 | <hsivonen> | at least not reliably |
| 10:16 | <MikeSmith> | oh |
| 10:16 | <MikeSmith> | I see now |
| 10:18 | <MikeSmith> | hey, btw, about the URL for this xml-stylesheet checker.. any suggestions for the name? I've got http://c.validator.nu/xmlstylepi/ now |
| 10:18 | <MikeSmith> | maybe http://c.validator.nu/xml-style-pi/ is better? |
| 10:18 | <MikeSmith> | or http://c.validator.nu/xml-stylesheet-pi/ ? |
| 10:18 | <MikeSmith> | dunno if you have any conventions you prefer to use for those names |
| 10:19 | <MikeSmith> | dashes or no dashes or whatever |
| 10:21 | <hsivonen> | MikeSmith: I've used /text-content/ with a hyphen |
| 10:21 | <hsivonen> | but otherwise I've managed to use single words, so the issue hasn't come up |
| 10:21 | <hsivonen> | how about /xml-stylesheet/ ? |
| 10:23 | <MikeSmith> | hsivonen: sounds fine to me |
| 10:23 | <MikeSmith> | I will make it so |
| 10:23 | <hsivonen> | ok |
| 10:23 | hsivonen | goes away for lunch |
| 10:24 | <MikeSmith> | hsivonen: thanks extremely much for all your help |
| 10:24 | MikeSmith | heads off to catch a train back to Tokyo |
| 10:37 | <Philip`> | hsivonen: "<--…--> escapes in <script>" (in html5-parser-improvements) |
| 10:38 | <Dashiva> | I don't recall seeing public-html this quiet for years |
| 11:08 | <hsivonen> | Philip`: thanks. fixed |
| 13:12 | <hsivonen> | http://livedom.validator.nu/ now has the latest parser version deployed |
| 13:18 | <annevk3> | Philip`, see "URL-encoded form data" |
| 13:21 | <Philip`> | annevk3: Did you mean foolip? |
| 13:31 | <annevk3> | yes |
| 13:38 | <foolip> | annevk3: thanks, looking now |
| 13:45 | <foolip> | that's just the encoding end, as expected |
| 13:47 | <hsivonen> | http://www.guardian.co.uk/environment/2009/dec/22/copenhagen-climate-change-mark-lynas |
| 13:51 | <karlcow> | hsivonen: it is at these moments that we wish there was a public transcript of the discussions |
| 13:51 | <hsivonen> | oops. wrong window. sorry about the off-topic URL |
| 13:56 | <karlcow> | hsivonen: still interesting ;) |
| 14:02 | <karlcow> | http://rebuildingtheweb.com/en/html5-make-web-more-invalid/ |
| 14:07 | <Philip`> | Sounds like it's arguing that HTML5 makes the concept of validity much less important (because it removes the link between validity and interoperability / forward-compatibility) |
| 14:07 | <Philip`> | and so people will focus less on validity |
| 14:07 | <Philip`> | since everything will work fine for them anyway |
| 14:07 | <Philip`> | and, uh, somehow that's a bad thing (?) |
| 14:07 | <annevk3> | foolip, maybe you should file a bug and say that it should define server requirements as well |
| 14:07 | <gsnedders> | We have pretty uniform behaviour already though |
| 14:07 | <annevk3> | foolip, would be somewhat logical |
| 14:08 | <hsivonen> | Philip`: I thought HTML5 doesn't move the link between validity and forward compat |
| 14:08 | <hsivonen> | everything invalid is reserved for future specs |
| 14:08 | <Philip`> | I don't see anything in that post saying why "invalid" content is actually bad |
| 14:09 | <hsivonen> | (of course, if you deploy a given piece of syntax enough, it'll show up as a legacy constraint on what future specs can say) |
| 14:09 | <hsivonen> | (so you only get burned if you make stuff up and aren't successful in deploying it widely) |
| 14:09 | <Philip`> | hsivonen: That's true, but it's not what the mentioned post is arguing |
| 14:32 | <Dashiva> | Philip`: There's a second, underlying assumption, that valid == best practice (and probably also XHTML :P) |
| 14:33 | <foolip> | annevk3: I'll do that if no one in the media fragments WG can find a spec which we can use |
| 14:37 | <annevk> | i think html5 should define it regardless |
| 14:38 | <annevk> | well, as long as it's the spec that defines how to serialize |
| 14:44 | <hsivonen> | Today I broke my rule of not redeploying V.nu before a vacation. I hope it stays up for the rest of the year... |
| 14:45 | <nirvdrum> | hsivonen: Happen to see my message about localents not fixing the CCE? |
| 14:45 | <hsivonen> | nirvdrum: hmm. that's odd. usually it fixes the problem |
| 14:46 | <hsivonen> | nirvdrum: it's a problem with the local entity cache being corrupt somehow |
| 14:46 | <hsivonen> | nirvdrum: I suggest trying to delete the local cache and then running localent |
| 14:46 | <nirvdrum> | hsivonen: It's very reproducible for me. If I execute "all" twice in a row, it works fine. |
| 14:47 | <nirvdrum> | I've just taken to making a tarball of my distribution and throwing it up on S3. |
| 14:47 | <nirvdrum> | I found the only way I could detach from the TTY, too, was to add a stop port to the jetty command. |
| 14:48 | <nirvdrum> | I think it's because Main has a System.in.read(); |
| 15:01 | <hsivonen> | nirvdrum: http://pastebin.mozilla.org/692476 works for me for detaching from TTY |
| 15:01 | <nirvdrum> | hsivonen: You added a stop port there, too. |
| 15:01 | <nirvdrum> | Without it, it tries to read from stdin, it seems. |
| 15:02 | <nirvdrum> | And then immediately stops the server. |
| 15:02 | <nirvdrum> | I spent a few hours trying to figure out why I could get as far as binding to the port and then the process would just kill itself. |
| 15:03 | <hsivonen> | clearly, I should do a better job with documenting my deployment procedure |
| 15:04 | <nirvdrum> | I'd really like to take a stab at building a web app directory structure at the very least. Going to WAR from there is simple. It'd simplify deployment considerably. |
| 15:04 | <hsivonen> | depends on how one is deploying |
| 15:05 | <hsivonen> | having worked on Java enterprise software and having written my of main() for Jetty, I vastly prefer writing my own main() for Jetty |
| 15:05 | <hsivonen> | s/of/own/ |
| 15:06 | <nirvdrum> | Well, if I want to use an existing app server, I could just plop it in and use my existing init scripts and monitoring tools. If I were to still the embedded jetty you have, I wouldn't need to add all those classpath entries. It'd just be an easier command to execute. |
| 15:06 | <nirvdrum> | I don't think you lose anything. |
| 15:06 | <nirvdrum> | Setting up a WebAppContext in Jetty is pretty straightforward. |
| 15:07 | <hsivonen> | classpath hell is bad enough with plain Java apps, I don't really want to deploy with more run-time classloader tricks |
| 15:07 | <hsivonen> | like an app server running itself and the .war under different classloaders or whatever |
| 15:07 | <hsivonen> | I am willing to consider patches for building a .war, though |
| 15:08 | <nirvdrum> | Well, what I was initially proposing was just a more standard approach to running the app in the embedded container *shrug* |
| 15:08 | <nirvdrum> | But I agree. You don't want to be debugging people JBoss issues, for example. |
| 15:09 | <hsivonen> | fwiw, V.nu at least at one point supported running inside W3C Jigsaw |
| 15:09 | <hsivonen> | which is yet different |
| 15:09 | <nirvdrum> | I run the CSS validator as a WAR in Jetty. I think that was designed to run in Jigsaw. |
| 15:09 | <nirvdrum> | So, maybe they've cleaned that up a bit. |
| 15:13 | <hsivonen> | nirvdrum: anyway, I understand that others may prefer to deploy a .war and I'm willing to accept code to enable it, but I don't see a compelling benefit to the deployment of the instances I'm running |
| 15:14 | <hsivonen> | btw, one reason of having my own main() is making debugging in Eclipse super-simple |
| 15:14 | <nirvdrum> | Fair enough. I'm just looking that I killed about 10 hours yesterday trying to get everything going. |
| 15:14 | <nirvdrum> | hsivonen: I normally handle that by add a TestMain class or whatever to my test classpath and execute from there. |
| 15:16 | <nirvdrum> | Another issue I had run into is that mercurial is a required dependency. I can file an issue to add that to the docs. |
| 15:16 | <nirvdrum> | It's been years since I've used bugzilla, though. Hopefully I remember my way around ;-) |
| 15:17 | <hsivonen> | sorry about the defective docs and the unusual deployment |
| 15:17 | <nirvdrum> | Eh, no worries. I'm just trying to think of ways to make it easier for the next time. |
| 15:18 | <hsivonen> | nirvdrum: did Jing's datatype library loading code work ok under your app server? |
| 15:18 | <hsivonen> | nirvdrum: previously, when I tried to sandbox the code, I gave up because what I did disrupted Jing's classloader tricks |
| 15:19 | <nirvdrum> | I guess so? I got the embedded Jetty server up and could validate an HMTL 5 site, both from the server directly and from the W3C validator frontended to the nu validator. |
| 15:19 | <hsivonen> | ok |
| 15:19 | <nirvdrum> | But, I really didn't try any other doc types. |
| 15:36 | <MikeSmith> | Philip`: fwiw, I figured out the cause of my problem with v.nu not actually accepting connections |
| 15:36 | <MikeSmith> | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560056 |
| 15:37 | <MikeSmith> | latest debian "netbase" package sets a new kernel param |
| 15:37 | <MikeSmith> | net.ipv6.bindv6only=1 |
| 15:37 | <Philip`> | Ah |
| 15:38 | <MikeSmith> | that totally muffs up all java networking |
| 15:38 | <Philip`> | Would http://[::1]:8888/ work? |
| 15:39 | <MikeSmith> | dunno |
| 15:39 | <MikeSmith> | I can try it |
| 15:40 | <MikeSmith> | I don't know what that syntax means |
| 15:41 | <MikeSmith> | wow |
| 15:41 | <MikeSmith> | Philip`: yeah, that works even when net.ipv6.bindv6only=1 |
| 15:41 | <MikeSmith> | so what does "[::1]" mean? |
| 15:44 | MikeSmith | steps away for a bit |
| 15:50 | <gratz|home_> | MikeSmith, ipv6 equivalent of 127.0.0.1 |
| 15:52 | <Mitsurugi> | hi all |
| 15:54 | <Philip`> | MikeSmith: What gratz|home_ said |
| 15:54 | <annevk> | http://rebuildingtheweb.com/en/ is pretty much like our other fan site in a slightly different tone... |
| 15:54 | <Philip`> | ::1 is like 127.0.0.1, [::1] is how you write it in URLs to be unambiguous |
| 16:06 | <annevk> | hsivonen, feel free to post such off-topic links btw |
| 16:06 | <annevk> | hsivonen, I'd go as far as encouraging it :) |
| 16:07 | <karlcow> | annevk: just realized that it was written by Vlad Alexander http://rebuildingtheweb.com/en/about/ |
| 16:18 | <annevk> | there's a lot less email these past few days |
| 16:18 | <annevk> | very nice |
| 16:18 | <Philip`> | Just wait until a microdata decision is made |
| 16:20 | <annevk> | when is that? |
| 16:20 | <annevk> | after the holidays somewhere? |
| 16:20 | Philip` | shrugs |
| 16:21 | foolip | looks forward to another cycle of the same nonsense |
| 16:23 | <gratz|home_> | what decision is there to be made? |
| 16:24 | <Philip`> | Whether it should be split out of the W3C's HTML5 document or not |
| 16:25 | <gratz|home_> | what should? |
| 16:25 | <Philip`> | All the bits to do with microdata |
| 17:40 | <MikeSmith> | gratz|home_, Philip` - I see, thanks (::1 thing) |
| 18:11 | <annevk> | task queues are fun |
| 19:25 | <Lachy> | Hixie, whatwg.org seems to be down |
| 19:49 | <smaug> | if some attribute should be parsed as non-negative integer, what is the default value for the DOM attribute if the attribute isn't there or if the parsing fails? |
| 19:52 | <smaug> | and since whatwg.org is down it is even harder to find out if the draft specifies that situation properly |
| 20:00 | <annevk> | http://dev.w3.org/html5/spec/infrastructure.html#non-negative-integers |
| 20:01 | <annevk> | oh, and http://dev.w3.org/html5/spec/infrastructure.html#reflecting-content-attributes-in-idl-attributes |
| 20:01 | <annevk> | smaug, ^^ |
| 20:02 | <annevk> | maybe we should host all specs on multiple servers in case stuff goes down |
| 20:04 | <smaug> | annevk: ok, thanks |
| 20:04 | <smaug> | though, there is this: "The maxLength IDL attribute must reflect the maxlength content attribute, limited to only non-negative numbers." |
| 20:04 | <smaug> | which sort-of says that maxLength is always non-negative |
| 20:05 | <annevk> | it depends on the type of maxLength in the IDL |
| 20:06 | <annevk> | if it's actually a signed integer it will return -1 if it's not present |
| 20:06 | <annevk> | sounds like that is the case |
| 20:06 | <smaug> | yeah, I think that is what the draft tries to say |
| 20:08 | <annevk> | tries? :) |
| 20:09 | <annevk> | having read it it seems that's what it says |
| 20:24 | <AryehGregor> | smaug, "limited to only non-negative numbers" is linked to something that explains pretty clearly, I think. |
| 20:26 | <smaug> | AryehGregor: I couldn't find it easily |
| 20:26 | <smaug> | it is explained in #reflecting-content-attributes-in-idl-attributes |
| 20:27 | <annevk> | you can just click on it |
| 20:28 | <annevk> | takes you right there |
| 20:28 | <AryehGregor> | http://dev.w3.org/html5/spec/infrastructure.html#limited-to-only-non-negative-numbers "If, on the other hand, it fails or returns an out of range value, or if the attribute is absent, the default value must be returned instead, or −1 if there is no default value." |
| 20:29 | <AryehGregor> | And if you follow the link to "rules for parsing non-negative integers", it tells you that the algorithm fails if there's a - before the first digit, among other things, if you read through the algorithm. |
| 20:29 | <smaug> | ok, my mistake then |
| 20:29 | smaug | wishes the draft would be reasonable easy to read |
| 20:30 | <AryehGregor> | Well, hard to be reasonably easy to read while being fully precise, I guess. |
| 20:30 | <smaug> | but since I don't have any real suggestions (other than splitting it to many parts), I shouldn't perhaps complain so much |
| 20:31 | <annevk> | you think splitting it would make it easier to read? |
| 20:31 | <smaug> | yes! |
| 20:31 | <annevk> | interesting; I think it makes things harder (for where we splitted it) |
| 20:31 | <smaug> | splitting things like XHR from it made both drafts somewhat easier to understand |
| 20:32 | <smaug> | same with storage etc |
| 20:32 | <AryehGregor> | Probably not possible to do sanely for things like maxlength, though. |
| 20:33 | <smaug> | even for maxLength |
| 20:33 | <Dashiva> | A split that can be accomplished by variable use of display:none on a single document isn't a real split :) |
| 20:34 | <smaug> | there could be some "core" spec, which tells how DOM attributes and content attributes are reflected and then HTML forms spec could have links to that |
| 20:34 | <smaug> | though, that is quite close to what we have now |
| 20:34 | <annevk> | it is almost exactly what we have now... |
| 20:35 | <annevk> | except it's in the same file... |
| 20:35 | <annevk> | (the same goes for all the other splitting btw) |
| 20:35 | <annevk> | (XHR has been rewritten a lot, I think that's what made it clearer) |
| 20:50 | <Mitsurugi> | hi all, is there any lists of compatible browsers for html5 ? |
| 20:51 | <AryehGregor> | Some parts of HTML5 are implemented by all browsers. Some parts aren't implemented by any yet. |
| 20:51 | <AryehGregor> | You'll have to ask about particular features. |
| 20:51 | <Mitsurugi> | aha |
| 20:51 | <Mitsurugi> | so, im looking for the browsers that support the video tag :) |
| 20:52 | <annevk> | I'd point to the wiki, but it's down |
| 20:52 | <annevk> | Mitsurugi, Chrome, Firefox, and Safari |
| 20:52 | <AryehGregor> | Mitsurugi, currently <video> is supported by Firefox 3.5 and up with Ogg Theora, recent Safari (4, maybe?) with H.264, and Chrome 3 and up with both. |
| 20:52 | <Mitsurugi> | thx annevk |
| 20:52 | <AryehGregor> | More precisely, Safari supports whatever QuickTime does. |
| 20:53 | <AryehGregor> | As far as I understand. Which includes H.264 but not Theora by default. |
| 20:53 | <AryehGregor> | But you can install a Theora codec if you want. |
| 20:53 | <Mitsurugi> | i was sure that i read that opera supports too |
| 20:53 | <AryehGregor> | Experimentally only, IIRC. |
| 20:53 | <Mitsurugi> | aha |
| 20:53 | <AryehGregor> | If annevk says it doesn't, then it doesn't. :) |
| 20:53 | <Mitsurugi> | gracias |
| 20:54 | <Mitsurugi> | sorry, thx |
| 20:54 | <Philip`> | Opera has said it will support Theora in <video>, at some point in the future, I believe |
| 20:54 | <annevk> | we will for Opera 10.5 |
| 20:54 | <Mitsurugi> | we believe that all browesers support |
| 20:54 | <AryehGregor> | Yes, that's my recollection too. |
| 20:54 | <AryehGregor> | Ah. |
| 20:54 | <annevk> | but not in the pre-alpha that was released yesterday |
| 20:54 | <Mitsurugi> | hehe |
| 20:55 | <annevk> | we also had experimental releases of Opera with <video> in the past |
| 20:56 | <Philip`> | How much resemblance does the current spec bear to Opera's initial experimental version? |
| 20:57 | <annevk> | a little |
| 20:57 | <annevk> | I think stop() got killed and a whole lot got added |
| 21:01 | <Dashiva> | I bet the first major video library will do HTMLVideoElement.prototype.stop = function(){...} :) |