| 00:11 | <Hixie> | othermaciej: i think we need a state that is neither "Rejected" nor "Accepted" but which is "I don't know what you want" |
| 00:12 | <Hixie> | othermaciej: because i have the feeling that some of these bugs that i'm marking "Rejected" due to unclear requests are going to just be raised as issues, and will waste a lot of the WG's time, where if the request had just been made clear in the bug, I maybe would have been fine with making the change |
| 00:16 | <othermaciej> | Hixie: I suppose marking the bug NEEDSINFO and asking for more info might be too subtle - I think it's fine to have a "Did Not Understand Request" state or whatever |
| 00:17 | <Hixie> | ok, i'll change to "Did Not Understand Request" instead of "Rejected" when marking the bug NEEDSINFO |
| 00:18 | <Hixie> | thanks |
| 00:18 | <othermaciej> | you could even directly encourage the originator to reopen the bug with additional info in that case if they can expand on their request |
| 00:19 | <Hixie> | i do do that, in the Rationale field |
| 00:19 | <othermaciej> | sounds good |
| 00:51 | <Hixie> | othermaciej: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8210 - do you think that should be a drawFocusRect(x,y,w,h) call or a drawFocusPath() call that uses the current path? |
| 02:12 | <roc> | If we start offering drawFocusRing, aren't we going to get requests for all kinds of native look-and-feel drawing in canvas? |
| 02:20 | <Hixie> | roc: possibly |
| 02:20 | <Hixie> | roc: if that's a problem, i'm certainly open to other suggestions to solve the focus ring problem |
| 02:21 | <roc> | it's not clear what problem the bug reporter is trying to solve |
| 02:28 | <Hixie> | http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/thread.html#msg27 |
| 02:28 | <Hixie> | basically how do you handle users who have magnifiers that follow the caret and system focus |
| 02:28 | <Hixie> | or who have the need for high-contrast focus rings |
| 02:53 | <gsnedders> | Since when was it 4am? |
| 02:54 | <gsnedders> | Oh, yeah. My computer is still on Europe/Stockholm, and I'm in Europe/London. |
| 03:17 | <annevk> | I cannot believe I'm awake |
| 03:32 | <annevk> | Hixie, "in optional canDrawCustom" does not specify a type |
| 04:34 | jwalden | snickers at the example in http://html5.org/tools/web-apps-tracker?from=4461&to=4462 |
| 05:04 | <annevk> | so does Python in CGI mode suck because CGI sucks so much? |
| 05:04 | <annevk> | if so, why hasn't that been replaced over the years? |
| 05:12 | <Hixie> | annevk: oops |
| 05:21 | <Hixie> | gsnedders: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8232 .... what? |
| 05:52 | <annevk> | I like how bz pointed out that browsers do byte-inflation rather than fiddling with ISO-8859-1 |
| 05:52 | <annevk> | It is more or less the same of course, but it makes it seem much more simple :) |
| 06:11 | <Hixie> | gsnedders: nm |
| 06:33 | <Hixie> | annevk: it wouldn't be byte inflation when it's not inflating :-P |
| 06:33 | <Hixie> | it'd be byte stripping or something |
| 06:33 | <Hixie> | pretty bogus to send just the lower byte of a two byte codepoint, though |
| 06:41 | <annevk> | Hixie, ah, doh, byte-deflation then |
| 06:41 | <annevk> | I'd personally be happy with switching HTTP to use UTF-8 everywhere, break a few servers, and patch it all up |
| 06:42 | <annevk> | but that's not going to happen |
| 06:43 | <annevk> | and fiddling with the lower byte (thanks for that, didn't know the term I had to use yet) seems the easiest solution... |
| 06:43 | <annevk> | at some point we'll overload this method with ByteArray or whatever we end up calling it and encourage people to use that I guess |
| 06:49 | <Hixie> | i agree that just switching to UTF-8 is the right solution |
| 06:50 | <annevk> | do you know anything about Chrome's HTTP implementation? |
| 06:50 | <Hixie> | not off-hand |
| 06:51 | <annevk> | it seems to actually use UTF-8 at least here |
| 06:51 | <annevk> | if they use it everywhere... |
| 06:51 | <annevk> | then maybe there is a way |
| 07:53 | <annevk> | hmm, from looking at http://src.chromium.org/viewvc/chrome/trunk/src/net/http/ I cannot find code that deals with the ISO-8859-1 thingie... |
| 07:54 | <annevk> | though for parsing location headers it does call EscapeNonASCII saying something about a compat issue... |
| 07:54 | <annevk> | makes me wonder what other browsers do there |
| 07:59 | <annevk> | Hixie, progressBar.getElementsByTagName('span').textContent is also buggy |
| 07:59 | <annevk> | Hixie, maybe progressBar.firstChild.textContent |
| 07:59 | <annevk> | or [0] of course |
| 08:00 | <Hixie> | oops |
| 08:04 | <annevk> | arguably <code title="">-//W3C//DTD HTML 4.0//EN</code> is somewhat problematic as it does not work if I copy and paste that |
| 08:05 | <annevk> | might be better to use actual spaces and have a class="token" with .token { white-space:pre } or some such |
| 08:06 | <Hixie> | browsers copy U+0020, actually |
| 08:07 | <othermaciej> | bug list is down to 178 I see |
| 08:07 | <othermaciej> | that's good progress |
| 08:08 | <Hixie> | it would be going faster if people didn't decide today was the day to file a bazillion bugs :-P |
| 08:08 | <annevk> | mkay |
| 08:08 | <annevk> | are public ids case-sensitive in SGML? |
| 08:08 | <annevk> | surprises me |
| 08:11 | <annevk> | looks like XMLHttpRequest will need at least one more Last Call |
| 08:12 | <nessy> | OMG - tell me I'm not the only person on this planet that has 13 different browsers installed on one computer |
| 08:12 | <nessy> | (admittedly in 3 different OSes) |
| 08:13 | <hsivonen> | annevk: public IDs are opaque strings in SGML |
| 08:13 | <hsivonen> | annevk: I'm pretty sure they don't get case-folded in SGML |
| 08:14 | <hsivonen> | nessy: I have that many on just one OS plus the ones on the other OSs |
| 08:15 | <nessy> | uff, good - I thought I was going mental |
| 08:15 | <nessy> | I'm just preparing demos for a html5 video tutorial |
| 08:16 | <hsivonen> | nessy: what's the status of the Theora ActiveX project? |
| 08:16 | <othermaciej> | do I get to count Safari 4.0.4, my WebKit nightly, my release build of Safari trunk and my debug build of Safari trunk as 4 different browsers? |
| 08:16 | <hsivonen> | othermaciej: I counted different builds from one codebase as separate |
| 08:16 | <nessy> | hsivonen: unfortunately not much progress yet - needs somebody to fund the poor soul - he has a main job, but would be prepared to reduce to do the thing |
| 08:17 | <hsivonen> | nessy: I see |
| 08:17 | <nessy> | othermaciej: I did count 3 different FF builds, so I guess, yes |
| 08:17 | <othermaciej> | Hixie: indeed I see 55 bugs resolved so far this month, but there has been a fair bit of incoming |
| 08:17 | <nessy> | actually, no, I only counted different browsers, not different versions - otherwise that'd be 3 more |
| 08:18 | <nessy> | hsivonen: we have FOMS coming up in 2 weeks and he will be there, so we'll see how far we can push it |
| 08:18 | <annevk> | hsivonen, kk |
| 08:21 | <othermaciej> | I have Firefox, Chrome, Opera and Safari, counting only distinct browsers |
| 08:21 | <hsivonen> | nessy: is the current recommended thing for IE support to use cortado as a fallback for <video>? |
| 08:21 | <othermaciej> | I have not bothered lately with Camino, OmniWeb, iCab or anything else |
| 08:21 | <hsivonen> | othermaciej: no IEs on VMs? |
| 08:22 | <nessy> | othermaciej: me, too, but 3 times, because of 3 different OSes |
| 08:22 | <nessy> | hsivonen: yes, cortado fallback right now |
| 08:22 | <hsivonen> | nessy: ok thanks |
| 08:22 | <nessy> | requires java installation, but there's a fair few of those around |
| 08:22 | <othermaciej> | I do also have IE on my Windows partition |
| 08:22 | <nessy> | go to http://theora.org/cortado |
| 08:23 | <othermaciej> | I'm not sure if IE/Mac is still runnable, but I don't have a copy here |
| 08:23 | <nessy> | IE/Mac died a long time ago, I think |
| 08:23 | <nessy> | never went back to it |
| 08:23 | <nessy> | but yeah, that on Windoze |
| 08:23 | <nessy> | bbiab |
| 08:24 | <hsivonen> | IE/Mac runs on Snow Leopard |
| 08:26 | <hsivonen> | nice, the progress/meter i18n can of worms is gone |
| 08:49 | <annevk> | hmm |
| 08:49 | <annevk> | getPosition takes an object |
| 08:50 | <annevk> | we discussed using object for APIs once in the WebApps WG and decided not to go there... |
| 08:50 | <annevk> | oh well |
| 08:50 | <annevk> | no consistency in the past, no consistency in the future either |
| 08:51 | <annevk> | one of the many flawed particles of the Web platform |
| 09:11 | <annevk> | the point Kai made has been addressed before |
| 09:11 | <annevk> | but I can't find the email :/ |
| 09:12 | annevk | lets it be someone else's problem |
| 09:12 | <othermaciej> | well I just took a fresh shot at replying |
| 09:12 | <othermaciej> | if you have an older email to cite that would be nice too |
| 09:14 | <annevk> | cannot find it |
| 09:16 | <hsivonen> | the id numbers for saved docs on the live DOM viewer are surprisingly small |
| 09:16 | <hsivonen> | I guess the user base isn't particularly large |
| 09:20 | hsivonen | wonders if there are test cases for load/unload/pagehide/pageshow events for about:blank loading into an iframe |
| 09:28 | <hsivonen> | is onpageshow supposed to work as a content attribute? |
| 09:29 | <annevk> | per HTML5, yes |
| 09:29 | <hsivonen> | what about real world? |
| 09:29 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/342 |
| 09:29 | <hsivonen> | is iframe not firing it or the handler not supported? |
| 09:29 | <annevk> | but only for body and frameset |
| 09:30 | <hsivonen> | oh |
| 09:30 | <annevk> | per html5 anyway |
| 09:30 | <hsivonen> | why frameset but not iframe? |
| 09:30 | <Hixie> | body and frameset are equivalent |
| 09:30 | <Hixie> | iframe and frame are equilavent |
| 09:30 | <annevk> | presumably because frameset takes the role of body |
| 09:30 | <hsivonen> | ok |
| 09:33 | <hsivonen> | is it even possible to register a pageshow event handler for an iframe that loads about:blank before it's too late? |
| 09:33 | <hsivonen> | parser-created iframe that is |
| 09:33 | <annevk> | prolly not |
| 09:33 | <annevk> | but you could load it again |
| 09:33 | <annevk> | after you add a listener to the window object |
| 09:57 | hsivonen | wonders what history behind about:blank loading synchronously is |
| 09:57 | <hsivonen> | not that it matters at this point to know who the guilty party is |
| 09:59 | <annevk> | i guess so that you can directly manipulate the document |
| 09:59 | <annevk> | makes sense to me |
| 10:00 | <hsivonen> | It's quite an annoyance |
| 10:01 | <annevk> | speaking as an author, i trump you :p |
| 10:01 | jgraham | was about to say the same thing as annevk |
| 10:01 | <hsivonen> | you shouldn't be using about:blank-created DOMs, because they aren in the quirks mode |
| 10:02 | <annevk> | thankfully jgraham loses with me |
| 10:02 | <annevk> | :p |
| 10:03 | <othermaciej> | is there any way to put an about:blank frame in standards mode? |
| 10:03 | <annevk> | about:standards-blank |
| 10:03 | <hsivonen> | othermaciej: I thinks there isn't |
| 10:04 | <othermaciej> | even if you document.write a standards-mode doctype into it? |
| 10:04 | <hsivonen> | othermaciej: document.writing into it implies document.open, which blows away html, head and body |
| 10:05 | <hsivonen> | and the "feature" here is that you get html, head and body synchronously and for free |
| 10:06 | <Lachy> | annevk, <iframe src="data:text/html,<!DOCTYPE html>"></iframe> will give you a blank document in standards mode |
| 10:07 | <hsivonen> | Lachy: but asynchronously |
| 10:07 | <annevk> | and in a different origin in some browsers |
| 10:07 | <Lachy> | oh, yeah. |
| 10:07 | <annevk> | though that's a bug per HTML5 |
| 10:18 | <zcorpan> | about:blank is standards mode in opera |
| 10:19 | <hsivonen> | zcorpan: does it have a doctype? |
| 10:19 | <hsivonen> | zcorpan: bug or deliberate feature? |
| 10:19 | <annevk> | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> |
| 10:19 | <zcorpan> | i've only seen one minor bug about it, so maybe we can change it to standards mode in other browsers too |
| 10:19 | <annevk> | has a <title> too |
| 10:19 | <hsivonen> | that's interesting |
| 10:19 | <annevk> | "Blank page" |
| 10:20 | <annevk> | and the root element has dir set to rtl |
| 10:20 | <hsivonen> | annevk: is the string localized? |
| 10:20 | <annevk> | euh ltr |
| 10:20 | <annevk> | no idea |
| 10:20 | <hsivonen> | about:blank in Gecko has a doctype, too |
| 10:20 | <hsivonen> | but a quirky one |
| 10:21 | <zcorpan> | i think it would be nice if about:blank were standards mode |
| 10:21 | Philip` | wonders how OS X interprets the encoding of non-ASCII filenames on 8-bit-filename-filesystems (like FAT) |
| 10:22 | <workmad3> | about:blank checks as valid in FF as well |
| 10:22 | <workmad3> | or at least, it reckons it's valid in the w3c validator |
| 10:22 | <workmad3> | web dev toolbar in FF reckons it's quirky :/ |
| 10:23 | <annevk> | the validator is out of touch with reality |
| 10:25 | <hsivonen> | hmm. if I'm reading the code right, about:blank in Gecko has or doesn't have a doctype depending on how it got created |
| 10:25 | <hsivonen> | fun |
| 10:26 | <workmad3> | heh :) |
| 10:29 | <zcorpan> | hsivonen: can about:blank be changed to standards mode in gecko? |
| 10:30 | <hsivonen> | zcorpan: as in can authors change its mode or could a Gecko developer land code for changing it in the engine? |
| 10:38 | <othermaciej> | document.write()ing a doctype seems simple enough as a way to get standards mode |
| 10:38 | <othermaciej> | it doesn't depend on about:blank being synchronous in any way but it's convenient enough |
| 10:38 | <othermaciej> | I think there are compat reasons that about:blank has to be in quirks mode |
| 10:38 | <jgraham> | othermaciej: You have a somewhat unusual view of "simple enough" |
| 10:38 | <zcorpan> | hsivonen: the latter |
| 10:39 | <othermaciej> | jgraham: if you're about to poke at the DOM of a frame. doing someFrame.contentDocument.write("<!DOCTYPE html>") first seems prety simple to me |
| 10:39 | <zcorpan> | othermaciej: can you cite the compat reasons? |
| 10:39 | <othermaciej> | zcorpan: not offhand |
| 10:40 | <jgraham> | othermaciej: The incantation isn't hard once you know it; it is realising that that is the right incantation that is the non-simple part |
| 10:40 | <othermaciej> | sure |
| 10:40 | <othermaciej> | that would be true of any special incantation, other than changing the default |
| 10:40 | <othermaciej> | I wonder if about:blank in a standards mode document could be in standards mode |
| 10:41 | <othermaciej> | but I would not be surprised if there are standards-mode pages with about:blank iframes that they depend on being quirky |
| 10:41 | <hsivonen> | zcorpan: probably not, but you might a get a better answer from Boris. |
| 10:42 | <zcorpan> | othermaciej: it has not caused much of a problem for opera to always use standards mode |
| 10:44 | <annevk> | much of or no problem? |
| 10:44 | annevk | hasn't seen a thing |
| 10:48 | <zcorpan> | i've seen one bug where it caused unwanted top margin because we insert a <p> when pressing enter in contenteditable |
| 10:48 | <zcorpan> | which could either be solved by using quirks mode or by not using <p> |
| 10:49 | <zcorpan> | i think we might move away from <p> anyway |
| 10:52 | <hsivonen> | hmm. so is pageshow supposed to fire on initial page load, too, and not only when navigating back to a page in the back-forward cache? |
| 10:53 | <hsivonen> | apparently yes |
| 10:53 | <hsivonen> | and Gecko and WebKit either differ in handler support or in event firing |
| 10:53 | <zcorpan> | does pageshow use the Event interface? |
| 10:53 | <hsivonen> | dunno |
| 10:54 | <othermaciej> | I don't like how pageshow is defined |
| 10:54 | <othermaciej> | it makes it needlessly awkward to have code that *only* runs when restoring from b/f cache |
| 10:55 | <othermaciej> | if only one of "load" or "pageshow" fired, you could easily put code in one handler or both depending on whether it's one-time, every-time or restore-only initialization |
| 10:55 | <othermaciej> | not only that but "load" has to do complete initialization anyway, to support browsers that don't have "pageshow" |
| 10:56 | <othermaciej> | I believe I gave this complaint to the folks who first implemented these events for Gecko but they were unconvinced |
| 11:00 | <zcorpan> | not too late to change it |
| 11:00 | <hsivonen> | hasn't Gecko had a b/f cache for years already? |
| 11:10 | <othermaciej> | yes it has |
| 11:10 | <othermaciej> | I discussed it with the engineers working on it before it shipped, years ago |
| 11:11 | <othermaciej> | I'd suspect at this point a new event ("pagerestore"?) would be required |
| 11:11 | <othermaciej> | although I think it's hard to depend on "pageshow" always firing, and yet still be compatible with browsers that never fire it at all |
| 11:28 | <Lachy> | wtf? http://rebuildingtheweb.com/en/invitation-html5-team/ |
| 11:29 | <hsivonen> | Lachy: I guess he missed the design principle debates |
| 11:29 | <Lachy> | "The first phase in these debates is a challenge, from me to Ian Hickson [...] to debate me on the following topic: Error messages should be displayed for corrupt HTML5." |
| 11:30 | <hsivonen> | (as if showing errors were up to Hixie to decide) |
| 11:30 | <Lachy> | I guess I shouldn't be too surprised he's still pushing for draconian error handling in HTML, even though that debate has been over for years. |
| 11:30 | <annevk> | http://xkcd.com/386/ |
| 11:31 | <othermaciej> | who is this person? |
| 11:31 | <Hixie> | lachy: http://lists.w3.org/Archives/Public/www-archive/2010Jan/0009.html |
| 11:31 | <hsivonen> | othermaciej: the XStandard XML editor guy |
| 11:34 | <zcorpan> | i thought almost all discussion in public-html is about design principles/process/direction |
| 11:34 | <hsivonen> | weird. I no longer see his byline on xhtml.com |
| 11:34 | <zcorpan> | as about in-depth, well the threads are well indented at least |
| 11:35 | <annevk> | for some people standards is fun |
| 11:35 | <annevk> | for others it's process |
| 11:35 | <Hixie> | standards are a tool |
| 11:35 | <Hixie> | for getting interop |
| 11:35 | <Hixie> | nothing more, imho |
| 11:36 | <Hixie> | (sometimes they're not even the best tool for that job) |
| 11:36 | <annevk> | i meant working on standards |
| 11:36 | <Hixie> | oh working on standards is a lot of fun :-) |
| 11:37 | <Hixie> | especially when it's like-minded people working on things together |
| 11:37 | <Hixie> | it's less fun when it's people who disagree on the fundamental goals |
| 11:38 | <zcorpan> | down with people who disagree |
| 11:39 | <othermaciej> | I replied to his post (perhaps foolishly) |
| 11:39 | <zcorpan> | validator.nu shows error messages for corrupt html5 |
| 11:42 | <Lachy> | zcorpan, based on what he's previously said on the topic, he means for browsers to show error messages to users |
| 11:42 | <Lachy> | I responded to his post too. |
| 11:43 | <zcorpan> | Lachy: of course, but the post didn't say that :) |
| 11:49 | <jgraham> | http://vocamus.net/dave/?cat=25 seems interesting |
| 11:56 | <Hixie> | ok got it down to 157 bugs |
| 11:56 | <Hixie> | i was aiming for 150 |
| 11:56 | <Hixie> | but i started about 20 higher than i expected to start |
| 11:56 | <Hixie> | so i'll call this a qualified success |
| 11:56 | <Hixie> | good night |
| 12:03 | <othermaciej> | good nigh |
| 12:03 | <othermaciej> | t |
| 12:07 | <annevk> | nn |
| 13:38 | <jgraham> | Heh |
| 13:38 | <jgraham> | I obviously shouldn't have replied |
| 13:38 | <annevk> | me neither I think |
| 13:38 | <annevk> | but I did |
| 13:39 | <annevk> | I'm already worried about flames |
| 13:39 | <hsivonen> | I have to wonder if were baited to reply accidentally or intentionally |
| 13:40 | <annevk> | quite surprising how much we're aligned on certain points |
| 13:41 | <hsivonen> | evidence of groupthink! |
| 13:41 | <annevk> | heh |
| 13:41 | <annevk> | might be |
| 13:42 | <annevk> | earlier today when I discussed that email with othermaciej neither of us mentioned a view point but we both knew it was the same |
| 13:42 | <TabAtkins> | Pretty sure it was an intentional baiting. |
| 13:42 | <annevk> | it struck me a little later how convenient that was |
| 13:47 | <othermaciej> | the "Browser implementations" thread? |
| 13:48 | <Lachy> | othermaciej, yeah, I think so |
| 13:49 | <othermaciej> | I don't see evidence of baiting (not really sure what we were baited into if so) |
| 13:50 | <jgraham> | I think the supposed baiting was the suggestion that only released specs contribute to the legacy |
| 13:50 | <Lachy> | re the autobuffer thread, I'm not entirely convinced that making autobuffer itself a tri-state attribute (on/off, or absent) is impossible, despite it being boolean in Firefox 3.5 |
| 13:51 | <jgraham> | But I'm not really sure that it was baiting (I'm not sure what the point would be) |
| 13:52 | <jgraham> | Lachy: Agreed but I don't really see the value in taking the risk |
| 13:52 | <othermaciej> | Firefox has pretty high uptake on updates |
| 13:52 | <Lachy> | since autobuffer is, I believe, currently only implemented in Firefox, and its omission currently has the same effect as autobuffer=off should have, then authors can simply omit the attribute for the relatively short transition from FF 3.5 to 3.6 |
| 13:53 | <othermaciej> | there are advantages and disadvantages to reusing autobuffer vs. minting a new buffer attribute |
| 13:53 | <Lachy> | so, if 3.6 supported autobuffer as tri-state, then the issue would not have serious long term consequnces |
| 13:53 | <othermaciej> | a new buffer attribute could be more clear and would have less risk of legacy conflict, but at the same time it might leave us stuck with two attributes |
| 13:53 | <othermaciej> | I'm planning to list both options when I file the bug |
| 13:53 | <jgraham> | I think we could obsolete autobuffer at this stage |
| 13:54 | <Lachy> | of course, using buffer="..." as tri-state, and obsoleting autobuffer would also be acceptable to me |
| 13:55 | <Lachy> | I don't think there is significant content out there relying on autobuffer for it to be impossible to remove once buffer="" is more widely supported |
| 13:55 | <annevk> | autobuffer can easily be removed |
| 13:55 | <annevk> | that was never the concern |
| 13:55 | <annevk> | afaict |
| 13:56 | <hsivonen> | Lachy: Gecko 1.9.2 is in RC in mobile. changes to the engine feature set are highly theoretical at this point |
| 13:57 | <Lachy> | also, I'm slighly less convinced about the need for tri-state buffering, until I've seen more evidence about what sort of heuristics browsers can realistically apply when the attribute is absent to make it significantly different from the no-buffering case. |
| 14:22 | <annevk> | othermaciej, did you file a bug on <img>.x/y |
| 14:23 | <annevk> | or can they can be nuked from the browsers |
| 14:24 | <othermaciej> | annevk: I don't know what that is |
| 14:24 | <othermaciej> | annevk: is it something we're missing? |
| 14:24 | <annevk> | it is something that's not in Opera of which we have a old bug report from 2007 or so about a compat issue |
| 14:24 | <annevk> | it is apparently in Firefox and WebKit |
| 14:25 | <annevk> | according to the bug "These properties are respectively the left offset and top offset relative to the viewport borders." |
| 14:25 | <annevk> | that sounds somewhat wrong terminology wise, but I guess you get the idea |
| 14:25 | <Huvet> | have anyone had any success with sending the lxml tree from html5lib to lxml.html.clean.Cleaner? |
| 14:26 | <Huvet> | I get a crash that _Element is missing a rewrite_links method |
| 14:30 | <virtuelv> | Image.x = The X coordinate of the image within the client display area. |
| 14:31 | <jgraham> | Huvet: That sounds like a difference between lxml.etree._Element and lxml.html.)Element or something |
| 14:31 | <virtuelv> | Have browsers nuked Image.vspace/hspace yet? |
| 14:31 | <annevk> | no :/ |
| 14:32 | <annevk> | and othermaciej is advocating lots of more cruft I found out today! |
| 14:32 | <Huvet> | jgraham: Ah, I assumed that an lxml.etree was always the same... I'll have a look |
| 14:32 | <virtuelv> | properties found in my ancient Wrox reference: |
| 14:32 | <virtuelv> | border, complete, constructor, defaultValue, height, hspace, lowsrc, name, size, src, vspace, width, x, y |
| 14:32 | <virtuelv> | and select() |
| 14:33 | <othermaciej> | annevk: Im not familiar with <img>.x/y, if you would like I can search through history and see if I can find why it was added |
| 14:33 | <othermaciej> | annevk: what cruft am I advocating? |
| 14:33 | <virtuelv> | <img>.x was first added in Netscape 3 |
| 14:33 | <annevk> | just the bugs you filed on even more interfaces for legacy elements :) |
| 14:35 | <annevk> | like HTMLAnchorElement.text |
| 14:35 | <virtuelv> | <a>. accessKey, dataFld, dataSrc, hash, host, hostname, href, Methods, mimeType, nameProp, pathname, port, protocol, protocolLong, rel, search, tabIndex, target |
| 14:35 | <annevk> | hmm, doesn't IE have a .text attribute for all elements? |
| 14:35 | <virtuelv> | dataFld/Src? |
| 14:37 | <Philip`> | virtuelv: They're a sort of client-side templating thing in IE (and in the HTML4 DTD) |
| 14:38 | <Philip`> | Fortunately approximately nobody uses that feature |
| 14:39 | <virtuelv> | some data binding thing, according to MSDN |
| 14:40 | <virtuelv> | I wonder if there's other, long-forgotten stuff this reference lists |
| 14:41 | <Philip`> | (I think I found one site that used the feature for real (to generate a list of cars from an XML data source), out of about half a million pages) |
| 14:41 | <virtuelv> | IMG.fileModifiedDate (Property) |
| 14:42 | <virtuelv> | iccProfile, fileSize, start |
| 14:43 | <virtuelv> | loop and dynSrc as well |
| 15:37 | <MikeSmith> | zcorpan: fyi, initial attempt at <script src=""></script> checking is live on qa-dev |
| 15:54 | <zcorpan> | MikeSmith: cool |
| 15:57 | <zcorpan> | MikeSmith: seems to work from quick testing |
| 16:03 | <Lachy> | Hixie, why does the complete version of the spec still have a version number in its title "Web Applications 1.0", given that the other version is now just called "WHATWG HTML" without a specific version? |
| 16:09 | <zcorpan> | why is it "WHATWG HTML" instead of just "HTML"? |
| 16:11 | <Lachy> | I think that's just to help distingish it from the subset of HTML currently being developed in W3C. Though, I don't feel strongly either way about it. |
| 16:50 | <Philip`> | How does replacing the boolean autobuffer attribute with a new enumerated attribute that has two values help with the problem of how browsers will react to new values they haven't heard of before? |
| 16:51 | <workmad3> | Philip`: allows them to die a bit more gracefully? :) |
| 16:51 | <Philip`> | (Is it just that having new values defaulting to don't-buffer is better than defaulting to do-buffer? Doesn't that depend on what the new values are going to be, which we don't know yet?) |
| 16:52 | <Philip`> | workmad3: I'm not sure I'd ever consider death to be graceful |
| 16:52 | <jgraham> | Philip`: I assume defaulting to more conservative behaviour is better |
| 16:53 | <jgraham> | (iundependent of what the less conservative options are) |
| 16:53 | <Philip`> | jgraham: i.e. defaulting to behaviour that harms the typical user experience by not buffering and delaying their enjoyment when they want to watch the video? |
| 16:53 | <workmad3> | I'd figure it makes it easier to expand future versions in a backwards compatible manner though |
| 16:54 | <Philip`> | jgraham: Seems like neither option is really "better", they all have drawbacks and people could complain either way |
| 16:54 | <jgraham> | Philip`: I think lots of flash0using sites already do no autobuffering so it can't be that bad for user experience |
| 16:54 | <workmad3> | adding a new value to the values available is less disruptive than changing the attribute to an enumeration and also adding a new value |
| 16:55 | <jgraham> | s/0/-/ |
| 16:56 | <workmad3> | imagine the complaints if the standard changed from 'autobuffer="autobuffer" ' enabling autobuffering to that being a non-valid value and therefore disabling it |
| 16:56 | <workmad3> | so betting that the attribute starts off with 'autobuffer="on" ' to enable it and never needing to change :) |
| 16:57 | <jgraham> | workmad3: I'm imagining the complaints and I can't really see them being that bad |
| 16:57 | <jgraham> | You simply make <video autobuffer> spec-wise identical to <video> |
| 16:57 | <workmad3> | true... not as bad as if it were the other way around |
| 16:58 | <jgraham> | and then people who really want autobuffering in FF3.5 just add the invalid attribute (in addition to the new attribute for other UAs) |
| 16:59 | <annevk> | Hixie, people are complaining about mozillaquestquest.com to me |
| 17:27 | <annevk> | foolip, if we have a new attribute that might support multiple states going forward but is currently just a flag there does not seem to be a need for more than one value |
| 17:28 | <annevk> | (the other value is simply omitting the attribute) |
| 17:56 | <TabAtkins> | Crap, maybe I shouldn't have gotten a computer upgrade. Now my dropdown menus are smooth as silk. At least before I could be reasonably assured that my customers had a computer equal to or better than mine, and so would have an equal or better experience. |
| 18:53 | <ehird> | which is correct: <article>...<section class="comments">...</section></article> or <article>...</article><section class="comments">...</section>? |
| 18:56 | <AryehGregor> | ehird, "For instance, a blog entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the blog entry." |
| 18:56 | <AryehGregor> | http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-article-element |
| 18:56 | <ehird> | OK. Just seemed weird to consider comments part of the article itself, to me. |
| 18:56 | <AryehGregor> | So the way the spec suggests is <article>...text of article... <article>comment 1</article> <article>comment 2</article>...</article> |
| 18:56 | <AryehGregor> | The idea is to suggest that they're related to it, I guess. |
| 18:57 | <AryehGregor> | It does seem awkward for CSS. |
| 22:30 | <gsnedders> | http://www.molly.com/2010/01/05/bob-dylan-meets-html5/ |
| 22:53 | <virtuelv> | gsnedders: I'd rather have hoped Dylan himself would write of it |
| 22:53 | <virtuelv> | But I'll settle for the Dylan christmas songs I bought a few weeks ago |
| 23:36 | <Hixie> | anyone know anything about nested iframes andonbeforeunloads? |
| 23:36 | <Hixie> | er |
| 23:36 | <Hixie> | "and onbeforeunload?" |
| 23:45 | <cardona507> | dylan meets html5 - sheesh :-/ |