| 00:00 | <gsnedders> | cardona507: No, there is no solution. |
| 00:01 | <cardona507> | too bad |
| 00:01 | <cardona507> | thanks gsnedders |
| 00:01 | <gsnedders> | (on the basis that vendor-specific stuff is bad) |
| 00:01 | <cardona507> | i understand |
| 00:02 | <eighty4> | hey, up late gsnedders :) |
| 00:02 | <gsnedders> | eighty4: Just got home :) |
| 00:02 | <gsnedders> | eighty4: Been over in Lambohov (sp?) |
| 00:03 | <eighty4> | so you can answer a question. Is it more proper to wrap a blogposts <p>s with a div or a section? |
| 00:03 | <eighty4> | sp? |
| 00:03 | <gsnedders> | spelling |
| 00:04 | <eighty4> | Lambohov is correct, I think |
| 00:11 | <eighty4> | gsnedders: and what happend at lambo? |
| 00:12 | <gsnedders> | eighty4: Just out at colleague's flat |
| 00:14 | <eighty4> | nice |
| 00:14 | <eighty4> | oh, there's a html5 watcher at twitter. My "HTML5 is missing a <comments> tag got a replay :P |
| 00:18 | <gsnedders> | eighty4: Quite a few of us watch that, to varying degrees of attentiveness |
| 00:19 | <eighty4> | :) |
| 00:20 | <Dashiva> | Hypothesis: The main use case for google alerts is Hixie |
| 00:25 | <gsnedders> | Sounds plausible. |
| 00:29 | <gsnedders> | eighty4: I used to follow it until it got to the point where it was impossible to keep up with |
| 00:29 | <gsnedders> | eighty4: When it was one tweet every 15 minutes or so, I could cope. Now it's closer to one per minute. |
| 00:31 | <gsnedders> | eighty4: Anyhow, what would the use of <comments> be? |
| 01:31 | <cardona507> | is it possible to have the <canvas> width be fluid? |
| 06:25 | <Hixie> | jgraham: w3c copy is hanging again if you're around and care to investigate |
| 06:31 | <Hixie> | ok every time i break down and complain, it starts working again |
| 07:04 | <hamaji> | Hixie: are there any scripts which generated ahem font? |
| 07:04 | <hamaji> | Hixie: i found this, but it's 500 http://hixie.ch/resources/fonts/iw-generator.py |
| 07:46 | <eighty4> | gsnedders: the use of it would be in my blog theme, so that I wouldn't have to use a list for comments :D |
| 08:01 | <Hixie> | hamaji: ahem font was made by hand |
| 08:01 | <Hixie> | in a font editor |
| 08:03 | <eighty4> | Hixie: you're saying not all fonts are made by hand? |
| 08:04 | <Hixie> | eighty4: some of the test fonts i use are created by a script, as hamaji pointed out |
| 08:05 | <eighty4> | Hixie: you're no fun :/ |
| 08:15 | <Adrian__> | Hixie: Hello! Im pretty new to all this web protocol stuff and until recently I had no idea that there was so much politic behind the internet! im hoping you can tell me a little about HTML5 and more specifically WebSocket |
| 08:16 | <Hixie> | anything in particular? |
| 08:16 | <Adrian__> | well just the jist of it and a point in the right direction so i can learn more |
| 08:16 | <Hixie> | and hi, welcome :-) |
| 08:17 | <Adrian__> | i worked with orbited, porting tcpsocket to flash |
| 08:17 | <Hixie> | best place to get up to speed is probably the FAQ: http://wiki.whatwg.org/wiki/FAQ |
| 08:17 | <Hixie> | for the overall view |
| 08:17 | <Hixie> | if you have any specific questions, though, i'd be more than happy to answer them |
| 08:18 | <Adrian__> | yah sure thanks |
| 08:18 | <Adrian__> | what time are you usually on here? |
| 08:19 | <Hixie> | anytime except about 6am to 11am US west coast time |
| 08:21 | <Hixie> | (my waking hours vary a lot) |
| 08:32 | <Adrian__> | Hixie: Do you know how far along WebSocket is? |
| 08:32 | <Adrian__> | could i write a client right now? |
| 08:32 | <Adrian__> | are there any demos out there you know of? |
| 08:32 | <Hixie> | a craw lient, or a web page using the api? |
| 08:32 | <Hixie> | a raw client, rather |
| 08:33 | <Hixie> | there's work going on for safari, chrome, and firefox, i think |
| 08:33 | <Hixie> | they're probably waiting to see what happens with the spec |
| 08:34 | <Hixie> | and there's a server implementation for apache or something, iirc |
| 08:34 | <Hixie> | other than that, nothing much yet |
| 08:34 | <Adrian__> | so i couldnt get anything to work in a browser right now? |
| 08:34 | <Hixie> | the spec is pretty stable though, i think |
| 08:34 | <Hixie> | not any shipping browsers, no |
| 08:34 | <hamaji> | Hixie: i see... thanks! |
| 08:35 | <hamaji> | Adrian__: i tried a flash implementation of websockets and it worked nicely http://github.com/gimite/web-socket-js |
| 08:36 | <Adrian__> | so i could put a flash app on a web page? |
| 08:40 | <hamaji> | this library provides standard js api of websocket, but it's implemented by flash. so, though you can write js to use websocket, but you need to put WebSocketMain.swf in your server. i think it's good as a preview of websocket for now |
| 08:50 | <Adrian__> | hamaji: does ruby work on windows? |
| 08:54 | <hamaji> | Adrian__: sometimes i use ruby with cygwin, and there are non-cywin implementations as well |
| 08:55 | <hamaji> | Adrian__: also, if you prefer python, there is a websocket server in python http://code.google.com/p/pywebsocket/ |
| 08:55 | <Adrian__> | heh yah ty |
| 08:55 | <Adrian__> | thatlll probably be easier |
| 10:30 | <MikeSmith> | Hixie: I'm looking at r4152.. "remove reversed DNS label support from microdata".. wondering why you mad that change |
| 10:32 | <Hixie> | http://lists.w3.org/Archives/Public/public-html/2009Oct/0536.html |
| 10:34 | <MikeSmith> | Hixie: "if aesthetics are important then authors will presumably use itemtype and short property names" is the actual rationale I guess |
| 10:34 | <Hixie> | people didn't seem to have trouble with URLs much |
| 10:35 | <MikeSmith> | yeah |
| 10:35 | <Hixie> | (contrary to what i expected) |
| 10:36 | <MikeSmith> | given that in the vast majority of use cases (regardless of the syntax), this stuff is going to be generated by some kind of CMS anyway |
| 11:17 | <gavin> | http://gavinsharp.com/irc/whatwg.html |
| 11:17 | <gavin> | just added #whatwg to my daily stats cronjob |
| 11:17 | <Hixie> | oh dear |
| 11:17 | <gavin> | should have thought of it sooner! |
| 11:18 | <Hixie> | hey now that's not fair, i look like i've chatted a lot, but people like anne have their stats split across a bazillion nicks |
| 11:18 | <gavin> | I can fix that |
| 11:19 | <Hixie> | lol, krijnh got the :-) bonus and krijn got the sadness bonus |
| 11:20 | <Hixie> | words #1 #3 and #6 were would, should, and could respectively |
| 11:21 | <Hixie> | gavin: what time zone is the chart at the top? |
| 11:22 | <Hixie> | that's actually useful data |
| 11:22 | <gavin> | "time in Toronto" |
| 11:22 | <gavin> | EDT or EST, depending |
| 11:22 | <Hixie> | -5? |
| 11:22 | <gavin> | yeah |
| 11:22 | <gavin> | I guess it isn't consistent |
| 11:23 | <Hixie> | so we have peaks at around midnight and noon UTC? or 10am and 10pm, i can't quite work out which way to send those numbers |
| 11:24 | <gavin> | 10&10 |
| 11:24 | <Hixie> | so 3am on your chart is my midnight, roughly |
| 11:24 | <Hixie> | ok |
| 11:24 | <gavin> | yeah |
| 11:24 | <Hixie> | so 8pm to midnight is when the channel has least traffic, interesting |
| 11:25 | <Hixie> | ok |
| 11:26 | <jgraham> | I'm slightly surprised that zcorpan has said more than me |
| 11:27 | <Hixie> | jgraham: btw, the status annotator has been very flaky ever since they changed their site |
| 11:27 | <Hixie> | i have to give two or three tries each time i regen the spec |
| 11:28 | <jgraham> | Hixie: Oh. I wonder if they hve made their site very slow |
| 11:28 | <jgraham> | Or at least slower than it was before |
| 11:29 | <jgraham> | Hixie: you should encourage mjs to fix the problem by resolving all the issues :) |
| 11:30 | <jgraham> | I guess I should look seriously at caching some of the data |
| 11:32 | <jgraham> | (well in addition to the HTTP caching which doesn't seem to be having any effect) |
| 11:37 | <gavin> | I just regenerated the stats with some aliases added |
| 11:37 | <gavin> | annevk made it to second place, and zcorpan's ever further ahead of jgraham now :) |
| 11:38 | <Hixie> | :-) |
| 11:54 | <mikekelly> | caching? |
| 11:55 | <mikekelly> | I hope you can provide some data as evidence that caching is a good idea |
| 11:56 | <mikekelly> | this is science |
| 13:21 | <Lachy> | I'm a little disappointed I only got 5th place in the rankings :-( |
| 13:21 | <Lachy> | oh |
| 13:21 | <Lachy> | well, |
| 13:21 | <Lachy> | I |
| 13:21 | <Lachy> | can |
| 13:21 | <Lachy> | fix |
| 13:21 | <Lachy> | that |
| 13:21 | <Lachy> | :-) |
| 13:26 | <erlehmann> | Lachy, which rankings? |
| 13:27 | <erlehmann> | ah wait |
| 13:27 | <erlehmann> | i got it |
| 13:27 | <erlehmann> | brace for |
| 13:27 | <erlehmann> | IMPACT :D |
| 13:41 | gsnedders | is surprised at some of the people he's above there |
| 14:05 | gsnedders | wonders how long he needs to leave to change between two Schengen flights at Schiphol… |
| 15:05 | <Lachy> | gsnedders, it depends if you need to collect luggage and re-check it in, or go through a passport check between flights. |
| 15:07 | <Lachy> | if you're switching from an international flight to a domestic flight, then I believe you would have to at least pick up luggage and re-check it in |
| 15:33 | Philip` | clearly spends too much time on IRC :-( |
| 15:34 | <AryehGregor> | "this 1049-day reporting period" |
| 15:34 | <AryehGregor> | And I'm still in 27th place, despite having used this nick for only like . . . a month? |
| 15:37 | Philip` | is apparently "Hixie's faithful follower" |
| 15:41 | <Philip`> | Could I say "HTML5 really seems something which people should think would" and take over the entire "Most used words / Last Used by" column? |
| 15:46 | AryehGregor | always wants to stab someone when he sees ">From" at the beginning of a line in an e-mail, and it's not a quote. |
| 15:46 | <AryehGregor> | THIS IS NOT 1995. THERE ARE BETTER STORAGE FORMATS THAN MBOX AVAILABLE. |
| 15:47 | <AryehGregor> | Including trivial variants like mboxrd that don't corrupt mail. |
| 15:52 | <gsnedders> | Lachy: If your checked in through, and by "Schengen" I was meaning the Schengen Agreement, I treaty which led to the removal of border controls. |
| 15:54 | <Lachy> | where are you travelling from and to? |
| 15:57 | <Lachy> | anyway, if you're sure you won't need to collect luggage, then you should only need to leave an hour, but that also assumes there are no unexpected delays for your first flight |
| 16:08 | <gsnedders> | Lachy: Linköping to Lyon |
| 16:08 | <gsnedders> | Lachy: I have a choice of 40 mins to change planes, or 5 hours. |
| 17:13 | <Lachy> | gsnedders, ask the airline customer service if 40 min is enough. |
| 17:22 | <AryehGregor> | "My main concern with namespaces is that people would use them." |
| 18:11 | <TabAtkins> | Hah, I love the IRC stats at http://gavinsharp.com/irc/whatwg.html |
| 18:12 | <TabAtkins> | Somehow, despite it measuring over a 3-year period and me only really joining the room a month or two ago, I'm already the 17th most prolific chatter. |
| 18:14 | <TabAtkins> | Had it been generated like the previous week, I'd definitely be #16, since mookid is just *barely* ahead of me. |
| 19:07 | <annevk42> | gsnedders, fourty minutes is plenty |
| 19:07 | <annevk42> | if it's the same airline company anyway |
| 19:42 | <gsnedders> | annevk42: k, thx |
| 19:57 | <gsnedders> | What effect does the frameset-ok flag have? |
| 19:59 | <Philip`> | If it's not set, framesets might not be ok |
| 19:59 | Philip` | is just guessing here |
| 20:02 | <gsnedders> | OK, so (ignoring fragment case) frameset is ignored in body if it is false, and otherwise the body element is removed from its parent and from the stack and a frameset element is added |
| 20:04 | <gsnedders> | How do I make sure I get the errors in an html5lib test right? |
| 20:05 | <Philip`> | I think you can only test the number of errors, not their positions or values |
| 20:05 | <Philip`> | using the normal tree-construction test format |
| 20:05 | <gsnedders> | So the strings themselves are meaningless? |
| 20:06 | <Philip`> | Yes, since the tests are meant to be portable between implementations and error strings are not portable |
| 20:06 | <Philip`> | as far as I'm aware |
| 20:06 | <gsnedders> | As far as I can tell, the Python impl doesn't even check the number |
| 20:07 | <Philip`> | self.assertEquals(len(p.errors), len(errors), errorMsg2.encode("utf-8")) |
| 20:07 | <Philip`> | Isn't that it? |
| 20:08 | <gsnedders> | I just added five more lines of errors to one test and it still passes. |
| 20:09 | <Philip`> | #Run the parse error checks |
| 20:09 | <Philip`> | checkParseErrors = False |
| 20:09 | <gsnedders> | Oh great. |
| 20:10 | <gsnedders> | Wow. Absolutely tons of failures with that true. |
| 20:11 | <gsnedders> | Philip`: errorMsg2 seems to try and contain the expected strings |
| 20:12 | <Philip`> | http://code.google.com/p/html5lib/source/diff?spec=svn84ba7e9cfe61830f13ef4f354b24397332386a39&r=84ba7e9cfe61830f13ef4f354b24397332386a39&format=side&path=/python/tests/test_parser.py |
| 20:13 | <Philip`> | It defaults to False, and the -p command-line option sets it to False |
| 20:13 | <Philip`> | Something's definitely dodgy there |
| 20:13 | <Philip`> | I don't see why it shouldn't always be enabled |
| 20:13 | <gsnedders> | I think it always should |
| 20:13 | <Philip`> | gsnedders: It prints the strings for debugging, it doesn't compare the strings |
| 20:13 | <gsnedders> | A lot more tests need to pass if it is enabled though |
| 20:14 | <Philip`> | Removing test assertions is not the bestest way to get high test pass rates |
| 20:14 | <gsnedders> | Indeed. |
| 20:16 | jgraham | has the alternative theory that we should stop reporting parse errors |
| 20:17 | <jgraham> | Or loging them rather |
| 20:17 | <Philip`> | Why? |
| 20:17 | <gsnedders> | jgraham: Until we drop support, it should work. |
| 20:18 | <jgraham> | Roughly no one cares, it adds complexity and probably a small but noticble amount of performance |
| 20:18 | <gsnedders> | 247 test failures with them enabled, 0 with them disabled. |
| 20:18 | <jgraham> | Especially since it constrains the implementation |
| 20:18 | <jgraham> | (so it prevents useful refactorings) |
| 20:19 | <Philip`> | It seems like it would help detect subtle bugs where the wrong code-path is executed but it gives the same tree output (but different error messages) |
| 20:19 | <Philip`> | but maybe that's untrue |
| 20:19 | <Hixie> | shelley is a wg member again! |
| 20:19 | <jgraham> | Philip`: Since no one looks at the error messages anyway I doubt it helps |
| 20:19 | <Philip`> | s/different error/different number of error/ |
| 20:20 | <jgraham> | I believe to date we have had exactly 0 bug reports about the error reporting |
| 20:21 | gsnedders | makes yet another commit |
| 20:21 | <Philip`> | gsnedders: Don't commit so much, or hg will run out of SHA1s :-( |
| 20:21 | <jgraham> | And I don't recall it finding significant bugs other than just "forgot to report an error" |
| 20:23 | <jgraham> | (In case you are wondering I would bet that I switched off the parse error reporting when adding the namespace support since I wanted to fix important bugs before trivial pedantic things) |
| 20:24 | <jgraham> | (but I guess you can check if you like) |
| 21:04 | <GPHemsley> | Am I the only one who sees the importance of exposing and processing the contents of @lang? |
| 21:33 | Philip` | wonders if getElementsByTagNameNS("http://example.org/widgets/";, "*") would really provide any practical performance benefits over querySelector("widget-foo, widget-bar, widget-baz") |
| 21:53 | Hixie | looks cross-eyed at public-html |
| 21:53 | <Hixie> | are we really talking about making HTML say that Microsoft can invent tags at random? |
| 21:53 | <Hixie> | what happened to people being upset about <marquee> and <blink>? |
| 21:54 | <AryehGregor> | Well, the spec already sort of says that for the XML serialization, doesn't it? You're allowed to use other namespaces there, IIRC. |
| 21:54 | <jgraham> | Apparently if it had been http://microsoft.com/happy/shiny/namespaces/holding/hands::marquee then everything would have been hunky-dory |
| 21:54 | <Hixie> | AryehGregor: it only allows elements that are allowed by an appropriate spec |
| 21:58 | <AryehGregor> | Hixie, so why is everyone saying stuff like "Non-colon-based stuff would be better" instead of "We don't want more <marquee>s"? |
| 21:59 | <TabAtkins> | Because nobody would use <com_microsoft_marquee> anyway, unless it was *really* useful, in which case everyone really should adopt it. If you have to allow bad things, making them hard to is good. |
| 21:59 | <Philip`> | AryehGregor: Because non-colon-based stuff would be better |
| 21:59 | <Philip`> | since it wouldn't pollute the language with colons and associated complexities and weirdnesses and incompatibilities |
| 22:00 | <Philip`> | (Being better doesn't mean it's good, though) |
| 22:00 | <Philip`> | (but if someone's going to do bad things anyway, it seems sensible to limit the damage the cause) |
| 22:00 | <jgraham> | Non colon based stuff would be better. But not making it easy to invent single-implemtation features with no clear path for standarisation would be best |
| 22:00 | <Philip`> | s/the cause/they cause/ |
| 22:02 | <jgraham> | (because, as has been previously pointed you can't really have <com_microsoft_wordart> and a w3c-endorsed <wordart> on the same page so there is no way to transition away from the prefixes) |
| 22:02 | <jgraham> | (unlike with css properties or DOM functions or similar) |
| 22:02 | <TabAtkins> | jgraham: Why can't you have them both on the same page? |
| 22:03 | <jgraham> | TabAtkins: Well you can but you can't make them mutually exclusive |
| 22:03 | <jgraham> | For the same content |
| 22:03 | <jgraham> | (in general) |
| 22:03 | <Hixie> | AryehGregor: beats me |
| 22:03 | <TabAtkins> | Oh, I see. Like CSS's ability to put "-moz-foo" and follow it with "foo". |
| 22:04 | <jgraham> | TabAtkins: Right |
| 22:04 | <TabAtkins> | That's sort of bad anyway, because it just makes me copy the contents of "-moz-foo" into "foo", which won't work if the syntax changes in the official implementation. Transitioning off of prefixes is always painful. |
| 22:04 | <Hixie> | TabAtkins: consider <canvas>, it'd be even more painful with HTML than in CSS |
| 22:04 | <jgraham> | I mean with the wordart example it might, possibly, work to do <com_microsoft_wordart><wordart>Village Fete!</></> |
| 22:04 | <jgraham> | (but with real closing tags obviously) |
| 22:05 | <jgraham> | But it might not |
| 22:05 | <jgraham> | With canvas it would be a real pain |
| 22:05 | <TabAtkins> | I see, so you'd have to do an all-or-nothing transition over, or else risk legacy clients not getting the functionality. |
| 22:06 | <TabAtkins> | Which is strictly worse than just standardizing the original browser-specific name, which at least works in one browser while people transition to newer UAs. |
| 22:09 | <GPHemsley> | Hixie: Did you ever revert that ua/uk issue? |
| 22:09 | <TabAtkins> | Clearly this means we need some way of multi-naming an element, so the browser has a choice of which name it wants to use. <com_microsoft_wordart|com_moz_wordart|wordart>Village Fete!</> |
| 22:09 | TabAtkins | is not serious, though it would solve at least part of the problem. |
| 22:09 | <Hixie> | GPHemsley: yes, right after you said to :-) |
| 22:10 | <Hixie> | TabAtkins: that would be a security nightmare |
| 22:10 | <GPHemsley> | Hixie: Oh, OK. I never saw a tweet about it. That's why I asked. :) |
| 22:10 | <TabAtkins> | Indeed! |
| 22:10 | <TabAtkins> | It would be horrifying. Just saying, that's basically how CSS's prefixed properties work. The browser just ignores all the properties it doesn't want to pay attention to. |
| 22:12 | <AryehGregor> | Someone needs to make a JavaScript validator. |
| 22:13 | <AryehGregor> | That will guess whether your JS is standards-compliant. |
| 22:13 | <AryehGregor> | (guess because of halting problem, natch) |
| 22:13 | <TabAtkins> | Or better would be some way of indicating that an element is 'experimental' and can be ignored if the browser wants. <wordart><com_microsoft_com wordart experimental>Village Fete!</></> |
| 22:13 | <AryehGregor> | Nobody pays any attention to JS validity, only HTML/CSS validity, presumably because JS doesn't have validators. |
| 22:14 | <TabAtkins> | Or, hrm. Man, translating this into HTML is hard. |
| 22:14 | <TabAtkins> | AryehGregor: Something like jslint doesn't go far enough? |
| 22:14 | <AryehGregor> | jslint is for checking code quality more than standards compliance, isn't it? |
| 22:14 | <TabAtkins> | Also, I *totally* screwed up the proprietary tag in the last example. |
| 22:15 | <TabAtkins> | AryehGregor: Yeah, but what standards are talking about? |
| 22:15 | <AryehGregor> | ECMAScript, DOM, HTML5, . . . |
| 22:16 | <TabAtkins> | Oh, so like if you're using properties that actually exist in the relevant standard? |
| 22:16 | <Hixie> | GPHemsley: it was editorial so it didn't get tweeted on @WHATWG -- if you want all the tweets, @HTML5 has all the HTML5 ones. There's no twitter for all the edits ever, though. |
| 22:16 | <Hixie> | GPHemsley: there's a mailing list for those if you want them though |
| 22:18 | <roc> | AryehGregor: it's a lot easier to validate declarative content than a program |
| 22:18 | <AryehGregor> | Yeah, I know. |
| 22:18 | <jcranmer> | is HTML 5 in last call? |
| 22:18 | <AryehGregor> | "A lot easier" meaning "not impossible, unlike with a program". |
| 22:18 | <webben> | jcranmer: No. |
| 22:19 | <roc> | well |
| 22:19 | <jcranmer> | I misread something at some point in time, then |
| 22:19 | <AryehGregor> | But it should be possible to try *some* kind of validation of JavaScript. So it could say "definitely invalid", "definitely valid", "maybe valid" in some very restricted cases. |
| 22:19 | <roc> | there are some things you can validate about programs |
| 22:19 | <AryehGregor> | Right. |
| 22:19 | <roc> | and there are some things you can't validate about declarative markup |
| 22:19 | <AryehGregor> | True, like semantic usage. |
| 22:20 | <webben> | AryehGregor: You could sniff JS for likely mistakes. |
| 22:20 | <AryehGregor> | Right. |
| 22:21 | <Hixie> | jcranmer: few more days! |
| 22:21 | <jcranmer> | I'm arguing with someone who claims HTML 5 is... |
| 22:21 | <jcranmer> | " |
| 22:21 | <jcranmer> | In violation of what? "HTML 5" is just a sketchy draft, purported to mainly describe how browsers actually behave, more or less. Why would you treat it as if it were a standard? " |
| 22:21 | <AryehGregor> | Typical. |
| 22:21 | <Hixie> | jcranmer: it's a "draft standard" |
| 22:21 | <Hixie> | jcranmer: and it's more accurate and detailed than HTML4 |
| 22:21 | <Hixie> | jcranmer: has been for years |
| 22:22 | <jcranmer> | I know |
| 22:22 | <tantek> | except for all the new stuff ;) |
| 22:22 | <jgraham> | Experience suggests that you would treat it as a standard because it is the closest thing to a functional standard that exists in the HTML5 space |
| 22:22 | <AryehGregor> | CSS Text is a WD too, is that also "a sketchy draft . . . why would you treat it as if it were a standard?" |
| 22:22 | <webben> | jcranmer: Maybe the argument needs to be about something other than its "standards" status, and focus on the interoperability angle? |
| 22:22 | <AryehGregor> | jgraham, s/5//? |
| 22:22 | <jcranmer> | I'm specifically arguing about some of the text it says on "applet" |
| 22:22 | <jgraham> | AryehGregor: Indeed |
| 22:23 | <jcranmer> | specifically about the interaction between <applet> and display: none |
| 22:23 | <tantek> | jcranmer - applet's been deprecated for over a decade, why would you bother with it at all? |
| 22:23 | <webben> | tantek: Migrating away from applet is non-trivial. |
| 22:23 | <Hixie> | jcranmer: i just added that in the last few hours! |
| 22:23 | <Hixie> | webben: really? |
| 22:23 | <tantek> | webben - it's one checkbox in the browser for me. works great. |
| 22:24 | <jcranmer> | Hixie: really? |
| 22:24 | <Hixie> | jcranmer: yup |
| 22:24 | <webben> | Hixie: In my experience, yeah. |
| 22:24 | <Hixie> | jcranmer: if it's wrong, let me know |
| 22:24 | <jcranmer> | hmm, 5:39 AM |
| 22:24 | <Hixie> | webben: should be relatively simple, it just maps to <embed> basically. what's difficult? |
| 22:24 | <jcranmer> | apparently IE and FF 3.0.1 differ in that regard |
| 22:24 | <jcranmer> | er, IE 7 |
| 22:24 | <webben> | Hixie: I tried to migrate to "object". iirc. |
| 22:24 | <Hixie> | jcranmer: oh, that's possible, yes. FF devs in particular have told me that's a known bug. |
| 22:25 | <Hixie> | webben: oh well <object> in general is non-trivial |
| 22:25 | <jcranmer> | mostly because IE and everybody else seem to implement it differently |
| 22:27 | <TabAtkins> | Hmm, the <link itemref="foo"> idea seems interesting. Would make it usable faster. |
| 22:27 | <tantek> | Hixie, jcranmer, worse yet, anything that invokes plugins (e.g. object, embed) may be impacted by http://en.wikipedia.org/wiki/Eolas |
| 22:29 | jcranmer | prays for an in re Bilski blanket invalidation of software patents |
| 22:30 | <TabAtkins> | jcranmer: Me too. Sigh, me too. |
| 22:31 | <jcranmer> | doesn't help the H.264 patent problems, though, unless you kill DSP patents as well |
| 22:32 | <TabAtkins> | Can we just wish for the death of patents in general? |
| 22:32 | <AryehGregor> | No. |
| 22:32 | <AryehGregor> | Some things have enormous R&D costs and would be impossible to make without patents. |
| 22:33 | <AryehGregor> | Like drug research. Much though people hate on big pharma, it costs hundreds of millions of dollars to get a new drug approved, and the process requires publishing enough info that any competitor could make your new drug en masse for cheap. |
| 22:33 | <jcranmer> | hundreds of millions of dollars and years |
| 22:33 | <AryehGregor> | So the end of patents would be the end of private drug research as we know it. The same doubtless applies to a variety of other fields. |
| 22:34 | <AryehGregor> | Software is already protected by copyright, though, and there's the potential for massive lock-in. |
| 22:34 | <jcranmer> | first you have to find biological mechanisms, then you have to attack those mechanisms, introduce various chemicals, and then find efficient ways to manufacture complex organic compounds |
| 22:34 | <AryehGregor> | If Pfizer comes out with a great new treatment for X, and they dominate for five years, that doesn't stop them losing out to a new drug someone else comes out with that works better or is cheaper. |
| 22:34 | <TabAtkins> | AryehGregor: I really don't wanna get into arguments about the validity of patents in certain realms, but the short answer is that experience has shown that patents do *not* increase innovaction in the medical research market. |
| 22:34 | <jcranmer> | and then you get to go through years of multi-phase trials |
| 22:35 | <AryehGregor> | TabAtkins, how would research occur *at all* without patents? Who would pay for the trials? |
| 22:35 | <AryehGregor> | You'd have to redo the system, like have the government fund the trials. |
| 22:35 | <TabAtkins> | (Some countries persisted quite a while into the modern era without patents on medical research, so we can compare their previous rates of innovation with their current.) |
| 22:35 | <AryehGregor> | TabAtkins, innovation including paying for trials, or did they let companies do that in countries where they could turn a profit off them? |
| 22:36 | <AryehGregor> | It's not just a matter of innovation, it's also a matter of you have to run multiple trials of many thousands of people according to demanding standards . . . something has to pay for that. |
| 22:36 | <tantek> | AryehGregor - plenty of research happens on food nutrition and other non-patented substances. So someone is paying for them. Who cares about who is paying? Fact remains, such research does happen. |
| 22:36 | <TabAtkins> | AryehGregor: I'd have to look up details of the papers that have been cited, but like I said, not really wanting to get into that sort of discussion atm. |
| 22:36 | <AryehGregor> | tantek, most food research doesn't have to go through the same FDA approval process as prescription drugs. |
| 22:36 | <tantek> | AyrehGregor - same thing with common vitamins |
| 22:36 | <AryehGregor> | Of course, you could say we should get rid of that approval process, or greatly cut it back. |
| 22:37 | <AryehGregor> | That might be sensible. |
| 22:37 | <jcranmer> | well, considering the high costs of a failure in the approval process |
| 22:37 | <tantek> | the point is, that there are plenty of things that improve your health, combat sickness etc. that are researched that are not-patented |
| 22:37 | <tantek> | focusing on drugs is the wrong framing. focusing on health is the right framing. |
| 22:37 | <AryehGregor> | Well, I'm pointing specifically to prescription drugs, because they have a necessary baseline cost due to FDA approval. |
| 22:38 | <AryehGregor> | I'm not commenting on other things that might not have such large overhead for introducing new products. |
| 22:38 | <AryehGregor> | Those are a different story and might not benefit at all from patents. |
| 22:38 | <TabAtkins> | So, worst case, government pays for FDA-level approvals, once a drug has sufficient promise from privately-run trials. Shrug. That would prevent people from locking up medical research behind paywalls. |
| 22:39 | tantek | is a little surprised that the HTML5 patent disclosures http://www.w3.org/2004/01/pp-impl/40318/status#current-disclosures do not list http://en.wikipedia.org/wiki/Eolas |
| 22:40 | <cardona507_> | hello, I am trying to get appcache setup and I believe that I have it. The browser asks if it is ok to store data on my computer for offline use - and I have the .manifest serving up with the correct mime type. And I have all of the files in the cache manifest . but it isn't working - does anyone have any trouble shooting tips? |
| 22:40 | <tantek> | Hixie, are <object> and <embed> optional for UAs? Can they simply ignore them as empty elements? Or just "always" go to fallback content? Or only handle "native" support and simply never invoke any plugin code? (nevermind if this is practical or not, just wondering if HTML5 allows such "degenerate" treatment of those tags) |
| 22:41 | <Hixie> | AryehGregor: re your mail about ajax |
| 22:41 | <jcranmer> | software was for the most part only patentable in the US since 1994, from what I can tell |
| 22:41 | <Hixie> | AryehGregor: i think it's pretty easy to do it in ajax while being backwards compatible -- you'd just grab every click using a capture listener, and cancel the navigation |
| 22:42 | <Hixie> | AryehGregor: and instead XHR the page over, pushState() the new URL, and replace the contents of the old page with the new page using innerHTML |
| 22:42 | <Hixie> | AryehGregor: it's probably like a 20 lne script |
| 22:42 | <Hixie> | tantek: they are not required to support any plugins |
| 22:42 | <TabAtkins> | Hixie: that works if you're willing to replace the whole page. |
| 22:43 | <tantek> | Hixie - ok, that is good to know. Thanks for the summary. |
| 22:43 | <Hixie> | TabAtkins: you can do it with bits of the page too |
| 22:43 | <TabAtkins> | Hixie: If you're not, you'll have to duplicate content. |
| 22:43 | <Hixie> | TabAtkins: duplicate how? |
| 22:44 | <TabAtkins> | Hixie: Well, how are you doing it with bits? Either the server is trimming pages down to particular bits based on the request (ajax call tells it what bits it wants), or you're parsing/trimming the response client-side, which is complex. |
| 22:44 | AryehGregor | needs to read more of the HTML5 spec, but first needs to do the complex analysis homework that he planned to do . . . oh, 12 hours ago |
| 22:44 | <Hixie> | TabAtkins: trimming the response client-side is easy |
| 22:44 | <tantek> | Hixie, as long as plugins are optional for conforming UAs in HTML5, I don't reasonably believe that http://en.wikipedia.org/wiki/Eolas will become essential for HTML5. (IANAL and all that) Therefore I won't be filling out this form accordingly: http://www.w3.org/2004/01/pp-impl/40318/disclose |
| 22:44 | <TabAtkins> | ?_? Seriously? The best way I've seen so far is to load it into an iframe and pull chunks out. |
| 22:45 | <TabAtkins> | Which is suboptimal, since it runs scripts, requests resources, etc. that may not even affect the bits you're pulling out. |
| 22:45 | <Hixie> | TabAtkins: you do a querySelectorAll('.replace') on the current document, then for each element in that list, you do a getElementById() on the DOM of the XHRed document, and replace the element in the old doc with the element in the XHRed doc. |
| 22:45 | <TabAtkins> | Okay, so see previous response. |
| 22:45 | <Hixie> | for instance |
| 22:45 | <tantek> | BTW - it's amazing how much faster how many sites get if you uncheck "[ ] Enable plug-ins" |
| 22:46 | <Hixie> | tantek: i think you want #htmlwg, for that issue :-) |
| 22:46 | <tantek> | Thanks Hixie. I will strongly support the current position of HTML5 that supporting plugins is optional for conforming UAs. |
| 22:47 | <Hixie> | it'd be basically impossible for us to require support for plugins |
| 22:47 | <Hixie> | since we'd have to define binary interfaces for all platforms |
| 22:48 | <TabAtkins> | If you do the "build the XHRed document's DOM, and extract bits", that means a possibly substantial wait while images load, scripts run, etc. when all you want is a particular chunk of content. |
| 22:48 | <TabAtkins> | For a js-heavy site, the kind that benefits most from being a single-page app, this will *always* be relatively substantial. |
| 22:49 | <Hixie> | TabAtkins: no scripts or images load when doing XHR |
| 22:49 | <TabAtkins> | (In my own hack-support for @onlyreplace, I'm going to mangle script and img elements on the page, then unmangle them for the bits that I'm replacing.) |
| 22:49 | <TabAtkins> | Hixie: When you build the DOM they do, certainly? |
| 22:50 | <GarethAdams|Home> | TabAtkins: external resources are only loaded when loaded into the DOM, an XHR isn't loaded into the DOM (it's just a external request) |
| 22:50 | <GarethAdams|Home> | *into the windowed document |
| 22:51 | <TabAtkins> | GarethAdams|Home: But to do what Hixie is saying you have to turn the XHR response into a separate DOM so you can yank chunks out of it. |
| 22:51 | <TabAtkins> | Which should, unless I'm wrong, download/execute linked resources. |
| 22:51 | <TabAtkins> | (If I am wrong, that's weird, but helpful.) |
| 22:52 | <GarethAdams|Home> | yes, I corrected myself, the DOM of an XHR isn't the same as the DOM of window.documentElement |
| 22:52 | <GarethAdams|Home> | there's no need to load CSS for example for a document that isn't being displayed |
| 22:53 | <TabAtkins> | Really? There's something going on that I'm not understanding, then. How would you take the response to an XHR and use document.getElementByID on it? |
| 22:53 | TabAtkins | may very well just be ignorant. |
| 22:55 | <Hixie> | TabAtkins: XHR itself givs you the DOM, no script execution |
| 22:55 | <TabAtkins> | In which property of the response object? |
| 22:55 | <Hixie> | TabAtkins: responseXML |
| 22:55 | <GarethAdams|Home> | https://developer.mozilla.org/en/XMLHttpRequest - an XHR has responseXML: "The response to the request as a DOM Document object" |
| 22:55 | <TabAtkins> | Hrm. I thought that only worked when you returned valid XML. |
| 22:56 | <Hixie> | i think XHR2 says to use that for HTML too |
| 22:56 | <GarethAdams|Home> | "Note: If the server doesn't apply the text/xml Content-Type header, you can use overrideMimeType() to force XMLHttpRequest to parse it as XML anyway." |
| 22:56 | <GarethAdams|Home> | but that's just mozilla's implementation being described there, AFAIK |
| 22:56 | <TabAtkins> | Okay, if XHR2 allows that to contain the DOM for an HTML document, then that's easy, sure. |
| 22:57 | <TabAtkins> | Of course, is that implemented by anyone yet? |
| 22:57 | TabAtkins | can't put together an experimental implementation of something that still relies on unimplemented behavior. |
| 23:06 | <foolip> | Hixie: I'd like some clarification on HTMLPropertyCollection. Are the items in tree-order and if so, why does the "the properties of an item" algorithm concern itself about order at all? |
| 23:07 | <GPHemsley> | Hixie: Did you ever get around to reading the <cite> thread, and the new proposal in it? |
| 23:07 | <TabAtkins> | annevk: Do you know if anyone supports XHR2 yet? Specifically, the ability for responseXML to contain HTML documents? |
| 23:08 | <Hixie> | foolip: looking... |
| 23:09 | <Hixie> | GPHemsley: yes, i believe i sent a reply |
| 23:09 | <foolip> | In the general section on collections it is noted that "In the absence of specific requirements to the contrary, the nodes within the collection must be sorted in tree order." I don't see anything explicit to the contrary. |
| 23:10 | <GPHemsley> | Hixie: I'm not seeing it. The thread is called "the cite element", and the pertinent discussion ran between Oct. 6 and 9. |
| 23:14 | <GPHemsley> | Also, if anyone wants to weigh in on this, it'd be greatly appreciated: https://bugzilla.mozilla.org/show_bug.cgi?id=522913 (completely unrelated to <cite>, FYI) |
| 23:15 | <Hixie> | foolip: the HTMLPropertyCollection actually explicitly says tree order, it seems |
| 23:15 | <Hixie> | foolip: probably for ease of implementation |
| 23:16 | <Hixie> | foolip: i could change the other algorithm to say that you resort the list in tree order |
| 23:16 | <foolip> | There's also the not that "Within an item, the properties are unordered with respect to each other, except for properties with the same name, which are ordered in the order they are given by the algorithm that defines the properties of an item." I'm not sure when that order is supposed to matter. |
| 23:17 | <Hixie> | foolip: it only matters when, e.g., finding the first value for a property name, which is useful when there's only supposed to be one |
| 23:17 | <Hixie> | foolip: what would be easier? the order as determined by crawling the doc (as per the algorithm that defines the properties of an item), or tree order? |
| 23:17 | <foolip> | I'm trying to determine exactly that |
| 23:17 | <Hixie> | foolip: i can change the spec either way, basically |
| 23:18 | <foolip> | it's itemref that makes crawling in tree order rather complex |
| 23:19 | <Hixie> | yes |
| 23:19 | <foolip> | but actually using the algorithm in the spec would also be non-trivial and certainly can't be hooked into the same code that handles all other collections |
| 23:19 | <foolip> | is it necessary to allow recursive itemrefs? |
| 23:20 | <Hixie> | you mean loops? |
| 23:20 | <Hixie> | or do you mean just two down? |
| 23:20 | <Hixie> | chains |
| 23:20 | <foolip> | I mean two down |
| 23:20 | <foolip> | chained |
| 23:20 | <foolip> | was there a use case for it or did it just happen that way because of the way the algorithm was specced? |
| 23:21 | <Hixie> | i think it'd be really weird to not allow it, personally |
| 23:21 | <Hixie> | but i don't think there was a strong use case for it |
| 23:22 | <foolip> | yes, all else equals its nice to allow it |
| 23:22 | <TabAtkins> | What if the ref'd subtree contained an @itemscope which had more refs? That sort of case is really weird to disallow. |
| 23:23 | <TabAtkins> | (I can see how not allowing a simple chained itemref within a single @itemscope would be justifiable.) |
| 23:23 | <Hixie> | TabAtkins: that'd be different |
| 23:23 | <foolip> | TabAtkins: but the PropertyNodeList just contains the properties for one item |
| 23:23 | <TabAtkins> | Okay, wasn't sure if it would be different or not. |
| 23:24 | <foolip> | but ok, it sounds like there's nothing deliberate about the order here, I'm going to try understanding better which is actually easier to implement and if necessary suggest that the spec is changed |
| 23:25 | <Hixie> | foolip: k. i definitely agree that it'd be nice to have those two orders be consistent, at least |
| 23:25 | <TabAtkins> | foolip: I suspect that algorithm-order would make more sense to authors. It would to me, at least. |
| 23:26 | <foolip> | TabAtkins: surely the order shouldn't matter as long as it doesn't vary between implementations? |
| 23:27 | <Hixie> | there's some logic to the crawled order |
| 23:27 | <Hixie> | but then i guess tree order is also easy to understand |
| 23:27 | <TabAtkins> | What about the case Hixie detailed, about checking the first/last prop with a given name (frex when the given prop should only appear once, and you're doing error-recovery). |
| 23:28 | <Hixie> | TabAtkins: we'd redefine the order returned by the algorithm to be tree order, so that'd still be consistent |
| 23:28 | <foolip> | sure, either is fine I guess, in the model properties are unordered anyway |
| 23:28 | <Hixie> | TabAtkins: it would just mean that tools that implement this by crawling would have to reorder their nodes before returning them |
| 23:28 | <TabAtkins> | Sure, that makes sense. I guess it doesn't matter, then. |
| 23:28 | <Hixie> | foolip: oh wait, what am i talking about |
| 23:29 | <foolip> | Hixie: ? |
| 23:29 | <Hixie> | foolip: the order of the elements in that object has nothing to do with the order of the properties |
| 23:29 | <Hixie> | foolip: elements there can have multiple properties |
| 23:30 | <foolip> | Hixie: oh right you are |
| 23:30 | <Hixie> | foolip: it's .namedItem()'s list whose order we should be talking about |
| 23:30 | <Hixie> | foolip: but then our entire converesation applies equally to that one, so carry on |
| 23:30 | <foolip> | but first, is .item() in tree order? |
| 23:31 | <Hixie> | yeah |
| 23:31 | <Hixie> | In the absence of specific requirements to the contrary, the nodes within the collection must be sorted in tree order. |
| 23:31 | <foolip> | right |
| 23:31 | <foolip> | just checking if this is deliberate |
| 23:32 | <foolip> | that sounds good, even though it's probably a bit messy to implement by walking in tree-order |
| 23:32 | <foolip> | but on to .namedItem |
| 23:33 | <foolip> | oh, it's already defined to be in tree-order |
| 23:33 | <Hixie> | yeah PropertyNodeList should be either changed to algorithm-order or the algorithm changed to tree-order |
| 23:35 | <foolip> | is the algorithm actually used for anything except determining which elements are the properties of an item, couldn't it just as well produce an unordered set of properties (conceptually at least) |
| 23:35 | <foolip> | ? |
| 23:35 | <Hixie> | well we need to define the relative ordering of values within a property |
| 23:35 | <AryehGregor> | Hixie, it occurs to me that AJAX doesn't really replicate native look and feel. For instance, the native browser "loading" bar doesn't fire; scripts can't manipulate it (can they?). Instead, each AJAX app makes up its own weird, hacky progress spinner that doesn't appear in the right place. |
| 23:36 | <AryehGregor> | You expect stuff like the favicon to be replaced by a little spinner, or whatever your browser usually does. |
| 23:36 | <foolip> | Hixie: for PropertyNodeList.values? |
| 23:36 | <Hixie> | AryehGregor: i guess... don't most authors consider that a feature not a bug? :-) |
| 23:36 | <foolip> | that's already defined to be in tree-order |
| 23:36 | <Hixie> | foolip: yeah, either we should redefine the algorithm or .values |
| 23:37 | <AryehGregor> | As a user I get annoyed sometimes when I see little made-up spinners instead of my usual loading cues. It's disorienting somehow. I don't know. |
| 23:37 | <AryehGregor> | Maybe I'm the only one. |
| 23:37 | <AryehGregor> | Maybe the annoyance is because I tend to get annoyed at overuse of AJAX. |
| 23:37 | <Hixie> | AryehGregor: to be honest i don't really get the use case. Why is what we have now a problem? |
| 23:37 | <AryehGregor> | I don't really know, as I said. |
| 23:38 | <foolip> | Hixie: fine, there's no big hurry I think, perhaps implementor feedback might be useful. I'll file a bug |
| 23:38 | <AryehGregor> | I wasn't the one who originally said that what we have is inadequate. |
| 23:38 | <AryehGregor> | I was just making a suggestion based on the premise that it is. |
| 23:38 | <Hixie> | foolip: thanks |
| 23:38 | <Hixie> | AryehGregor: right |
| 23:38 | <Hixie> | anyway. new features are not for this version. |
| 23:38 | <AryehGregor> | I'm not at all sure that this is useful enough middle ground to have a special declarative syntax. |
| 23:38 | <AryehGregor> | Right, certainly not. |
| 23:38 | <AryehGregor> | I said that in my first post on the matter. |
| 23:38 | <Hixie> | :-) |
| 23:39 | <AryehGregor> | GPHemsley, can't you usually tell what language something is in by looking at it? Or do you often want to know what language something is when you don't know the language, *and* the author has actually used correct language markup (which most don't, I imagine)? |
| 23:40 | <GPHemsley> | AryehGregor: Once you get beyond your own language and its relatives, it becomes increasingly more difficult to determine what language something is in. Or what script. Or what dialect. Etc. |
| 23:41 | <AryehGregor> | GPHemsley, but do authors actually mark up language reliably enough for this to be useful in practice? |
| 23:41 | <AryehGregor> | For instance, Wikipedia has mostly correct lang tags on the root element, but everything below that tends to be unmarked-up. |
| 23:42 | <AryehGregor> | And the one on the root element is sometimes a nonstandard code, too. |
| 23:42 | <AryehGregor> | And Wikipedia seems to be on the more enthusiastic-about-standards side of things compared to most websites. |
| 23:43 | <GPHemsley> | Yes. And if they had somewhere for that information to be displayed, they're probably do it more. |
| 23:43 | <GPHemsley> | AryehGregor: I'd like to continue this conversation, but I actually have to run right now. I'll be back in about an hour or so, OK? |
| 23:44 | <AryehGregor> | I might or might not be here. |
| 23:44 | <GPHemsley> | Alright, well, if you are. :) |
| 23:44 | <AryehGregor> | My opinion is irrelevant to what Mozilla does anyway, I'm a web developer. |
| 23:44 | <GPHemsley> | heh |
| 23:44 | <GPHemsley> | anyway, gotta go |
| 23:48 | <mikekelly> | lol |