| 00:01 | <deane> | How popular is the polyglot idea these days? |
| 00:01 | <key> | plz |
| 00:02 | <deane> | I think it's a silly idea |
| 00:02 | <AryehGregor> | Its popularity is the same as ever, negligible. |
| 00:03 | <Dashiva> | It's very popular among the people who like it |
| 00:03 | <AryehGregor> | Self-flagellation is also very popular among the people who like it. |
| 00:03 | <AryehGregor> | However, they're not representative of the general population. |
| 00:03 | <Dashiva> | Yeah, but I don't think anyone's writing a spec for that |
| 00:04 | <AryehGregor> | I'm fairly sure the details of self-flagellation can be left implementation-defined. |
| 00:04 | <Dashiva> | Yeah, there's no real need for interoperability |
| 00:04 | <AryehGregor> | There could be room for an informative best-practices document, though. |
| 00:05 | <deane> | It conflicts with the HTML WG design principles, for one thing |
| 00:05 | <key> | anyone? |
| 00:06 | <AryehGregor> | deane, if you want spec changes, you should either send a mail to the whatwg list or file a W3C bug. IRC isn't effective, things will get lost. |
| 00:06 | <key> | i really need some strong minds to chime in on this conceptual issue. |
| 00:11 | <deane> | AryehGregor: Thanks, I'm aware of that. I preferred to just let Hixie become aware of it. Plus, I'm waiting for nameserver delegation before I can use my email again |
| 00:11 | <key> | bueller? |
| 00:12 | <deane> | DNS updates ever hour here is NZ |
| 00:12 | <annevk> | oh, Google Voice is international now |
| 00:12 | <key> | when did DNS start propagating in hourly intervals ? |
| 00:13 | <annevk> | I can call for free to Zakim it seems |
| 00:13 | <key> | DNS should update whenever the record's timeout is reached, no? |
| 00:15 | <TabAtkins> | Oh, I didn't realize international was free now. Is it only free for calling into the US, or for any call? |
| 00:17 | <deane> | key: Sorry, I meant name server delegation. The records are updated on the hour here in New Zealand |
| 00:18 | <Sirisian> | omg. Web-apps needs to switch to a forum system. How people can follow mailing lists is insane. |
| 00:18 | <TabAtkins> | Sirisian: The first step is to get a proper mail client. What do you use? |
| 00:19 | <annevk> | TabAtkins, free calling to the US, but I could not get Google Voice so far |
| 00:19 | <annevk> | oh geez |
| 00:19 | <annevk> | I should really sleep |
| 00:19 | <key> | hey guys, please comment on http://www.pastie.org/private/z4e91xoa8dx8twu4etl2ua |
| 00:19 | <jamesr_> | Sirisian: the webapps group does not have changing to a forum in its charter |
| 00:20 | <key> | the basic question is, include expanded full menu tree of a web site in every page, showing only appropriate menu sections with css. or use server side coding to include in each web page only the main menu + sub menu of current section |
| 00:20 | <key> | then not needing to use css to effectively 'hide' inactive sub menus |
| 00:21 | <Sirisian> | TabAtkins, yahoo mail |
| 00:21 | <Sirisian> | heh |
| 00:21 | <TabAtkins> | Sirisian: There's your problem. |
| 00:21 | <TabAtkins> | Get a threaded client with decent search. |
| 00:21 | <Sirisian> | name one. |
| 00:21 | <TabAtkins> | gmail |
| 00:21 | <jamesr_> | no love for my w3c process joke? sigh :( |
| 00:22 | <Sirisian> | If you guys want to join my movement: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/ <-- Mouse Capture for javascript. I need implementors more than other web developers though hmm. |
| 00:24 | <TabAtkins> | The majority of actives in this channel are implementors. |
| 00:25 | <Sirisian> | Good. I need a small army to kill doug maybe. |
| 00:25 | <Sirisian> | I mean er supporters to make a prototype >_> |
| 00:26 | <key> | i'm a developer |
| 00:27 | <Dashiva> | I'm a peanut |
| 00:27 | <tw2113> | my planet got demoted away from a planet |
| 00:29 | <tw2113> | freaking nasa |
| 00:30 | <TabAtkins> | With good reason. |
| 00:30 | <tw2113> | prejudice? |
| 00:30 | <tw2113> | :D |
| 00:31 | <TabAtkins> | Screw pluto. |
| 00:31 | <TabAtkins> | If it can't clean up its neighborhood, it doesn't deserve planethood. |
| 00:32 | <Hixie> | clean up its neighborhood? pluto is an itinerrant planet. |
| 00:32 | <TabAtkins> | We don't allow hobo planets. |
| 00:32 | <Hixie> | it can't even decide where it falls in the order of planets |
| 00:33 | <Hixie> | sometimes it's before neptune or not |
| 00:33 | <Hixie> | s/or not/sometimes it's after/ |
| 00:36 | <ahume_> | Hi WG |
| 00:36 | <ahume_> | Is anyone aware of any conversation around best practises on stashing potentially sensitive data in client-side storage mechanisms? I notice Gmail's mobile app caches unencrypted email messages in a Web SQL db. Is anyone talking about the obvious attack vector there, not in regard to the spec as such, but just around best practise and, well frankly, common sense? |
| 00:37 | <TabAtkins> | Yes. If you're vulnerable to attack, you're vulnerable no matter what the webapp does. Use full-disk encryption. |
| 00:38 | <ahume_> | So you'd argue Gmail's approach is bad practise? |
| 00:38 | <TabAtkins> | No, the opposite. GMail is just fine, because nothing it can do can protect against a compromised computer anyway. |
| 00:40 | <ahume_> | It somehow feels wrong, that I can log in to a site over SSL and when I'm done it's left behind unencrypted data on the client machine's hard drive for the next person to come along and read. |
| 00:40 | <annevk> | jamesr_, I chuckled ;) |
| 00:41 | <TabAtkins> | ahume_: Don't use public computers that don't clean themselves between sessions. |
| 00:41 | <jamesr_> | annevk: thank you :) |
| 00:42 | <TabAtkins> | ahume_: Or use incognito modes, which FF and Chrome both offer (and maybe other browsers?) |
| 00:43 | <ahume_> | Sure - works for me. But in reality people are doing just that everyday. |
| 00:43 | <ahume_> | I'm not saying it's a problem for browser technology or a spec to solve, just that it seems like there should be some best practises for developers. |
| 00:44 | <jamesr_> | don't persist data on a machine you do not trust :) |
| 00:44 | <TabAtkins> | ahume_: The correct practice is for the owner of the computer to set it up properly. |
| 00:45 | <TabAtkins> | For example, ChromeOS has a Guest mode, which automatically makes the session incognito. Running ChromeOS on public computers would thus help. |
| 00:46 | <AryehGregor> | ahume_, there's not really anything you can do. If they can steal data from the computer, they can also steal saved passwords and log in as the user. |
| 00:46 | <AryehGregor> | So you're just making an attacker's life a bit easier if you decide to store data locally. |
| 00:46 | <AryehGregor> | Not really much to do about it. |
| 00:47 | <sephr> | AryehGregor: don't know the context of the argument, but the answer is encryption |
| 00:47 | <sephr> | which chrome os surely would do |
| 00:47 | <AryehGregor> | sephr, no it's not, because we're asking what web developers should do, and they have no control over user-end disk encryption. |
| 00:47 | <TabAtkins> | sephr: No it's not. A compromised computer can intercept information before it's encrypted. |
| 00:48 | <AryehGregor> | Unless you mean encrypt the local DB with a key that's only provided by the server, but that really doesn't buy you much. |
| 00:48 | <TabAtkins> | The correct answer is for the OS to be set up appropriately to prevent data from leaking between sessions. |
| 00:48 | <sephr> | what's the argument about? |
| 00:48 | <AryehGregor> | [110209 19:41:04] <ahume_> Is anyone aware of any conversation around best practises on stashing potentially sensitive data in client-side storage mechanisms? I notice Gmail's mobile app caches unencrypted email messages in a Web SQL db. Is anyone talking about the obvious attack vector there, not in regard to the spec as such, but just around best practise and, well frankly, common sense? |
| 00:48 | <sephr> | I meant os-level encryption |
| 00:48 | <sephr> | not web content level |
| 00:48 | <AryehGregor> | Yes, OS-level encryption is good, but doesn't really help with the original question. |
| 00:48 | <TabAtkins> | Oh, well, yes. |
| 00:48 | <AryehGregor> | Which was asked by a web developer. |
| 00:49 | <TabAtkins> | Dammit, Aryeh, you're beating me. |
| 00:49 | <AryehGregor> | Chrome OS certainly uses full-disk encryption. |
| 00:49 | <AryehGregor> | TabAtkins, getting addicted to a MUD when I was twelve really paid off in typing speed improvements. |
| 00:49 | <sephr> | what's the problem? |
| 00:49 | <sephr> | if everything is encrypted |
| 00:49 | <TabAtkins> | Plus I'm typing another document on my other monitor, and have to flip my mouse to this window to start typing. |
| 00:49 | <AryehGregor> | The problem is it's generally not, on a typical computer. |
| 00:49 | <sephr> | well we're talking about chrome os, no? |
| 00:49 | <AryehGregor> | And you can't tell, as a web developer. |
| 00:49 | <AryehGregor> | No. |
| 00:50 | <AryehGregor> | This is #whatwg, not #chromium-os or whatever the channel is for that. |
| 00:50 | <sephr> | why would I want a web developer to know if I'm using encryption or not? |
| 00:50 | <AryehGregor> | We're talking about web apps. :) |
| 00:50 | <sephr> | that's none of their business |
| 00:50 | <AryehGregor> | . . . |
| 00:50 | <AryehGregor> | The question was asked *by* a web developer. |
| 00:50 | <AryehGregor> | Asking what they, as a web developer, should do. |
| 00:50 | <AryehGregor> | It was not asked from a user's perspective. |
| 00:50 | <sephr> | oh I thought you meant through a JS api |
| 00:50 | <sephr> | to tell if the db is encrypted |
| 00:50 | <sephr> | AryehGregor: <AryehGregor> And you can't tell, as a web developer. |
| 00:51 | <AryehGregor> | That would be hard to define and probably pointless. |
| 00:51 | <sephr> | that's what I was replying to |
| 00:51 | <AryehGregor> | Okay, I think one or both of us is extremely confused, and that we don't actually disagree on anything. |
| 00:53 | <paul_irish> | I think that calls for some P-I-Z-Z-A http://youtu.be/wusGIl3v044 |
| 00:54 | <TabAtkins> | paul_irish: My soul is melting. |
| 00:55 | <key> | extremely odd video |
| 00:56 | <ahume_> | I take the point about users setting up their machines correctly. Most won't of course, and browsers aren't warning about what is being stored locally. But if the local computer is compromised I guess it's compromised and you've got bigger issues. Thanks for your take. |
| 00:57 | <key> | why don't browsers just delete data associated with a secure session when they log out? |
| 00:57 | <key> | or something |
| 00:58 | <key> | (only half listening to ahume's thoughts) |
| 00:58 | <AryehGregor> | Because maybe users want to save data associated with a secure session? |
| 00:58 | <TabAtkins> | Just remember the take-away point. It's not that webdevs *could* protect themselves, but it's easier for the OS to do it. It's that if the OS doesn't do it, there is *nothing* the webdev can do that'll provide proper protection. |
| 00:58 | <TabAtkins> | The most a webdev can do is make it more difficult for an attacker, but "security through slightly increased difficult" isn't security. |
| 00:58 | <key> | what about pragmas that tell the browser how to handle the data |
| 00:58 | <key> | so like some pragma where any data associated with a site is cleared |
| 00:59 | <AryehGregor> | Like sessionStorage? |
| 00:59 | <key> | anything |
| 00:59 | <key> | or user options or something |
| 01:01 | <TabAtkins> | paul_irish: http://www.youtube.com/watch?v=FsJhfwbfMvU |
| 01:02 | <paul_irish> | Director's Cut! |
| 01:18 | <TabAtkins> | I need to expose my pretty view for my blog. |
| 01:40 | <key> | if i have a sub menu UL nested within a main menu UL, what's the best way to style the sub menu distinctly from the main menu? nav > ul and nav > ul > li > ul? or id the UL's and do #main-menu + #main-menu > li and #section-menu + #section-menu > li? |
| 01:43 | <MikeSmith> | ignore key * |
| 01:46 | <tw2113> | how is everyone |
| 01:49 | <TabAtkins> | Man, I want to buy some dang fonts. |
| 01:49 | <tw2113> | i say do it |
| 01:49 | <TabAtkins> | Chaparral is so pretty, but $300 is too much. |
| 01:49 | <tw2113> | unless you can download them free legally |
| 01:49 | <TabAtkins> | Lessee if there's something similar in google's font api... |
| 01:50 | <tw2113> | key whichever adds the least amount of markup |
| 01:52 | <tw2113> | can you style only the items that you want, without adding any ids/classes? if so, go with that method |
| 01:52 | <key> | tw2113: only issue is #id route lets me target all/most browsers, whereas using child selector nav > ul etc is less compatible |
| 01:53 | <key> | id route is faster too i've heard, for the dom, than navigating tags |
| 01:53 | <tw2113> | according to the resource i have with css selectors, you only lose IE6 with >'s |
| 01:53 | <key> | you sure? |
| 01:54 | <tw2113> | http://net.tutsplus.com/tutorials/html-css-techniques/the-30-css-selectors-you-must-memorize/ |
| 01:54 | <tw2113> | #8 |
| 02:02 | <key> | what i *like* about id's is they don't allow reuse |
| 02:02 | <key> | there is exactly 1 main-menu in my site, and only 1 active section-menu at a time |
| 02:02 | <tw2113> | one reason i prefer classes, smaller css files when possible |
| 02:03 | <tw2113> | due to reusability |
| 02:03 | <key> | hrm |
| 02:03 | <key> | yea |
| 02:03 | <key> | "Pro-tip – If your selector looks like X Y Z A B.error, you’re doing it wrong. Always ask yourself if it’s absolutely necessary to apply all of that weight." |
| 02:03 | <key> | so too much decendent lineage is bad too |
| 02:08 | <Sirisian> | Guys API naming. Since mousecapture and mouserelease are pretty much taken by an IE API someone suggested mousegrab. Any other ideas? |
| 02:08 | <Sirisian> | http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0477.html |
| 02:08 | <Sirisian> | bottom part. hmm |
| 02:08 | <key> | thanks for that article tw2113 |
| 02:09 | <key> | mousehouse? |
| 02:09 | <TabAtkins> | mouselock? |
| 02:09 | <tw2113> | comprattrap |
| 02:09 | <Sirisian> | TabAtkins, mouselock and mouseunlock? |
| 02:09 | <key> | mouseear? |
| 02:10 | <Sirisian> | Would that describe the operation of a mouse capture correctly and intuitively for developers? |
| 02:10 | <key> | what is a 'mouse capture' ? |
| 02:10 | <Sirisian> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557#c4 |
| 02:11 | <TabAtkins> | Given the behavior of the mouse not moving, and you only getting deltas instead of movement, I think "lock" is a reasonably clear name. |
| 02:13 | <Philip`> | (I think the technical term for mouse deltas is "mickeys") |
| 02:15 | Philip` | doesn't know if not moving the mouse is always the desired behaviour, though |
| 02:15 | <Philip`> | e.g. there's games which are fullscreen and you can use the mouse cursor like normal except if you move to the edge of the screen it pans the camera |
| 02:16 | <Philip`> | (instead of the default edge-of-screen behaviour, which is moving the mouse onto your second monitor or making the OS switch to the next virtual desktop or whatever) |
| 02:16 | <Philip`> | so you want to capture the mouse but still want absolute coordinates |
| 02:19 | <Sirisian> | Speaking of fullscreen that needs to be changed in most browsers. Going to fullscreen triggers resize events like crazy forcing you to debounce. That and moving the mouse up brings down that bar. Horrible design that needs to be defined in the standard. "A user-agent should not use hover toolbars on the edges of the screen. The fullresolution of the monitor should be used". |
| 02:20 | <Sirisian> | full resolution* |
| 02:20 | <Sirisian> | meh one problem at a time. |
| 02:21 | <jamesr_> | sounds like a quality of implementation issue |
| 02:21 | <jamesr_> | have you filed bugs on the relevant browser vendors? |
| 02:22 | <Sirisian> | I should. Chrome does it in a less annoying way. |
| 02:23 | <jamesr_> | i don't think the spec should (or really can) say that a browser isn't allowed to have hover toolbars or whatnot |
| 02:24 | <Sirisian> | it can make suggestions. |
| 02:24 | <Sirisian> | It's used by implementors after all |
| 02:36 | <MikeSmith> | http://tools.ietf.org/html/draft-rosenberg-rtcweb-framework-00 |
| 02:36 | <MikeSmith> | "Architectural Framework for Browser based Real-Time Communications" |
| 02:52 | roc | wonders why Skype employees are working to put their company out of business |
| 02:54 | <Sirisian> | https://bugzilla.mozilla.org/show_bug.cgi?id=633068 http://code.google.com/p/chromium/issues/detail?id=72515 |
| 02:54 | <Sirisian> | done |
| 02:54 | <Hixie> | roc: because it's good for the world and that trumps short-term corporate interests? |
| 02:54 | <roc> | "Yeah right" |
| 02:54 | <Hixie> | it's going to happen eventually anyway, might as well be part of it |
| 02:55 | <jamesr_> | Sirisian: the fullscreen hover reminder doesn't go away when you move your mouse away? |
| 02:56 | <Sirisian> | jamesr_, hmm? No I mean you should be able to get rid of the reminder. It's pivotal in the future for fullscreen FPS games. |
| 02:57 | <jamesr_> | that doesn't answer my question |
| 02:57 | <Sirisian> | yes it does go away when moving away from the top |
| 02:57 | <Sirisian> | sorry |
| 02:57 | <jamesr_> | then what's the bug? |
| 02:57 | <key> | roc, wise of you to ponder the question with skepticism |
| 02:57 | <roc> | Hixie: that is more likely |
| 02:57 | <key> | there's always an agenda money and/or power are involved |
| 02:57 | <Sirisian> | I can't change it to an enhancement I don't think? |
| 02:58 | <jamesr_> | i don't understand what behavior you think would be better |
| 02:58 | <Sirisian> | jamesr_, A small X to close the reminder. |
| 02:58 | <Sirisian> | hmm maybe I should have written more |
| 02:58 | <jamesr_> | how is that better than moving your mouse away? |
| 03:00 | <Sirisian> | In a game where you're in fullscreen moving the mouse to the top of the screen would cause the reminder to come down. Unless my mouselock idea disables that. meh |
| 03:22 | <Sirisian> | http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0495.html |
| 03:23 | <Sirisian> | His argument kind of makes sense. |
| 03:33 | <roc> | I would like to know about use-cases where the user doesn't want to be full-screen |
| 03:35 | <jcranmer> | so he can alt-tab |
| 03:35 | <jcranmer> | I have no idea what you're talking about |
| 03:39 | <Sirisian> | roc, Games. |
| 03:39 | <Sirisian> | fullscreen canvas is sometimes too CPU intensive. |
| 03:39 | <roc> | nah |
| 03:39 | <roc> | canvas scaling will happen on the GPU in most cases |
| 03:39 | <roc> | going forward |
| 03:39 | <Sirisian> | What if you don't want to scale? |
| 03:39 | <Sirisian> | IE non-vector graphics. |
| 03:40 | <Sirisian> | i.e.* |
| 03:40 | <roc> | bilinear scaling doesn't work for you? |
| 03:40 | <roc> | then put your canvas in the middle of a blank page and make that fullscreen |
| 03:40 | <Sirisian> | Actually I had a few bugs submitted about that |
| 03:40 | <Sirisian> | Most browsers handled bilinear interpolation different causing artifacts. |
| 03:40 | <Sirisian> | I'm not sure if that's fixed. I haven't tested it. |
| 03:42 | <Sirisian> | roc, That would work. Not all games should be forced to be fullscreen. :P |
| 03:43 | <Sirisian> | Basically what that thread and the spec suggestion is to add a java like mouse lock |
| 05:17 | <Hixie> | can you make a call to another function in JS passing it the same arguments without knowing what those arguments might be? something like otherFunction(arguments)? |
| 05:17 | <Hixie> | or does |arguments| not support being passed like that |
| 05:21 | <Sirisian> | apply? |
| 05:21 | <Sirisian> | wait |
| 05:22 | <Sirisian> | not sure why I said that |
| 05:26 | <miketaylr> | from within a function you can do something like fn.apply(this, arguments) |
| 05:27 | <Hixie> | why do i have to use .apply? |
| 05:28 | <miketaylr> | hmm maybe you don't |
| 05:29 | <paul_irish> | because arguments is an array and you have no idea how many there may be.. unless you do. |
| 05:29 | <Hixie> | oh, .apply() takes an array |
| 05:29 | <Hixie> | ok |
| 05:29 | <paul_irish> | fn(arguments[0], arguments[1], ... ) |
| 05:29 | <paul_irish> | yeah fn.apply( context, arrayOfArgs); |
| 05:31 | <miketaylr> | effin apply |
| 05:31 | <Hixie> | k, thanks |
| 07:34 | <Yuhong> | The history of style in HTML is a mess. I am thinking of writing it all up in a blog article. |
| 07:34 | <Yuhong> | It began with when Netscape 0.9 was released around the same time as the first draft of CSS. |
| 07:35 | <Sirisian> | hmm. it's basically XML |
| 07:35 | <Sirisian> | oh style as in styles |
| 07:35 | <Yuhong> | Then Netscape had the JSSS/CSS fiasco around the same time MS rushed to implement draft CSS standards. |
| 07:36 | <Yuhong> | Then eventually came DOCTYPE switching. |
| 07:37 | <Yuhong> | Then the "standards mode" of some browsers turned out to not really comply with standards, requiring more modes to be added. |
| 07:38 | <Sirisian> | I prefer just targetting the newest versions of DOM, JS, and CSS. Much easier. |
| 07:39 | <Sirisian> | My stuff rarely works on anything though. |
| 07:45 | <Yuhong> | One of the worse cases was IE6, which had a "standards mode" that was not really compliant, which lasted for *five* years, causing trouble when IE7 was released after that. |
| 07:47 | <Yuhong> | And it's dominance didn't help either. |
| 07:47 | <Sirisian> | I feel bad for the people that had to target it |
| 07:54 | <Yuhong> | http://www.reddit.com/r/web_design/comments/filpx/the_full_story_on_css_support_in_ie_second_attempt/ |
| 08:23 | <othermaciej> | what browsers support History.pushState? |
| 08:24 | <annevk> | Gecko/WebKit I think? |
| 08:25 | <othermaciej> | not in Opera yet? |
| 08:29 | <gsnedders> | othermaciej: not in Opera yet. |
| 08:29 | <othermaciej> | ok |
| 08:29 | <othermaciej> | I wanted to know for purposes of posting on a Hacker News thread |
| 08:29 | <othermaciej> | since no one knew there was actually a way to avoid #! URLs in AJAX apps |
| 08:30 | <othermaciej> | (though sadly not in Opera or IE) |
| 08:31 | <matjas> | http://caniuse.com/history |
| 08:31 | <othermaciej> | matjas: sweet! |
| 08:32 | <matjas> | othermaciej: caniuse.com/[insert feature here] |
| 08:54 | <hsivonen> | annevk: this is the encoding sniffing ping |
| 09:01 | <hsivonen> | https://twitter.com/#!/simonstl/status/35451136970334209 |
| 09:02 | <othermaciej> | the Web would be so awesome if only we didn't have those pesky browsers in the way |
| 09:03 | <annevk> | I replied to that |
| 09:03 | <hsivonen> | othermaciej: browsers are a just a niche thing. like the Web! |
| 09:03 | <annevk> | it did not really go anywhere |
| 09:04 | <annevk> | all I got out was a link to the article about when Larry objected to publishing and there was a minor media frenzy |
| 09:05 | <annevk> | I wondered after I got that link if that was also the point when Larry pretty much stopped participating |
| 09:05 | <hsivonen> | If the WHATWG is the Republicans, what's Adobe? |
| 09:05 | <Dashiva> | The UN |
| 09:06 | <deane> | or worse |
| 09:07 | <zewt> | in its own little closed-off completely proprietary world with no interoperability with anyone else--i suppose suggesting north korea would be a little harsh, heh |
| 09:10 | <zewt> | only one of countless islands, of course |
| 09:10 | <zewt> | (... adobe, not korea) |
| 09:17 | <annevk> | hsivonen, emailed the little bit of information I have |
| 09:17 | <annevk> | hsivonen, oh, and it's not pretty :) |
| 09:19 | <hsivonen> | annevk: thanks. |
| 09:20 | <hsivonen> | annevk: looks like what you said is incomplete or .org is a sniffable domain |
| 09:20 | <hsivonen> | annevk: or UTF-16 is special |
| 09:20 | <hsivonen> | annevk: because BOMless UTF-16 gets sniffed when served from bugzilla.mozilla.org |
| 09:22 | <annevk> | maybe it is enabled by default then on desktop |
| 09:23 | <hsivonen> | annevk: it would be a very odd choice to enable stuff by default on desktop if it isn't enabled everywhere |
| 09:23 | <hsivonen> | because desktop has UI override but Mini/Mobile don't |
| 09:24 | <hsivonen> | sigh. it looks like Firefox 3.6 sniffs BOMless UTF-16 even when chardet has been turned off |
| 09:25 | <annevk> | hmm yeah sorry :/ |
| 09:25 | <hsivonen> | I guess it's another late-cycle firedrill for me then |
| 09:25 | <annevk> | basically I would not worry too much about Operad |
| 09:26 | <hsivonen> | bz worries about this, so now I am |
| 09:26 | <hsivonen> | worrying that is |
| 12:07 | <jgraham> | hsivonen: FWIW I would appreciate tests for bug 11393 in the html5lib testsuite (segregated into a -pending file) if you have the chance to write them |
| 12:09 | <hsivonen> | jgraham: might take a while |
| 12:11 | <jgraham> | hsivonen: Sure. I might even get their first :) |
| 12:12 | <annevk> | http://norman.walsh.name/2011/02/08/html-xml#comment0001 good comment |
| 12:13 | <hsivonen> | annevk: mine hasn't been approved yet |
| 12:13 | <annevk> | mattur really hits it |
| 12:14 | <hsivonen> | mattur should definitely have more followers |
| 12:18 | <karlcow> | mattur has interesting points but I don't see how it hits it. |
| 12:20 | <karlcow> | what the comment shows is a surprising understanding of how w3c organization is working. |
| 12:20 | <karlcow> | I meant surprising as ill |
| 12:22 | <annevk> | if it's XML vs HTML he hits in the way that the HTML proponents never tried blocking XML (in fact, many of us have actively advocated XHTML) yet the opposite clearly happened time and again |
| 12:23 | <karlcow> | rdf has been developed test driven for a very long time. OWL is entirely built like this through implementation. The mistake of Semantic Web participants has been to not take into account the messy Web as a requirement. It was not their goal before. |
| 12:23 | <karlcow> | where I deeply agree with mattur though |
| 12:24 | <karlcow> | is "If one of those development paths wants to feature in the other development path, it should probably do so by integrating rather than attempting overwriting." |
| 12:24 | <karlcow> | he is perfectly right on it here. |
| 12:24 | <jgraham> | karlcow: What does test-driven have to do with anything? |
| 12:24 | <karlcow> | yes annevk agreed. |
| 12:25 | <hsivonen> | karlcow: it seems to me that circa 1998 RDF was theory-driven |
| 12:25 | <hsivonen> | karlcow: 1998 matters |
| 12:25 | <karlcow> | first version of rdf yes. |
| 12:25 | <hsivonen> | karlcow: it's what poisoned XML with Namespaces |
| 12:26 | <annevk> | I'm getting a little tired of the continued slamming from the XML community and might just start ignoring them at some point. |
| 12:26 | <hsivonen> | AFAICT, the URI as identifier for everything meme didn't have wide XML community support |
| 12:26 | <karlcow> | hsivonen: this seems to be new "story" but I haven't found any mail yet saying namespaces for XML because of RDF |
| 12:27 | <annevk> | I have worked hard in the past to make XHTML work. To get XML properly implemented. I have proposed an alternative for XML that I think will give it more traction and make it more useful on the web. |
| 12:27 | <hsivonen> | karlcow: http://lists.w3.org/Archives/Public/semantic-web/2007Dec/0116.html |
| 12:27 | <karlcow> | annevk: I do not agree with norman as well in his blog post |
| 12:27 | <annevk> | I have done my part to make their vision a reality. What have they done? |
| 12:27 | <karlcow> | he is missing one point in his 3 use cases |
| 12:27 | <hsivonen> | annevk: I used to be a believer when I made Gecko load XHTML incrementally |
| 12:28 | <hsivonen> | annevk: well, maybe not a believer but I still cared enough |
| 12:28 | <karlcow> | hsivonen: this is a recent email. The oldest mail about mail I found about namespaces so far was 2001 |
| 12:28 | <hsivonen> | karlcow: are you saying that TimBL misrepresents history in the email? |
| 12:28 | <annevk> | I don't think any of those in the XML community has done as much as us to make XML useful for people making web sites. |
| 12:29 | <annevk> | And yet all we get is shit. |
| 12:29 | <karlcow> | the point that IMHO norman forgets is the possibility of one community to forge its own model and not care about the rest because it is not important. It's how all social groups in history have changed a way of thinking. |
| 12:29 | <hsivonen> | btw, my todo list for *this* year, too, includes making XHTML suck less |
| 12:30 | <karlcow> | intimately I think norman things about the consensus and the collective agreement as I do. (old school I guess) |
| 12:31 | <karlcow> | hsivonen: I'm saying that Timbl has certainly his own interpretation like I do and like you do. |
| 12:32 | <webr3> | hsivonen, RDF didn't poisen XML with Namespaces, there was a requirement to have uri shortening and the xml folks decided that tuples with two components that don't turn back in to a single URI would be ideal |
| 12:33 | webr3 | researched and stuck out the tweet bringing this to the fore again because of the issue-120 thing, wanted to know history |
| 12:33 | <hsivonen> | webr3: the toxic meme is identifying with things that aren't Web resources with URIs in the first place |
| 12:33 | <hsivonen> | webr3: shortening is just a consequence |
| 12:34 | <webr3> | hsivonen, you mean like mailto: and data: i guess? |
| 12:34 | <hsivonen> | webr3: that is, I think wanting to identify element names with URIs is where things went wrong |
| 12:34 | <webr3> | k, i follow :) |
| 12:35 | <webr3> | what about specifying link relations with uris? |
| 12:35 | <karlcow> | the thing which worries me about using http uri for identifying things is the "domain name". This part is the weakest link in the chain. |
| 12:36 | <karlcow> | socially and structurally weak |
| 12:36 | <hsivonen> | webr3: that sucks, too, but allowing it makes the "everything is a URI" folks complain less |
| 12:38 | <webr3> | hsivonen, can track that back to: http://markmail.org/message/gzelah3xqxspuoy2 |
| 12:39 | <webr3> | karlcow, the above link also covers what you said |
| 12:40 | <webr3> | i.e. decision was taken w/ eyes wide open and trade-offs were made - afaict |
| 12:40 | <hsivonen> | webr3: ooh! also WebDAV to blame in addition to RDF! |
| 12:41 | <webr3> | hsivonen, lol yup you'd be surprised.. http://markmail.org/message/kwk5bfpbisww3itg - karlcow, you may appreciate that one too (it's read write web of linked data 13.5 years ago)! |
| 12:42 | <webr3> | hsivonen, webdav and rdf came together as a result of PICS NG http://www.w3.org/PICS/NG/ |
| 12:43 | <webr3> | quite interesting to see the design process and hook it up to whats happening today, a lot of things still make sense (to me), although some bits i would have cut and simplified |
| 12:43 | <hsivonen> | webr3: WebDAV is an overkill compared to sftp or sshfs |
| 12:44 | Philip` | 's favourite part of WebDAV is how it means he can't access SVN when he's forced to use a standard HTTP proxy |
| 12:47 | <hsivonen> | HTTP proxies are also such a huge source of badness |
| 12:47 | <hsivonen> | great idea in theory, of course |
| 12:49 | <jgraham> | Philip`: Not being able to access SVN is a good thing :) |
| 12:50 | <jgraham> | It's a hint |
| 12:51 | <webr3> | so, what happens when two worlds colide, one where people took one set of tradeoffs, and the other took the other set, this is basically what's happening with issue 120, identifying relations as "foo" vs "http://example.org/vocab#foo";, do you go for one, the other or both, and if both do you cater for the needs of both parties or not |
| 12:52 | <webr3> | the decision is already "both", and now all that remains is whether to cater for the needs or not, in this case, URI shortening |
| 12:52 | webr3 | sumamrises |
| 12:55 | <karlcow> | nice finds, web |
| 12:56 | <karlcow> | webr3 |
| 13:29 | <karlcow> | http://tools.ietf.org/html/draft-rosenberg-rtcweb-framework-00 |
| 13:44 | <Ms2ger> | annevk, AryehGregor, I'm probably going to submit my drafts somewhere this month |
| 13:55 | <jgraham> | Ms2ger: You are going away? |
| 13:57 | <webr3> | karlcow, cheers re "nice finds" - and re rtcweb, Figure 1 looks like it's wrong, very wrong - in fact websockets/http would be positioned exactly as rtc (apis,functions,arrows) are |
| 13:57 | webr3 | afaict |
| 14:06 | <annevk> | I threw my IRC lines together in this short rant: http://annevankesteren.nl/2011/02/xml-tired |
| 14:06 | <annevk> | Hopefully I can now focus on DOM Events again |
| 14:06 | <Ms2ger> | jgraham, no |
| 14:36 | <virtuelv> | are there any crawlers that crawl with scripting enabled these days? |
| 14:37 | <annevk> | if Bing picks up results from what you browse in IE... |
| 14:38 | <Philip`> | Googlebot crawls URLs extracted from strings in JS code |
| 14:38 | <Philip`> | (not via a real JS parser though) |
| 14:44 | <annevk> | hmm |
| 14:44 | <annevk> | is it |
| 14:44 | <annevk> | invoke e's target event listeners |
| 14:44 | <annevk> | or |
| 14:44 | <annevk> | invoke e's target's event listeners |
| 14:49 | <Philip`> | Is this a spec question or a grammar question? |
| 14:49 | <annevk> | grammar |
| 14:49 | <Philip`> | If it's the event listeners of the target of e, then the latter |
| 14:50 | <annevk> | thanks |
| 14:50 | <annevk> | seemed a bit weird |
| 14:50 | <Philip`> | ("X's Y" == "Y of X", pretty much) |
| 14:51 | <annevk> | I guess I could reword it |
| 14:51 | <annevk> | maybe later |
| 14:51 | <annevk> | I'm sure this section will be refactored a few times |
| 15:11 | <connrs> | annevk: <delurk> i feel that 'invoke the event listeners of e's target' may be more readable and reduces misinterpretation <relurk> |
| 15:11 | jgraham | wonders what happens if you nest a <relurk> inside a <delurk> |
| 15:12 | <annevk> | connrs, changed |
| 15:12 | <hsivonen> | jgraham: <relurk> implicitly pops <delurk> off the stack, so you can't nest them |
| 15:13 | <jgraham> | hsivonen: Ah. That makes sense |
| 15:14 | <connrs> | hsivonen: agreed. in fact if you tried to force a <delurk><relurk/></delurk>, heads of introverts around the globe would pop simultaneously |
| 15:25 | <annevk> | why is it cancelable and preventDefault()? |
| 15:25 | <annevk> | e.g. cancelable and cancel() would make more sense |
| 15:25 | <annevk> | or hasDefaultAction and preventDefault() |
| 15:28 | <annevk> | ah, topic |
| 15:28 | <jgraham> | annevk: The thing you have to remember about the DOM specs is that they were written in the 90s. In the 90s people thought that Pop Tarts made sense for breakfast. Is it any wonder then that DOM can seem a little illogical? |
| 15:29 | <annevk> | :) |
| 15:54 | <connrs> | hatwg.org/ -- logs: http://krijnhoetmer.nl/irc-logs/ -- stats: hhatwg.org/ -- logs: http://krijnhoetmer.nl/irc-logs/ -- stats: hhatwg.org/ -- logs: http://krijnhoetmer.nl/irc-logs/ -- stats: h |
| 15:54 | <connrs> | le.net/k2QxH/ , I am trying to have #edit_resolved checked or unchecked based on the result of the resolved variable that is pulled from p |
| 16:28 | <jgraham> | IE9 RC today, it seems |
| 16:33 | <karlcow> | http://code.google.com/web/ajaxcrawling/docs/getting-started.html |
| 16:33 | <karlcow> | # in URIs |
| 16:39 | <karlcow> | https://github.com/fields/addressable#readme |
| 16:43 | <TabAtkins> | Argh, the :visited styling on the HTML objection polls is HORRIBLE. ARgha;sdlkfs |
| 16:44 | <hsivonen> | is there a poll I should object on? |
| 16:44 | <TabAtkins> | http://www.w3.org/2002/09/wbs/40318/issue-129-objection-poll/ |
| 16:44 | <TabAtkins> | about aria changes |
| 16:44 | <hsivonen> | :-( that one takes some reading to object to |
| 16:44 | <TabAtkins> | Yup, that's what I'm doing this morning. |
| 16:46 | <karlcow> | TabAtkins: the visited styling is the purple underscored. Another suggestion? |
| 16:47 | <TabAtkins> | It's purple with a black background. |
| 16:47 | <karlcow> | huh? |
| 16:47 | <karlcow> | I do not have that |
| 16:47 | <TabAtkins> | I don't know how it gets that. |
| 16:47 | <TabAtkins> | My inspector clearly shows an #eee background winning. |
| 16:47 | <TabAtkins> | But there's black on my screen. Hm. |
| 16:47 | <TabAtkins> | Chrome 9 beta, for what it's worth. |
| 16:48 | <hsivonen> | isn't 9 beta ancient by now? |
| 16:48 | <TabAtkins> | Huh. Turning off the #eee rule (letting it go back to the default transparent) makes it fine. |
| 16:48 | <karlcow> | no issue on Opera and webkit for me |
| 16:48 | <TabAtkins> | hsivonen: I haven't rebooted my computer in a month. |
| 16:48 | <karlcow> | must be your build |
| 16:48 | <karlcow> | strange |
| 16:49 | <TabAtkins> | Well, my comp's yelling at me to reboot anyway, and I've got weeks of browser updates waiting for a restart, so I guess I'll just restart today and see what happens. |
| 16:51 | <TabAtkins> | Yeah, this doesn't even make sense. Inspector claims the computed style for "background-color" is "black", and links to line 44 of style.css, which clearly says "background: #EEE;". |
| 16:51 | <TabAtkins> | I dunno, that's crazy. |
| 17:04 | <jgraham> | TabAtkins: You know it is generally possible to restart your browser without restarting your computer, right? |
| 17:05 | <webr3> | fyi: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0104.html proposal to strongly deprecate xmlns in rdfa 1.1 |
| 17:12 | <bfrohs> | IE9 RC just released: http://www.beautyoftheweb.com/ |
| 17:12 | <bfrohs> | (well, at least announced on twitter) |
| 17:12 | <TabAtkins> | jgraham: The two are basically connected. All the important desktop state is contained in my tabs. |
| 17:14 | <jgraham> | TabAtkins: But restarting you browser is fast compared to restarting you computer (probably) and most state will be restored |
| 17:14 | <TabAtkins> | Your moon logic is nonsensical to me. |
| 17:16 | <hsivonen> | FAIL! Without Flash Player installed, IE9 RC prompts to save Flash ads to disk as downloads |
| 17:16 | jgraham | is trying to work out if the implication was that I'm female and, if so, TabAtkins will survive the offence taken by girls everywhere |
| 17:17 | TabAtkins | doesn't understand how he implied James was female. |
| 17:17 | <jgraham> | hsivonen: Seems like a showstopper. Of course they may be using this newfangled meaning of "RC" |
| 17:17 | <hsivonen> | jgraham: maybe everyone except me has Flash Player installed anyway, so it doesn't matter |
| 17:18 | <jgraham> | TabAtkins: The intertubes inform me that "moon logic" might be primarily used when boys don't understand girls |
| 17:18 | <jgraham> | They may be confused ofc |
| 17:18 | <TabAtkins> | ...I have never heard of this. |
| 17:35 | <jgraham> | To ensure that I have read this correctly: If I have a parser-inserted <script> that (synchronously) removes a subtree containing itself from the tree and, later in the same subtree have another script, that second script will not be run |
| 17:35 | <jgraham> | right? |
| 17:36 | <jgraham> | Because the second script is not in a document at the time we prepare it |
| 17:36 | <hsivonen> | jgraham: right |
| 17:38 | <Sirisian|Work> | Hey guys. How do you send correctly formatted mailing list stuff from a yahoo email? Apparently when I use yahoo mail the font is too large or wrong. What font and size do people use? I keep doing it wrong :\ Is there like a separate client people use to view and post to mailing lists? |
| 17:39 | <TabAtkins> | Can you send plaintext email? |
| 17:39 | <TabAtkins> | That's what most of us do. Using HTML email is a failure. |
| 17:39 | <Sirisian|Work> | ooh I see |
| 17:40 | <TabAtkins> | For formatting in plaintext, most people use Markdown or some ad hoc variant. |
| 17:41 | <Sirisian|Work> | Cool I got it working. There was a "plain text" and "rich text" mode. |
| 17:50 | <TabAtkins> | Okay, so this is an interesting proposal from Sylvain. Plan for the "From-Origin" header to let sites opt into same-origin restrictions for any resource. Then, have @font-face act as if "From-Origin:same" was sent by default (overrideable by actually sending From-Origin). |
| 17:56 | <jgraham> | TabAtkins: That doesn't seem to address othermaciej/annevk's consistency objections |
| 17:58 | <TabAtkins> | It partially does. The default behavior of fonts is different, but they're all controllable with the same mechanism in this proposal, unlike the existing idea of using SOR+CORS for font, and From-Origin for other things. |
| 18:07 | <hsivonen> | What kind of geolocation back end does IE9 use? |
| 18:08 | <hsivonen> | it reports my location in the sea next to New Zealand |
| 18:09 | <bfrohs> | Are you in Atlantis, perhaps? |
| 18:09 | <Rik`> | nice :) |
| 18:09 | <TabAtkins> | I'm going to assume that's accurate from now on, hsivonen. |
| 18:13 | <hsivonen> | hmm. maybe the site I used randomized the location on failure |
| 18:14 | <hsivonen> | another site said the location request failed |
| 18:22 | <TabAtkins> | Oh jeezus I just broke my computer. |
| 18:22 | <TabAtkins> | This is the computer's way of saying "Restart me now, jackass". |
| 18:40 | <AryehGregor> | So what's a good way to break up tests like <http://aryeh.name/spec/dom-range/test/Range-set.html>;? Just make lots of files arbitrarily, like each one tests only a few of the test Ranges? |
| 18:46 | <AryehGregor> | Hmm. How does encoding work for JavaScript files? |
| 18:46 | AryehGregor | uses HTML escapes to avoid the issue |
| 19:20 | <TabAtkins> | Bleh, back. Computer hung on restart, and I was doing other things so I didn't notice. |
| 19:34 | <AryehGregor> | IE9 just crashes on my latest test. Or at least the tab does. |
| 19:34 | AryehGregor | doesn't care, it works fine in Gecko and WebKit |
| 19:34 | <AryehGregor> | IE9 has come a long way, but it still has ground to cover . . . |
| 19:47 | <Moo-_> | AryehGregor: I saw the release |
| 19:48 | <Moo-_> | can you please tell me what kind of issues I need to prepare with the newest incarnation of blue E? |
| 19:49 | <AryehGregor> | Oh, now there's an RC. |
| 19:49 | <AryehGregor> | I should upgrade. |
| 19:49 | <AryehGregor> | In my experience with the betas, JS you write for other browsers is fairly likely to work in IE9, or at least mostly work. |
| 19:49 | <AryehGregor> | As opposed to failing horribly as with IE8. |
| 19:49 | <AryehGregor> | So it's a huge step forward. |
| 19:50 | <Moo-_> | so it doesn't fail horrible, but fails pleasantly |
| 19:50 | <Moo-_> | nice :) |
| 19:51 | <AryehGregor> | If it fails, it often fails in a way you can work around without having to have a separate code path. |
| 19:51 | <AryehGregor> | Or at least so I've seen so far. |
| 19:52 | <AryehGregor> | It looks like Opera's Selection.toString() does plaintext conversion, so sadly, it seems like some form of that might have to be specced one way or the other. :( |
| 20:04 | <AryehGregor> | See, this is why I want DOM Range to be in W3C space: http://lists.w3.org/Archives/Public/public-html-testsuite/2011Feb/0014.html |
| 20:04 | <AryehGregor> | IE actually pays some attention to stuff in W3C space. |
| 20:06 | <AryehGregor> | Oh, atob()/btoa() aren't in the W3C HTML5 version anymore. Oh well. |
| 20:06 | <Hixie> | it'll be back i expect |
| 20:06 | <AryehGregor> | In HTML5, or some future W3C version? |
| 20:06 | <Hixie> | 5 |
| 20:07 | <Hixie> | i was speaking to jeff jaffe (w3c ceo) about stuff on the same day i was adding atob() and he said he though things like atob() were important enough to do an in-place edit of a REC to add them back. |
| 20:07 | <AryehGregor> | Really? Interesting. |
| 20:07 | <AryehGregor> | Why is it so important? |
| 20:08 | <AryehGregor> | They seem to still be there, by the way: http://dev.w3.org/html5/spec/webappapis.html#atob |
| 20:08 | <Hixie> | well if you buy into the idea that only RECs are relevant, and you still want interop, that's pretty much the only way to get interop |
| 20:08 | <AryehGregor> | Yeah, it's not like it's a new feature. Just speccing a preexisting one. |
| 20:08 | <othermaciej> | I'm sure someone will file a bug asking to add them back |
| 20:09 | <Hixie> | anyway i don't know how sam's viewpoint on things like this and jeff's viewpoint on things like this will shake out, but i expect they'll find a compromise before we go to REC |
| 20:09 | <TabAtkins> | Wait, why was atob removed? |
| 20:09 | <Hixie> | i just don't want to fight sam on what's in and what's out, so i figured i should pre-emptively try to get on his good side (http://www.w3.org/Bugs/Public/show_bug.cgi?id=12029) |
| 20:10 | <TabAtkins> | Ah, kk. |
| 20:10 | <TabAtkins> | I suppose I can object to it being excluded when it tries to move to CR. |
| 20:11 | <Hixie> | a good argument can be made that it shouldn't be in the html spec at all anyway |
| 20:11 | <Hixie> | if one cares about such things |
| 20:11 | Hixie | neither cares about that nor about CR/REC anymore, so... :-) |
| 20:12 | <AryehGregor> | Where should it be, then? |
| 20:12 | <Hixie> | DOM Core, and we'd move Window there too, probably |
| 20:12 | <Hixie> | dunno |
| 20:12 | <Hixie> | i think we should be merging all these specs, not splitting them |
| 20:20 | <hsivonen> | Hixie: will Acid4 test only RECs? :-) |
| 20:23 | <Moo-_> | when I will be able to copy-paste image to my WYSIWYG browser based editor? :) |
| 20:25 | <TabAtkins> | That's possible now, via D&D. |
| 20:28 | <AryehGregor> | If the author writes support, or just for all contenteditable? |
| 20:28 | <TabAtkins> | I think you have to write support. |
| 20:29 | <othermaciej> | you can copy and paste images into an HTML editable area |
| 20:29 | <othermaciej> | I don't think you need to write support |
| 20:29 | <othermaciej> | though arranging to upload the image may be tricky |
| 20:29 | <othermaciej> | (for DnD you probably need to write something) |
| 20:34 | <AryehGregor> | If I wanted to submit the execCommand() stuff to the W3C, which Working Group would I submit it to? |
| 20:34 | <jgraham> | I thought that was part of HTML5 at one point |
| 20:34 | <realityking> | I may be mistaken, but isn't in XHTML5 valid behavior for a parser to ignore anything and all inside a comment just like in XML? (e.g. an XML comment inside a style or script element, the commented code can be ignored). Or has that changed? |
| 20:34 | <TabAtkins> | execCommand is part of HTML. |
| 20:35 | <AryehGregor> | Where is it in the HTML spec? |
| 20:35 | <AryehGregor> | realityking, XHTML is parsed like normal XML, according to XML parsing rules. |
| 20:35 | <AryehGregor> | No magical behavior for scripts. |
| 20:35 | <AryehGregor> | Anyway, if there's a preexisting spec for execCommand(), I'd like to know about it, because I'm starting to write one. |
| 20:35 | <realityking> | then Mircosofts HTML5 testsuite is in error? http://samples.msdn.microsoft.com/ietestcenter/html5/xhtml_harness.htm?url=html_style_in_comment |
| 20:37 | <TabAtkins> | Just based on history and statistics, the answer is "probably yes". |
| 20:37 | <AryehGregor> | realityking, the test looks correct to me. |
| 20:38 | <AryehGregor> | The correct behavior is to ignore the h4 { color: red } rule, which is what the test asks. |
| 20:38 | <TabAtkins> | AryehGregor: Look in the "Editing APIs" section. |
| 20:38 | <AryehGregor> | Oh. |
| 20:38 | <AryehGregor> | Okay, then. |
| 20:38 | <jgraham> | AryehGregor: Does that mean that you are going to submit many tests to the HTML testsuite? Yay! |
| 20:39 | <AryehGregor> | jgraham, does which mean? |
| 20:39 | <realityking> | AryehGregor: thanks, I read that wrong |
| 20:40 | <AryehGregor> | Oh, what I was given even says it's supposed to be in the HTML spec in the end. |
| 20:40 | <AryehGregor> | Okay, then. |
| 20:41 | <jgraham> | AryehGregor: That you are working on execCommand |
| 20:41 | <AryehGregor> | Hopefully, yep. |
| 20:41 | AryehGregor | writes his own spec for now, it can be integrated later |
| 20:41 | jgraham | thinks the W3C should use the HTML logo t-shirt monet to buy t-shirts for people that submit tests to the HTML testsuite |
| 20:42 | bfrohs | agrees |
| 20:42 | <jgraham> | Or we should have some reward system based on number of approved tests (or better, number of approved tests that fail in two or more browsers) |
| 20:45 | <roc> | Moo-_: in Firefox 4 we changed things so that pasting an image creates an <img> with a data: URL |
| 20:45 | <AryehGregor> | Failing in one browser should be good enough. |
| 20:45 | <AryehGregor> | roc, with any limitations on size? |
| 20:46 | <roc> | I do not recall |
| 20:46 | <zewt> | hopefully that'll get a real API soon; data: URLs aren't very practical for full-size images |
| 20:46 | <roc> | why not? |
| 20:46 | <roc> | the base64 expansion kinda sucks but it's not that bad |
| 20:47 | <zewt> | multi-megabyte URLs? |
| 20:47 | <roc> | there aren't really any other options |
| 20:47 | <roc> | works for me |
| 20:47 | <TabAtkins> | It's only, what, 2/3rds larger than a naive binary encoding? |
| 20:47 | <TabAtkins> | At worst? |
| 20:48 | <roc> | 1/3 |
| 20:48 | <roc> | i.e. a 100K image expands to 133K |
| 20:49 | <zewt> | setting a 5-megabyte attribute value in javascript sets of general alarm bells in mind mind; but i'd need to think about it more |
| 20:49 | <roc> | I can't think of any better way to get an image inline that survives roundtripping |
| 20:49 | <zewt> | (mind mind mind mind mind) |
| 20:50 | <jgraham> | AryehGregor: Maybe one point per browser it fails in |
| 20:50 | <roc> | I know certain browsers have limitations on data: URL length, but those are just bugs |
| 20:50 | <hsivonen> | did IE9 remove that bug? |
| 20:51 | <roc> | An editor script could override this by replacing the data: URLs with links to some upload service or something, but that's not something the browser should do IMHO |
| 20:51 | <zewt> | an ideal API, i think, would be for pasting with an image (or other large resource) to expose a FileAPI file, which you could get an object URL from--though that doesn't actually cover the case of raw image data in the clipboard (it'd need to be transparently converted to a BMP, or something along those lines) |
| 20:52 | <AryehGregor> | Does Firefox 4 have some type of built-in DOM inspector? |
| 20:52 | <AryehGregor> | (or alternatively, does Firebug work with it?) |
| 20:54 | <roc> | Firebug does work |
| 20:54 | <roc> | there is no built-in DOM inspector |
| 20:54 | <roc> | (yet) |
| 20:55 | <zewt> | perhaps not enough justification, but one advantage of that is if you paste into a page and the page (for example) draws it into a canvas, it can be done without converting the data at all; it'd only need to be converted to a visible file format if it was actually read from |
| 20:55 | <roc> | the "DOM Inspector" extension also works |
| 20:55 | <AryehGregor> | Ah, you need to use an alpha version. |
| 21:02 | <jgraham> | TabAtkins: I don't understand what point you are making in your recent whatwg post |
| 21:03 | <Hixie> | hsivonen: the bar with acid3 was already just "in CR for at least 3 years" or some such, it's only a little step forwards to go from that to just "specified for at least 3 years". |
| 21:03 | <jgraham> | (about script execution/parsing) |
| 21:03 | <TabAtkins> | jgraham: Trying to correct getify, is all. |
| 21:03 | <TabAtkins> | jgraham: He's making a bad distinction that's harming his reasoning. |
| 21:03 | <jgraham> | Maybe I don't understand what distinction he was making then |
| 21:03 | <zewt> | awesome, single-page html5 spec has completely frozen ff3, heh |
| 21:04 | <zewt> | time for all work to come to a grinding halt until it wakes up again |
| 21:04 | <roc> | mmm use FF4 :-) |
| 21:04 | <TabAtkins> | He thinks that there is some step called "parsing" where function definitions are evaluated. |
| 21:04 | <roc> | that page is, in fact, much better in FF4 |
| 21:04 | <jgraham> | there is a not-quite-irrelevant distinction between a FunctionExpression and a FunctionDeclaration which is that a FunctionDeclaration is hoisted to the top of the enclosing scope |
| 21:05 | <TabAtkins> | That distinction *is* irrelevant for the purpose of determining when functions are parsed or defined. |
| 21:06 | <zewt> | roc: i suppose there would be some circularity to using the html5 spec's html as a test case for rendering html |
| 21:07 | <roc> | Ian's a big fan of that :-) |
| 21:07 | <TabAtkins> | zewt: Only if you are literally executing the html5 spec as your browser's implementation of HTML5. |
| 21:07 | <TabAtkins> | And even then, that's just testing the ability of html5 to self-host. ^_^ |
| 21:08 | <zewt> | heh well, just referring to a basic performance regression test, eg. "how long does the HTML5 spec page take to render" |
| 21:08 | <zewt> | don't know if there's one of those in firefox, but i wouldn't be surprised |
| 21:08 | <jgraham> | TabAtkins: I don't understand wht you mean by "defined". But sure, the implementation will likely convert the whole thing to an AST at once |
| 21:08 | <hsivonen> | zewt: the spec is a test case |
| 21:10 | <jgraham> | (or bytecode) |
| 21:10 | <hsivonen> | zewt: it's not a basic test. It's a special tests that is unusually heavy on selector matching |
| 21:11 | <othermaciej> | jgraham: no, a smart JS parser implementation won't build an AST of the whole thing at once |
| 21:12 | <othermaciej> | since many functions are never called, the WebKit JS parser for instance will only syntax check function definitions when parsing the top level, and not actually build an AST or bytecode |
| 21:13 | <jgraham> | othermaciej: Yes, I guess that makes sense |
| 21:13 | <jgraham> | So is TabAtkins mistaken, or am I confused? |
| 21:13 | <TabAtkins> | Hmm, then my correction may be wrong. |
| 21:13 | <othermaciej> | I didn't pay attention to the discussion |
| 21:13 | <othermaciej> | so I don't know what the real question is |
| 21:13 | <zewt> | i think this underlies part of the confusion: |
| 21:13 | <zewt> | > So, it strongly suggests that the parsing/interpretation of the code was in |
| 21:14 | <othermaciej> | is the question about what the phases are in executing a script? |
| 21:14 | <jgraham> | othermaciej: More or less, yes |
| 21:14 | <othermaciej> | things happen in this order: |
| 21:14 | <zewt> | maybe not--well, backing up |
| 21:14 | <othermaciej> | (1) Top level is parsed (but you don't necessarily build AST for function definitions at top level) |
| 21:14 | <zewt> | people seem to be getting hung up on when parsing happens, but that doesn't seem relevant to that thread, since that's entirely up to the browser |
| 21:14 | <othermaciej> | (2) variable slots are created, without initialization |
| 21:14 | <othermaciej> | (3) function bindings are initialized with function objects |
| 21:15 | <othermaciej> | (4) code for top-level statements is executed in order |
| 21:16 | <othermaciej> | if this is about the "separating script downloads and execution" thread... |
| 21:16 | <TabAtkins> | Yes. |
| 21:16 | <othermaciej> | then why not just download scripts with XHR and stuff into a <script> element as inline? |
| 21:16 | <othermaciej> | I guess that doesn't work for cross-origin scripts |
| 21:17 | <zewt> | that forces the browser to delay parsing until execution (without evil hacks, at least), and seems to make things like caching compiled bytecode much harder |
| 21:18 | <zewt> | (speculatively compiling javascript received through XHR seems like an evil hack in my book, at least, and doesn't seem like something an optimized script loader would want to depend on) |
| 21:21 | <zewt> | i recall XHR has a bad tendency to never use browser cache in some browsers, too (hopefully that'll get fixed, if it hasn't already--don't recall which browsers) |
| 21:22 | jgraham | has to go now but shares bz's general concern that script authors will think they know what works best from limited testing and just wind up defeating browser optimisations |
| 21:22 | <jamesr_> | why doesn't <link rel=prefetch> solve this case? |
| 21:23 | <zewt> | i *think* both the noexecute and readyState proposals avoid the problems of breaking browser optimizations |
| 21:23 | <zewt> | (of course, I havn't thought up every possible optimization) |
| 21:23 | <zewt> | jamesr_: there's been some discussion on prefetch in that thread |
| 21:25 | <zewt> | off-hand, prefetch is a hint and often loads lazily; when you want to separate script fetching and execution you want it to be guaranteed and a normal-priority fetch, just like a regular script element |
| 21:25 | <othermaciej> | zewt: most of the cost of executing an inline script can't be saved by pre-parsing |
| 21:25 | <othermaciej> | zewt: that being said, it's totally possible to expose XHR to such optimizations |
| 21:26 | <jamesr_> | when you really need the code, you add the <script> |
| 21:26 | <othermaciej> | if the problem is that XHR doesn't give enough optimization, but otherwise does the right thing, then better to improve XHR than add a new feature |
| 21:26 | <zewt> | othermaciej: that's only true with the lazy-compilation model, right? eg. speculative, background compilation (instead of waiting for execution) could be done at some point |
| 21:27 | <othermaciej> | zewt: I don't really understand what you're saying |
| 21:28 | <othermaciej> | I will say this, I know about JavaScript implementation internals and browser cache internals, and I do not believe having a special new API to load a script and then execute it is likely to give any performance gain over XHR and then insert inline script |
| 21:28 | <zewt> | othermaciej: i mean: it's conceivable that future javascript engine optimizations could benefit from doing work in advance |
| 21:28 | <Hixie> | is compilation really that expensive? |
| 21:28 | <Hixie> | i haven't seen numbers on compilation cost |
| 21:29 | <othermaciej> | More generally, I am skeptical of introducing APIs for performance without metrics that show they can help |
| 21:29 | <Hixie> | (most of the benchmarks test execution not compilation) |
| 21:30 | <zewt> | (that's a question for the people pushing for the API; I don't need it myself) |
| 21:30 | <othermaciej> | if you want to introduce an API, and the goal is performance and not functionality, you need to have a really clear understanding of how it helps performance, and why these optimizations can't be done without new API |
| 21:31 | <zewt> | they tend to cite gmail's "scripts-in-comments" hack, but I suspect that's an optimization for crappy dated javascript engines on mobile phones and likely irrelevant on modern ones |
| 21:31 | <zewt> | (even on mobile hardware) |
| 21:34 | <matjas> | “Remove window.atob/btoa from the W3C draft — http://html5.org/tools/web-apps-tracker?from=5866&to=5867” → Sorry if I missed anything; why was this done? |
| 21:34 | <Hixie> | matjas: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12029 |
| 21:35 | <annevk> | there's a bug number |
| 21:35 | <zewt> | well also, there's the case of having major features sets that you don't need at first: whether the expensive part is parsing, compilation, execution or any step in-between, being able to defer that until the feature is used is a reasonable case, too |
| 21:35 | <annevk> | matjas, you didn't spot the bug column? |
| 21:35 | <Hixie> | matjas: (it's still in the whatwg draft) |
| 21:35 | annevk | wonders what should be done about that |
| 21:35 | <Hixie> | put it before the summary |
| 21:35 | <Hixie> | people assume the big column is the last one |
| 21:35 | <matjas> | annevk: D’oh, no for some reason I never noticed that column before |
| 21:35 | <matjas> | Hixie: Thanks |
| 21:36 | <TabAtkins> | Damn, I once again missed that there was a bug column. |
| 21:36 | <matjas> | annevk: maybe change the ‘B’ into something more descriptive? |
| 21:36 | <TabAtkins> | It has nothing to do with the palcement, but is entirely due to the naming. |
| 21:36 | <TabAtkins> | What matjas said. |
| 21:37 | <matjas> | “Bug #” might make a difference |
| 21:37 | <Dashiva> | Can we send bloodthirsty ferrets to the person who named atob/btoa? |
| 21:37 | <TabAtkins> | Yes. |
| 21:37 | <annevk> | hmm boring |
| 21:37 | <zewt> | drop them in a cage with atoi, atof and itoa |
| 21:38 | <Dashiva> | Those haven't infected the web |
| 21:38 | <zewt> | five incomprehensibly-named functions enter, one incomprehensibly-function leaves |
| 21:39 | <zewt> | might as well drop ntohl and htonl in while we're having a cage match |
| 21:39 | <TabAtkins> | What are those? |
| 21:39 | <zewt> | posix byte order conversion functions |
| 21:40 | <Dashiva> | network order to host order long or something |
| 21:40 | <matjas> | Sounds like these could all reside under the 1337 namespace. |
| 21:40 | <Dashiva> | It's not that I don't understand atob, I just think we could've made a better name for the web |
| 21:40 | <zewt> | network to host leet/host to network leet |
| 21:43 | <zewt> | (everyone feel free to stop talking right when I make a terrible joke, so it can just sit there festering) |
| 21:46 | <TabAtkins> | Sounds like a plan. |
| 21:49 | <alystair> | according to the standard, is it safe to remove quotation marks around properties if they are single words or contain no spaces? |
| 21:50 | <alystair> | eg. <meta charset="utf-8"> becomes <meta charset=utf-8> |
| 21:50 | <annevk> | pretty much |
| 21:50 | <alystair> | excellent :) |
| 21:50 | <annevk> | we're lazy too |
| 21:50 | <annevk> | ;) |
| 21:50 | alystair | is a bit-trimming-junky |
| 21:50 | <annevk> | hehe |
| 21:51 | <TabAtkins> | alystair: You can omit quotes if the value doesn't contain ", ', >, `, or spaces. |
| 21:51 | <alystair> | Thanks so much, I'm contributing a patch to html5-boilerplate... as minor as it is :) |
| 21:53 | <zewt> | i'll be sad if i start seeing <a href=http://url>;, heh |
| 21:53 | <paul_irish> | alystair: pretty cool.. though the build script does all that too. :) |
| 21:53 | <TabAtkins> | zewt: I do that. |
| 21:53 | <nimbupani> | :)) |
| 21:53 | <zewt> | : | |
| 21:54 | <paul_irish> | zewt: i see it a lot. annevk pointed out a while ago that people always do background-image: url(http://omgomg.com/pony.gif); |
| 21:54 | <alystair> | paul_irish: augh my ghost! |
| 21:54 | <paul_irish> | which is equivalent |
| 21:54 | <alystair> | paul is everywhere I want to be >:( |
| 21:54 | <TabAtkins> | paul_irish: That's something different than HTML attributes. |
| 21:54 | <alystair> | 2 steps ahead, always... always |
| 21:54 | <zewt> | in CSS it doesn't bother me intuitively, which is probably just a difference in habit |
| 21:54 | <paul_irish> | similar but different |
| 21:54 | <nimbupani> | yeah i doesnt quite seem that same |
| 21:55 | <nimbupani> | i know why |
| 21:55 | bfrohs | now believes he's the only person to always use quotes around attributes (and in CSS) |
| 21:55 | <TabAtkins> | Note: It *should* bother you in CSS, as it's difficult to parse efficiently. HTML attributes are the opposite. |
| 21:55 | <alystair> | paul_irish: I'm just thinking it should be modified in the base script that's downloadable as many people won't rebuild it.. |
| 21:55 | <nimbupani> | because a href can have spaces |
| 21:55 | <nimbupani> | while *usually* it is not the case for image file names |
| 21:55 | <Dashiva> | TabAtkins: Don't you just tokenize until ) ? |
| 21:55 | <TabAtkins> | Dashiva: The answer is, apparently, no. Handling invalid urls is made difficult somehow. |
| 21:55 | <zewt> | spaces are more often than not URL-encoded in either case, though |
| 21:55 | <TabAtkins> | I dunno the problems. |
| 21:55 | <nimbupani> | thats true zewt |
| 21:56 | <alystair> | unless it breaks your build scripts :/ |
| 21:56 | <zewt> | though browsers don't require it (not sure if that's according to spec or not) |
| 21:57 | <annevk> | the problem is silly grammar-based parsers |
| 21:57 | <annevk> | rather than a flexible parser |
| 21:57 | <annevk> | so you need hacks for URLs because they do not follow the grammar |
| 21:58 | <zewt> | i'd expect a strict grammar-based parser trying to parse real-world HTML would find itself unhappy in uncountable ways, heh |
| 21:58 | <alystair> | I normally keep quotes around src and href because it's sensible |
| 21:58 | <annevk> | if CSS' parser were defined and implemented like the one in HTML, this would be way more easy (and CSS would be a lot less ambiguous) |
| 21:58 | <alystair> | I think it would be neat if html or css could apply a click-through |
| 21:59 | <alystair> | so you could still layer imagery above actionable content, yet not interfere with operations |
| 21:59 | <nimbupani> | you can alystair |
| 21:59 | <zewt> | not sure what you mean--pointer-events: none? |
| 21:59 | <nimbupani> | what zewt sez |
| 21:59 | <alystair> | ... ther's such a thing already? |
| 21:59 | <TabAtkins> | annevk: That's not the problem. The problem is that error-handling in unquoted urls requires more lookahead than anything else in CSS. |
| 21:59 | <alystair> | holy crap, I'm such a nub. |
| 22:00 | <alystair> | the more you know, the more you know you don't know blah blah |
| 22:00 | <paul_irish> | you nub. |
| 22:02 | <annevk> | TabAtkins, only because you have a grammar-based parser |
| 22:02 | <annevk> | TabAtkins, otherwise you could just look for ) |
| 22:03 | <zewt> | is there someone i can hit at google to stop making w3schools.com results come before w3.org, so i can stop site:*.w3.org'ing all the time, heh |
| 22:03 | <TabAtkins> | annevk: Unless there was a preceding /*? |
| 22:04 | <TabAtkins> | zewt: We don't manually tweak results. Ever. |
| 22:04 | <TabAtkins> | zewt: Get people to stop linking w3schools. |
| 22:04 | <zewt> | well, more seriously what I've wanted countless times is a way to blacklist sites from my results, heh |
| 22:04 | <zewt> | w3schools, experts-exchange, etc |
| 22:04 | <annevk> | TabAtkins, sort of doubt comments work inside URL tokens |
| 22:04 | <TabAtkins> | zewt: There are extensions for that, depending on your browser. |
| 22:04 | <annevk> | spaces and such do |
| 22:05 | <nimbupani> | all documented in w3fools.com zewt |
| 22:05 | <TabAtkins> | annevk: I thought they did. Anyway, I only barely understand the problems with parsing url(). Ask Moz's Zach. |
| 22:05 | <TabAtkins> | zewt: Also, experts exchange is actually useful when you apply a user stylesheet that removes 90% of the page. Did you know that the *actual* thread is down at the very bottom of the page, so Google can read it? |
| 22:05 | <annevk> | they don't |
| 22:06 | <annevk> | anyway, I was trying to explain the problem ;) |
| 22:06 | <zewt> | TabAtkins: i do, but i don't tend to use sites that deliberately hide their content that much; doesn't inspire any confidence in it |
| 22:06 | <TabAtkins> | Well, they're certainly not "experts" there, but it's equivalent or better to most forum posts on technical issues. |
| 22:06 | <TabAtkins> | stackoverflow is usually better. |
| 22:07 | <zewt> | heh, that's quite an endorsement :P |
| 22:09 | <TabAtkins> | How did I never know about the QSA flag in rewrite rules? I've been hacking around the lack of this for *so long*. |
| 22:09 | <gsnedders> | TabAtkins: Because you never fully RTFM? |
| 22:09 | <TabAtkins> | TFM is horribly written and gigantic. |
| 22:09 | <zewt> | features that require fully RTFMing to use well are questionably-designed features |
| 22:09 | <zewt> | ... in general, at least |
| 22:09 | <TabAtkins> | Yay, it works! |
| 22:10 | <TabAtkins> | http://www.xanthir.com/blog/b4AD0?pretty |
| 22:10 | <nimbupani> | alystair: |
| 22:10 | <nimbupani> | if people add multiple classes |
| 22:10 | <nimbupani> | it will break without quotes |
| 22:11 | <nimbupani> | are you not using benschwarz work TabAtkins? |
| 22:11 | <nimbupani> | alystair: so we wanted to be consistent and use quotes always |
| 22:12 | <alystair> | hmmm alright |
| 22:12 | <TabAtkins> | nimbupani: Naw, just my own older styling for my document editor, before I turned it into a blog. |
| 22:12 | <alystair> | it is somewhat trivial =) |
| 22:12 | <nimbupani> | TabAtkins: i meannn you could :)) |
| 22:13 | <TabAtkins> | Heh, I don't like all the choices benschwarz made. |
| 22:13 | <nimbupani> | kkk :) |
| 22:15 | <nimbupani> | can I suggest turning off the bg color/small-caps/underline on the headings >_> |
| 22:15 | <TabAtkins> | Just don't look at the pretty version. |
| 22:16 | <nimbupani> | :))) |
| 22:16 | <zewt> | http://www.xanthir.com/blog/b4AD0?unreadable was worth a try |
| 22:17 | <TabAtkins> | ...I should do that. |
| 22:17 | <zewt> | background-color: #888; color: #999; |
| 22:18 | <alystair> | TabAtkins: want to see a fun bug in chrome renderer? :) |
| 22:18 | <alystair> | er wait, it's webkit, nvm. |
| 22:19 | <alystair> | I keep forgetting that |
| 22:24 | <TabAtkins> | Wut: http://twitter.com/mnot/status/35813633313218560 |
| 22:24 | <nimbupani> | hahahaha |
| 22:24 | <nimbupani> | anti-trust! |
| 22:27 | <zewt> | accused of standard documents price-fixing |
| 22:27 | <alystair> | wow I just broke every rendering engine with this bug :S |
| 22:27 | <alystair> | even opera |
| 22:27 | <zewt> | lynx |
| 22:28 | <TabAtkins> | lynx doesn't have a rendering engine. It has a CURSES engine. |
| 22:28 | <alystair> | it's an image positioning bug, so lynx is not affected :S |
| 22:28 | <zewt> | (in that case I think you'd have to put "rendering engine" in quotes) |
| 22:28 | <nimbupani> | wat is it alystair? |
| 22:28 | <alystair> | sec lemme edit the informational text |
| 22:30 | <alystair> | http://lorinhalpert.com/ipoc/bugs/html-positioning/ |
| 22:31 | <zewt> | https://bugzilla.mozilla.org/show_bug.cgi?id=620156 heh i think this is my single favorite Firefox bug |
| 22:31 | <alystair> | I already reported this issue to every major engine group but response has been tepid, expcet for Firefox where they fixed it incorrectly (I broke it again by adding width:auto so they images are scaled properly) |
| 22:32 | <alystair> | without width:auto opera manages to render it correctly until you try resizing the window... |
| 22:33 | <zewt> | actually there's a better bug--iirc i managed to create a javascript timer that kept activating after the tab was closed; was able to make it open an alert() every ten seconds until the browser was restarted |
| 22:33 | <zewt> | (didn't report it since it's fixed in 4; it's useless but amusing) |
| 22:33 | <alystair> | haha now get it working in chrome and win 20k :P |
| 22:33 | <alystair> | although with sandboxing, doubt it would work |
| 22:34 | <zewt> | it's especially obnoxious since it's essentially impossible to tell who's doing it |
| 22:34 | <TabAtkins> | alystair: Your test case seems incorrect. If I remove the @width and @height from both <img>s, I get the same result. |
| 22:35 | <alystair> | what do you mean by same result? |
| 22:36 | <TabAtkins> | Where they don't overlap properly. |
| 22:36 | <alystair> | removal of height prevents the browser from resizing the image tho'. |
| 22:38 | <alystair> | the end result here is if someone decides to have an image within a block that is automatically resized to the height of the viewport, it pushes the resized image away from the correct position because it's still using the width of the natural image, not the resized dimension |
| 22:39 | <alystair> | the simple solution would be using the resized image width instead of natural width for block size calculations :p |
| 22:42 | <zewt> | it goes away if i change .bug { height: 100%; } to eg. .bug { height: 500px; } |
| 22:43 | <alystair> | yes but that's cheating :) |
| 22:43 | <zewt> | it also goes away if i set img { height } similarly |
| 22:43 | <alystair> | I could have js that automagically goes in and sets height to correct px depending on viewport resize (which I do) |
| 22:43 | <alystair> | but realistically when you want something to fill the viewport in all use cases, 100% height should work... |
| 22:43 | <zewt> | size determination in css always gives me a headache, heh |
| 22:44 | <alystair> | or % |
| 22:44 | <Hixie> | is arun still editing the file api spec? |
| 22:44 | <Hixie> | also, is there a convention for getting Blob or File objects asynchronously? |
| 22:46 | <TabAtkins> | alystair: Okay, I've fiddled with your testcase more. I still don't see the problem. body>img is left-aligned, while .bug>img is right-aligned. Neither is sized to completely fill the viewport in both dimensions, so of course they won't perfectly overlap unless you got really lucky. |
| 22:46 | <Hixie> | aha, getEntry() in DirectoryEntry in http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#idl-def-DirectoryEntry |
| 22:46 | <zewt> | depends on which api you're getting them from, right? |
| 22:46 | <annevk> | Hixie, they are async themselves... |
| 22:47 | <Hixie> | Blob.size isn't async |
| 22:47 | <Hixie> | actuall yBlob.size isn't anything, it has no "must"s |
| 22:47 | <TabAtkins> | Blob.size is the only sync part of it, as far as I know. |
| 22:47 | <Hixie> | for my purposes i need to not return the Blob until i know the size |
| 22:48 | <Hixie> | (getting a blob from a canvas) |
| 22:48 | <zewt> | TabAtkins: simplified in http://zewt.org/~glenn/Natural%20Width%20Error.htm; resize the window and it's not immediately obvious why the image is left-justified in the div, instead of the div and img coming to the same size and being right-aligned to the window |
| 22:48 | <alystair> | TabAtkins: you're still left with unexplained padding in the the surrounding div |
| 22:48 | <zewt> | (not entirely convinced it's a bug, guessing it's one of those weird unintuitive css oddities) |
| 22:49 | <annevk> | Hixie, could be a bug that size is sync |
| 22:49 | <annevk> | anyway, gotta go |
| 22:55 | <TabAtkins> | alystair: Ah, I finally see the "bug" you're running into. My previous criticisms were incorrect. |
| 22:56 | <TabAtkins> | Wait, hm, let me make sure I'm reading the spec right... |
| 22:56 | <TabAtkins> | It looks like the difference in width/positioning between abspos normal elements and abspos replaced elements. |
| 22:58 | <alystair> | TabAtkins: you might hate me for this but I know nothing of specs yet, I'm just a lowly it/ux/designer consultant looking for employment at the moment... that's why my terminology is probably all wrong and confusing :) |
| 23:11 | <karlcow> | http://ai-depot.com/articles/the-easy-way-to-extract-useful-text-from-arbitrary-html/ |
| 23:17 | <TabAtkins> | alystair: Okay, found the problem. Yes, it's a bug. When we're calculating the size of an abspos element (or fixpos, same thing) where 'width' and one of the edges is 'auto', you're supposed to set the 'width' to the shrink-to-fit width, then solve for the other side. |
| 23:18 | <TabAtkins> | What this *should* do is set <div.bug>'s 'left' property to a negative value. However, in ltr we don't let the 'left' calculate to less than 0. |
| 23:18 | <TabAtkins> | Similarly, if you swap the "right:0" to "left:0", and then set dir=rtl on <html>, the same error pops up. |
| 23:19 | <TabAtkins> | If "left" is specified in ltr, or "right" is specified in rtl, it works correctly. |
| 23:22 | <alystair> | TabAtkins: wow you're a beast |
| 23:24 | <gsnedders> | Not a beauty? Blast. |
| 23:24 | <TabAtkins> | This might be a reasoanble behavior, though - it prevents you from having data (in this case, part of the image) in an area you can't scroll to, since you can't scroll to any position less than 0 in ltr, and similarly in rtl. |
| 23:24 | <TabAtkins> | gsnedders: I DISAGREE. |
| 23:24 | TabAtkins | preens. |
| 23:24 | <zewt> | nobody says they're mutually exclusive; perhaps he's a beautiful beast |
| 23:25 | <TabAtkins> | Lemme see if I can reproduce it with just text. |
| 23:25 | <alystair> | I think it's simply lazy programming, where all image engines return original image width instead of resized width... |
| 23:26 | <zewt> | i think css layout is more complicated than that :) |
| 23:26 | alystair | knows nothing of the behind-the-scenes magic |
| 23:31 | <TabAtkins> | The hell? I just broke X by doing alert(x.toDataURL()). |
| 23:31 | <TabAtkins> | Or rather, I broke Compiz I think. |
| 23:32 | <TabAtkins> | (x was a 500x500 canvas painted pure blue) |
| 23:32 | <zewt> | heh i've exploded things frequently doing that sort of thing |
| 23:32 | <TabAtkins> | I just wanted a large square image to test things with. ;_; |
| 23:33 | <zewt> | which is why I generally don't like toDataURL at all--object URLs are much saner... |
| 23:33 | <TabAtkins> | And it was faster to generate a data url via canvas typed in as a data url than it was to open GIMP. |
| 23:33 | TabAtkins | probably does too much in data: urls these days. |
| 23:33 | <alystair> | Canvas has such great flexibility, but at the same time it could be used for pure evil :/ |
| 23:34 | <TabAtkins> | This has nothing to do with canvas. I think alerting a large unbreakable string is what caused the problem. |
| 23:34 | <Hixie> | surely 500x500 pure blue should compress really well |
| 23:34 | <alystair> | Hixie: maybe you should try #f0f instead? maybe it likes magenta better :p |
| 23:35 | <zewt> | that's another thing about data urls--often you want uncompressed data (if you're taking data from a canvas and dropping it in an img, you don't want PNG mixed in) ... which seems to suggest using BMP, which itself is unpleasant |
| 23:36 | <zewt> | i guess technically you can make uncompressed PNGs |
| 23:38 | <TabAtkins> | Hixie: The resultant data url is nearly 3k. |
| 23:38 | <TabAtkins> | Which seems pretty heavyweight for a pure blue png. |
| 23:38 | <Hixie> | that doesn't seem optimal, yeah |
| 23:39 | <zewt> | that sounds pretty normal |
| 23:39 | <TabAtkins> | Actually, it's pure black. I guess I did something wrong. Anyway, it's 500x500 and a solid color. |
| 23:39 | <zewt> | png isn't good at getting *really* small like, say, gifs |
| 23:40 | <TabAtkins> | Hm. Running it through an optimizer only gets me down to 2k. |
| 23:42 | <TabAtkins> | Ah, here we go. Running it through a better optimizer dropped the entire file to 125 bytes. |
| 23:42 | <TabAtkins> | That's more like it. |
| 23:42 | <zewt> | extra metadata chunks? |
| 23:42 | <TabAtkins> | I doubt canvas adds too much metadata. |
| 23:42 | <zewt> | i wouldn't expect it to, but i'm not sure why else it would be that different |
| 23:44 | <TabAtkins> | We don't seem to have a bug for this. I'll add one. |
| 23:45 | <zewt> | for the alert problem? |
| 23:45 | <TabAtkins> | No, for the horrible dataurl generation. |
| 23:45 | <TabAtkins> | I need to test the alert problem more. |
| 23:46 | <Philip`> | I assume browsers are unlikely to automatically palettise PNGs, which is what you need to get it to 125 bytes |
| 23:47 | <roc> | I write canvas code to generate PNGs too |
| 23:47 | <zewt> | heh all of the png spec liniks on libpng.org are broken |
| 23:47 | <Yuhong> | IE9 RC was released today, which finally supports XHTML. |
| 23:48 | <Philip`> | Strangely the PLTE chunk supports 1-entry palettes but the image can't be 0-bit, only 1-bit :-( |
| 23:48 | <Yuhong> | The sad thing about it is that it will be likely about 5 years after IE9 releases for IE8 to die. |
| 23:48 | <Yuhong> | And today it is already 11 years after the release of XHTML 1.0! |
| 23:48 | <zewt> | seems like pngcrush won't automatically trim PLTE chunks |
| 23:49 | <Rik`> | Yuhong: RC doesn't mean general availability for everyone |
| 23:49 | <Rik`> | we still need to wait for a true release |
| 23:49 | <Yuhong> | Yes. |
| 23:50 | <AryehGregor> | So the latest IE blog post yet again quotes pass figures on MS's own tests without counting anyone else's and without making this fact clear. |
| 23:50 | <TabAtkins> | Interestingly, there's a significant size difference between a 500x500 transparent image and a 500x500 black image. |
| 23:51 | <TabAtkins> | The former is about half the size. |
| 23:52 | <AryehGregor> | Yuhong, I think IE8 will die a lot faster than IE6 did. |
| 23:52 | <AryehGregor> | Because of IE9's compatibility mode. |
| 23:52 | <TabAtkins> | I assume that every pixel being 0,0,0,0 instead of 0,0,0,255 allows better compression. |
| 23:52 | <AryehGregor> | IE7 died more quickly than IE6, right? |
| 23:53 | <Yuhong> | But then there is the issue of the lack of XP support. |
| 23:53 | <zewt> | TabAtkins: that's what I was thinking, but I'd expect the difference to be tiny |
| 23:53 | <AryehGregor> | XP is no longer supported by Microsoft as of when? |
| 23:53 | <zewt> | ie9 doesn't run in XP, which is aggrevating; I have to run win7 in a VM to test with it |
| 23:53 | <TabAtkins> | Let's test by filling it with a color that's different in every component. |
| 23:53 | <Yuhong> | And BTW, XP and IE6 end support together in the MS support lifecycle. |
| 23:53 | <zewt> | of course since you can't really run multiple versions of IE on one system I need VMs for each version anyway |
| 23:53 | <AryehGregor> | Ah, IE9 finally supports WebM if the codec is present. |
| 23:53 | <AryehGregor> | With the RC. |
| 23:53 | <AryehGregor> | Or so the blog post says. |
| 23:54 | <Yuhong> | And yes, I mentioned XHTML because of yesterday's discussion. |
| 23:54 | <zewt> | TabAtkins: fyi, from PS, 500x500 transparent is 4340 bytes, black is 3840 |
| 23:54 | <TabAtkins> | That's just crazy talk. |
| 23:55 | <zewt> | er wait, I saved as paletted |
| 23:56 | <AryehGregor> | So, two-factor authentication for Google Accounts. |
| 23:56 | <AryehGregor> | Sounds scary. |
| 23:56 | <AryehGregor> | What if you lose your cell phone? |
| 23:56 | <TabAtkins> | And, nope, filling it with #05a (0055aaff, in full) is identical. |
| 23:56 | <TabAtkins> | AryehGregor: They give you a set of backup codes. |
| 23:56 | <TabAtkins> | AryehGregor: It's your responsibility to keep track of them. |
| 23:56 | <zewt> | heh, saving as non-paletted, transparent is 4409 bytes, black is 4408 |
| 23:56 | <AryehGregor> | Oh, so you get some codes that permanently work, so you can write them down in a bunch of secret places and if you lose your phone you can disable two-factor authentication? |
| 23:57 | <TabAtkins> | Yeah. |
| 23:57 | <AryehGregor> | Awesome. |
| 23:57 | AryehGregor | signs up |
| 23:57 | <TabAtkins> | And I'm sure there's some recovery option. |
| 23:57 | <TabAtkins> | There are a few things that don't work well with 2-factor yet, but I'm pretty happy with it all-told. |
| 23:57 | <TabAtkins> | (Mainly, profile sync on ChromeOS after you've already set up your account.) |
| 23:58 | <TabAtkins> | Bookmark the application-specific password page. You'll need it. |
| 23:58 | <TabAtkins> | And it's hard to find otherwise. |
| 23:58 | <AryehGregor> | "Application-specific password page"? |
| 23:59 | <TabAtkins> | There should be links somewhere in the information about setting it up. |
| 23:59 | AryehGregor | doesn't see the option yet, will have to wait |
| 23:59 | <TabAtkins> | Most external programs don't understand 2-factor, so you instead make an application-specific password for them which is very long. |
