| 00:34 | <Lachy> | Does anyone understand the problem that might be solved by poetry markup, as being discussed on public-html? |
| 00:35 | <Lachy> | I just can't figure out what user agents could do with the markup that would make it more useful than just using the existing, more general purpose elements. |
| 01:02 | <webben> | Lachy: I get the impression from LML that Hoffman is concerned with poetry being read aloud differently. |
| 01:03 | <webben> | "Prose is in general text with no specific requirements for the presentation of rhythmic or rhymed content. On the contrary the presentation should not pronounce accidental rhythmic or rhymed fragments." |
| 01:16 | <webben> | Lachy: Not significant, but I think you just missed http://krijnhoetmer.nl/irc-logs/whatwg/20100121#l-83 |
| 01:17 | <Hixie> | fwiw, in case anyone was wondering, macbooks aren't waterproof. |
| 01:18 | <webben> | Lachy: see also http://markmail.org/message/6pxz74sm3zcs4gn3 |
| 01:18 | <webben> | Hixie: This sounds like wisdom gleaned from bitter experience :( |
| 01:19 | <Hixie> | yeah. |
| 01:20 | <webben> | Lachy: So: 1) read stuff aloud differently and 2) expose the structure of the poetry itself as visible data. |
| 01:20 | <AryehGregor> | Are they water-resistant? |
| 01:21 | <Hixie> | what's the threshold? |
| 01:21 | <Hixie> | i.e. how much water would they have to resist for the answer to be yes? |
| 01:21 | <AryehGregor> | I don't know, but I assume the terms have some conventional meanings. |
| 01:21 | <AryehGregor> | I think "water-resistant" means it will be okay if you take it out in the rain, "waterproof" means it will be okay if you drop it in the bathtub. |
| 01:21 | <AryehGregor> | Roughly. |
| 01:22 | <Hixie> | ah |
| 01:22 | <Hixie> | well |
| 01:22 | <Hixie> | where do you think half a glass of water straight into the keyboard fits in this spectrum? |
| 01:25 | <Lachy> | maybe laptops should have depth ratings on them, like watches do |
| 01:25 | <Hixie> | "rated up to -1cm below water level" |
| 01:26 | <Lachy> | where such depth ratings do not correspond with the actual water depth they are capable of handling. |
| 01:26 | <Lachy> | like, e.g. a watch rated at "30m" corresponds to roughly splash resistant from, e.g. a tap while washing hands. |
| 01:26 | <Hixie> | hah |
| 01:27 | <AryehGregor> | Hixie, so I think you're supposed to take out the battery and let it dry out? |
| 01:27 | <AryehGregor> | Apparently it will often be okay if you give it a few days to fully dry. |
| 01:31 | <Lachy> | Hixie, you have a terminal. Can't you just use the date command for that? |
| 01:32 | <Hixie> | the clock in my irssi window gives me CET time :-) |
| 01:32 | <Hixie> | but yes, i could have used terminal too |
| 01:32 | <Hixie> | i just happened to already have google open |
| 01:32 | <Lachy> | is CET the time zone I'm in? |
| 01:32 | <Hixie> | is it 02:39 where you are? |
| 01:32 | <Lachy> | I'm guessing Central European Time |
| 01:32 | <Lachy> | yes |
| 01:33 | <Hixie> | then yes |
| 01:37 | <Lachy> | Hixie, maybe you missed this earlier... |
| 01:37 | <Lachy> | <Lachy> Hixie, re: using HTTP URLs for Microdata itemtype, does it have to be a URL at all? http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-January/024770.html |
| 01:37 | <Lachy> | <Lachy> The problem I have with using URLs for this, and for namespaces in general, is that formats will most likely out-last the organisation that created them and assigned the namespace or itemtype URL |
| 01:38 | <Hixie> | what should we use instead? people didn't like the reverse-dns identifiers |
| 01:38 | <Hixie> | and urls are what rdf uses already |
| 01:38 | <Hixie> | users didn't have any problems dealing with urls in the studies, fwiw |
| 01:38 | <Lachy> | I know that, and realise we're stuck with URLs, at least for RDF conversion. |
| 01:39 | <Lachy> | I just don't like the idea of tying widely used metadata formats to one particular organisation. |
| 01:39 | <Hixie> | *shrug* |
| 01:39 | <Lachy> | and one of the problems that has occured with namespaces is that there's no widely used convention for how the URLs should be structured, so we've ended up with a wide range of confusing, non-memorable URLs |
| 01:40 | <Lachy> | which often contain effectively meaningless stuff like the years in the older W3C namespaces |
| 01:42 | <Lachy> | e.g. compare http://www.w3.org/1999/xhtml, http://www.w3.org/2005/Atom (note the unexpected capital A), http://www.w3.org/XML/1998/namespace |
| 01:43 | <Lachy> | so I would prefer that we could come up with a simpler, predictable format for itemtype, which identify the format, without identifying the organisation that happened to define it |
| 01:44 | <Hixie> | this is not a battle i want to engage in, but if you can find a solution that i can adopt without having to spend effort defending, i'll happily do so |
| 01:46 | <Lachy> | I also assume that using a centralised registry won't go down well either, since one of the claimed benefits I've heard for using URLs, is that it piggy backs on top of the existing DNS registry |
| 01:47 | <Hixie> | long term i think we need to support URLs anyway, given the volume of vocabularies already using them, and if we have to support _two_ mechanisms, that may be worse than URLs, however good the alternative mechanism |
| 01:47 | <Hixie> | which may be an argument for not bothering |
| 01:47 | <Hixie> | (it was the argument against reverse-dns -- it just wasn't enough of a gain to be worth it) |
| 01:48 | <Lachy> | hmm, ok. That does suck that we have to continue to suffer from the mistakes of RDF and namespaces :-( |
| 01:49 | <Hixie> | just like we have to suffer from SVG's design mistakes |
| 01:49 | <Lachy> | btw, is there any plan to switch the itemtypes from using n.whatwg.org URLs to W3C URLs, or is the intention just to keep those permanently, regardless of whatever eventually happens with microdata? |
| 01:49 | <Hixie> | and just like people in the future will have to deal with ours |
| 01:49 | <Hixie> | e.g. the storage mutex |
| 01:50 | <Hixie> | i don't intend to change anything |
| 01:50 | <Lachy> | ok |
| 01:50 | <Hixie> | of course if the w3c can provide a better URL (-> shorter, memorable) before that one gains usage, then i don't see why we wouldn't use it |
| 01:52 | <Lachy> | it's going to be nice when spammers inevitably take over whatwg.org and start serving ads or even malicious content from those URLs |
| 01:53 | <Hixie> | i wish i could renew domains for more than 1 year at a time |
| 01:53 | <Hixie> | i'd just renew it for 100 years if i could |
| 01:53 | <Lachy> | that depends which provider you register it through |
| 01:53 | <Hixie> | dreamhost |
| 01:54 | <Lachy> | I thought the maximum permitted by the .com registry was about 10 years |
| 01:54 | <Hixie> | that's already pretty miserly |
| 01:54 | <AryehGregor> | Maybe DNS won't exist in 100 years, then you wasted your money. |
| 01:55 | <Lachy> | but I once saw one registrar use a loophole to allow 100 year registrations, where they would register it for 10 and promise to keep renewing it automatically |
| 01:56 | <Hixie> | AryehGregor: it's ok, by then the money would have been worthless anyway :-P |
| 02:14 | <Hixie> | http://www.w3.org/mid/201001201816.14025.Dr.O.Hoffmann⊙gd |
| 02:14 | <Hixie> | "Already XHTML2 was considered to be too progressive" |
| 02:14 | <Hixie> | i really don't think that's the criticism i would level at XHTML2 |
| 02:16 | <AryehGregor> | Maybe "too progressive" means "trying to make too much progress". |
| 02:22 | <Hixie> | XHTML2 was one of the slowest moving specs the W3C has ever worked on, so that doesn't seem like a valid criticism either |
| 02:22 | <AryehGregor> | I said trying, not succeeding. |
| 02:25 | <AryehGregor> | As in, it tried to improve HTML as much as possible, even regardless of backward compatibility. |
| 02:25 | <boblet> | MikeSmithX: Hey Mike, are you in town today? |
| 02:28 | <boblet> | heh |
| 04:12 | <othermaciej> | so, http://dev.w3.org/html5/status/issue-status.html now lists every issue that's still open |
| 04:13 | <othermaciej> | and has per-issue permakinks |
| 04:13 | <othermaciej> | *pernalinks |
| 04:13 | <othermaciej> | dang it |
| 04:13 | <othermaciej> | permalinks |
| 04:17 | <cardona507> | wow - so google is putting HTML5 now into youtube http://youtube-global.blogspot.com/2010/01/introducing-youtube-html5-supported.html |
| 04:17 | <cardona507> | very sweet |
| 04:19 | <othermaciej> | I wonder when you can actually enable it (instead of just seeing it on the demo page) |
| 04:19 | <othermaciej> | I would love to be done with using Flash for YouTube... |
| 04:20 | <jcranmer> | everyone keeps saying that "oh, theora quality sucks", but people have pointed out that theora outperforms youtube at current quality levels |
| 04:23 | <cardona507> | jcranmer - I read Chris DiBona from Google say “If [YouTube] were to switch to Theora and maintain even a semblance of the current YouTube quality it would take up most available bandwidth across the Internet.” |
| 04:24 | <cardona507> | http://www.betanews.com/article/Stalemate-for-Web-standards-continues-with-no-open-video-for-HTML-5/1248278484 |
| 04:25 | <cardona507> | othermaciej - I wonder the same - as I am sure you know Youtube has had the sample page up for quite a while - but the announcement from today makes it seem like soon if you are running a modern webkit browser it will just load <video> - I too am waaay over flash for youtube |
| 04:26 | <othermaciej> | cardona507: it sounded like you could now enable HTML5 mode on all pages, but it looks like all there is for now is a demo page |
| 04:26 | <cardona507> | Here is another article from techcrunch that explains it a bit more http://www.techcrunch.com/2010/01/20/youtube-html5/ |
| 04:27 | <cardona507> | It sends you to this page to "activate" the feature http://www.youtube.com/testtube |
| 04:28 | <cardona507> | but yeah - it only sends me to the original html5 video example page - |
| 04:28 | <jcranmer> | cardona507: [citation needed] |
| 04:28 | <cardona507> | I guess we will see more and more over the coming weeks |
| 04:28 | <cardona507> | jcranmer - I posted the link below |
| 04:28 | <jcranmer> | http://people.xiph.org/~greg/video/ytcompare/comparison.html |
| 04:29 | <cardona507> | http://www.betanews.com/article/Stalemate-for-Web-standards-continues-with-no-open-video-for-HTML-5/1248278484 |
| 04:29 | <cardona507> | oh - nice |
| 04:29 | <jcranmer> | theora has comparable quality and comparable bitrates under "standard" arguments |
| 04:30 | <cardona507> | What is the main argument against using it then? that it "might" have silent patents? |
| 04:30 | <jcranmer> | no hardware decoders was a major reason listed |
| 04:31 | <jcranmer> | I suspect that's probably the primary reason Apple and Nokia dug in their heels |
| 04:32 | <cardona507> | I am really hoping hoping that google gets a codec from it's potential On2 acquisition and makes it open source - that would be great |
| 04:36 | <cardona507> | On an entirely unrelated and unlikely wish- I sure wish that microsoft would scrap Trident and go with Webkit for IE 9 - Hey we can dream can't we? |
| 04:38 | <othermaciej> | I think the odds of that are pretty much nil |
| 04:38 | <cardona507> | :D |
| 04:39 | <cardona507> | webkit is turning into a defacto standard for modern browsers - especially mobile |
| 04:39 | <cardona507> | (as you all know) |
| 04:40 | <cardona507> | What are the chances of firefox going with webkit? also nil? |
| 04:41 | <jcranmer> | yep |
| 04:43 | <jcranmer> | I would be remiss if everyone went to one layout engine |
| 04:43 | <cardona507> | I guess an entirely homogenous environment (all modern broswers using webkit) could potentially be a security hazard |
| 04:43 | <jcranmer> | it would essentially become an innovation graveyard as ewll |
| 04:53 | <Necrathex> | presto 2.5 seems pretty awesome though |
| 05:00 | <cardona507> | Necrathex - yeah - I agree - |
| 05:01 | <cardona507> | pretty interesting that opera bought an ad network today |
| 05:01 | <cardona507> | or at least the announcement was today |
| 06:32 | <beilabs> | Are there any examples of a basic rails app which syncs offline/online data using HTML5? |
| 07:56 | <Hixie> | hmm |
| 07:59 | <othermaciej> | Hixie: ayt? |
| 07:59 | <othermaciej> | Hixie: I guess you are since you just said something |
| 07:59 | <Hixie> | hey |
| 07:59 | <othermaciej> | I have a hopefully brief question relating to a WebKit bug |
| 08:00 | <othermaciej> | someone submitted a patch that would cache the actual NodeList objects returned by getElementsByTagName, getElementsByTagNameNS, getElementsByName, and getElementsByClassName |
| 08:00 | <othermaciej> | so if called on the same node with the same parameter twice, they would return the same value |
| 08:00 | <othermaciej> | DOM Level 3 Core seems to explicitly forbid this for gEBTN and gEBTNNS |
| 08:00 | <othermaciej> | but for the two specified in HTML5, it does not say one way or the other |
| 08:01 | <othermaciej> | here is the bug: https://bugs.webkit.org/show_bug.cgi?id=33696 |
| 08:01 | <othermaciej> | my comment links the relevant spec sections: https://bugs.webkit.org/show_bug.cgi?id=33696#c17 |
| 08:01 | <othermaciej> | my question to you is whether HTML5's silence on whether these methods return a new object is meant to intentionally diverge from DOM Core and allow caching, or if it's just an oversight and is actually supposed to match DOM Core |
| 08:03 | <Hixie> | the latter |
| 08:04 | <othermaciej> | ok |
| 08:04 | <Hixie> | can you file a bug for that? |
| 08:04 | <othermaciej> | I will |
| 08:04 | <Hixie> | thanks |
| 08:04 | <othermaciej> | I think it would be better if DOM 3 Core and HTML5 both allowed caching, but it certainly seems bad for them to differ |
| 08:04 | <othermaciej> | so probably the right thing to do is fix it in DOM Core first |
| 08:05 | <Hixie> | i would rather scripts always get reliably a new object |
| 08:05 | <Hixie> | so that they don't start getting non-interoperable behaviour if they're messing with properties on these objects |
| 08:05 | <Hixie> | either it should always return the same object or never, imho |
| 08:06 | <othermaciej> | that is indeed somewhat safer to always return a new object |
| 08:06 | <Hixie> | it seems like it'd be relatively easy to implement wrappers that make it seem like they're new objects while being mostly the same object internally |
| 08:06 | <othermaciej> | the only reason I was enthused about the caching is that I think setting custom properties on NodeLists is kinda rare, and the performance win seems really big |
| 08:06 | <othermaciej> | that is in fact what we do currently |
| 08:06 | <Hixie> | what's most of the win from? |
| 08:06 | <Hixie> | is creating JS objects that expensive? |
| 08:07 | <othermaciej> | I believe most of the win is from not allocating the JS-level wrapper, but it's not my patch and I did not do profiling so I can't say for sure |
| 08:07 | <Hixie> | ah |
| 08:07 | <Hixie> | maybe you can do copy-on-write magic or something |
| 08:08 | <othermaciej> | that's not really practical to do with JS objects |
| 08:08 | <othermaciej> | they can easily share all their innards but be different wrappers, and we do that already (essentially) |
| 08:08 | <othermaciej> | but you can't have two pointers to the same JS-level wrapper turn different later |
| 08:08 | <othermaciej> | so there's no way to avoid doing an allocation on every call with the current requirements |
| 08:09 | <Hixie> | seems like you should be able to add one level of indirection -- one pointer and one bit, in fact -- but i guess the code complexity would be disproportionate |
| 08:10 | <Hixie> | and i guess the cost could be prohibitive |
| 08:10 | <Hixie> | relative to the win |
| 08:10 | <othermaciej> | it's really the fixed overhead of allocating the JS wrapper that I believe is the expensive part, so adding a level of indirection would not help, since the indirect part would have to be allocated as a JS value itself |
| 08:10 | <othermaciej> | to work with the GC |
| 08:12 | <Hixie> | ah, yeah |
| 08:12 | <Hixie> | surely your JS wrappers are all fixed-size and can be arena allocated really cheaply |
| 08:13 | <Hixie> | seems odd that that would be the expensive bit |
| 08:13 | <Hixie> | allocating the actual NodeList, sure |
| 08:15 | <othermaciej> | GC allocation ain't cheap |
| 08:15 | <othermaciej> | allocating the C++-level NodeList might be a big part of the cost too, and in theory we can have distinct wrappers for the same C++-level NodeList |
| 08:16 | <othermaciej> | I think our caching right now is of an object that's shared by multiple C++ NodeLists |
| 08:16 | <othermaciej> | I can suggest trying that to the contributor and see if returning the same actual JS-level NodeLists still looks like a big win after |
| 08:17 | <othermaciej> | filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=8792 |
| 08:17 | <Hixie> | with the caveat that i am talking out of my nether regions, it seems like getting GC structures to allocate fast would be a good win in general |
| 08:17 | <Hixie> | but i expect you have experts who are better positioned to work out this kind of thing :0) |
| 08:17 | <Hixie> | :-) even |
| 08:18 | Hixie | poured water on his macbook pro yesterday and has been relegated to an X41 |
| 08:18 | <Hixie> | running Windows |
| 08:18 | <Hixie> | what a life |
| 08:18 | <othermaciej> | Hixie: I am sure JSC and V8 have both put a good bit of work into tuning our respective GC allocators |
| 08:19 | <othermaciej> | there are some fundamental limits |
| 08:19 | <Hixie> | yeah |
| 08:19 | <othermaciej> | in the case of this test it's not just the allocation, but the fact that you are creating lots of garbage |
| 08:19 | <othermaciej> | and every garbage JSNodeList needs to have a finalizer |
| 08:19 | <Hixie> | makes sense |
| 08:19 | <othermaciej> | that will strain any GC algorithm I know of |
| 08:20 | <othermaciej> | anyway I r-'d the patch for now |
| 08:21 | <othermaciej> | I am finding that a lot more WebKit contributors are submitting stuff lately that I have to r- because it directly violates a spec, without apparent compatibility need (or similarly good reason) |
| 08:21 | <othermaciej> | I am not sure what to do about this |
| 08:22 | <othermaciej> | also I am far from the only reviewer so I wonder how much of that sorta thing is slipping through |
| 08:22 | <othermaciej> | not that it's your problem |
| 08:22 | <Hixie> | yeah i dunno what the solution is |
| 08:22 | <Hixie> | what other kind of stuff has there been? |
| 08:24 | <othermaciej> | one that I specifically recall is someone submitting a patch to implement HTML5 footer that tried to enforce the content model in the parser |
| 08:24 | <othermaciej> | i.e. it would actually reparent on an attempt to nest <footer> elements |
| 08:24 | <Hixie> | oh yeah, i saw that one |
| 08:24 | <Hixie> | that seems like a pretty fundamental failure to read the spec |
| 08:24 | <Hixie> | some of the feedback on the mailing lists has been like that too |
| 08:28 | <othermaciej> | standards are complex |
| 08:28 | <othermaciej> | and it can take a while to get up to speed on some of the basic concepts |
| 08:46 | Hixie | is baffled at the apparent lack of online chat or e-mail support for natwest bank accounts |
| 08:47 | <Hixie> | can anyone in the UK check for me whether you guys have the internet yet? |
| 08:49 | <MikeSmith> | Hixie: I spilled beer on my Macbook keyboard a while back, so I bought one of those newish aluminum bluetooth keyboards, which worked great |
| 08:50 | <MikeSmith> | excpet that I split coca-cola on it a while ago, so now several of the keys have this gummy response action |
| 08:50 | <MikeSmith> | when I get a new machine, I guess I should probably invest in a keyboard cover |
| 08:50 | <Dashiva> | http://twitter.com/sideshowbarker/status/8020153069 |
| 08:50 | <Dashiva> | Isn't it reasonable to assume anything application/* isn't text? |
| 08:51 | <hsivonen> | Dashiva: it's reasonable to assume it's not text in the IETF sense of text |
| 08:51 | <hsivonen> | Dashiva: it's not reasonable to assume it's not text in the common-sense sense of text |
| 08:51 | <Hixie> | MikeSmith: well for me this is only a temporary inconvenience, since google will just get me a replacement, but still, it's an inconvenience :-) |
| 08:52 | <MikeSmith> | Dashiva: the direct problem in my case is that svn refuses to do diffs on anything it thinks is a binary file |
| 08:54 | <MikeSmith> | Hixie: my problem is that any time I get a new/replacement machine, I lose all my old stickers I have on current one, then I have to spend a bunch of time finding stuff to re-sticker the new one with |
| 08:55 | <MikeSmith> | Dashiva: what hsivonen said |
| 08:55 | <Dashiva> | But would we have that problem at all if XML hadn't decided against being text/*? |
| 08:56 | <MikeSmith> | ain't just a problem for XML mime types |
| 08:59 | <Dashiva> | I just can't find any obvious examples that aren't XML or XML me-toos. |
| 09:01 | <hsivonen> | Dashiva: RELAX NG Compact Syntax |
| 09:01 | <hsivonen> | Dashiva: PostScript |
| 09:01 | <hsivonen> | Dashiva: a PDF without flate streams |
| 09:02 | <othermaciej> | holy crap I'm running HTML5 YouTube |
| 09:02 | <othermaciej> | I even checked that there's really a <video> element in the DOM |
| 09:03 | <hsivonen> | It's a shame they don't support unencumbered formats |
| 09:04 | <othermaciej> | I am just amazed that it actually works |
| 09:04 | <othermaciej> | with the load thermometer and everything |
| 09:05 | <othermaciej> | now my only reason to use Flash is Flash games |
| 09:07 | <erlehmann> | othermaciej, there is a html5 youtube? not only that demo? |
| 09:07 | <othermaciej> | erlehmann: now you can enable "HTML5 beta" which gives it to you on all their videos |
| 09:07 | <hsivonen> | erlehmann: http://youtube-global.blogspot.com/2010/01/introducing-youtube-html5-supported.html |
| 09:07 | <othermaciej> | (earlier it was only the demo page) |
| 09:08 | <Rik`> | othermaciej: you could already use youtube with html5 with clicktoflash in Safari |
| 09:08 | <Rik`> | btw, the activation page is pretty bad |
| 09:08 | <erlehmann> | i'm shocked and appalled ! thanks |
| 09:08 | <hsivonen> | Rik`: what's clicktoflash? |
| 09:09 | <Rik`> | hsivonen: a Safari plugin similar to flashblock |
| 09:09 | <othermaciej> | yeah but I'm not willing to run haxies |
| 09:09 | <hsivonen> | Rik`: YouTube was also available as HTML5 in Chromium+encumbered ffmpeg and Chrome using some kind of user script |
| 09:09 | <Rik`> | hsivonen: http://rentzsch.github.com/clicktoflash/ |
| 09:09 | <Rik`> | <p>Right now we support browsers that support both the <video> tag in HTML5 and the h.264 video codec. These include:</p> |
| 09:10 | <Rik`> | the <video> tag should be >video< |
| 09:10 | <hsivonen> | Rik`: whoa. that goes into ~/Library/Internet Plug-ins/ |
| 09:10 | <erlehmann> | sadly, no theora ;_; |
| 09:11 | <hsivonen> | Rik`: so it's not an input manager? surely NPAPI doesn't offer enough surface for this |
| 09:11 | <hsivonen> | Rik`: or does it override Flash's mime registrations or something? |
| 09:12 | <hsivonen> | and hosts Flash inside the other plug-in? |
| 09:12 | <Rik`> | I think it overrides the mime registration |
| 09:13 | <Rik`> | that's what I understand in http://github.com/rentzsch/clicktoflash/blob/master/Plugin/Info-Plugin.plist |
| 09:13 | <othermaciej> | it steals Flash's MIME registration |
| 09:13 | <othermaciej> | it only works because WebKit plugins take priority over NPAPI plugins |
| 09:13 | <hsivonen> | people go to great lengths to avoid Flash |
| 09:14 | <Rik`> | clicktoflash blocks flash and add a few nice stuffs like html5 on youtube and special treatment for sifr titles |
| 09:14 | <hsivonen> | we had some people over and one person (a physicist, not a software developer) was praising the virtues of not having Flash but having enough Chromium trickery for watching YouTube videos nonetheless |
| 09:14 | <othermaciej> | I wish YouTube would stop telling me to download Chrome on every single page though |
| 09:15 | <Rik`> | oh, that doesn't work for embedded videos :( |
| 09:21 | <hsivonen> | intersting. YouTube shows the Chrome ad in Safari on Mac but not in Minefield on Mac |
| 09:22 | <hsivonen> | ad also shown in Opera |
| 09:23 | <hsivonen> | leveraging leadership in one service to promote another product, I guess |
| 09:27 | <Rik`> | and so I miss a "Go fullscreen" button in Safari |
| 09:35 | <Lachy> | othermaciej, from what I can tell, it seems that Minefield does return the same object from subsequent getElementsByTagName calls. (Opera and WebKit don't) |
| 09:35 | <Lachy> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3Etest%3C%2Fp%3E%0A%3Cscript%3E%0Avar%20a%20%3D%20document.getElementsByTagName%28%22p%22%29%3B%0Aa.foo%20%3D%20%22FAIL%22%0Avar%20b%20%3D%20document.getElementsByTagName%28%22p%22%29%3B%0Aw%28%22Same%20object%3A%20%22%20%2B%20%28a%20%3D%3D%3D%20b%29%29%3B%0Aw%28%22foo%20property%3A%20%22%20%2B%20b.foo%29%3B%0A%3C%2Fscript%3E%0A |
| 09:36 | <othermaciej> | Lachy: ORLY |
| 09:36 | <othermaciej> | Lachy: that's a direct violation of DOM Level 3 Core if true |
| 09:36 | <othermaciej> | I wonder if it is intentional |
| 09:36 | <othermaciej> | Lachy: Minefield only, or also release Firefox? |
| 09:37 | <othermaciej> | Lachy: doesn't happen in Firefox 3.5.2 for me |
| 09:40 | <othermaciej> | Lachy: cannot reproduce |
| 09:40 | <othermaciej> | Lachy: in latest Mnefield on Mac |
| 09:40 | <othermaciej> | oh, I gess the w function is not doing anything |
| 09:42 | <othermaciej> | Lachy: seems to be true in Firefox 3.5.2 as well |
| 09:42 | <othermaciej> | Lachy: not sure whether to file a Firefox bug or r+ the WebKit patch to do the same now... |
| 09:43 | <othermaciej> | I am not sure how to find out if this kind of thing is intentional |
| 09:43 | <othermaciej> | wish there were someone here to ask |
| 09:46 | <hsivonen> | Boris would most likely know |
| 09:52 | <hsivonen> | othermaciej: I did some hg mining but I didn't find anything obviously intentional in the post-3.5 time frame |
| 09:52 | <othermaciej> | hsivonen: the change already exists in 3.5.2, my initial testing was mitsaken |
| 09:53 | <hsivonen> | othermaciej: http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsContentList.cpp#221 |
| 09:54 | <hsivonen> | othermaciej: there's a cache whose existence predates the migration to mercurial |
| 09:55 | <hsivonen> | othermaciej: https://bugzilla.mozilla.org/show_bug.cgi?id=140758 |
| 09:55 | <othermaciej> | if Mozilla is already doing this for a long time and doesn't have resulting problems, then it's likely not a compat problem to allow it |
| 09:56 | <hsivonen> | I don't know about the absence or presence of problems |
| 09:57 | <othermaciej> | hsivonen: so it seems intentional and longstanding to return the same NodeList, but there doesn't seem to mention of intentionally violating the DOM spec |
| 10:12 | <Lachy> | othermaciej, the w() function just outputs the value to the log below. It says "Same object: true" for me in Minefield, but false in Opera and WebKit |
| 10:13 | <othermaciej> | Lachy: I see the same (after changing to document.write) and Firefox 3.5.2 also has the Minefield behavior |
| 10:13 | <othermaciej> | hsivonen also found that this Firefox behavior dates back to 2002 |
| 10:13 | <Lachy> | wasn't the w() function working for you? |
| 10:13 | <othermaciej> | I might not have looked in the right place |
| 10:13 | <Lachy> | it's in the log at the very bottom of the page, below the rendered view of the page |
| 10:14 | <othermaciej> | indeed I did not - since the log was scrolled off the bottom of my window |
| 10:16 | <Lachy> | othermaciej, why are we going to do a new CfC for publishing Microdata? |
| 10:17 | <othermaciej> | Lachy: the new CfC will be for HTML5, Microdata, 2D Context, and HTML+RDFa to all get first or new Working Drafts |
| 10:18 | <othermaciej> | Lachy: reasons for a new CfC are threefold: |
| 10:18 | <othermaciej> | (a) some of the objections from the first one will be addressed by Hixie's changes |
| 10:18 | <othermaciej> | (b) the HTML5 proposed for publication originally will be materially changed by the further splitting of 2D Context |
| 10:19 | <othermaciej> | (c) may as well just have one CfC for everything we want to publish |
| 10:20 | <Hixie> | you know, it strikes me that i have no way to describe a string as having to match the HTML or XML syntax |
| 10:20 | <Hixie> | this seems like a substantial oversight |
| 10:20 | <Lachy> | really? How do you state that requirement for innerHTML? |
| 10:21 | <Hixie> | there are no conformance criteria for what hte value passed to innerHTML should be |
| 10:21 | <Lachy> | ok |
| 10:22 | <Hixie> | i guess for this body="" or whatever we end up calling it, i can add a new subsection to the syntax section that describes a document with the doctype made optional |
| 10:22 | <Hixie> | and then i can make the <title> section say that it can be omitted for these types of documents |
| 10:23 | <Hixie> | i'm leaning towards calling the attribute doc="" or srcdoc="" again, btw, since body="" doesn't really work if it's a full doc (especially in xml) |
| 10:24 | <Lachy> | you could call it content="" |
| 10:25 | <Hixie> | that's confusingly similar to <meta content>, especially with microdata |
| 10:26 | <Hixie> | it would also screw over RDFa |
| 10:26 | <Hixie> | which I'd rather not do |
| 10:26 | <Lachy> | ok |
| 10:26 | <Lachy> | how would it screw over RDFa? Do they use a content attribute? |
| 10:27 | <Hixie> | yeah, iirc |
| 10:27 | <Lachy> | I don't mind if you screw over RDFa. I'm ignoring their spec entirely |
| 10:29 | <Philip`> | inlinesrc="..." |
| 10:32 | <hsivonen> | does pagehide fire if the document being navigated away from hasn't fired its onload yet? |
| 10:34 | <hsivonen> | hmm. doesn't matter in the case I'm looking at |
| 10:38 | <Creap> | Is there a place with an easy list of all legal attributes in HTML5? for a syntax checker |
| 10:39 | <Lachy> | Creap, there's the index of attributes in the spec http://www.whatwg.org/specs/web-apps/current-work/#attributes-0 |
| 11:12 | <AryehGregor> | HTML5 YouTube, awesome. Now all it needs is fullscreen support. |
| 11:12 | <AryehGregor> | Maybe I'll still have to switch from Chrome to Firefox to view YouTube, for the fullscreen support instead of Flash. :P |
| 11:13 | <Necrathex> | isn't it possible for youtube to support both h264 and theora, so everyone is happy? |
| 11:13 | <AryehGregor> | Hmm, it also doesn't work on lots of videos. |
| 11:14 | <AryehGregor> | Necrathex, if they transcode their ridiculously large existing body of content, yes, in theory. |
| 11:14 | <AryehGregor> | Oh, right, I can't use Firefox to view YouTube, no H.264 support. Rats. |
| 11:14 | <AryehGregor> | Well, I guess I still will sometimes, just using Flash. |
| 11:14 | <Necrathex> | well, they did that before with the transition to HQ and HD vids |
| 11:16 | <zcorpan__> | AryehGregor: you could use opera on linux if your gstreamer can play h264 |
| 11:17 | <AryehGregor> | zcorpan__, interesting thought. Does it support full-screen? |
| 11:17 | <zcorpan__> | AryehGregor: no, not yet |
| 11:17 | <AryehGregor> | Also, YouTube doesn't say it's supported. |
| 11:17 | <hsivonen> | a new public draft of XHTML2 is out: http://www.w3.org/MarkUp/2010/ED-xhtml2-20100113/ |
| 11:17 | <AryehGregor> | Well, then I may as well keep using Chrome. :) |
| 11:17 | <AryehGregor> | Wait, I thought the XHTMLWG had been discontinued? |
| 11:19 | <hsivonen> | AryehGregor: the charter of the XHTML2 WG expired at the end of last year, but apparently the WG didn't turn into a pumpkin immediately |
| 11:19 | <AryehGregor> | You can publish new working drafts without a charter? |
| 11:20 | <hsivonen> | AryehGregor: I've heard you can. |
| 11:20 | <AryehGregor> | Obviously so. |
| 11:20 | <AryehGregor> | Then what's the point of a charter, though . . . ? |
| 11:20 | <AryehGregor> | Could they decide they'd publish a new version of PNG too? That's not outside their charter right now. :) |
| 11:21 | <AryehGregor> | Well, I guess we can now go back to telling people who don't like HTML5 to join the XHTMLWG. |
| 11:21 | <hsivonen> | the XHTML2 WG |
| 11:22 | <Hixie> | zombie wg! |
| 11:22 | <Hixie> | actually to be fair they published that note (which they were required to publish) within only a few weeks of the charter running out |
| 11:23 | <Hixie> | in w3c terms that's positively timely |
| 11:23 | <Hixie> | contrast with us (the htmlwg), we're at this point something like a year or two behind schedule |
| 11:24 | <hsivonen> | did they already publish it as a Note. I thought it was still an ED for a Note. |
| 11:24 | <gsnedders> | I guess this is basically because everything published as a FPWD must become a REC or a NOTE |
| 11:24 | <Hixie> | hsivonen: oh i thought that was the note |
| 11:25 | <hsivonen> | so pagehide is supposed to fire in all iframes of a pages that is being navigated away from, right? |
| 11:25 | <hsivonen> | are there some exceptions to this? |
| 11:25 | <Hixie> | how come if i publish an ED that claims to be a WD or NOTE i get told off but they can do it and it's fine? |
| 11:25 | <Philip`> | It does say "W3C Note" on the left, and "This document is a Working Group Note. The XHTML2 Working Group's charter expired before it could finish work on this specification.", so I'd assume it's meant to be a Note |
| 11:26 | <Hixie> | doesn't seem to have made the TR/ page yet |
| 11:26 | <Hixie> | but the 13th was a long time ago |
| 11:26 | <zcorpan__> | maybe they just forgot to change the boilerplate |
| 11:26 | <Philip`> | Hixie: Maybe because HTML5 is important enough for people to care about, whereas fewer people worry about what happens with XHTML2 |
| 11:26 | <Philip`> | Hixie: Or maybe because everybody hates you and wants to make trouble for you |
| 11:27 | <Hixie> | your first hypothesis was better |
| 11:27 | <Hixie> | i don't like the other one |
| 11:27 | <Hixie> | it makes me sad |
| 11:27 | <Philip`> | Hopefully evidence supports the first one :-) |
| 11:28 | <hsivonen> | shouldn't a scientist test both hypotheses? |
| 11:28 | <Hixie> | i gave up science after university |
| 11:29 | <AryehGregor> | hsivonen, sure. Shall we go find one? |
| 11:30 | <hsivonen> | AryehGregor: go ahead :-) |
| 11:31 | <AryehGregor> | Bah, Analytics still uses Flash all over the place. |
| 11:31 | AryehGregor | glares at it |
| 11:46 | <hsivonen> | so, pagehide is supposed to be targeted at the document but be dispatched on the window, right? |
| 11:47 | <hsivonen> | and then there's another piece of magic that handles the onpagehide attribute on the body element, right? |
| 11:47 | <hsivonen> | so the event handler magically goes on window and not on body, right? |
| 11:48 | <zcorpan__> | hsivonen: yes, onpagehide on HTMLBodyElement and HTMLFrameSetElement register a listener on window |
| 11:48 | <hsivonen> | ok. |
| 11:48 | <zcorpan__> | hsivonen: and yes to the first question |
| 11:48 | <hsivonen> | and pagehide and unload are sync, and pageshow and load are always async, right? |
| 11:49 | <zcorpan__> | i don't know about syncness |
| 11:49 | <hsivonen> | ok. thanks |
| 12:03 | <Lachy> | AryehGregor, which videos on YouTube now support HTML5? Have they started rolling out support for that already? |
| 12:04 | <AryehGregor> | Lachy, yes. |
| 12:04 | <AryehGregor> | http://youtube-global.blogspot.com/2010/01/introducing-youtube-html5-supported.html |
| 12:04 | <AryehGregor> | Not all videos, but a lot. |
| 12:05 | <AryehGregor> | You'll have to check if they do browser sniffing or capability testing to exclude Opera. :) |
| 12:05 | <Lachy> | awesome, 1080p is coming too! http://youtube-global.blogspot.com/2009/11/1080p-hd-comes-to-youtube.html |
| 12:08 | <Lachy> | where can I find an actual video page using <video>? |
| 12:08 | <Lachy> | I clicked the link on http://www.youtube.com/html5 to join the HTML5 beta |
| 12:09 | <virtuelv> | Lachy: after you have joined, I think you can go to any video and get html5 |
| 12:10 | <Lachy> | it doesn't seem to be supported on any video, but I found one http://www.youtube.com/watch?v=YQThSvHiYjU&feature=popular |
| 12:26 | <zcorpan__> | has anyone tried it with opera (on linux)? |
| 12:27 | <Necrathex> | cant even get it to work in chromium |
| 12:28 | <Lachy> | Hixie, the Save link on the Live DOM Viewer seems to be broken |
| 12:39 | <Hixie> | huh |
| 12:47 | <Hixie> | i have no idea why |
| 12:47 | <Hixie> | seems sqlite changed |
| 12:47 | <Hixie> | but i don't see how |
| 12:47 | <Hixie> | i mean, how it is differnet |
| 12:52 | <Hixie> | well i did something that shouldn't have made any difference |
| 12:52 | <Hixie> | and it seems to work now |
| 12:53 | <Hixie> | nn |
| 12:56 | <ader10> | Does the HTML5 doctype tag work in IE5? |
| 12:59 | <hsivonen> | ader10: IE 5 doesn't have modes, so mode switching considerations are irrelevant. I haven't tested it for parsing oddities, though. |
| 12:59 | <ader10> | Thanks for your helpful answer. |
| 13:01 | <gsnedders> | ader10: For IE5/Mac, which nobody uses, it uses standards mode AFAIK |
| 13:20 | <hsivonen> | judging from the YouTube feedback forum, Google now has the kind of fanboyism Apple has had for years |
| 13:43 | <dytrivedi> | joined! |
| 14:56 | <AryehGregor> | Wow, rumor has it that Bing might become the default search on the iPhone? Microsoft and Apple *teaming up*, against Google? How times change. |
| 14:59 | <Philip`> | If it's true, I'd tend to assume it's more to do with Microsoft offering Apple more money to be the default search provider than Google is offering, rather than being about teaming up with/against anyone |
| 15:00 | <Philip`> | (I'd assume that's the same reason Opera oscillates between Google and Yahoo and Ask as the default) |
| 15:02 | <hsivonen> | when has Ask been the default on Opera? |
| 15:02 | <AryehGregor> | Eh, there's a lot of strategizing here too. Does Google really pay Mozilla tens of millions of dollars a year just to be the default search provider, or also to get at Microsoft? |
| 15:03 | <Philip`> | hsivonen: It's the default right now, on the Speed Dial page in 10.10 |
| 15:03 | <Philip`> | (although "default" probably isn't the right term, because I don't think it's possible to change it to anything else) |
| 15:04 | <FireFly> | Philip`, it's trivial to change it |
| 15:04 | <hsivonen> | Philip`: oh |
| 15:04 | <hsivonen> | does Ask actually work? |
| 15:04 | <FireFly> | Right click -> manage search engines |
| 15:04 | <Philip`> | FireFly: Ah, right, I just found that |
| 15:04 | <Philip`> | hsivonen: No idea, I never use it :-) |
| 15:04 | <hsivonen> | does Ask do their own R&D or do they outsource to someone else? |
| 15:05 | <hsivonen> | who is supplying actual search back end stuff other than Google and Microsoft? |
| 15:05 | <takkaria_> | I thought Ask used google's backend |
| 15:05 | <hsivonen> | Opera defaults to Google to me |
| 15:05 | <Philip`> | As far as I'm aware they have their own backend |
| 15:05 | <hsivonen> | is it Ask just for new installations? |
| 15:05 | <Dashiva> | Yandex? :) |
| 15:06 | <Lachy> | oh, I didn't know we'd switched the speeddial search to Ask. |
| 15:06 | <Philip`> | e.g. http://sp.uk.ask.com/en/docs/about/webmasters.shtml talks about their crawler |
| 15:06 | <hsivonen> | oh. it's Ask in Speed Dial and Google in the toolbar |
| 15:06 | <hsivonen> | that's ... interesting |
| 15:07 | <Lachy> | yeah, I think it's a bit silly to have multiple defaults. But AIUI, it's done for financial reasons of some kind, though that's not my department and I have no idea what deals we have with each search engine. |
| 15:09 | <AryehGregor> | I wonder where Opera gets its revenue. Google, Microsoft, and Apple all have huge non-browser sources of revenue, and Mozilla gets paid by Google. |
| 15:09 | <zcorpan__> | opera ships on lots of devices |
| 15:10 | <Lachy> | AryehGregor, we get lots of revenue from device manufactures who pay us to put Opera on their devices. e.g. Nintendo Wii, HTC phones, Samsung phones, etc. |
| 15:10 | <FireFly> | There's the wii browser |
| 15:10 | <AryehGregor> | Ah, right. |
| 15:10 | <Dashiva> | I seem to recall seeing a press release that the desktop browser was also in black, though |
| 15:10 | <AryehGregor> | The non-desktop market. |
| 15:10 | <Dashiva> | A few years back |
| 15:10 | <hsivonen> | Opera Link doesn't tell me about crypto |
| 15:11 | <Lachy> | hsivonen, what would you like to know about it? |
| 15:11 | <Lachy> | If we encrypt the connection between you and Opera Link, or whether the data is stored encrypted on our servers? |
| 15:12 | <Philip`> | AryehGregor: I think the idea was Mozilla gets paid by Google for being the default search engine, and so Opera could do exactly the same (with revenue proportional to market share) |
| 15:12 | <hsivonen> | Lachy: those and whether Opera can decrypt it |
| 15:12 | <Philip`> | (and for search engines other than Google) |
| 15:12 | <hsivonen> | and if Opera can't decrypt it, how does Mini work? |
| 15:13 | <hsivonen> | (for comparison, the crypto key for Weave residers on the user's devices) |
| 15:13 | <hsivonen> | *resides |
| 15:14 | <hsivonen> | Does Google already have a way for syncing Chrome and the Android browser? |
| 15:15 | <hsivonen> | this sync stuff is clearly going to make browser choices more sticky, because one has to buy into the product family of one vendor for all devices |
| 15:15 | <hsivonen> | (well, the Weave API is documented, but I'm not aware of any non-Gecko-based browsers implementing a sync client) |
| 15:17 | <AryehGregor> | Cross-browser sync would be awesome. Especially if it actually synced my logins and cookies, not just useless stuff like bookmarks. |
| 15:17 | <AryehGregor> | It could sync my currently open pages. Maybe even my history, for things like the awesome bar/omnibox, but that might be a bit much. |
| 15:17 | <hsivonen> | already works if you run one product family across all your devices |
| 15:17 | <hsivonen> | I have Weave syncing 3 desktop Firefoxes and one Firefox Mobile |
| 15:18 | <hsivonen> | but then I have a device that has Opera Mobile but not Firefox |
| 15:18 | <AryehGregor> | Well, that only works for Firefox, right? Chrome only supports bookmark sync, I think . . . |
| 15:18 | <hsivonen> | but I can't use Opera Mobile as a Weave client |
| 15:18 | <hsivonen> | AryehGregor: right |
| 15:18 | <Lachy> | hsivonen, I asked internally, and was given this as the answer. http://www.opera.com/privacy/#operalink |
| 15:18 | <Lachy> | they don't seem to want to reveal more than that |
| 15:19 | <hsivonen> | Lachy: thanks |
| 15:19 | <hsivonen> | can Opera Link sync passwords? |
| 15:19 | <AryehGregor> | http://code.google.com/p/chromium/issues/detail?id=812 |
| 15:19 | <hsivonen> | syncing passwords is an awesome feature of Weave |
| 15:20 | <hsivonen> | but I wouldn't sync my passwords using a system where the sync server operator could decrypt |
| 15:21 | <Creap> | let's all put our passwords "in the cloud" :) |
| 15:21 | <hsivonen> | Creap: putting passwords in the cloud is fine if your crypto key doesn't travel to the cloud |
| 15:22 | <AryehGregor> | You'd have to copy a private key between all your computers, then. How would that work? |
| 15:23 | <AryehGregor> | I don't see how it could be as convenient as having a central party know your password. |
| 15:23 | <Philip`> | You could type it in |
| 15:23 | <hsivonen> | AryehGregor: with Weave, I created an insanely long key that I printed and typed in on the other devices once for each |
| 15:23 | <AryehGregor> | Google already knows my Gmail password anyway, and I can use that to recover practically any of my other logins except for my bank, so . . . |
| 15:23 | <Philip`> | (assuming it's like some kind of master password, not a 4096-bit private key) |
| 15:23 | <Lachy> | hsivonen, we do use SSL connections for syncing between the client and the server, but it seems I can't get an answer about what security measures we take to protect the data on the server. |
| 15:24 | <AryehGregor> | Hmm, yeah, a master password would work. |
| 15:24 | <hsivonen> | Lachy: thanks |
| 15:24 | <hsivonen> | AryehGregor: Weave has a password that you log into the server with |
| 15:25 | <hsivonen> | AryehGregor: and with that password, you can retrieve encrypted data from the server |
| 15:25 | <hsivonen> | and then you decrypt it with a long passphrase that never travels to the cloud |
| 15:26 | <hsivonen> | as far as I can tell, the scariest part of Weave is losing your mobile device |
| 15:26 | <AryehGregor> | Can you choose to skip the extra passphrase if you don't care about hiding from the cloud? |
| 15:26 | <hsivonen> | AryehGregor: IIRC, no |
| 15:26 | <AryehGregor> | Also, is someone working on integrating this with the system so that it automatically unlocks when you log in? |
| 15:26 | <AryehGregor> | Because having to type a password every time you start your browser is obnoxious. |
| 15:27 | <hsivonen> | AryehGregor: you don't need to |
| 15:27 | AryehGregor | used master passwords on Firefox and doesn't think the feature exists on Chrome, but doesn't miss it much . . . |
| 15:27 | <hsivonen> | each local browser remembers both the password and the passphase |
| 15:27 | <hsivonen> | which is why losing your mobile device becomes scarier |
| 15:28 | <hsivonen> | but it's so awesome you want to use it on your mobile device anyway |
| 15:28 | <AryehGregor> | Well, I guess if the attacker can't log in, you're safe. Probably an attacker would prefer to just wipe the thing and sell it. A determined one could access everything, but the same is true if you have your browser remember your passwords . . . |
| 15:29 | <hsivonen> | I don't know how safe e.g. Maemo is against an attacker who possesses the device |
| 15:29 | <zcorpan__> | you'd need a way to lock your device from somewhere else if you lose it |
| 15:29 | <hsivonen> | the Maemo security folks work against threats from the network |
| 15:30 | <hsivonen> | or wipe it, like with MobileMe |
| 15:30 | <AryehGregor> | A determined attacker with physical access can probably break anything except an encrypted disk. |
| 15:30 | <zcorpan__> | preferably also a way to find your device again if you lose it |
| 15:30 | <Lachy> | hsivonen, have you tried 1Password? I believe their system does client side encryption before syncing with a server |
| 15:31 | <Philip`> | A determined attacker can grab your device while you're in the middle of using it and are alerady logged in |
| 15:31 | <hsivonen> | Lachy: not with multiple Macs |
| 15:31 | <Creap> | zcorpan__: when I lost my cellphone, someone found "home" and called to return it. |
| 15:31 | <hsivonen> | Lachy: I installed it once on one Mac |
| 15:32 | <Lachy> | hsivonen, I installed it recently to try it out. But I haven't fully learned about how it all works yet, and it seems to have some annoying UI bugs that I don't like |
| 15:32 | <Creap> | android has some PIN:y thing as a screenlock |
| 15:32 | <hsivonen> | Lachy: but I didn't trust the app would always be compatible with everything, so I didn't want to make it part of my routines |
| 15:32 | <hsivonen> | and instead I use Keychain and Firefox password manager |
| 15:32 | <AryehGregor> | Philip`, not necessarily, unless they have a gun or something, or you leave yourself logged in all the time. |
| 15:33 | <hsivonen> | Maemo has a PIN screenlock, too. |
| 15:33 | <Lachy> | the Firefox password manager stores everything in a barely obfuscated password file. |
| 15:33 | <Lachy> | I use that too, but I'm trying to migrate away from it |
| 15:33 | <Lachy> | well, unless you use a master password, but I found that to be rather intrusive |
| 15:34 | <hsivonen> | on Mac, I use Filevault in case immigration officials take my laptop and store it inappropriately |
| 15:35 | <Philip`> | AryehGregor: You don't need a gun to grab a phone out of somebody's hand when they're not expecting it, or from a table when they're not watching it for a few seconds |
| 15:35 | <AryehGregor> | Firefox master passwords are lousy UI. You have a modal dialog popping up at some random point after you restart the browser every time. |
| 15:35 | <Philip`> | AryehGregor: and then you run away before the owner catches you |
| 15:36 | <AryehGregor> | Philip`, okay, granted. |
| 15:36 | <AryehGregor> | Most of us don't face determined attackers, happily. |
| 15:36 | <Philip`> | AryehGregor: Seems a lot simpler than trying to extract passwords from the device's memory |
| 15:38 | <AryehGregor> | Not memory, disk, unless that's encrypted. |
| 15:38 | <workmad3> | physical device security is always a problem |
| 15:38 | <AryehGregor> | That's the easiest way, if you have any technical know-how. |
| 15:38 | <workmad3> | that is, until we have a keypad that can read and check your fingerprint on every key-press :) |
| 15:38 | <AryehGregor> | Much less risky, you can steal it whenever and however you feel like. |
| 15:39 | <AryehGregor> | And don't have to worry that maybe they weren't actually logged in. |
| 15:39 | <AryehGregor> | workmad3, fingerprints are easy for a dedicated attacker to forge. |
| 15:39 | <AryehGregor> | Your fingerprints are going to be all over the phone. |
| 15:39 | <AryehGregor> | Just make a mold, doesn't even take a day if you know what you're doing. |
| 15:39 | <workmad3> | ok... easy until the devices are implanted directly into our bodies |
| 15:39 | <workmad3> | better? :P |
| 15:39 | <AryehGregor> | Yeah, that would solve the issue. |
| 15:40 | <AryehGregor> | It would also freak out some Christians, particularly if the devices were used for commerce. :P |
| 15:40 | <workmad3> | heh :) |
| 15:40 | workmad3 | wants a retina implant for his phone display already |
| 15:41 | <AryehGregor> | Should it treat pt as a physical unit? :) |
| 15:41 | <gsnedders> | hehe |
| 15:43 | <workmad3> | hmm, that's a point (no pun intended)... are there physical differences in the size of rods and cones, and if so, which should be used? |
| 15:44 | <AryehGregor> | What? |
| 15:45 | <AryehGregor> | It seems rods and cones are about the same size. |
| 15:45 | <AryehGregor> | Wait, hmm. |
| 15:45 | <AryehGregor> | Or maybe cones are much larger, the Wikipedia articles are confusing. |
| 15:45 | <AryehGregor> | (as usual) |
| 16:12 | <AryehGregor> | "User agents may wait for a suitable break in the user's interaction before queuing the task; for example, a user agent could wait for the user to have not hit a key for 100ms, so as to only fire the event when the user pauses, instead of continuously for each keystroke." |
| 16:13 | <AryehGregor> | So I guess this means we need to use onkeypress or onkeyup instead of oninput? |
| 16:13 | <AryehGregor> | If we really want to have it be per key. |
| 16:16 | <AryehGregor> | I guess there's no event that fires after the input has happened, so that it will reliably fire once each keystroke and event.target.value will be the current value? |
| 16:17 | <Philip`> | Why would you want such a thing? |
| 16:17 | <Philip`> | What do you expect it to do with input methods where you use multiple keystrokes to insert a single character? |
| 16:18 | <AryehGregor> | Just give the current value after whatever the user just entered. Really I want an event whenever the contents of the form field change, with the new value of the field. |
| 16:18 | <AryehGregor> | For using <datalist>. |
| 16:18 | <Philip`> | Why is 100ms latency unacceptable? |
| 16:18 | <AryehGregor> | I want to dispatch the new contents to my backend to ask for suggestions. |
| 16:19 | <AryehGregor> | Because the result has to be thrown out if the form value is no longer the same when the suggestion returns, and there already may be a significant round-trip delay. |
| 16:19 | <Philip`> | You'd have to implement some kind of buffering yourself anyway, because you don't want to send a request to the backend after every keystroke if the user's typing really really fast and has a dialup connection |
| 16:21 | AryehGregor | tries to figure out if MW already buffers |
| 16:22 | <AryehGregor> | It looks like we usually wait 250 ms, except if the user hits the down arrow. |
| 16:23 | <AryehGregor> | We use keyup, keydown, keypress, blur, and focus, but of course we also use a <div> positioning hack right now to generate the results. |
| 16:23 | <AryehGregor> | Probably we don't need to hook blur and focus with datalist. |
| 16:23 | <AryehGregor> | Using datalists via JS is really ugly, by the way. |
| 16:23 | <Philip`> | Given that pages will have to implement some kind of buffering if some browsers don't buffer themselves, it seems silly for the spec to say "may" - it should require buffering for all browsers or none |
| 16:24 | <AryehGregor> | I'd really prefer just input.suggest = ['Foo', 'Bar'] instead of creating a datalist element, making up an id, giving it the id, setting the input's list attribute, and looping through the result list to add <option> children. |
| 16:24 | <Philip`> | (maybe) |
| 16:24 | <AryehGregor> | Anyway, yeah, "may" is a pain. |
| 16:25 | <Philip`> | Author feedback from attempting to use the element is a good thing to have :-) |
| 16:26 | <Lachy> | AryehGregor, datalist is useful to have when the choices are a fixed list, so they can just be listed in the page and not have to worry about being modified by scripts |
| 16:26 | <Lachy> | but maybe we need an optimised API for the scripted use cases that dynamically change the list |
| 16:26 | <AryehGregor> | Lachy, when does that actually happen? I can't think of a real-world page where it would be useful. |
| 16:26 | <Lachy> | html5.lachy.id.au has uses a fixed list |
| 16:26 | <AryehGregor> | The only use-case I can see for this is suggestions generated as the user types. |
| 16:27 | <AryehGregor> | Interesting. |
| 16:27 | <Lachy> | also, another simple case is a form requesting personal details. The title field could offer defaults of Mr, Mrs, Ms, etc. but still allow users to type in their own |
| 16:27 | <AryehGregor> | Okay, granted, it has some uses, but the script use case seems a lot more compelling. |
| 16:27 | <Philip`> | AryehGregor: Normal UI widget systems have combo boxes, which seem to be what this is similar to |
| 16:27 | <Philip`> | and they're used in lots of places |
| 16:27 | <AryehGregor> | I've seen plenty of sites hack up their own absolutely-positioned divs to do dynamic search suggestions, never seen anyone try it to suggest MIME types or honorifics. |
| 16:27 | <Philip`> | like, um, |
| 16:28 | <AryehGregor> | I still don't know what a combobox is. |
| 16:28 | Philip` | fails to think of compelling examples of static lists |
| 16:28 | <Philip`> | AryehGregor: It's just a dropdown list you can type arbitrary text into |
| 16:29 | <AryehGregor> | Hmm, okay. |
| 16:29 | <webben> | Rationale: maximize conformity of input without enforcing uniformity. |
| 16:29 | <webben> | e.g. by offering a carot against entry of multiple spellings of a thing |
| 16:30 | <Philip`> | Hmm, the only one I can easily find in my currently-open applications is a "Default Graphic Extension" configuration, which offers eps/pdf/png/jpg/tif but lets you type in other values if you want |
| 16:32 | <Lachy> | AryehGregor, a combobox is just a select list, but which also allows users to type in other values. Your browsers address bar is bascially an example of this. |
| 16:32 | <AryehGregor> | Interesting. |
| 16:33 | <Lachy> | ordinarily, they have drop down arrows on the side, but unfortunatley, Opera's datalist implementation omitted this for some reason |
| 16:34 | <Philip`> | Scripted search suggestions typically don't have arrows on the side |
| 16:34 | <AryehGregor> | Maybe there should be an entirely separate JS-only interface for scripted search suggestions? |
| 16:34 | <Lachy> | AryehGregor, HTMLSelectElement contains APIs for add() and remove(), that simply the process of adding and removing options. Would those help if they were available on datalist, or would you like a more optimised alternative? |
| 16:34 | <Philip`> | Seems problematic if the same HTML control is meant to be used for all the cases |
| 16:36 | <Lachy> | yeah, I suppose. Perhaps that issue is best handled with CSS using the 'appearance' property. |
| 16:36 | <Lachy> | appearance: combo-box; is already defined in the spec |
| 16:37 | <AryehGregor> | Lachy, I'd really just like to be able to do input.suggest = ['foo', 'bar']. I don't see why it should need to be more complicated than that. |
| 16:38 | <Lachy> | how would that interact with the suggestions from the datalist element, if both were used together? |
| 16:38 | <AryehGregor> | I'd expect the scripted results would override the datalist ones. |
| 16:38 | <AryehGregor> | But I dunno, just don't use them together. :) |
| 16:39 | <AryehGregor> | Doesn't matter much for authors, it just needs to be unambiguous. |
| 16:39 | <Lachy> | maybe it could merge the two sets of suggestions, like Firefox's search box does, when it lists previous searches, then a separator line, and then the google suggest results. |
| 16:39 | <AryehGregor> | I dunno. It's hard to say without use-cases. |
| 16:40 | <AryehGregor> | I mean, maybe the browser could merge datalist suggestions with its own too, right? |
| 16:40 | <Lachy> | yeah, I think the spec says it can do that |
| 16:40 | <AryehGregor> | Actually, I guess the spec permits that, doesn't it? |
| 16:41 | <Philip`> | Are people really going to use datalist if its behaviour is so unpredictable? |
| 16:42 | <Philip`> | I'd hope it works consistently everywhere, otherwise people would be better off writing their own implementations in JS |
| 16:42 | <Lachy> | for existing scripted implementations, do you know what the responses from the server looks like? Do they commonly just return JSON, or even just an serialised array, and then use eval(...) to parse it? |
| 16:42 | <AryehGregor> | Lachy, that's what mwsuggest.js does. |
| 16:42 | <AryehGregor> | JSON in our case. |
| 16:42 | <AryehGregor> | So allowing a literal list to be assigned would be ideal. |
| 16:43 | <Lachy> | ok. Do you know what Google Suggest uses? |
| 16:43 | <AryehGregor> | No idea. |
| 16:46 | <Philip`> | http://www.google.com/complete/search?q=what |
| 16:48 | <Lachy> | I found an article explaining it http://serversideguy.blogspot.com/2004/12/google-suggest-dissected.html |
| 16:51 | <Philip`> | It's changed a little bit since 2004 |
| 16:51 | <AryehGregor> | Interesting that they just use a loop instead of key events. |
| 16:51 | <AryehGregor> | Er, right, used. |
| 16:54 | <Lachy> | AryehGregor, does your use case involve replacing the entire suggestion list each time the data is updated, or would you want the ability to selectively add and remove options? |
| 16:55 | <AryehGregor> | Lachy, replacing the whole thing is fine, typically. |
| 16:55 | <AryehGregor> | If it's just a list, I don't see why you couldn't use normal list methods, though. |
| 16:56 | <Philip`> | Are there any existing list-taking APIs in HTML? |
| 16:57 | <Philip`> | Seems tricky to make the reflection work right |
| 16:58 | <AryehGregor> | Why would it be tricky? |
| 16:58 | <Philip`> | e.g. if people say x=[]; input.suggest=x; x.push('cheese'); // does suggest update? |
| 16:58 | <Philip`> | or x=input.suggest; x.push('cheese'); // does suggest update? |
| 16:58 | <Philip`> | or input.suggest.push('cheese'); // surely this should update? |
| 16:58 | <AryehGregor> | Don't the same questions apply to strings? |
| 16:58 | <Philip`> | No |
| 16:58 | <Philip`> | Strings are immutable |
| 16:58 | <Lachy> | I don't think that would work. |
| 16:58 | <AryehGregor> | Hmm. |
| 16:59 | <Philip`> | Immutability makes everything easy |
| 16:59 | <AryehGregor> | So every single API in HTML only takes immutable objects? |
| 16:59 | <Philip`> | (Well, everything except mutations) |
| 16:59 | <AryehGregor> | Just say it copies the list on assignment, if you want. |
| 17:00 | <Lachy> | I'd expect input.suggest to use a specialised interface, not a normal array |
| 17:00 | <Philip`> | AryehGregor: They take immutable strings/numbers, or objects with special interfaces that define their own mutation semantics |
| 17:00 | <AryehGregor> | Lachy, as long as you can assign an array to it and have it work, be auto-converted or such. Does that sound reasonable? |
| 17:00 | <Lachy> | but I would expect the setter for input.suggest to accept an array, and to return a collection on getting. |
| 17:00 | <Lachy> | not sure what type of collection to return though |
| 17:01 | <Philip`> | AryehGregor: If it copies the list on assignment, would you still expect normal list methods to work? (input.suggest.push etc) |
| 17:01 | <Lachy> | AryehGregor, I suggest you clearly document the use case and problem to be solved, and document the proposed solution along with it. |
| 17:01 | <AryehGregor> | k. |
| 17:01 | <Lachy> | write it up in the wiki |
| 17:01 | <AryehGregor> | I was planning on posting to whatwg. |
| 17:01 | <Lachy> | yeah, that'll do too |
| 17:49 | <Dashiva> | Arguing about intent with regard to XHTML served as text/html, when XML itself completely ignores intent... |
| 18:27 | <JonathanNeal> | Heyo |
| 20:31 | <AryehGregor> | Wait, so the list IDL property of inputs isn't settable? |
| 20:32 | <AryehGregor> | readonly attribute HTMLElement list; |
| 20:32 | <AryehGregor> | That might explain my problems. |
| 20:34 | <AryehGregor> | I assumed it reflected the list DOM attribute. |
| 20:41 | <Philip`> | AryehGregor: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-list says what it does |
| 20:42 | <Philip`> | and indeed it doesn't say it reflects anything |
| 20:42 | <AryehGregor> | Yeah, I eventually figured that out. :) |
| 22:59 | <remysharp> | quick question: with a web socket, is there any way to 'reopen' a socket if the socket go closed? Or do I just create a brand new WebSocket? |
| 23:09 | <AryehGregor> | Hmm. Opera seems not to update the suggestions list from <datalist> until you press a key. This makes it fairly useless for dynamic scripting. |
| 23:11 | <AryehGregor> | data:text/html,<!doctype html><input list="datalist" onkeypress="document.getElementById('datalist').innerHTML = '<option value="' + event.target.value + 'fizzle">'; return true"><datalist id="datalist"></datalist> |
| 23:11 | <AryehGregor> | Notice how it lags behind what you type by one key. |
| 23:12 | <AryehGregor> | Any workaround? Should I file this in Opera's bug tracker where I never see any response and don't get any status notifications ever? |
| 23:13 | <Lachy> | what does the spec say about the issue? |
| 23:15 | <AryehGregor> | It doesn't, it's very vague, as with all UI issues. But it seems wrong if I update the datalist and the suggestions don't actually display right away. |
| 23:15 | <AryehGregor> | I'd expect them to display immediately (if suggestions would normally be displayed right now). |
| 23:15 | <Lachy> | AryehGregor, I would recommend filing a bug anyway, since it's obviosly not well optimised for the use cases it's meant for |
| 23:15 | <AryehGregor> | I was going to convert mwsuggest.js to use <datalist> where supported, but I guess I won't if the suggestions are for what you typed in on the last key . . . |
| 23:15 | <AryehGregor> | You mean a spec bug? |
| 23:15 | <AryehGregor> | Or an Opera bug? |
| 23:15 | <Lachy> | Opera bug |
| 23:16 | <Lachy> | but you could file a spec bug too, if you think the spec needs to say something about this |
| 23:16 | <AryehGregor> | Okay. |
| 23:16 | <Lachy> | though, it is a UI issue, so maybe it doesn't |
| 23:16 | <AryehGregor> | Last time I filed an Opera bug (also about a problem with Opera HTML5 implementation) I never got a response. |
| 23:16 | <Philip`> | All you need to do is get yourself employed by Opera, so you can access the bug tracker |
| 23:17 | <AryehGregor> | I don't think the spec needs to say anything here, although I'll have other suggestions about <datalist>. |
| 23:17 | <AryehGregor> | Philip`, why didn't I ever think of that |
| 23:17 | <AryehGregor> | ? |
| 23:17 | <AryehGregor> | "Spec violation – Opera is performing contrary to published, interworking recommendations by the W3C" So I shouldn't use this if it violates IETF specs? :) |
| 23:18 | <Lachy> | AryehGregor, unfortunately, since we don't run an open bug tracker, external bug reporters don't automatically get notified of further discussions |
| 23:18 | AryehGregor | enters a data: URL in the "What URL triggers this bug, if any?" field |
| 23:18 | <AryehGregor> | Lachy, why don't you run an open bug tracker? It's very annoying. |
| 23:18 | <Lachy> | I know. The issue has been discussed internally many times |
| 23:19 | <AryehGregor> | I figured, but I was wondering what the reasons are for the status quo. Since you aren't saying, and neither did the last Opera dev I talked to about this (who was possibly also you), I guess it's secret. |
| 23:19 | <AryehGregor> | Oh well. |
| 23:19 | <AryehGregor> | I guess I'll work for Wikimedia instead. :P |
| 23:19 | <Lachy> | unfortunately, AIUI, we have bugs related to client work and other secret stuff that can't be revealed publicly, and there's no easy way to identify bugs that are safe for public viewing from those that aren't |
| 23:20 | <AryehGregor> | Well, Apple manages. I assume they have secret internal bug trackers, but they have a public Bugzilla too. |
| 23:20 | <AryehGregor> | For WebKit, I mean. |
| 23:20 | <AryehGregor> | I'm sure you've heard all this before, though. |
| 23:20 | <Lachy> | yeah, I know. But we only have one bug tracker used for both internal and external reports |
| 23:21 | <Lachy> | it's been suggested that bugs filed by external reporters are made public, but then the issue here is that someone internally could comment and inadvertenly mention something that's not public knowledge |
| 23:30 | <AryehGregor> | Lachy, filed as DSK-276870. |
| 23:31 | <AryehGregor> | Oh, crud, it looks like I accidentally quoted Manu on-list when he replied to me off-list. |
| 23:31 | <AryehGregor> | I hate it when I do that. |
| 23:31 | AryehGregor | blames Gmail. |
| 23:32 | AryehGregor | feels really guilty. |
| 23:40 | <Lachy> | AryehGregor, if you replied to an off-list mail, why would gmail add pubilc-html to the CC list? |
| 23:40 | <AryehGregor> | Lachy, because I reply to all on the first post I'm replying to, then copy-paste other things to reply to from lower posts. This is the only way I can see to respond to multiple people in the same post. |
| 23:40 | <AryehGregor> | I prefer not to make five posts in a row responding to five separate people. |
| 23:42 | Lachy | wonders which meaning of the phrase 'table the discussion' Maciej was using when he wrote "let's table this process discussion for now" |
| 23:42 | <AryehGregor> | Presumably "set aside", since we were in the middle of discussing it already, so the other definition wouldn't make sense, would it? |
| 23:43 | <Lachy> | yeah, that was my assumption |
| 23:43 | <AryehGregor> | Words shouldn't be able to mean two opposite things. >:( |
| 23:43 | <AryehGregor> | "ravel" is another culprit, but it's less common. |
| 23:43 | <Lachy> | but I really hate that phrase since it has 2 contradictory meanings, and I never remember which one is the typical American meaning, and which is the typical British (or, rest of the world) meaning |
| 23:49 | <AryehGregor> | It's usually clear from context, though. |
| 23:56 | <TabAtkins> | Grah, it's surprising how much of a difference a little syntax makes. I don't like passing literal arrays to functions in PHP, especially nested ones. But passing objects in javascript is no problem at all. |
| 23:56 | <AryehGregor> | Yeah, it's remarkable. |
| 23:57 | <AryehGregor> | The syntax for arrays in PHP is ugly, and it makes them so much less usable. |
| 23:57 | <othermaciej> | Lachy: I meant it in the colloquial sense of "set aside", not the formal parliamentary sense of "let's put it before the group as the topic of discussion" |
| 23:59 | <TabAtkins> | AryehGregor: It's especially annoying because the ugliness of the syntax is the only thing really stopping me from finally making my sql-query constructor handle table joins. |
| 23:59 | <AryehGregor> | Heh, so you made one too? |