| 00:00 | <abarth> | Hixie: thx |
| 00:06 | <jamesr> | heycam: there's another question about the timestamps |
| 00:06 | <jamesr> | a lot of animation systems provide two timestamps |
| 00:06 | <jamesr> | a "when is this callback being invoked" time and a "when is this frame expected to hit the screen" time |
| 00:07 | <heycam> | is the former related to the currently displayed frame time? |
| 00:07 | <jamesr> | i don't fully grok the requirements around that |
| 00:07 | <jamesr> | no, i don't think so |
| 00:08 | <heycam> | would it be a different time per callback? |
| 00:08 | <heycam> | that doesn't seem that useful, if so |
| 00:09 | <jamesr> | like i said i don't fully understand what it's all about |
| 00:09 | <heycam> | ok |
| 00:09 | <jamesr> | but if CoreAnimation does it, seems worth at least figuring out why |
| 00:35 | <JonathanNeal> | Hey all. |
| 00:38 | <danheberden> | g'day JonathanNeal |
| 00:42 | <JonathanNeal> | :) thanks danheberden |
| 00:54 | <erlehmann> | I see what you did there. <http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-maxlength>; |
| 01:10 | <jamesr> | AryehGregor: what's the conceptual difference between parsing a script and executing it? |
| 01:11 | <AryehGregor> | jamesr, the same as the difference between compiling a C program and executing it. It might not actually be relevant to all existing implementations, of course. |
| 01:11 | <jamesr> | no such distinction exists for javascript, really |
| 01:11 | <AryehGregor> | But I assume everyone does something like compile the whole file to bytecode first thing, at least. |
| 01:11 | <jamesr> | no |
| 01:11 | <AryehGregor> | No? |
| 01:11 | <jamesr> | no |
| 01:11 | <AryehGregor> | Then what do you do with it? |
| 01:11 | <jamesr> | there's a few things |
| 01:12 | <jamesr> | but one really important distinction is that code can be lazily compiled and constantly recompiled during execution |
| 01:13 | <jamesr> | the only thing we do on a chunk of script in v8 currently before starting to execute code is to essentially brace match |
| 01:13 | <jamesr> | also keep in mind that evaluating the source "function foo() { }" is _executing_ code |
| 01:13 | <AryehGregor> | The assertion in that thread is that compilation of large amounts of causes visible lag if it has to be done synchronously, even if the code doesn't actually do anything beyond define some functions. Is that the case in V8? |
| 01:13 | <jamesr> | that's setting a variable called 'foo' on the global object |
| 01:13 | <AryehGregor> | I realize that. |
| 01:14 | <jamesr> | i think that assertion is based on the time spent executing the code |
| 01:14 | <jamesr> | i.e. assigning the global variable to 'foo' and dealing with all the side effects of that |
| 01:14 | <jamesr> | which you can't meaningfully pass to another thread |
| 01:14 | <AryehGregor> | Hmm. |
| 01:14 | <jamesr> | you can brace match on another thread, but that's not going to buy you much |
| 01:15 | <jamesr> | i haven't jumped in on that thread because everyone is using slightly different terminology and it's just kind of a mess :/ |
| 01:15 | <AryehGregor> | So you're saying that executing a couple hundred KB of JavaScript is always going to require a large synchronous lag, and you can't just separate off some of the expensive parts to a background thread? |
| 01:15 | <jamesr> | no, not really |
| 01:15 | <AryehGregor> | That's not really what you're saying, or you can't really separate it off? |
| 01:15 | <jamesr> | JS engine developers work really hard to cut down on the time it takes to execute a few hundred KB of javascript |
| 01:16 | <jamesr> | i think what authors want is a way to download script but not execute it |
| 01:16 | <jamesr> | and they are just being lazy about what they mean by 'parse' |
| 01:16 | <AryehGregor> | I'd assume people like Steve Souders can figure out the difference between download and execution. |
| 01:16 | <jamesr> | hah! |
| 01:16 | <AryehGregor> | Or execution/parsing/whatever. |
| 01:16 | <AryehGregor> | You can just look at the right tab in Web Inspector, right? It tells you how much time it's spending on what. |
| 01:17 | <jamesr> | even very educated and web-saavy people on the internet can have pretty broken mental models about how javascript engines work |
| 01:17 | <AryehGregor> | When I go to the "Timeline" tab in Web Inspector, I see separate steps called "Parse" and "Evaulate Script". |
| 01:18 | <AryehGregor> | It doesn't say what it's parsing, though. |
| 01:18 | <jamesr> | that's just confusing UI |
| 01:18 | <AryehGregor> | Not totally sure if it's JS or HTML. |
| 01:18 | <jamesr> | it's parsing HTML |
| 01:18 | <jamesr> | which might include time spent executing script |
| 01:18 | <jamesr> | if it parses a <script> tag, f'instance |
| 01:18 | <AryehGregor> | That is pretty confusing. |
| 01:19 | <jamesr> | there isn't a useful "parse' time for JS to expose, tho |
| 01:21 | <jamesr> | some website we saw tries to 'preload' script by setting it as the src of an <object> tag |
| 01:22 | <jamesr> | caused a gigantic pause in webkit once the thing loaded since we tried to linebreak it all nicely |
| 01:22 | <AryehGregor> | Hahaha. |
| 01:22 | <AryehGregor> | Is there any good way to separate download from parse/execute time right now? |
| 01:22 | <jamesr> | does disabled work on <script> tags? |
| 01:23 | <AryehGregor> | There's no disabled attribute on <script>, no. |
| 01:23 | <AryehGregor> | With <img>, apparently new Image().src = 'foo' works. |
| 01:23 | <jamesr> | yeah |
| 01:23 | <jamesr> | that creates a new image element and starts a load |
| 01:24 | <JonathanNeal> | AryehGregor, free to answer another selection related question? |
| 01:24 | <jamesr> | was there a use case B on that thread or just use case A? |
| 01:24 | <AryehGregor> | JonathanNeal, not now. Ask tomorrow. |
| 01:24 | <AryehGregor> | jamesr, seems it was just A. |
| 01:24 | <AryehGregor> | According to you, though, use case A was incoherent. |
| 01:25 | <jamesr> | incoherent in modern JS engines where there's not much of a distinction between parse and execution, yes |
| 01:25 | <JonathanNeal> | Will do, thanks :D |
| 01:25 | <jamesr> | and i think the original author requests were about execution |
| 01:25 | <jamesr> | even if they thought it was about parsing |
| 01:30 | <jamesr> | AryehGregor: seems like what hixie is really saying is that the author could wrap everything in a big closure and not execute it |
| 01:30 | <smaug____> | what is the origin of term "browser chrome" or just "chrome"? Was that used already before Mozilla? |
| 01:30 | <jamesr> | so it's entirely up to the author how much time it takes to execute |
| 01:31 | <AryehGregor> | jamesr, so if they wrap it in a big closure and don't execute it, that does take negligible time? |
| 01:31 | <jamesr> | depends on what the JS engine is doing |
| 01:31 | <jamesr> | but it could take negligible time, yes |
| 01:33 | <jamesr> | afaict nobody's actually measured that and reported it to the thread |
| 01:34 | <jamesr> | i think the biggest thing hixie is ignoring is that the author isn't necessarily in control of the contents of the script |
| 01:34 | <jamesr> | if i want to load up jquery or something else that has a lot of expensive top-level statements, then i can't just wrap it in a closure |
| 01:35 | <jamesr> | i gotta add it to a <script> and let all of those top-level statements execute whenever it finishes loading |
| 01:39 | <AryehGregor> | Well, if you're actually using jQuery right away on page load, that's not avoidable, except by modularizing jQuery and only loading the modules you need (which they already do AFAIK). |
| 01:39 | <jamesr> | sure, but if you aren't using it right away but still want to start the download ASAP then you are AWOL |
| 01:40 | <AryehGregor> | Didn't people say Gmail puts the script contents in a big comment and uncomments it when needed? |
| 01:41 | <AryehGregor> | Anything wrong with that? |
| 01:41 | <jamesr> | nope |
| 01:41 | <jamesr> | still doesn't help with the jquery case |
| 01:41 | <jamesr> | where you want to use a well-known URL to hit cache if possible |
| 01:41 | <AryehGregor> | Ah, that's a different case, yeah. |
| 01:41 | <AryehGregor> | I'm not sure that's what was being asked, though. |
| 01:41 | <jamesr> | not exactly |
| 01:41 | <jamesr> | but it seems related |
| 01:43 | <AryehGregor> | Okay, now it's time for me to head off to bed. |
| 01:43 | <jamesr> | oh yay you responded so now i don't have to say anything on the thread |
| 01:43 | <jamesr> | wheeee |
| 01:55 | <zewt> | jamesr: isn't that the example I showed? |
| 01:56 | <jamesr> | zewt: ah, seems it is |
| 01:56 | <jamesr> | (i skipped most of the thread) |
| 01:56 | <jamesr> | did you try it on mobile? |
| 01:56 | <zewt> | nope |
| 01:56 | <zewt> | i generally just assume mobile browsers are bad at everything |
| 01:56 | <jamesr> | there is some work that happens before executing the line 'var yourAPI = '... |
| 01:56 | <zewt> | but i think there's no reason they couldn't do it as efficiently |
| 01:56 | <jamesr> | but i don't think it is terribly significant |
| 01:56 | <jamesr> | you can observe that by timing in a different <script> block |
| 01:57 | <jamesr> | yeah grab a start time in a script block above the one defining go() and grab and end time in a block after |
| 01:57 | <zewt> | not sure how to get anything after parsing and before top-level execution to do timings there |
| 01:57 | <jamesr> | the first line of execution is roughly the end of parsing |
| 01:57 | <jamesr> | for this very loose definition of 'parsing' |
| 01:57 | <zewt> | that's the point--parsing can be async, so we don't (in theory) care about it |
| 01:58 | <jamesr> | observable side effects or it didn't happen |
| 01:58 | <zewt> | if there's anything after parsing but before execution that can't be async (eg. depends on the window somehow), that's the only thing that would be a problem, I think |
| 01:58 | <zewt> | (that's the part that I mentioned I don't know about) |
| 02:19 | <zewt> | curse you chrome to phone for not working for apps accounts and making me type out my own annoying long URL on a touchscreen |
| 02:20 | <zewt> | top-level context time is also 0ms on android 2.3.4 (stock) browser, FYI |
| 02:20 | <zewt> | curiously, the "initializing API" part took 1884ms the first time and 89ms after a refresh |
| 02:21 | <zewt> | don't know if that's some kind of caching or just a timing hiccup |
| 02:22 | <jamesr> | does it repeat if you clear cache + try again? |
| 02:25 | <zewt> | yeah |
| 02:25 | <zewt> | I/browser (10698): Console: Initializing API took: 1944ms https://zewt.org/~glenn/test-top-level-context-execution/:10 |
| 02:26 | <zewt> | that's the inner call, though, not the part that people want to be cheap |
| 02:26 | <zewt> | still curious |
| 02:56 | <MikeSmith> | Hixie: I want to let you know I have set up some semi-automation for generating new bugs from comments posted the public-html-comments list |
| 02:57 | <MikeSmith> | if it ends up causing too much confusion/redundancy/extra-work, I can try to figure out something else |
| 02:58 | <MikeSmith> | but one of the reasons I set it up was to help address the problems that have been raised with accessibility of the bugzilla UI |
| 02:58 | <MikeSmith> | I am told that those problems are not insignificant |
| 02:59 | <MikeSmith> | so I'm also going to be working on trying to get improvements made to our bugzilla UI |
| 02:59 | <MikeSmith> | e.g., by upgrading to v4, or by setting up alternative templates, or whatever else helps |
| 03:01 | <MikeSmith> | but in the mean time at least, I hope it'll help that we can let people know we're providing the comments list as an alternative, and have some way of taking those and raising bugs for them that we can track (for the purposes of being able to include them in the LC disposition of comments, etc.) |
| 05:38 | <Hixie> | MikeSmith: k |
| 05:38 | <Hixie> | jamesr_: you'd better do more than just brace matching, otherwise you're non-compliant |
| 05:38 | <Hixie> | e.g. you have to be able to catch syntax errors deep inside a script before you do anything with visible sideeffects |
| 05:41 | <MikeSmith> | Hixie: the volume on the comments list has been really low anyway, so if it stays on the same order it has in the past, there additional mail/notifications shouldn't be too excessive. But if it does get to be too annoying, definitely let me know |
| 05:41 | <MikeSmith> | Hixie: and thanks, btw |
| 05:41 | <MikeSmith> | and congratulations |
| 05:41 | <MikeSmith> | on the spec having reached LC at the W3C |
| 05:42 | <MikeSmith> | I know you don't see it as quite the milestone that others do |
| 05:42 | <MikeSmith> | but it's a milestone nonetheless |
| 05:42 | <Hixie> | we reached last call in october 2009 |
| 05:43 | <MikeSmith> | for some definition of "we", yeah |
| 05:43 | <Hixie> | and that actually meant something -- we got to zero outstanding feedback |
| 05:43 | <Hixie> | the latest milestone was completely arbitrary and date driven |
| 05:43 | <Hixie> | and happened with over 2000 open e-mails and bugs |
| 05:43 | <Hixie> | forgive me for feeling a bit cynical about it |
| 05:44 | <othermaciej> | it has marketing value, at the very least; and if we are lucky, may lead to useful feedback from folks who would not give it otherwise |
| 05:44 | <MikeSmith> | Hixie: forgive me for feeling a bit positive about it :) |
| 05:45 | <Hixie> | it's rather too late for high-level feedback on most existing features |
| 05:45 | <Hixie> | but i certainly don't have a problem getting more feedback |
| 05:50 | <MikeSmith> | Hixie: my point in mentioning it here was just that it gives me a reason to express some personal gratitude to you, fwiw |
| 05:50 | <MikeSmith> | as the architect of the spec |
| 05:50 | <Hixie> | thanks :-) |
| 05:50 | <Hixie> | it is very much a group effort |
| 05:51 | <Hixie> | couldn't do it without all of you and the hundreds of other contributors :-) |
| 05:52 | <othermaciej> | Hixie: I think we owe you, not just for the semi-arbitrary LC milestone, but for the fact that if you hadn't stepped up and put in so much energy, innovation in the Web platform would probably be far behind where it is today |
| 05:52 | <othermaciej> | or possibly driven by competing proprietary extensions |
| 05:52 | <MikeSmith> | amen to that |
| 05:53 | <othermaciej> | I know a whole host of people have contributed in incredibly ways, and I am grateful to them as well |
| 05:53 | <MikeSmith> | yeah, the collective time that has gone into this work is phenomenal |
| 05:53 | <othermaciej> | also I am a bit tipsy right now |
| 05:54 | <MikeSmith> | heh |
| 05:54 | <MikeSmith> | I wish I was |
| 05:54 | <MikeSmith> | I missed my breakfast beer this morning |
| 05:54 | <MikeSmith> | so I'll need to double-up for lunch |
| 05:56 | <Hixie> | othermaciej: my pleasure :-) |
| 05:56 | <Hixie> | othermaciej: the technical aspects of this stuff are a lot of fun |
| 05:56 | <MikeSmith> | yeah |
| 05:57 | <MikeSmith> | would that the rest of it was as fun |
| 05:57 | <MikeSmith> | and had a big a return of investment |
| 05:57 | <Hixie> | luckily the rest of it is mostly opt-in |
| 06:00 | <MikeSmith> | Hixie: imma shut up about this for now, but I do want to say that anyway, in particular, I think it remains important to get the spec through the process at the W3C, and there have been some significant costs to getting it this far, including for you, and I personally appreciate that you have stuck with it |
| 06:00 | <MikeSmith> | (end of speech) |
| 06:00 | <Hixie> | hehe |
| 06:03 | <Hixie> | i think the patent policy is valuable. i think the rest of the process is somewhat harmful at this stage. |
| 06:04 | <Hixie> | it encourages people to view standards development as something with an end |
| 06:04 | <Hixie> | which imho is how we got into this mess in the first place |
| 06:05 | <Hixie> | the web should continuously evolve, it doesn't make sense to freeze it for years at a time |
| 06:06 | <MikeSmith> | I think there is large room for improvement in the standards-development and standards-publication process at the W3C |
| 06:07 | <MikeSmith> | and I think there is real possibility of significant concrete changes to improve |
| 06:07 | <MikeSmith> | *improve it |
| 06:07 | <MikeSmith> | but as you well know, it can seem like trying to move a mountain |
| 06:08 | <MikeSmith> | or even sometimes like actually moving a mountain a bit, or thinking you had, and then watching the mountain move right back where it was to begin with |
| 06:09 | <zewt> | shape-memory mountains |
| 06:09 | <MikeSmith> | myth of sisyphus |
| 06:17 | <othermaciej> | I think a stable branch / unstable branch development model an make sense for specs |
| 06:17 | <othermaciej> | but, I haven't really seen a good version of it done, so who can say |
| 06:19 | <Hixie> | i don't think stable/unstable is the right split, because nothing is truly stable |
| 06:19 | <Hixie> | i mean, the navigation algorithm has been "stable" for 15 years, long before we started speccing it, but we still change it every other week |
| 06:20 | <Hixie> | i think it would make sense to have a "full" spec and an "only widely implemented features" spec |
| 06:20 | <Hixie> | the only reason i haven't done it already is that we have way too many specs as it is |
| 06:36 | <MikeSmith> | very much agreed about the idea of having an "only widely implemented features" spec |
| 06:39 | <MikeSmith> | if we were to systematically keep the spec annotations up to date, we could at least generate a view with the sections and subsections for the not-widely-implemented features omitted |
| 06:41 | <MikeSmith> | which reminds me, I think I still have the following being automatically regenerated each time the spec is pushed to W3C cvs: |
| 06:41 | <MikeSmith> | http://dev.w3.org/html5/spec/status.html |
| 06:41 | <MikeSmith> | hmm, or maybe not |
| 06:42 | <MikeSmith> | I see Undo History is still there |
| 06:45 | <MikeSmith> | oh, actually, that's expected because it's generated from the annotations for the full upstream spec |
| 08:24 | <Hixie> | MikeSmith: the problem with the section annotations (as far as using them to make a spec is concerned) is that they're too coarse |
| 08:24 | <MikeSmith> | right |
| 08:24 | <MikeSmith> | I know |
| 08:24 | <Hixie> | (e.g. think about what adding or removing appcache should do to the navigate algorithm) |
| 08:24 | <MikeSmith> | yeah |
| 09:26 | <jgraham> | "W3C also reconfirmed today that, as announced, these specifications are on track to become stable standards in 2014." |
| 09:27 | <jgraham> | Well as long as "stable standards" doesn't imply "has a testsuite", maybe |
| 11:12 | <zcorpan> | ie doesn't support conditional comments in application/xhtml+xml, right? right? |
| 11:13 | <zcorpan> | or x-ua-compatible? |
| 11:17 | <zcorpan> | what are the use cases for crossorigin="" again? should it be a content attribute at all? |
| 11:23 | <MikeSmith> | zcorpan: didn't it mostly come out of WebGL use cases? |
| 11:26 | <MikeSmith> | zcorpan: https://bugs.webkit.org/show_bug.cgi?id=61015#c6 |
| 11:26 | <MikeSmith> | and https://bugs.webkit.org/show_bug.cgi?id=61015#c7 |
| 11:27 | <MikeSmith> | "I forgot the mention that the point of the attribute is to let you draw images onto 2D and 3D canvases and read back the results. In the case of 3D canvas, my understanding is that a thumbs up for CORS is going to be required for drawing the image at all." |
| 11:31 | <zcorpan> | if it's just for drawing on canvas, you probably don't want the image in the document at all, much less declaratively |
| 11:32 | <MikeSmith> | yeah, I can't say I really understand the use cases |
| 11:32 | <MikeSmith> | maybe there was some discussion on the webgl list that will provide some clues |
| 14:11 | <MikeSmith> | heh |
| 14:11 | <MikeSmith> | http://gijsvanzon.posterous.com/peter-paul-koch-about-the-future-of-mobile-we |
| 14:11 | <MikeSmith> | great PPK photo |
| 14:12 | <Peter`> | haha |
| 14:15 | jgraham | wonders if he should make it his mission in life to get a picture of Hixie that doesn't make him look like a drug-addled-monkey on wikipedia |
| 14:26 | <erlehmann> | jgraham, he looks more like out of a british TV series from the 80ies. |
| 14:28 | <jgraham> | erlehmann: I see you had a bad experience with british TV from the 80s |
| 14:36 | <asmodai> | hsivonen: that highlighting in the source on validator.nu is nicely done btw |
| 14:49 | <hsivonen> | asmodai: thanks |
| 14:53 | <asmodai> | mmm, normal lxml.html.tostring(pretty_print=True) is not quite fully pretty printing this HTML 5 stuff. |
| 14:54 | <asmodai> | wonder if I need html5lib to get that done |
| 16:56 | <TabAtkins> | Ok, I'm clearly missing something. In Hixie's email about separating script download/parsing/execution, why wouldn't it alert "fail"? |
| 16:56 | <Ms2ger> | Because you have to throw a SyntaxError before you can execute it, if you mean the email I think you mean? |
| 16:58 | <AryehGregor> | This is hilarious. It actually works for everything I've tried so far: http://ryanelmquist.com/cgi-bin/xkcdwiki |
| 17:04 | <TabAtkins> | Ms2ger: Ah, duh. |
| 17:06 | <TabAtkins> | AryehGregor: Heh, cool. I guess it's related to the fact that articles usually start with a summary that might link to more general concepts, and a lot of "baseline" general concepts link to philosophy. |
| 17:06 | <AryehGregor> | Seems so. |
| 17:10 | <Workshiva> | heh |
| 17:10 | <Workshiva> | The sequence quickly reached 'Language' and then spent 11 steps reaching Philosophy |
| 17:10 | <Workshiva> | ... but with a detour into geology, wtf |
| 17:11 | <TabAtkins> | Workshiva: Your task is to edit the language article to point directly to philosophy first. |
| 17:11 | <Ms2ger> | TabAtkins, I wonder how many such changes have happened recently |
| 17:11 | <Workshiva> | The penultimate article was Modern Philosophy |
| 17:11 | <Workshiva> | That's cheating! |
| 17:13 | <Workshiva> | Challenge: Find a 10+ chain that doesn't terminate with Property (philosophy) -> Modern philosophy -> Philosophy |
| 17:20 | <Philip`> | Workshiva: Ryan Giggs |
| 17:27 | <MikeSmith> | hsivonen: http://lists.w3.org/Archives/Public/www-validator/2011May/0031.html |
| 17:28 | <MikeSmith> | "Is Unicode Normalization Form C actually required by HTML5 or is this a validator bug?" |
| 17:31 | <MikeSmith> | hsivonen: I realize the spec doesn't cite Form C directly, but I'm wondering what part of the conformance requirements that are directly stated in the spec have the effect of also make Form C a requirement |
| 17:32 | <AryehGregor> | Ugh. |
| 17:33 | <AryehGregor> | Can we get rid of contenteditable=false? It's a pain in the neck to worry about it all the time. |
| 17:33 | <AryehGregor> | (that was rhetorical, I'm pretty sure the answer is "no") |
| 17:34 | <TabAtkins> | Does that let you embed non-editable regions inside a contenteditable? |
| 17:34 | <AryehGregor> | Yes. |
| 17:34 | <AryehGregor> | Which I guess is handy, but it's a huge PITA to make sure all the algorithms leave them alone. |
| 17:35 | <AryehGregor> | Corner case, likely to have lots of bugs. |
| 17:35 | <AryehGregor> | Just ensuring that you don't climb out of contenteditable regions is comparatively easy. |
| 17:35 | <AryehGregor> | Although the original idea of only allowing designMode on whole documents would be even easier to spec and implement. :) |
| 17:36 | <AryehGregor> | But I guess those horrible author people will want these silly features, so spec it we must. |
| 17:37 | <TabAtkins> | Those jerks. |
| 17:38 | <jgraham> | I hate authors almost as much as I hate generated content |
| 17:39 | jgraham | imagines he won't like shadow DOMs any more than generated content |
| 17:39 | <TabAtkins> | At least you've dealt with shadow DOM for years and years, you just didn't know it. |
| 17:40 | <jgraham> | Because of generated content? Well yeah that's one way to look at it |
| 17:40 | <TabAtkins> | No, because of <input>. |
| 17:40 | <TabAtkins> | And friends. |
| 17:41 | <jgraham> | Oh well that's just magic as far as I'm concerened |
| 17:41 | <TabAtkins> | s/magic/shadow DOM/ |
| 17:42 | <Ms2ger> | s//magic/ |
| 17:42 | <jgraham> | If that's how we implement it than I don't know about it. So it's magic to me :) |
| 17:42 | <TabAtkins> | magicmagicmagic |
| 17:42 | <nimbu> | s/magic/typing nightmare/ |
| 17:42 | <TabAtkins> | I know that we, at least, implement it with some combination of pseudo-shadow-DOM and custom C++ renderers. |
| 17:43 | <TabAtkins> | But we're now switching over to pure shadow DOM. |
| 17:43 | <TabAtkins> | And it's apparently a big win. |
| 17:43 | <jgraham> | I remember Mozilla tried to do that like 10 years ago |
| 17:43 | <jgraham> | I dunno what happened |
| 17:43 | <jgraham> | But I certainly recally pure-XBL-forms builds |
| 17:43 | <jgraham> | *recall |
| 17:44 | <TabAtkins> | XBL was just a bad version of shadow DOM, so there you go. |
| 17:44 | Ms2ger | removed some traces of that earlier this year |
| 17:44 | <jgraham> | Well I know that XBL and shadow dom are the same or I wouldn't have mentioned it :) |
| 17:45 | <asmodai> | ye gods, people just don't grasp how ditching HTML versions in favour of feature detection is So Much Nicer(tm). |
| 17:45 | <jgraham> | Who wants versions now? |
| 17:45 | <Ms2ger> | MS? |
| 17:49 | <AryehGregor> | Still? |
| 17:51 | <AryehGregor> | Are they reopening the issue? |
| 17:55 | Ms2ger | knows nothing, but they seemed a possible suspect |
| 17:55 | <asmodai> | Nah, was some topic on a website about last call for HTML 5 |
| 17:56 | <asmodai> | A relatively high-tech oriented site and there's people seriously wondering wth you would want feature detection over HTML versions. |
| 17:57 | <AryehGregor> | Maybe they've never written actual websites. |
| 17:58 | <asmodai> | That's my best explanation. |
| 17:58 | <Philip`> | Got to teach them that web standards aren't like actual standards that software actually implements, where you can meaningfully ask software what standards it implements |
| 17:59 | <asmodai> | I mean, I don't mess with website coding on a daily basis, but the entirety of using feature detection just makes so much more sense for a developing and moving platform like the web. |
| 17:59 | <asmodai> | Philip`: Yeah, pointed them to explanations of graceful degradation and feature detection. |
| 18:00 | <AryehGregor> | In bytes, http://aryeh.name/spec/editcommands/editcommands.html is now about 6% the size of http://whatwg.org/c. |
| 18:00 | <AryehGregor> | And growing. |
| 18:01 | AryehGregor | isn't sure if that's scary or not |
| 18:02 | Philip` | imagines the complexity of a spec increases non-linearly with its size |
| 18:02 | <Philip`> | so the next 6% will be much harder |
| 18:02 | <AryehGregor> | In some ways I've found it's gotten easier, because I have a much better understanding of how everything works. |
| 18:03 | <Philip`> | but fortunately /c will find growth even harder so it won't be too fast a moving target |
| 18:03 | jgraham | imagines this document will be merged into /c eventually |
| 18:03 | <jgraham> | So you can't win |
| 18:04 | <Philip`> | Hmm, yeah, I suppose agglutinating specs is quicker way to seemingly grow |
| 18:21 | <asmodai> | Anyone happen to know if lxml.html's pretty_print needs html5lib to function properly for pretty printing HTML 5 markup? |
| 18:21 | <asmodai> | Because currently, without any html5lib serialisation, it doesn't seem to properly pretty print. |
| 18:25 | <jgraham> | asmodai: No idea. I didn't think lxml ever depended on html5lib though, so I don't see why it would |
| 18:27 | <asmodai> | Well, it doesn't depend on it for its parsing, but you can use it in conjunction. |
| 18:27 | <asmodai> | I'm just not understanding why it's not pretty printing how I expect it. |
| 18:28 | <asmodai> | Even non-HTML5 elements are not pretty printing. |
| 18:28 | <asmodai> | I doubt that lxml would have a bug, so I must be doing something wrong. |
| 18:41 | <hsivonen> | MikeSmith: Normalization checking is based on my 2006 expectation that HTML5 would normatively reference C300 in Charmod-Norm |
| 18:42 | <MikeSmith> | hsivonen: oh |
| 18:42 | <MikeSmith> | but doesn't it sorta do that indirectly now? |
| 18:43 | <hsivonen> | MikeSmith: how? AFAICT, my expectation has so far been wrong |
| 18:44 | <hsivonen> | I also received other feedback about this today |
| 18:44 | <hsivonen> | now I'm really curious to find out what the W3C i18n folks think about charmod-norm today and why |
| 18:45 | <MikeSmith> | hsivonen: I can probably get a quick answer to that by pinging r12a |
| 18:45 | <hsivonen> | I suppose the errors should be downgraded to warnings if there's not going to be a normative trail to a normalization spec |
| 18:45 | <hsivonen> | MikeSmith: already did |
| 18:45 | <othermaciej> | good morning, folks |
| 18:45 | <MikeSmith> | hsivonen: OK |
| 18:46 | <Ms2ger> | I hear i18n has been asking the CSSWG to require NFC-normalizing selectors in css3-namespaces |
| 18:46 | <MikeSmith> | as far as how, I guess I assumed this was something that the upstream Unicode spec would mandate by now |
| 18:46 | <hsivonen> | Ms2ger: I thought they wanted processors to do late normalization |
| 18:46 | <MikeSmith> | hsivonen: so that the rest of us don't have to N number of times |
| 18:46 | <hsivonen> | Ms2ger: instead of requiring authors to do early normalization |
| 18:46 | <hsivonen> | Ms2ger: in the CSS case |
| 18:47 | <Ms2ger> | I think you're right |
| 18:47 | <Ms2ger> | I'm still surprised that they want that specced in namespaces |
| 18:47 | <hsivonen> | (FWIW, I'm very, very much against late normalization for identifier matching) |
| 18:48 | <Ms2ger> | Make sure to convince your CSSWG representative, then :) |
| 18:48 | <hsivonen> | Ms2ger: there are multiple reps to convince :-/ |
| 18:49 | <MikeSmith> | multiple points of failure? |
| 18:49 | <MikeSmith> | othermaciej: おはよう |
| 18:50 | <AryehGregor> | There's no way to make a position: fixed box adjust height (for instance) to fit its contents, right? |
| 18:50 | <hsivonen> | frankly, I get the feeling that the selector normalization debate is an indication that i18n on the Web has been solved |
| 18:50 | <Ms2ger> | By that logic, a11y has been solved as well |
| 18:51 | <hsivonen> | Ms2ger: good point |
| 18:53 | <MikeSmith> | hsivonen: fwiw, I just (re)pinged r12a (but fact is, dude's pretty busy. used to be he had another full-time i18n person on W3C team to help, but now it's just him, and other i18n people outside of the W3C team have been significantly less active lately) |
| 19:50 | AryehGregor | has come to the realization that he needs a higher chair and a higher desk |
| 19:51 | <AryehGregor> | When I sit up straight, my eye level is slightly above the top of my monitor, and my legs have to be uncomfortably squished under me. |
| 19:51 | <AryehGregor> | It can't be good for me. |
| 19:51 | <aho> | i miss my huuuuge desk |
| 19:51 | <aho> | 2.5m x 1.2m x 0.8m |
| 19:52 | <aho> | it was so lovely |
| 19:52 | <aho> | interestingly... it was stolen |
| 19:52 | <aho> | which is... pretty weird |
| 19:53 | <aho> | mmm |
| 19:53 | aho | checks ikea |
| 19:57 | <jgraham> | aho: Noooo. IKEA is the source of all evil |
| 19:58 | <aho> | they dont have ridiculously large desks anyways :f |
| 20:42 | <AryehGregor> | So is there any way at all to center something vertically in CSS, say in a position:fixed div that takes up the whole screen? |
| 20:42 | <AryehGregor> | (don't ask why I'm using a position: fixed div that takes up the whole screen) |
| 20:45 | <AryehGregor> | (or if you want to know: http://aryeh.name/spec/editcommands/linebreaktest.html) |
| 20:49 | <Jon47> | aryehgregor - there's definitely a way |
| 20:49 | <AryehGregor> | Namely? |
| 20:50 | <Jon47> | somethign like this perhaps: http://www.emblematiq.com/blog/vertical_align_with_css/assets/03.html |
| 20:59 | <The_8472> | AryehGregor, that is not easy to achieve because it goes against the concept of CSS flows. at least of vertical ones. and the ability to create horizontal flows is... well... not widely supported yet. |
| 21:00 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=12101 - do we need to clone getters at all? |
| 21:00 | <AryehGregor> | Jon47, oh, display: table-cell. Big surprise. |
| 21:01 | <Jon47> | lol, sorry :( |
| 21:01 | <zcorpan> | seems annoying if a getter does sync xhr or alert or so |
| 21:01 | <The_8472> | another way would be creating an inline-block and making the line-height as big as the container, then vertical-align the inline block |
| 21:02 | <The_8472> | since lines are a poor man's horizontal flow |
| 21:02 | <Jon47> | whenever I've had to do this in the past I just invoke a jquery method to center the element |
| 21:03 | <zcorpan> | just do <br><br><br><br><br> until it looks about right |
| 21:04 | <The_8472> | table layout! |
| 21:07 | <Philip`> | AryehGregor: You don't need a higher chair and desk, you just need a lower floor |
| 21:07 | <AryehGregor> | Philip`, I'll take that into consideration. |
| 21:07 | <Philip`> | Cutting/digging a hole can't be that hard, surely |
| 21:09 | <AryehGregor> | I suspect I'd need a permit. |
| 21:12 | <Philip`> | It's easier to ask for forgiveness than permission |
| 21:13 | <AryehGregor> | Easier, but probably not quite as wise when you're talking about the city buildings commission. |
| 21:13 | <Philip`> | Besides, you could cover the hole up with some kind of camouflage when you're not using it to rest your legs in, so nobody would even know |
| 21:20 | <nimbu> | dbaron: i cant seem to find mochitest in mozilla's latest source code :s the test_animations.html in layout/style/ wont run :/ |
| 21:21 | <dbaron> | nimbu, the stuff in layout/style/test/ and the stuff in testing/mochitest/tests/ gets installed into a separate directory structure |
| 21:21 | <nimbu> | ohh |
| 21:21 | <nimbu> | oops |
| 21:21 | <dbaron> | nimbu, but just combining them so that layout/style/test/ -> .../layout/style/test/ and testing/mochitest/tests/SimpleTest/ -> .../SimpleTest/ should work |
| 21:22 | <dbaron> | nimbu, though there may be some cases where it has / rather than ../../../, which means you'd need to fix that at the top of the *.html in layout/style/test/ |
| 21:22 | <dbaron> | nimbu, since they get served with a local web server |
| 21:22 | <nimbu> | i thought I could get away without building mozilla >_> |
| 21:22 | <dbaron> | nimbu, you can, for many of the tests |
| 21:22 | <nimbu> | ah but your API needs mochitest :) |
| 21:23 | <nimbu> | SpeciaPowers™ |
| 21:23 | <nimbu> | +l |
| 21:23 | <dbaron> | nimbu, yeah, the animations test needs SpecialPowers and that API, but the transitions tests don't |
| 21:23 | <nimbu> | oh neet |
| 21:23 | <nimbu> | let me look at that first then. |
| 21:25 | <dbaron> | nimbu, and it looks like I got the path mapping a little wrong (testing/mochitest/tests/ -> .../tests) |
| 21:25 | <dbaron> | nimbu, and also the MochiKit copy in testing/mochitest/ is needed |
| 21:25 | <dbaron> | nimbu, though it's really just 3 files total |
| 21:27 | <nimbu> | thanks dbaron! ah, i will try building this (my first time!) if I fail I will trouble you again. |
| 21:27 | <dbaron> | nimbu, ah, well, you'd only need to build for the animations test, but yeah... |
| 21:51 | <TabAtkins_> | AryehGregor: Do you know the height of the object? If so, you can center it using "top:50%;margin-top:-<half-the-height>;". |
| 21:52 | <AryehGregor> | TabAtkins_, you mean of the thing I want to center? It's some text, so I suppose I could guess how many lines it will wrap to. |
| 21:58 | <hsivonen> | http://ryanelmquist.com/cgi-bin/xkcdwiki |
| 21:58 | <hsivonen> | 15 steps from HTML5 |
| 22:31 | <jgraham> | Like the Radiohead song |
| 22:33 | <jgraham> | Clearly we should adopt that as the official theme song of HTML5. "How come I end up where I started/ How come I end up where I went wrong / won't take my eye off the ball again" - clearly a reference to W3C abandoning HTML development |
| 22:41 | <yuhong> | FYI, on ISSUE-129 table-border, look up "HTML 3.0 vs Netscape table border" on Google Groups and particularly read the threads from 1995. |
| 22:41 | <yuhong> | ISSUE-155 table-border, sorry. |
| 22:42 | <yuhong> | For some important history. |
| 23:12 | <Yuhong> | http://groups.google.com/group/comp.infosystems.www.browsers.mac/browse_thread/thread/44db96d108412b66/84961a8fa90a26ff?hl=en&ie=UTF-8&oe=utf-8&q=netscape+vs+%22html+3.0%22+tables+border+attribute#84961a8fa90a26ff |
| 23:13 | <Yuhong> | (about the history behind issue-155 table-border) |
| 23:25 | <AryehGregor> | "3D video games are in wide use today." http://www.0xdeadbeef.com/weblog/2011/05/bringing-the-first-3d-html5-video-to-the-web-with-firefox-nvidia-and-youtube/ |
| 23:26 | <AryehGregor> | Um, like which ones? |
| 23:26 | <Hixie> | do they mean in general? |
| 23:33 | <AryehGregor> | I used to do a lot of gaming and read PC Gamer every month, and I don't know of any 3D video games. |
| 23:39 | <Hixie> | there have been 3D video games since the early nineties at least |
| 23:39 | <Hixie> | "Time Traveler" being the first one I know of |
| 23:39 | <Hixie> | dunno about "wide use" though, i'll grant you that |
| 23:40 | <Hixie> | most modern ones tend to be rather elaborate affairs in labs or theme parks |
| 23:40 | <jamesr> | 3ds games? |
| 23:40 | <jamesr> | those are fairly widely used |
| 23:41 | <jamesr> | dunno how well the 3ds is selling |
| 23:41 | <Hixie> | oh yeah, forgot about the 3ds |
| 23:41 | <AryehGregor> | Is that some console? I never followed console gaming. |
| 23:41 | <Hixie> | handheld |
| 23:41 | <jamesr> | nintendo 3ds handheld |
| 23:41 | <AryehGregor> | I know there have been 3D games since the 1990s, but at least on the PC, there have never been any of importance that I know of. |
| 23:43 | <jamesr> | as of late april nintendo claims to have shipped over 9million games for the 3Ds, presumably all of those 3d |
| 23:44 | <jamesr> | 3.6m devices |
| 23:45 | <Lachy> | There are some console games that can be played in 3D if you've got a 3D TV. |
| 23:46 | <Lachy> | The PS3 supports for some games |