| 00:00 | <roc> | I'll have to add extra code to detect the outside-box case to match the spec as written |
| 00:00 | <TabAtkins> | Yeah, I had to do so as well (my code didn't gracefully handle it, so it was required anyway). |
| 00:01 | <roc> | so I suggest changing the spec to make that the behaiour |
| 00:01 | <anoopb> | any recommendations for tutorials/demos of the canvas element and images? |
| 00:01 | <TabAtkins> | Hm, k. I'll see if I can do so gracefully. |
| 00:01 | <anoopb> | more specifically, i'm looking for effects. |
| 00:02 | <roc> | I think it probably would be useful, e.g. it means you could animate the movement of an ellipse into the box by animating the start position |
| 00:02 | <roc> | oh wait, that wouldn't work |
| 00:02 | <roc> | so I dunno :-) |
| 00:02 | <TabAtkins> | Nah, it'll collapse to a line as it crosses the box-edge. ^_^ |
| 00:04 | <TabAtkins> | I mean, you could still use it when it was outside of the box. You'd have to use color-stop positions greater than 100%, but still. |
| 00:04 | <TabAtkins> | I just figured using farthest-side/farthest-corner was equally useful. |
| 00:11 | <TabAtkins> | roc: Doing the animated ellipse thing would be doable relatively easily with an explicitly sized SVG gradient, and animating the background-position. |
| 00:12 | <roc> | yeah |
| 00:12 | <deltab> | anoopb: https://developer.mozilla.org/en/Canvas_tutorial |
| 00:12 | <deltab> | anoopb: effects? |
| 00:13 | <TabAtkins> | roc: I'm heading out to do some yardwork, but I'll stay in the channel and be back later. If you have any more questions, just ask. |
| 00:13 | <roc> | sure, thanks a ton |
| 00:14 | <anoopb> | deltab: i didn't mean effects. I wanted to be able to do some neat things like expand the image in focus while shrinking others to maintain the bounds of the canvas |
| 00:15 | <deltab> | transformations? https://developer.mozilla.org/en/Canvas_tutorial/Transformations |
| 00:20 | <anoopb> | deltab: that's it. thank you. |
| 00:50 | <TabAtkins> | roc: Here's an interesting question. I say that the "box" referred to throughout the rules is simply a rectangle the same size as an SVG image without intrinsic dimensions (in background situations, that's the size of the background bounding-box). However, once that's calculated, it doesn't change. If you used background-position to *move* the gradient image, it shouldn't adjust to the... |
| 00:50 | <TabAtkins> | ...new box edges, right? |
| 00:50 | <roc> | no |
| 00:50 | <roc> | it shouldn't |
| 00:51 | <roc> | I should write a test for that but I'm pretty we'll do that right |
| 00:51 | <TabAtkins> | Frex, radial-gradient(ellipse farthest-side, red, blue) should create a gradient that turns blue *right* at the box edges. But if I then do background-position: 100px top (in a 200px wide box) it'll instead look like a half-ellipse, correct? |
| 00:52 | <TabAtkins> | One that starts on the right side and turns blue halfway through the box. |
| 00:56 | <roc> | yes |
| 01:22 | <othermaciej> | hey all |
| 01:24 | <othermaciej> | is anyone around who is familiar with the html5 spec production toolchain, and perhaps willing to volunteer to enhance it? |
| 01:30 | <TabAtkins> | That'd be philip and/or gsnedders, right? |
| 01:35 | <othermaciej> | I don't actually know anything about the mechanics |
| 01:35 | <othermaciej> | I know jgraham has done something with it as well (adding the issue markers) |
| 01:36 | <othermaciej> | specifically I wanted to get someone to make the change to add spec diff links to bugzilla bugs based on commit messages |
| 02:45 | <roc> | TabAtkins: for radial gradients, does <shape> default to 'circle' and <size> default to 'closest-side'? |
| 02:45 | <roc> | oh wait |
| 02:46 | <roc> | <size> defaults to cover, with mean farthest-corner, ok. I still don't see the default for <shape> |
| 05:38 | <TabAtkins> | roc: Dangit, how did I forget that one too? It defaults to ellipse. |
| 05:38 | <roc> | ok, thanks |
| 05:56 | <TabAtkins> | roc, I'm making edits to the draft on my personal site now. I think you were ok with linear-gradient being 'invalid' if it points in the wrong direction, right? But you wanted the final 'invalid' radial-gradient case to be valid? |
| 05:57 | <roc> | TabAtkins: actually in my implementation it was simplest to not make linear-gradient invalid |
| 05:57 | <roc> | we pick the destination corner based entirely on the angle |
| 05:58 | <TabAtkins> | Hmm. What happens with -10px -10px 180deg, then? |
| 05:58 | <roc> | the destination corner is the top-right corner |
| 05:59 | <TabAtkins> | Really? How do you figure? 180deg points to the left. |
| 05:59 | <roc> | oh sorry, it's the opposite corner, right |
| 06:00 | <roc> | bottom left |
| 06:00 | <roc> | then we find the point that is the intersection of the gradient line with the line that passes through the bottom-left corner and is perpendicular to the gradient line |
| 06:00 | <roc> | that's the gradient line end point |
| 06:01 | <roc> | you can always follow the instructions in your draft, and it will give you a unique point |
| 06:01 | <TabAtkins> | Ah, k. So you're okay with the direction getting flipped in degenerate cases like that. |
| 06:01 | <roc> | yeah |
| 06:01 | <TabAtkins> | k. |
| 06:01 | <roc> | it would be extra code to detect that case and do something special |
| 06:03 | <TabAtkins> | No problem. I don't have a particular preference on that; I just chose what felt like a reasonable behavior. |
| 06:05 | <roc> | I've got radial gradients all working now, but writing the automated tests for gradients sucks :-( |
| 06:07 | <TabAtkins> | Yeah, I'm sure. |
| 06:07 | <TabAtkins> | Thanks for implementing it all, though! Woo! |
| 06:15 | <TabAtkins> | roc: I'm willing to spec repeating-linear-gradient and repeating-radial-gradient. The only difference is that the color-stops repeat infinitely in both directions, +/- multiples of the distance between the first and last stop, right? |
| 06:16 | <roc> | right |
| 06:16 | <roc> | you need to define the rendering when stops all coincide |
| 06:17 | <TabAtkins> | Hmm? You mean when you have linear-gradient(red 50px, blue 50px)? |
| 06:17 | <roc> | yeah |
| 06:17 | <roc> | actually |
| 06:18 | <roc> | yeah |
| 06:18 | <roc> | :-) |
| 06:18 | <TabAtkins> | That should be already defined. Before the first color-stop it's red, and after the last it's blue. |
| 06:18 | <roc> | I mean repeating-linear-gradient(red 50px, blue 50px) |
| 06:18 | <TabAtkins> | Oh! Um. |
| 06:19 | <TabAtkins> | I'll just say it's purple. ^_^ |
| 06:19 | <TabAtkins> | Do you have anything in mind to do yet? There's no 'right' behavior here - anything I spec will be essentially arbitrary. |
| 06:21 | <TabAtkins> | Actually, I'll probably just be consistent with the other failure modes and say it's blue. |
| 06:24 | <TabAtkins> | k, all the changes are made except for the 'invalid' linear-gradient case. I'm still trying to figure out an elegant way to say that. |
| 06:25 | <roc> | yeah, I'd say "blue" |
| 06:31 | TabAtkins | will try very hard not to actually say "blue" when he writes it up. |
| 07:17 | <zcorpan> | good morning |
| 07:17 | <annevk42> | morning |
| 07:17 | annevk42 | is still somewhat asleep |
| 07:27 | <zcorpan> | Philip`: any progress yet? :) |
| 07:33 | <zcorpan> | Hixie: should nextid and rb get the isindex treatment wrt HTMLUnknownElement? |
| 07:34 | <Hixie> | hm? |
| 07:34 | <zcorpan> | i'm pretty sure <nextid> is an HTMLUnknownElement in browsers |
| 07:34 | <Hixie> | ah |
| 07:34 | <Hixie> | file a bug |
| 07:34 | <Hixie> | :-) |
| 07:35 | Hixie | is trying to figure out why prince doesn't seem to support <style> in SVG |
| 07:35 | <zcorpan> | i'll check all obsolete elements to see if there are more |
| 07:35 | <Hixie> | cool, thanks |
| 07:41 | annevk42 | wonders what <a methods> did |
| 07:42 | <annevk42> | hmm, weird |
| 07:45 | <othermaciej> | <a methods>? |
| 07:47 | <zcorpan> | html2? |
| 07:49 | <annevk42> | http://www.utoronto.ca/web/HTMLdocs/NewHTML/a_methods.html |
| 07:51 | <annevk42> | looks like it might be for non-browser UAs though the search icon remark suggests otherwise |
| 07:51 | annevk42 | doesn't really get the design |
| 07:52 | <othermaciej> | maybe the idea was that the browser would let you choose what method to use to dereference the link? |
| 07:53 | <Hixie> | <a methods> is just like <a urn> and <head profile> |
| 07:53 | <Hixie> | nonsensical solution to a non-problem |
| 07:54 | <othermaciej> | I have no idea what <a urn> is either |
| 07:54 | <othermaciej> | man, every time I think I have heard of everything that was ever in HTML, something new surprises me |
| 07:56 | <othermaciej> | I love what the HTML 2.0 spec says: "The syntax and semantics of the URN attribute are not yet specified." |
| 07:56 | <othermaciej> | rare moment of honesty! |
| 07:59 | <zcorpan> | anyone have ie8 around? |
| 07:59 | <Hixie> | .sure |
| 07:59 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/283 |
| 07:59 | <Hixie> | othermaciej: are recent bugs what you had in mind? |
| 08:00 | <othermaciej> | Hixie: yes, thank you very much sir |
| 08:01 | <Hixie> | cool |
| 08:01 | <zcorpan> | do we have to mark bugs as closed? |
| 08:01 | <Hixie> | zcorpan: i got an error |
| 08:01 | <Hixie> | looks like IE broke the link |
| 08:01 | <Hixie> | can you upload it? |
| 08:02 | <othermaciej> | zcorpan: if you don't it will get marked as "no reply from commenter" eventually, so depends on whether you care about that |
| 08:02 | <zcorpan> | Hixie: done |
| 08:02 | Philip` | still thinks Hixie should add the header that disables IE XSS protection on the Live DOM Viewer |
| 08:02 | <zcorpan> | othermaciej: ok |
| 08:03 | <Hixie> | zcorpan: got another error |
| 08:03 | <Hixie> | Philip`: i refuse to add a non-standard header whose purpose it is to tell the browser to follow the spec |
| 08:03 | <zcorpan> | Hixie: error about <applet>? or other? |
| 08:03 | <zcorpan> | Hixie: (you can change the prefs in ie to disable the xss protection) |
| 08:04 | <Hixie> | zcorpan: Object doesn't support this property or method on line 30 |
| 08:04 | <othermaciej> | zcorpan: once we're actually in Last Call, it's probably good to do so, because our Disposition of Comments will look suspicious if all of them indicate no reply and there aren't any "agree" responses |
| 08:05 | <zcorpan> | maybe i can batch-close my bugs at some point |
| 08:10 | <zcorpan> | anyone got an opinion on whether <spacer> should be HTMLElement or HTMLUnknownElement? |
| 08:10 | <ttepasse> | Hey, HTML 3.0 ditches <a urn> but has instead <html urn="..."> |
| 08:11 | <zcorpan> | why is spacer a void element in the html5 parser? |
| 08:12 | <zcorpan> | it's void and HTMLSpacerElement in gecko but a normal unknown element in webkit, opera and ie, afaict |
| 08:12 | <annevk42> | yeah |
| 08:13 | <othermaciej> | I had no idea <spacer> existed |
| 08:13 | <annevk42> | could remove that quirk |
| 08:13 | <othermaciej> | we don't do anything special for it afaik |
| 08:13 | <annevk42> | Safari on Mac doesn't afaict |
| 08:13 | <annevk42> | nor Chrome |
| 08:17 | <zcorpan> | ok filed bugs |
| 08:17 | <Hixie> | thanks |
| 08:19 | <zcorpan> | ie7 has the form margin in standards mode too (like opera) |
| 08:19 | <ttepasse> | zcorpan, in Netscape 3 <spacer> was a void element. Says this tutorial from 1998. |
| 08:35 | <zcorpan> | "Inserting a form on a page would often break the pixel-perfect design by pushing things around. That was caused by the form’s margins, but I didn’t know that. So to prevent this I used to insert the form’s start and end tags between table rows." - http://www.456bereastreet.com/archive/200511/reveal_your_old_school_web_development_hacks/ |
| 08:41 | othermaciej | facepalms |
| 08:43 | <zcorpan> | i think we should just change the parser to not foster parent forms |
| 08:45 | <Dashiva> | Having per-row forms would be useful for many things |
| 08:46 | <zcorpan> | Dashiva: form="" handles that |
| 08:47 | <Dashiva> | Yeah, but that leads to really silly markup |
| 08:47 | <Dashiva> | A hundred empty form tags outside the table |
| 08:47 | <zcorpan> | they don't have to be outside the table |
| 08:47 | <zcorpan> | can be in the first cell |
| 08:47 | <Dashiva> | True |
| 08:47 | <zcorpan> | of the relevant row |
| 08:47 | <Dashiva> | Didn't think of that |
| 08:48 | <zcorpan> | i agree though that it'd be nice to support forms in tables as if they were <tbody>, but Hixie didn't want to experiment with it and it'd probably break things anyway |
| 08:56 | <zcorpan> | Hixie: should we have <link rel=author> too, mapping to atom <author><uri>? |
| 08:56 | <Hixie> | no way to map it to a name |
| 08:57 | <zcorpan> | you get the name from <meta name=author> |
| 08:58 | <Hixie> | but how do you know which rel=author maps to which name=author? |
| 08:59 | <zcorpan> | ah... i thought you'd only have one |
| 09:11 | <annevk> | you could map it based on the title attribute |
| 09:11 | <annevk> | if you specify that for rel=author the title attribute gives the name |
| 09:11 | <annevk> | and that for name=author content gives the name |
| 09:12 | <annevk> | not sure you'd need <meta name=author> in that case though |
| 09:13 | <Hixie> | so <link rel=author href="http://ln.hixie.ch/"; title="Hixie's Natural Log"> would be invalid? |
| 09:14 | <annevk> | yes |
| 09:14 | <annevk> | prolly not ideal |
| 09:14 | <Hixie> | annevk: what's the latest ED of MQ? http://www.w3.org/TR/css3-mediaqueries/ is more recent than http://dev.w3.org/csswg/css3-mediaqueries/ |
| 09:15 | <annevk> | it's more recent because I made all the edits way in advance and Bert did the WD version in private |
| 09:15 | <annevk> | with "way in advance" I mean that publication was "way delayed" |
| 09:16 | <Hixie> | so what should i reference? the TR which will become out of date, or the ED which is out of date? |
| 09:16 | <annevk> | how is the ED out of date? |
| 09:17 | <hsivonen> | I guess MS has problems getting people to install Silverlight. Now Flip4Mac is used as a Silverlight delivery device. |
| 09:24 | <Hixie> | annevk: it's august |
| 09:24 | <Hixie> | annevk: TR is sept |
| 09:25 | <Hixie> | oh i see |
| 09:25 | <Hixie> | you mean it's the same version |
| 09:25 | <Hixie> | just different date |
| 09:25 | <annevk> | yes |
| 09:25 | <Hixie> | ok |
| 09:26 | <Hixie> | thanks |
| 09:27 | <Hixie> | othermaciej: when i mark a bug as NEEDSINFO because I simply don't understand the request, should I be giving the Rejected boilerplate, or can i just mark it NEEDSINFO without the boilerplate? |
| 09:28 | <othermaciej> | Hixie: I think it would be good to have the boilerplate, but maybe there should be a version specifically for NEEDSINFO bugs that highlights the need to provide the requested info |
| 09:29 | <othermaciej> | Hixie: specifically, I wouldn't want someone to complain that they didn't know they had to take action on their NEEDSINFO bug to have it actually addressed |
| 09:30 | <Hixie> | k. i'll use rejected until further notice then. |
| 09:31 | <zcorpan> | will we see the boilerplate over and over in the same bug when it's reopened and NEEDSINFOed back and forth? |
| 09:31 | <zcorpan> | or just the first time it's NEEDSINFOed |
| 09:33 | <Dashiva> | Maybe just a link to the process |
| 09:33 | <Hixie> | othermaciej: is http://www.w3.org/Bugs/Public/show_bug.cgi?id=7923#c1 ok? |
| 09:33 | <othermaciej> | Hixie: works4me |
| 09:33 | <Hixie> | k |
| 09:34 | <othermaciej> | zcorpan: yeah, I don't think it's necessary to repeat the whole thing over and over - though hopefully it's rare for that to happen at all |
| 09:34 | <annevk> | the contributor⊙wo bugs prolly deserve special status anyway |
| 09:34 | <zcorpan> | othermaciej: it has happened a couple of times |
| 09:35 | <jgraham> | I guess in most cases the original commenter never sees the replies to thoise bugs |
| 09:35 | <annevk> | cause unless the person that files them keeps track it's unlikely the person will close it |
| 09:35 | <othermaciej> | yeah |
| 09:35 | <othermaciej> | they're highly likely to end up in the NoReply pile |
| 09:35 | <zcorpan> | would be nice if the comment box would hook into the annotation login system and add the email to cc |
| 09:36 | <annevk> | only registered emails can be on the cc |
| 09:36 | <zcorpan> | oh well |
| 09:37 | <jgraham> | It would be nice if you could add your email address to the comment box anyway |
| 09:37 | <jgraham> | Or at least if it gave you a link to the bug page (an actual link not just an alert) |
| 09:37 | <Hixie> | you can just copy and paste the link from the alert |
| 09:38 | <Hixie> | anyway, patches welcome, so long as it doesn't make the UI any more complicated |
| 09:38 | <jgraham> | Hixie: That's significantly more work |
| 09:38 | <jgraham> | (one middle click on a link vs select text + copy + open new tab + paste + press return) |
| 09:38 | <zcorpan> | Hixie: is a line above the comment box showing status/link instead of alert more comlicated UI? |
| 09:39 | <Hixie> | zcorpan: that might work |
| 09:41 | hsivonen | wonders how many names with capital letters X3D has |
| 09:41 | hsivonen | wonders what the level of browser vendor interest in X3D as Part of the Platform is |
| 09:42 | <Philip`> | hsivonen: All of them have capitals |
| 09:42 | <hsivonen> | Philip`: how many is "All"? |
| 09:44 | <Philip`> | hsivonen: Zillions |
| 09:44 | <Philip`> | (approximately) |
| 09:44 | <Philip`> | http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19776-1.2-X3DEncodings-XML/Part01/Schema.html |
| 09:45 | <Hixie> | othermaciej: what is "auto-click" in the safari bookmark manager? |
| 09:45 | <othermaciej> | Hixie: the worst name for a feature ever |
| 09:45 | <othermaciej> | Hixie: but what it does is... |
| 09:45 | <Philip`> | (http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19776-1.2-X3DEncodings-XML/Part01/examples.html#SimpleExample has specific examples) |
| 09:46 | <othermaciej> | if you check that box that for a bookmark folder, then selecting that folder will open its contents in tabs (one tab per bookmark) |
| 09:46 | <hsivonen> | Philip`: the use of XSD doesn't make a good first impression |
| 09:47 | <Hixie> | othermaciej: ...i see |
| 09:47 | <othermaciej> | hsivonen: I'm curious how X3D compares to Google's O3D (which I gather is now built in to Chrome but not yet proposed for standardization afaik) |
| 09:47 | <othermaciej> | Hixie: it's a useful feature - just very badly named for reasons I can't get into here |
| 09:47 | <hsivonen> | I don't think I'm putting X3D in the parser for plug-ins. And I'm not seeing any interest in shipping a native X3D impl. in Gecko. |
| 09:47 | <Philip`> | hsivonen: I expect they didn't have any realistic choices other than DTD and XSD when writing the spec (several years ago) |
| 09:48 | jgraham | hoped that autoclick would cause random and unexpected click events to be dispatched all over the screen |
| 09:48 | <Hixie> | othermaciej: the only thing i use bookmarks for is bookmarklets, so not useful for me, but i can see it might be useful :-) |
| 09:48 | <Philip`> | othermaciej: They seem totally different, since X3D is declarative and O3D is imperative |
| 09:48 | <jgraham> | It would be like the days when Yahoo had the "take me to a random site" feature |
| 09:49 | <othermaciej> | Philip`: but both are based on a retained scene graph model |
| 09:49 | <hsivonen> | othermaciej: do you mean Google is putting O3D into Chrome even though Gecko and WebKit have this WebGL thing going? |
| 09:49 | <othermaciej> | (unlike WebGL which is immediate mode) |
| 09:49 | <othermaciej> | hsivonen: well, Google is also putting WebGL into Chrome |
| 09:50 | <othermaciej> | O3D is different from WebGL - it's retained mode, so a bit more like Opera's old 3D canvas experiment, or like X3D (not sure if it has a serialized markup form though) |
| 09:50 | <hsivonen> | so we are headed towards 3 out of 5 supporting WebGL, 1 out of 5 supporting O3D and 0 out of 5 supporting X3D? |
| 09:50 | <othermaciej> | Google is also shipping Native Client built in (I believe you can now start a Worker that loads and runs x86 native code) |
| 09:51 | <othermaciej> | I believe Opera is in the Khronos subgroup that is working on WebGL but I'm not 100% sure |
| 09:51 | <hsivonen> | does built-in mean that O3D and Native Client aren't in the NPAPI prison? |
| 09:51 | <annevk> | we are |
| 09:51 | <othermaciej> | I suspect Microsoft will never ever implement it because Mozilla chose to do it at Khronos, a standards body that Microsoft will never join in a million years |
| 09:51 | <Philip`> | othermaciej: Hmm, I suppose the retainedness thing is true, though O3D seems to be more of a low-level render graph while X3D is a higher-level thing |
| 09:51 | <Dashiva> | Why not? |
| 09:51 | <annevk> | not sure if our old 3D stuff was retained, but it was definitely higher-level |
| 09:52 | <othermaciej> | hsivonen: I believe that is the case for NaCl, at least that was their plan |
| 09:52 | <hsivonen> | othermaciej: I see |
| 09:52 | <Philip`> | X3D also has support for interactivity (routing messages between objects, optionally with scripts and stuff), whereas O3D presumably leaves it all to JS |
| 09:52 | <othermaciej> | I'm kind of concerned about pushing x86 native code into the Web platform, even if supposedly safely sandboxed |
| 09:52 | <annevk> | as long as they ensure it can be implemented on top of DirectX Microsoft can probably do it |
| 09:52 | <hsivonen> | I hope we don't end up in a situation where all devices have to support i386 instructions for Web compat |
| 09:53 | <annevk> | othermaciej, last I heard they had not specced the details of sandboxing |
| 09:54 | <hsivonen> | even if Google manages to badger people into publishing x86, x86_64 and arm code, it would we a huge barrier for entry for novel CPU architectures |
| 09:54 | <othermaciej> | I asked some Chrome folks about this and they said the solution was to let Web sites post native code binaries for whatever architectures they cared to, and eventually they'd port Native Client to support some other architectures that they care about |
| 09:54 | <othermaciej> | that or some server component would translate to different native instruction sets on the fly |
| 09:54 | <Philip`> | I thought the idea was to emulate x86 on other CPUs, but that seems to be missing the performance aspect |
| 09:54 | <annevk> | othermaciej, ouch |
| 09:55 | <Philip`> | (and performance seems to be largely the point of native code) |
| 09:55 | <othermaciej> | any of these approaches seems pretty detrimental to innovation in CPU arhictectures |
| 09:55 | <hsivonen> | it would suck big time if Native Client was already established enough to require iPhone and N900 to support x86 instructions |
| 09:55 | <Philip`> | Intel ought to be promoting NaCl |
| 09:55 | <othermaciej> | anyway, yeah, no formal spec, not proposed as a standard, only barely less terrible for the Web than ActiveX, and now available in Chrome |
| 09:56 | <annevk> | hopefully they don't become market leader |
| 09:56 | <Dashiva> | The people saying "Google is becoming Microsoft" must feel vindicated |
| 09:57 | <Philip`> | Is Google planning to support all these features backward-compatibly in Chrome forever? |
| 09:57 | <hsivonen> | I think disrespecting JS as a language and treating it as a mere GWT compile target is way better than sending x86 code down the wire |
| 09:57 | <othermaciej> | the IE team seems more hesitant to push proprietary extensions than the Chrome team |
| 09:58 | <Philip`> | That's not surprising given the different reactions those teams get when pushing proprietary extensions |
| 09:59 | <othermaciej> | I think sending a portable low-level bytecode down the wire would be better than sending x86 code down the wire but apparently it's impossible for the world's brightest engineers to make that fast enough |
| 10:00 | <othermaciej> | I did see some minor blowback about Native Client on the programming reddit, but some cheering too |
| 10:00 | <hsivonen> | couldn't they at least spec a register-oriente abstract byte code, target LLVM to the byte code and ship JITs in the client? |
| 10:00 | <hsivonen> | x86 seems like an awful choice for the universal bytecode |
| 10:00 | <Philip`> | Or use the JVM, which is a pretty popular bytecode format |
| 10:01 | <Philip`> | hsivonen: About X3D plugins vs native implementations: what about script implementations, which are neither? (Would it be worth changing the language to support those better?) |
| 10:01 | <jgraham> | Everything old is new again? |
| 10:02 | <othermaciej> | Native Client was interesting as a proof of concept but it won't be all that funny if Google starts posting x86 binaries as part of their Web apps |
| 10:03 | <hsivonen> | Philip`: for script implementations, I'd rather see script implementations of the feature set using WebGL and XHR before taking any steps to put it in the HTML parser in anticipation |
| 10:03 | <othermaciej> | Philip`: seems to me like <object> and XMLHttpRequest respectively give all you need for plugin and script implementations |
| 10:03 | <othermaciej> | apparently the X3D guys have a demo of it running on top of WebGL |
| 10:04 | <hsivonen> | Philip`: I imagine Oracle would line up the lawyers if Google wanted to use the JVM byte code in workers without the standard library |
| 10:05 | <hsivonen> | Philip`: there has to be a reason to do Dalvik |
| 10:05 | <hsivonen> | Philip`: and if you invent a new byte code, you might as well make it register-based to avoid having to undo the stackness in the JIT |
| 10:07 | <Philip`> | I assume the X3D guys' demo is basically my demo from years ago, updated a bit |
| 10:09 | <Philip`> | (which used inline X3D in XHTML) |
| 10:09 | <othermaciej> | rendering to WebGL? |
| 10:11 | <annevk> | might as well try to standardize JS bytecode then |
| 10:13 | <Philip`> | othermaciej: Rendering to Mozilla's GL API from years ago, which is basically the same as WebGL |
| 10:14 | Philip` | goes away |
| 10:15 | <Philip`> | Oh, no I don't |
| 10:16 | <jgraham> | Philip`: You're a bit early for pantomime season |
| 10:26 | <zcorpan> | Philip`: any progress on end tag data? |
| 10:33 | <Philip`> | zcorpan: No, I keep forgetting about it |
| 10:33 | <zcorpan> | does it help that i keep reminding you about it? |
| 10:34 | <Philip`> | Yes, because eventually you'll remind me at a time when I can't think of anything better to do :-) |
| 10:34 | <zcorpan> | like now? |
| 10:35 | <Philip`> | No |
| 10:35 | <zcorpan> | bummer |
| 10:37 | <Hixie> | man, the number of times i mistype "typo" isn't even funny |
| 10:38 | <zcorpan> | you should have a macro key that types "typo" |
| 10:41 | <Hixie> | hm, not a bad idea |
| 10:42 | <Hixie> | unfortunately i need PS/2 to USB adapter to use my macro keyboard |
| 10:42 | <Hixie> | and i'm out of keys to use for macros on my main keyboard |
| 10:42 | <Philip`> | Use mouse gestures |
| 10:43 | <Philip`> | Or you could use longer combinations of keys to activate the macro, for example "t"+"y"+"p"+"o" |
| 10:43 | <Hixie> | mmmhm |
| 10:52 | <Hixie> | 19 e-mails remaining; 1 issues remaining; 24 bugs remaining! |
| 10:52 | <Hixie> | totally doable by the end of the month |
| 10:53 | <zcorpan> | yay |
| 10:53 | <jgraham> | Can we have a WHATWG LC sweepstakes now? And a seperate HTMLWG one (with higher stakes) |
| 10:54 | <jgraham> | (since the probability distribution is rather broader and has a really long tail) |
| 10:55 | <Dashiva> | Possibly infinite |
| 10:55 | <Philip`> | Hixie: Does that mean you'll have time left over to rewrite the spec into rhyming couplets? |
| 10:55 | <Hixie> | nooo |
| 10:55 | <Dashiva> | What's wrong with pentameter? |
| 10:58 | <Philip`> | Whoever decided that a pentameter contains five feet clearly wasn't an expert on measurement units |
| 11:12 | <AryehGregor> | This spec aims to evolve HTML / and all of its related APIs, / to help the authoring of Web-based apps. |
| 11:13 | <AryehGregor> | Hmm, now can I make it rhyme? |
| 11:15 | <Philip`> | AryehGregor: Those aren't iambs, the stresses are all wrong :-( |
| 11:15 | <Philip`> | Actually the second and third lines seem alright, but the first doesn't, unless I'm just reading it wrong |
| 11:16 | <AryehGregor> | So sue me. I only even know what an iamb is because of some undergrad world humanities course three years ago that I didn't even mean to take. |
| 11:17 | <AryehGregor> | You have to stress "to" in the first line, maybe that's wrong? |
| 11:17 | <AryehGregor> | I dunno. |
| 11:18 | <Philip`> | The pronunciation of "HTML" as four letters seems incompatible with the requirements |
| 11:18 | <Philip`> | since I'd stress the "H" and "L" |
| 11:18 | <zcorpan> | so pronounce it as "hutmel" |
| 11:19 | <Philip`> | zcorpan: Too few syllables in that case |
| 11:19 | <AryehGregor> | Yeah, you have to stress the T and L instead of the H and L. |
| 11:20 | <AryehGregor> | "Hypertext" is also a problem, so you can't just expand the acronym. |
| 11:20 | <Philip`> | "Hypertext" seems okay to me |
| 11:20 | <mikekelly> | =/ |
| 11:20 | <Philip`> | (as long as you follow it with something unstressed, i.e. not "Markup") |
| 11:21 | <AryehGregor> | You'd have to stress it "HYperTEXT", I guess? I suppose that works. |
| 11:21 | <Philip`> | though I'm certainly not an expert on any of these things and I barely know what a syllable is |
| 11:22 | <AryehGregor> | You can read what I wrote as iambic pentameter if you want, anyway. |
| 11:22 | <AryehGregor> | It's just not the most natural way to read it. |
| 11:22 | <AryehGregor> | It's not like I'm putting stresses like "auTHORing" that are completely crazy. |
| 11:22 | <Philip`> | It seems wholly unnatural to me :-) |
| 11:22 | <AryehGregor> | Oh well. |
| 11:22 | <Philip`> | (The first sentence anyway) |
| 11:22 | <Philip`> | But don't ask me to produce anything better :-p |
| 11:23 | Philip` | wonders how Shakespeare would have written a play about HTML |
| 11:23 | <AryehGregor> | Most of Shakespeare isn't in verse. |
| 11:23 | <AryehGregor> | So he's safe. |
| 11:23 | AryehGregor | doesn't dare trying to rewrite even a single sentence of the spec in Elizabethan English |
| 11:24 | <AryehGregor> | Archaic Hebrew I can do, English not so much. |
| 11:52 | <mikekelly> | Philip`: was it you was saying the other day a discussion came up about providing access to request object for a page? |
| 11:53 | <mikekelly> | trying to find it but got no idea what I should be looking for :( |
| 11:54 | <hsivonen> | Does this make sense: http://groups.google.com/group/mozilla.dev.tech.dom/msg/6dfd6196523b02e9 ? |
| 11:54 | <hsivonen> | also, has the issue already moved to the WebApps WG? |
| 11:58 | <othermaciej> | I don't recall addChild() being proposed |
| 11:59 | <othermaciej> | the proposal strikes me as a little odd |
| 12:00 | <hsivonen> | othermaciej: it's basically DWIM that hides the need to pass NS URIs to the APIs |
| 12:00 | <hsivonen> | in Minefield, http://www.apple.com/imac/the-new-imac/#large plays the sound but no video |
| 12:01 | <othermaciej> | why is append the only case of DOM insertion that needs a convenient built-in way to create the element? |
| 12:01 | <hsivonen> | that's supposed to be HTML5 <video>, right? |
| 12:02 | <othermaciej> | that page does use a <video> element (at least what it serves to Safari includes a <video> element) |
| 12:02 | <hsivonen> | othermaciej: append is a natural excuse for taking an existing element as context |
| 12:02 | <annevk42> | hsivonen, innerHTML strikes me as a much more convenient API |
| 12:02 | <hsivonen> | annevk42: we don't have an efficient appendInnerHTML API |
| 12:02 | <othermaciej> | hsivonen: to the point that you should fall completely off the API cliff if you want to prepend, insert, replace or make a detached subtree? |
| 12:03 | <hsivonen> | annevk42: Firebug rolls its own using createContextualFragment |
| 12:03 | <othermaciej> | actually, there's insertAdjacentHTML() |
| 12:03 | <othermaciej> | (which I guess Mozilla doesn't have yet?) |
| 12:03 | <hsivonen> | hmm. that could be useful |
| 12:03 | <hsivonen> | assuming of course, that it's added to SVG elements, too |
| 12:03 | <hsivonen> | no idea if Mozilla has it yet |
| 12:03 | <annevk42> | I'm not too sure we should be inventing new DOM APIs before we have some more experience with what libraries are doing and what authors want |
| 12:04 | <othermaciej> | insertAdjacentHTML is probably easier to use than what is proposed, though arguably more sloppy since it does runtime parsing of markup |
| 12:04 | <annevk42> | especially since everything is already possible so it seems like too much premature optimization to me |
| 12:04 | <hsivonen> | annevk42: libraries can deal with the horror of NS URIs anyway |
| 12:04 | <othermaciej> | but it does solve the problems with using innerHTML to append though |
| 12:04 | <othermaciej> | I too am hesitant to add DOM APIs |
| 12:04 | <annevk42> | hsivonen, right, so why have new APIs? |
| 12:04 | <hsivonen> | othermaciej: insertAdjacentHTML may be a nicer API if you don't need to vary the attribute values depending on program state |
| 12:05 | <othermaciej> | I'd like to see us have a sound DOM4 Core draft that strips out the useless/unimplemented DOM APIs first, then consider additions very carefully |
| 12:05 | <othermaciej> | hsivonen: depends on whether string-pasting is acceptable as a way to vary the attributes |
| 12:05 | <hsivonen> | othermaciej: escaping them to be parser-safe seems awfully inefficient |
| 12:05 | <othermaciej> | having to allocate a JS object to hold the attributes solely to pass them is an efficiency hit, though one that is common in JS libraries |
| 12:05 | <annevk42> | I'm with othermaciej |
| 12:05 | <annevk42> | that's pretty much what I'm doing for CSSOM |
| 12:05 | <Hixie> | me too |
| 12:06 | <Hixie> | what zcorpan was doing with Web DOM Core seemed like the right thing to do |
| 12:07 | <othermaciej> | hsivonen: anyway I'm not totally convinced that the separateness of create and append is a major pain point |
| 12:08 | <othermaciej> | hsivonen: I do think that dealing with the few well-known namespaces, and defining attributes after creating are real pain points |
| 12:08 | <othermaciej> | hsivonen: on the other hand, why built-in handling for setting attributes but not text content? |
| 12:09 | <annevk42> | is setAttribute() really that bad? |
| 12:09 | <jgraham> | FWIW I find create+setAttribute being seperate to be a bigger pain point |
| 12:09 | <othermaciej> | having to create and insert a Text node separately is kind of a pain |
| 12:09 | <hsivonen> | when coding without libs on the raw DOM, creating and appending as separate ops sucks pretty badly, IMO |
| 12:09 | <jgraham> | Oh yeah and the text node thing for sure |
| 12:09 | <annevk42> | true, we should prolly overload a few methods at some point to also accept strings |
| 12:09 | <hsivonen> | looks like the iMac ad uses <embed> in Minefield |
| 12:09 | <othermaciej> | given that there are multiple useful ways to insert, there should be an uncombined version of the most convenient form of create |
| 12:09 | <hsivonen> | no idea why the video doesn't render |
| 12:10 | <othermaciej> | in my raw DOM programming (mostly for WebKit test cases), the most annoying part of dynamically creating elements is usually making a text node to add text content |
| 12:10 | <jgraham> | I sometimes create a wrapper funciton like Element(name, attributes, children) |
| 12:10 | <jgraham> | where children can be a list of elements or text |
| 12:10 | <jgraham> | But it's not a great design |
| 12:11 | <hsivonen> | looks like Apple doesn't want to provide Theora video :-( |
| 12:11 | <othermaciej> | is that in any way surprising? |
| 12:11 | <hsivonen> | othermaciej: not really. just makes the hype about the ad using HTML5 fall a bit flat |
| 12:12 | <othermaciej> | I guess assigning foo.textContent would be easier than creating a Text node, though less cross-browser portable |
| 12:13 | <annevk42> | I usually set textContent |
| 12:13 | <annevk42> | or innerHTML |
| 12:13 | <annevk42> | depending on the string |
| 12:13 | <annevk42> | and what browsers it needs to work in |
| 12:13 | <othermaciej> | I use innerHTML or document.write() when I am lazy |
| 12:13 | <gsnedders|work> | document.write() is just evil though |
| 12:13 | <hsivonen> | I guess one might argue that all DOM sugaring that isn't perf-oriented like the Selectors API should just go in JS libs |
| 12:13 | <othermaciej> | I guess that no longer stops my tests from being standards-compliant |
| 12:14 | <othermaciej> | document.write() is only a little bit more evil than innerHTML |
| 12:14 | <hsivonen> | othermaciej: document.write() is way, way more evil |
| 12:14 | <annevk42> | ah yeah, I use document.write a lot too |
| 12:14 | <annevk42> | very convenient for tests |
| 12:14 | <gsnedders|work> | document.write() affects the parser as it is parsing. innerHTML doesn't do anything like that. |
| 12:14 | hsivonen | has spent insanely more time on implementing document.write than innerHTML |
| 12:14 | <gsnedders|work> | Hence, document.write is more evil |
| 12:15 | <othermaciej> | mere implementation concerns! |
| 12:15 | <annevk42> | my test case writing trumps your implementing :p |
| 12:15 | <othermaciej> | hsivonen: I think it's plausible that some sugar in the core would be useful, but if so it should be based on carefully studying what popular JS libraries do (perhaps after SVG-in-HTML and such is available) |
| 12:16 | <othermaciej> | hsivonen: I think with Selectors API we made a mistake by not studying JS libs close enough, and ended up implementing something that didn't really work for them or their clients |
| 12:16 | <othermaciej> | s/implementing/specifying and implementing/ |
| 12:18 | <jgraham> | FWIW I don't think you should hace to pull in thousands of lines of jQuery to do simple things in a clean way |
| 12:18 | <othermaciej> | agreed |
| 12:18 | <jgraham> | But I agree that we shouldn't specify something that doesn't work for jQuery too |
| 12:19 | <othermaciej> | in the case of DOM Core sugar, it would be more a question of whether it could serve the needs of jQuery (or Dojo or YUI) clients directly |
| 12:19 | <othermaciej> | cause it doesn't matter that much what you use to implement the libraries |
| 12:20 | <othermaciej> | it's actually kind of hard to make a sugary API that works better for implementing library-based convenience APIs, unless it exactly matches the API |
| 12:21 | <jgraham> | Arguably that means it doesn't matter too much if it meets the exact needs of the library since the use case would be people doing something too simple to want to pull in a whole complex library |
| 12:21 | <othermaciej> | the question to ask would be how often does it save you from having to pull in the whole library |
| 12:22 | <jgraham> | Indeed. For me it would be a big win but I'm quite atypical |
| 12:22 | <othermaciej> | this is why I prefer such an API not to have a steep "cliff" - so if it doesn't do exactly what you want, you can just add a couple of other raw DOM calls, rather than having to find a completely separate way to do it |
| 12:24 | <mikekelly> | which one is better to use - document.location.href or just document.location? or does it not make a diff? |
| 12:24 | <othermaciej> | it doesn't really matter |
| 12:24 | <mikekelly> | ok cool thanks |
| 12:24 | <mikekelly> | do browsers store the location as an <a> tag then? |
| 12:25 | <mikekelly> | also - are browsers coming up with a 'microformat' type giblet for storing bookmarks |
| 12:25 | <mikekelly> | that would be snazzy |
| 12:33 | <Philip`> | mikekelly: It wasn't me |
| 12:34 | <gsnedders|work> | mikekelly: No, they store the location as a URL (or as an entire DOMLocation object) |
| 12:35 | <gsnedders|work> | mikekelly: It would make no sense to store it as an a element |
| 12:36 | <Philip`> | othermaciej: Reported telecon date is wrong again :-p |
| 12:36 | <Philip`> | Subject says 22, body says 15, link says 8 |
| 12:36 | <othermaciej> | dammit! |
| 12:37 | <Philip`> | (of October) |
| 12:37 | <othermaciej> | at least I got it right in the subject |
| 12:37 | <othermaciej> | clearly too much copy-pastery involved |
| 12:52 | <smaug_> | Hixie: ping |
| 12:52 | <smaug_> | Hixie: dnd doesn't seem to handle drop on form controls properly |
| 12:53 | <Hixie> | how so? |
| 12:53 | <smaug_> | basically, should drop fire? |
| 12:54 | <Hixie> | generally speaking, yes |
| 12:54 | <smaug_> | "If the dragover event is not canceled, the current drag operation must be reset to "none"." |
| 12:55 | <smaug_> | "If the current drag operation is none (no drag operation), or, if the user ended the drag-and-drop operation by canceling it (e.g. by hitting the Escape key), or if the current target element is null, then the drag operation failed" |
| 12:55 | <smaug_> | so what does cancel dragover when dropping to form controls? |
| 12:56 | <mikekelly> | hmm seems the only way I can get headers for current page's response is to make a new HEAD request with XHR to document.location |
| 12:56 | <Hixie> | smaug_: oh, i see. dragover should have some default behaviour that sets the current drag operation for form controls, or something |
| 12:56 | <Hixie> | smaug_: send a mail or file a bug? |
| 12:56 | <smaug_> | ok, will send a amil |
| 12:56 | <smaug_> | |
| 12:56 | <mikekelly> | is there any other way to approach this or is that the solution? |
| 12:57 | <Philip`> | mikekelly: I think that's the only client-side solution |
| 12:57 | <Hixie> | smaug_: thanks |
| 12:57 | <mikekelly> | Philip`: so browser deliberately drop the response data once the page is loaded? |
| 12:57 | <Philip`> | mikekelly: (You could instead approach it by passing everything through a proxy server that captures headers and returns them on demand, or something, but that wouldn't be great) |
| 12:58 | <Philip`> | mikekelly: I believe so |
| 12:58 | <mikekelly> | is there a specific reason for that or is it just how its ended up? |
| 12:58 | <Philip`> | mikekelly: (or at least they don't expose it to scripts) |
| 12:58 | <Philip`> | mikekelly: Features don't exist by default |
| 12:59 | <mikekelly> | hmm I guess not |
| 12:59 | <Hixie> | wow, did i really just address all those bugs? |
| 12:59 | <Hixie> | it seems like the pile suddenly got smaller. |
| 12:59 | <mikekelly> | most dev platforms make sure their APIs present all the relevant information :P |
| 12:59 | <mikekelly> | fair enough though |
| 13:00 | <mikekelly> | I doubt anyone will be convinced that is a good idea so looks like have to stick to making HEAD requests back |
| 13:00 | <mikekelly> | all this inefficiency probably costs like.. a million trees a year or something like that |
| 13:01 | <Philip`> | mikekelly: Seems unlikely, since it's a feature that approximately zero people want and emulate with HEAD requests |
| 13:01 | <Philip`> | Also, trees are big and HTTP requests are tiny |
| 13:01 | <mikekelly> | scale |
| 13:01 | <mikekelly> | plus - people are moving away from message oriented approaches |
| 13:02 | <Philip`> | Trees are really really big and HTTP requests are really really tiny |
| 13:02 | <mikekelly> | and towards using HTTP headers for metadata |
| 13:03 | <mikekelly> | so I don't think it's as crazy an idea as you think it is :P |
| 13:05 | <mikekelly> | just a bit frustrating have to go back to fetch data that could've been made available already |
| 13:06 | <mikekelly> | but hey - I'm sure it's within everyone's best interests to have it that way |
| 13:06 | <Philip`> | It wouldn't be a problem if the server put all the needed data in the response body |
| 13:06 | <mikekelly> | ;D |
| 13:06 | <mikekelly> | that is not the same thing. |
| 13:06 | Philip` | doesn't think it's a crazy idea, he just doesn't care about it |
| 13:07 | <mikekelly> | if you standardise your application's metadata in the headers you get metadata across all content-types |
| 13:07 | <mikekelly> | jpg/png/html/doc/pdf/xml/json |
| 13:08 | <mikekelly> | OCCI looks like it is going this way |
| 13:08 | <Hixie> | ok bed time |
| 13:08 | <Hixie> | nn |
| 13:10 | <mikekelly> | Philip`: you still disagree it is not equivalent to put metadata in the entity body? |
| 13:10 | hsivonen | wonders if Opera and WebKit have a pseudoclass for matchin on the HTMLness bit of the owner document |
| 13:10 | <hsivonen> | Gecko has :-moz-is-html |
| 13:13 | <Philip`> | mikekelly: I agree they're different, but that doesn't mean you can't put the data in the HTML entity body to avoid the problem of scripts wanting headers from the current response |
| 13:13 | <Philip`> | (You might introduce other problems by doing that, of course) |
| 13:22 | <mikekelly> | Philip`: exactly :) |
| 13:24 | <Philip`> | Would anyone shoot me for reporting WHATWG-copy-of-spec-specific issues in the W3C bug tracker? |
| 13:25 | <hsivonen> | Philip`: people who disapprove of the existence of the WHATWG might |
| 13:26 | <hsivonen> | Am I imagining things or does GCC run faster on Snow Leopard than on Leopard? |
| 13:26 | <hsivonen> | x86_64 additional registers maybe? |
| 13:27 | <Philip`> | Newer version of GCC? |
| 13:29 | <hsivonen> | maybe |
| 13:29 | <hsivonen> | no, actually, the big digits of the GCC version are supposed to be the same, I think |
| 13:30 | <hsivonen> | hmm. did heycam ever file the bug about insertion modes when there are nested <td><svg>s? |
| 13:31 | <Philip`> | Compiling for different targets (32-bit vs 64-bit)? or is it only the compiler itself that changed to 64-bit? |
| 13:32 | <hsivonen> | Philip`: 32-bit target still |
| 14:09 | <mikekelly> | Philip`: meh - this works fine so can't really complain http://jsbin.com/eyobo |
| 14:09 | <mikekelly> | apart from the state of the resource being modified between requests.. |
| 14:10 | <mikekelly> | and the server providing inconsistent headers between GET/HEAD |
| 14:10 | <mikekelly> | if you look at the content-length on that link it's actually wrong |
| 14:10 | <smaug_> | Hixie: btw, could you remove initXXXEventNS methods from the draft? D3E draft doesn't have namespaced events anymore. |
| 14:12 | <Dashiva> | He already did, I believe |
| 14:12 | <Dashiva> | r4204 |
| 14:14 | <smaug_> | ah |
| 14:14 | <smaug_> | hmm |
| 14:14 | <smaug_> | did I load the draft from cache |
| 14:15 | <smaug_> | I guess I did |
| 15:15 | <Philip`> | mikekelly: Yeah, HEAD doesn't really work well enough to rely on if you don't control the server |
| 15:15 | <Philip`> | If I remember correctly, I once found a server that returned four random bytes (like uninitialised memory or something) for Content-Type on HEAD requests |
| 15:15 | <mikekelly> | which is why it would be nice to have access to the original request :P |
| 15:16 | <mikekelly> | technically if a server isn't consistent across GET/HEAD then it''s breaking HTTP |
| 15:17 | <mikekelly> | it's still annoyingly inefficient to have to make another request for information that's already been downloaded |
| 15:20 | <mikekelly> | i'm not saying it should be - but how does stuff like that get standarised across browsers if it's decided it should be added? |
| 15:25 | <Philip`> | mikekelly: Someone writes a specification for the stuff (often as part of an existing spec or working group), then someone convinces browser developers to implement it (by asking them, preferably showing usefulness and demand from users), then people write tests and documentation and stuff, and then everyone waits a few years until they can use it |
| 15:25 | <mikekelly> | lol |
| 15:25 | <Philip`> | (not necessarily in that order) |
| 15:25 | <mikekelly> | I hope google chrome does well so we don't have to put up with nonsense much longer |
| 15:26 | <Philip`> | Which nonsense? |
| 15:26 | <mikekelly> | the nonsense you just described |
| 15:26 | <mikekelly> | :P |
| 15:27 | <Philip`> | The nonsense of developing clear specifications and getting browser developers to agree to implement it interoperably? |
| 15:27 | <mikekelly> | yeah there's too many browsers that try to do too much |
| 15:27 | <TabAtkins> | ...so you want a monoculture again? |
| 15:27 | <mikekelly> | google chrome monoculture looks good to me |
| 15:27 | <TabAtkins> | ::shudders:: |
| 15:28 | <mikekelly> | look at their extension system |
| 15:28 | <TabAtkins> | There is no such thing as a good monoculture in tech. |
| 15:28 | <mikekelly> | I'm sure Ian would have something to say about that |
| 15:28 | <TabAtkins> | ?_? |
| 15:29 | <mikekelly> | :D |
| 15:29 | <Philip`> | I think I prefer standards rather than the alternative approach of Google adding hugely complex features willy-nilly and hoping they become de facto standards |
| 15:29 | <mikekelly> | yeah I agree - personally I think browsers should do nothing other than render html/css and run javascript |
| 15:29 | <mikekelly> | but that's just me |
| 15:30 | <mpilgrim> | you're welcome to build one that does nothing but that |
| 15:30 | <mikekelly> | I might well do that if I get time. |
| 15:30 | <mikekelly> | or if that's what google chrom OS turns out to be I wont have to bother |
| 15:31 | <TabAtkins> | Chrome OS is just going to be a light-weight Linux with a new windowing system that's designed to run webapps well, somehow. |
| 15:31 | Philip` | was just at a talk about V8, and the person said Chrome OS wouldn't have device drivers written in JS :-( |
| 15:31 | <mikekelly> | be cool to bootstrap my browser off my web server :) |
| 15:31 | <Philip`> | mikekelly: By "cool" you mean "really slow"? |
| 15:31 | mpilgrim | still isn't sure what chrome os is |
| 15:31 | <mikekelly> | Philip`: why would that be slow? |
| 15:31 | <TabAtkins> | mpilgrim: It's what I just described. |
| 15:32 | <Philip`> | It's an OS that's shiny |
| 15:32 | <Philip`> | That's enough to get excited about |
| 15:32 | <mikekelly> | if the core engine for rendering html/css and running javascript is on the client |
| 15:32 | <Philip`> | No need to worry about technical details like what it is |
| 15:32 | <mikekelly> | the rest is just UI components |
| 15:33 | <mikekelly> | you recon it's not possible to design a browser UI with html5/css3/javascript? |
| 15:33 | <mikekelly> | looks to me like it is/will be |
| 15:33 | <mpilgrim> | i have that already |
| 15:33 | <mikekelly> | well then. |
| 15:33 | <mpilgrim> | it's called linux |
| 15:34 | <mpilgrim> | (oops, that was responding to TabAtkins) |
| 15:34 | <mikekelly> | yeah I know sorry =) |
| 15:34 | <TabAtkins> | Yeah, just with a new windowing system, like I said. |
| 15:34 | <mpilgrim> | i like my windowing system |
| 15:34 | <TabAtkins> | Then don't use Chrome OS. ^_^ |
| 15:35 | <mpilgrim> | but given the default windowing systems on various platforms, i can certainly see the market opportunity for one that doesn't suck |
| 15:35 | <mikekelly> | I got one desktop on ubuntu full screen chrome |
| 15:35 | <mikekelly> | does that count? |
| 15:35 | <Philip`> | The V8 person suggested it was largely for people like his daughters, who use no applications other than the web browser |
| 15:35 | <TabAtkins> | Yah, I think it's supposed to make the distinction between webapps/native apps mostly disappear too, like Chrome browser currently does with Application Shortcuts. |
| 15:36 | <TabAtkins> | Only more so. |
| 15:36 | <Philip`> | (which presumably doesn't apply to anybody who's in here) |
| 15:36 | <mikekelly> | I don't think google will store any of this on the client |
| 15:36 | <mikekelly> | well I wouldn't anyway |
| 15:36 | <Philip`> | (Ah, the V8 person was Lars Bak) |
| 15:37 | <TabAtkins> | Actually, I could get by pretty well with a browser-focused OS. My current spread of windows is pretty typical - 4 browser windows, IRC (in an FF plugin), and my music player. |
| 15:37 | mpilgrim | decides, apropos of nothing, that what "dive into html5" needs is a recurring "ask doctor markup" sidebar |
| 15:38 | <TabAtkins> | mpilgrim: Ooh! Ooh! Make it be an <html> tag with glasses! |
| 15:38 | <TabAtkins> | Like Dr. Swordopolis! |
| 15:38 | <mikekelly> | I'd need a terminal client |
| 15:38 | <Philip`> | Why only a doctor? Make him a professor, with crazy hair |
| 15:38 | <mpilgrim> | ooh, i might even have clip art of a crazy-haired professor |
| 15:38 | <mikekelly> | there's no way I'm going out to the fucking cloud just to get a terminal session going |
| 15:38 | <mpilgrim> | now i'm going to lose the next two hours to looking at clip art |
| 15:39 | <TabAtkins> | mikekelly: It's still going to be Linux. |
| 15:39 | <Philip`> | mikekelly: What would you do with the terminal session, when all your data and applications are in the cloud? |
| 15:39 | <mikekelly> | Philip`: connect to my shell |
| 15:39 | <mikekelly> | where irssi lives |
| 15:40 | <mikekelly> | that is unless IRC moves onto HTTP |
| 15:40 | <mpilgrim> | how about http://openclipart.org/people/johnny_automatic/johnny_automatic_little_professor.svg |
| 15:41 | <mikekelly> | there's that mebbit thing I guess |
| 15:41 | <TabAtkins> | Dang that'd be good, mpilgrim. |
| 15:42 | <TabAtkins> | sgalineau: http://www.engadget.com/2009/09/24/video-windows-7-launch-party-parody-is-bleeping-genius/ |
| 15:42 | <Philip`> | Trim out the background and have him point at the sidebar and I expect it'd be good |
| 15:43 | <mpilgrim> | or http://commons.wikimedia.org/wiki/File:Stethoscope_(PSF).png |
| 15:43 | mpilgrim | hearts the Pearson Scott Foresman collection |
| 15:44 | <TabAtkins> | I like the chubby professor. |
| 15:44 | <TabAtkins> | He's adorable. |
| 15:44 | <Philip`> | The person with the stethoscope scares me |
| 15:45 | <Philip`> | I'm not even sure if it's male or female |
| 15:45 | <mpilgrim> | chubby professor it is |
| 15:46 | <mpilgrim> | and Professor Markup is born |
| 15:46 | <TabAtkins> | Woo! |
| 15:47 | <mikekelly> | lol. |
| 16:27 | <ttepasse> | Uh. <spacer> died. |
| 16:30 | <Philip`> | Nobody will mourn it |
| 16:30 | <mpilgrim> | TabAtkins: http://diveintohtml5.org/canvas.html#reset |
| 16:31 | <TabAtkins> | mpilgrim: I sort of think he needs a bit of a shadow to lift him off of the bottom border, but otherwise I love him to pieces. |
| 16:31 | ttepasse | has some nostalgia for these nn3 elements. Also: <multicol>. |
| 16:32 | <Philip`> | How odd, that page is no longer unreadable in Opera |
| 16:34 | <Philip`> | http://diveintohtml5.org/canvas.html#pixel-madness - he's been scalped :-( |
| 16:40 | <mpilgrim> | adding a min-height... |
| 16:41 | <mpilgrim> | CSS is awesome http://www.zazzle.com/css_is_awesome_mug-168716435071981928 |
| 19:10 | <yael> | Hi, I am working on implementation of http://dev.w3.org/html5/spec/infrastructure.html#url-decomposition-idl-attributes, and I cannot find a clear explanation of what is a "Server-based naming authority". Can anyone here help me? thanks |
| 19:34 | <mattl> | i fear i'm going insane, but does a poster attr on a video tag really need to relative to the src URL? |
| 19:34 | <anoopb> | so twitpics api allows to upload/uploadandpost but not view pics? |
| 19:45 | <Philip`> | mattl: As far as I can tell, the spec says it's just relative to the normal document base URL |
| 19:46 | <Philip`> | (or technically the base URL of the <video> element) |
| 19:46 | <Philip`> | and src should be irrelevant |
| 20:05 | <TabAtkins> | yael: I found this - http://www.cs.tut.fi/~jkorpela/rfc/2396/full.html - that looks somewhat useful. |
| 20:27 | <aroben> | what's the recommended way to provide feedback on HTML5 these days? should I send an email to the list? should I use the comment form on the spec page? |
| 20:28 | <TabAtkins> | Use an email if you want to discuss the issue, or just file a bug in bugzilla. |
| 20:28 | <TabAtkins> | (The spec's comment form also works for this, though you won't automatically receive replies.) |
| 20:28 | <aroben> | TabAtkins: thanks |
| 20:44 | <yael> | TabAtkins: Thank you. The RFC 2396 says that "server-based naming authority" is tied to schemes that use IP based protocol. I have tested setting host and port on URLs with the sceme foo:. So I assume it should not work, but both IE8 and FF allowed that . |
| 20:49 | <TabAtkins> | yael: I *really* don't have the experience necessary to answer that appropriately, but it does sound like unknown schemes probably shouldn't be assumed to use a server-based naming authority. |
| 20:50 | <TabAtkins> | Search the mailing list, though - I think I recall some discussion around that issue previously. |
| 20:51 | <yael> | TabAtkins: thanks, appreciate your help. |
| 20:52 | <TabAtkins> | No problem. |
| 23:33 | <TabAtkins> | I've got a friend who wants to know what character of text is under the mouse during a mouseDown event. There's not any way to determine that currently, right (without horrible hacks like wrapping every character in a span)? Where would be an appropriate place to tell him to suggest an offsetText property or similar? |
| 23:36 | <Hixie> | anne's already looking at that for cssom iirc |
| 23:37 | <TabAtkins> | Ah, cool. |
| 23:57 | <othermaciej> | TabAtkins: there was a proposed caretRangeFromPoint() API |
| 23:58 | <othermaciej> | TabAtkins: there's the slight complication right now that people want it to work for plaintext controls like <textarea> and <input type="text">, but a DOM Range can't represent a text range inside a form control |
| 23:59 | <TabAtkins> | My friend wasn't wanting that - just the character in a normal text node. |
| 23:59 | <othermaciej> | well, caretRangeFromPoint() will do that in WebKit, but like I said the API is likely to change incompatibly |
.png){kind=link}