| 00:00 | <doodlewarrior> | that broke my validation for a little while. it boggled my mind that value='value' was true and a complete omission was false |
| 00:01 | <doodlewarrior> | second (and final so far) feedback: |
| 00:01 | <doodlewarrior> | it would be really sweet if you could get the value of a radio group by name in javascript |
| 00:02 | <Hixie> | i've added a note for the boolean attributes |
| 00:02 | <Hixie> | i agree about the radio buttons |
| 00:02 | <doodlewarrior> | thanks :) |
| 00:03 | <Hixie> | i suppose we could add a method on the object returned by HTMLFormControlCollection... |
| 00:04 | <Hixie> | hm no that wouldn't always work |
| 00:04 | <doodlewarrior> | i don't know the implementation so much as the UI |
| 00:05 | <Hixie> | i suppose we could add a .groupValue attribute on HTMLInputElement |
| 00:05 | <doodlewarrior> | i would expect that as myForm.myTextField returns the value of the text field, myForm.myRadioButton would return the value of the chosen element |
| 00:05 | <Hixie> | myForm.myRadioButton returns a NodeList of all the controls with the name "myRadioButton" |
| 00:06 | <doodlewarrior> | ahhh |
| 00:06 | <Hixie> | (which might not even be the same as the list of radio buttons in that group) |
| 00:06 | <doodlewarrior> | isn't a group defined by having a similar name? |
| 00:07 | <Hixie> | yeah but "similar" for radio button grouping and for NodeList returning is defined differently |
| 00:07 | <doodlewarrior> | i see |
| 00:07 | <doodlewarrior> | so if you add groupValue, then it would be myForm.myRadio[0].groupValue? |
| 00:08 | <Hixie> | yeah |
| 00:08 | <Hixie> | which looks silly, i admit |
| 00:08 | <doodlewarrior> | it's better than nothing |
| 00:08 | <Hixie> | yeah |
| 00:08 | <doodlewarrior> | i feel for you though |
| 00:08 | <doodlewarrior> | backwards compatibility is a bitch when you're trying to standardize |
| 00:09 | <Hixie> | yeah |
| 00:09 | <doodlewarrior> | it would be really nice to iron out all of the inconsistencies, like bool='false' being invalid or a myForm.text returning something different than myForm.radio |
| 00:10 | <Hixie> | myForm.text returns a NodeList if there are multiple controls with the name text too |
| 00:10 | <Hixie> | but yeah |
| 00:10 | <doodlewarrior> | really, myForm.text ought to always return a NodeList |
| 00:10 | <doodlewarrior> | it would make the DOM slightly shittier |
| 00:10 | <doodlewarrior> | but more predictable |
| 00:10 | <Hixie> | yeah well |
| 00:11 | <Hixie> | that boat sailed decades ago |
| 00:11 | <doodlewarrior> | i know it |
| 00:12 | <doodlewarrior> | there needs to be a backwards-incompatible HTML upgrade |
| 00:12 | <doodlewarrior> | its probably to late to have it be HTML5, but maybe HTML6 |
| 00:12 | <doodlewarrior> | fix all the bullshit that people are afraid to change because of backwards incompatibility |
| 00:13 | <Hixie> | we'll never be able to do that |
| 00:13 | <Dashiva> | Philip`: Would it be wrong to suggest XHTML2 here? :) |
| 00:13 | <Hixie> | the content that we need to be compatible with today isn't going to go away tomorrow |
| 00:13 | <doodlewarrior> | exactly |
| 00:13 | <doodlewarrior> | that's what DOCTYPE is for |
| 00:14 | <Hixie> | browsers aren't going to add yet another processing mode |
| 00:14 | <Hixie> | microsoft tried that with ie8 |
| 00:14 | <Hixie> | and they're already regretting it as far as i can tell |
| 00:14 | <Hixie> | they haven't even shipped it yet |
| 00:14 | <Hixie> | opera, mozilla, and safari devs have all told me point blank that there's zero chance they'll ever want to do that |
| 00:14 | <Hixie> | we already have four modes |
| 00:14 | <Hixie> | which they consider to be plenty |
| 00:14 | <Hixie> | (quirks, limited quirks, no quirks, and xml) |
| 00:15 | <doodlewarrior> | wow |
| 00:15 | <Dashiva> | Before I can even ask what the fourth was... |
| 00:17 | <doodlewarrior> | so Hixie, do you imagine we'll be tiptoeing around things that are broken in HTML indefinitely? |
| 00:17 | <Hixie> | until something replaces html entirely, yes |
| 00:17 | <Hixie> | e.g. xhtml2 |
| 00:17 | <Hixie> | though i doubt xhtml2 is radical enough to be the one to replace html |
| 00:18 | <Dashiva> | Something json-based |
| 00:18 | <Dashiva> | Angle brackets are out |
| 00:18 | <doodlewarrior> | so if the browsers refuse to add a processing mode to iron out the kinks in HTML |
| 00:19 | <doodlewarrior> | why would they even start from 0 on a new language entirely? |
| 00:19 | <doodlewarrior> | *ever |
| 00:19 | <Hixie> | they probably wouldn't |
| 00:19 | <Hixie> | they'll probably be replaced by some newcomer |
| 00:19 | <Philip`> | Dashiva: Suggest XHTML2 where? |
| 00:19 | <doodlewarrior> | so HTML will be broken until the entire web is replaced? |
| 00:19 | <doodlewarrior> | in your estimation |
| 00:19 | <Dashiva> | Philip`: <doodlewarrior> fix all the bullshit that people are afraid to change because of backwards incompatibility |
| 00:20 | <Hixie> | doodlewarrior: unless someone can work out a way to upgrade all the old unmaintained content in one go, yes, probably |
| 00:20 | <Philip`> | Dashiva: Oh, I wasn't reading the context :-p |
| 00:20 | <Philip`> | Dashiva: Am I an expert in making wrong suggestions, or something? :-) |
| 00:20 | <Hixie> | doodlewarrior: for some meaning of the word "broken" anyway |
| 00:20 | <doodlewarrior> | broken being things that are inconsistent or unintuitive |
| 00:21 | <doodlewarrior> | adding tags and properties is one thing |
| 00:21 | <Hixie> | doodlewarrior: do you know much about the Win32 API? |
| 00:21 | <doodlewarrior> | but overhauling them is another |
| 00:21 | <doodlewarrior> | no |
| 00:21 | <Hixie> | hmm |
| 00:21 | <doodlewarrior> | i do mostly flash |
| 00:21 | <doodlewarrior> | some django/javascript |
| 00:22 | <Hixie> | i was going to illustrate with the Win32 API, or the Unix API for that matter, that pretty much every successful long-lived platform so far has been inconsistent or unintuitive |
| 00:22 | <doodlewarrior> | flash spoils me. one language - a cleaned up version of javascript, with a built in display list |
| 00:22 | <Hixie> | successful platforms pick up cruft over the years |
| 00:22 | <Hixie> | from all the people working on them |
| 00:22 | <Hixie> | with different ideals, different motivations, different visions |
| 00:22 | <doodlewarrior> | my room does too, but i clean it when that happens ;-) |
| 00:22 | <doodlewarrior> | i certainly understand why it happens |
| 00:22 | <Dashiva> | Philip`: Wasn't it you who said something about XHTML2 being the default response whenever someone made a silly request? |
| 00:22 | <Hixie> | imagine if your room was the size of a city, and there were lots of blind people who knew where all the junk was |
| 00:23 | <doodlewarrior> | i just happen to be a UI designer/entrepreneur |
| 00:23 | <Hixie> | you couldn't clean it any more :-) |
| 00:23 | <doodlewarrior> | so i constantly think of 'how can this be fixed' |
| 00:23 | Hixie | . o O ( ok everyone except Firefox seems to agree that the base URL is the same as the url of the frame before it was replaced ) |
| 00:23 | <Dashiva> | Don't fix it, make an alternative that's so awesome everyone stops using the old way |
| 00:23 | <Hixie> | doodlewarrior: well if you can think of a way, do let us know :-) |
| 00:23 | <Dashiva> | Then you can let the old way fade into obscurity and remove it when you think no one cares anymore |
| 00:24 | <Hixie> | that's what will eventually happen, as i said above |
| 00:24 | <doodlewarrior> | Dashiva: i agree |
| 00:24 | <doodlewarrior> | i figured it could be an iteration on HTML though |
| 00:24 | <Dashiva> | But that's probably on a time scale of decades |
| 00:24 | <doodlewarrior> | a real standards mode |
| 00:24 | <doodlewarrior> | but we've established that won't happen |
| 00:24 | <Dashiva> | No one's preventing you from only using a subset of HTML5 |
| 00:25 | <Dashiva> | You could form the HTML5 Samurai or somesuch :) |
| 00:25 | <doodlewarrior> | hahaha |
| 00:25 | <doodlewarrior> | ill leave that to others |
| 00:25 | <doodlewarrior> | i have other parts of the world to change :-p |
| 00:25 | <doodlewarrior> | speaking of which, i need to get back to that |
| 00:25 | <doodlewarrior> | i'll be at the google appengine meeting in palo alto tonight if anyone wants to say hi |
| 00:39 | <Philip`> | Dashiva: I don't remember saying something about that |
| 00:39 | <Philip`> | Dashiva: though I say a lot of things that I immediately forget, so that's not saying much |
| 00:42 | <Philip`> | Would an HTML5 Samurai have to commit seppuku if they noticed themselves thinking that actually maybe XML isn't that bad after all? |
| 00:45 | <sicking> | Hixie, ping |
| 00:46 | <Hixie> | hey |
| 00:50 | <Hixie> | sicking: pong |
| 00:52 | <sicking> | Hixie, would be great if you could have a looksee at the onerror thread i posted to whatwg. We're still a few weeks out from shipping, and I doubt that any comments you have are major, so there's still time to fix things. Just prefer not to get past that point |
| 00:53 | <Hixie> | sure, will do that next |
| 00:53 | <sicking> | Hixie, other than that i think we're either not implementing an API (such as location or shared workers) or follow the spec |
| 00:53 | <Hixie> | nice |
| 00:55 | <Hixie> | shepazu: was there every a decision made in the svgwg about http://www.w3.org/mid/48B26024.8090403⊙wo ? |
| 00:59 | <MikeSmith> | Philip`: the HTML5 Samurai would need to commit seppuku after their lord was executed and they had extracted revenge from all those responsible |
| 00:59 | <jcranmer> | せぷく (and yes, I'm forgetting the tsuku-thing or whatever it's called) |
| 00:59 | sicking | needs more fonts on his system |
| 01:00 | <Philip`> | IRC needs embeddable TTF fonts |
| 01:00 | <sicking> | @font-face ftw! |
| 01:07 | <Hixie> | sicking: you still there? |
| 01:08 | <Hixie> | sicking: re your first point, i don't understand. the onerror on the worker global scope is exactly the same as window.onerror, including the three parameters. |
| 01:08 | <Hixie> | sicking: the onerror on the Worker object is the one that involves the event. |
| 01:10 | <Hixie> | i can do your second request easily though |
| 01:11 | <roc> | Philip`: that would be easy to implement in Chatzilla! |
| 01:11 | Hixie | pokes sicking |
| 01:20 | <Lachy> | http://lastweekinhtml5.blogspot.com/2009/01/bonnie-prince-cheesie.html |
| 01:21 | <sicking> | Hixie, pong |
| 01:23 | <Hixie> | sicking: see above |
| 01:24 | <sicking> | Hixie, oh? |
| 01:26 | <sicking> | Hixie, interface WorkerGlobalScope { ... attribute EventListener onerror; |
| 01:26 | <sicking> | Hixie, that's not right then |
| 01:26 | <Hixie> | its the same as on Window |
| 01:26 | <sicking> | Hixie, well, it's wrong there too then :) |
| 01:27 | <sicking> | Hixie, "Must be invoked whenever an error event is targeted at or bubbles through the element" is also wrong, there is no element and no event |
| 01:27 | <Hixie> | hm |
| 01:27 | <Hixie> | wonder how to fix onerror then |
| 01:27 | <Hixie> | since it can also take an EventListener |
| 01:27 | <sicking> | Hixie, JS prose is all i can think of |
| 01:27 | <Hixie> | yeah |
| 01:27 | <sicking> | Hixie, really? on window too? |
| 01:27 | <Hixie> | heycam: yt? |
| 01:27 | <heycam> | yeah.. |
| 01:28 | <sicking> | Hixie, that seems very hokey |
| 01:28 | <Hixie> | heycam: so window.onerror is called both for 'error' events and with three arguments sometimes |
| 01:28 | <Hixie> | sicking: yeah... maybe we should just use the events on Worker after all |
| 01:28 | <Hixie> | workers, i mean |
| 01:28 | <sicking> | Hixie, i think we should :) |
| 01:28 | <Hixie> | heycam: any idea how to do that in the idl? just have it be an 'any' thing? |
| 01:29 | <Hixie> | sicking: k, i'll do that. sorry for wasting your time trying to be compatible with Window. |
| 01:29 | <sicking> | Hixie, otherwise we have to look at how many arguments the function takes, and if it's 3 give it those, and if it's 1 give it an event |
| 01:29 | <sicking> | Hixie, heh, no problem |
| 01:29 | <Hixie> | well we still have the weirdness with window.onerror |
| 01:29 | <heycam> | so onerror is sometimes called with (Event) and sometimes with (some, thing, else) ? |
| 01:30 | <sicking> | Hixie, i don't think window.onerror is anything event like on window. At least not in gecko. Maybe in safari/opera though |
| 01:30 | <heycam> | what about introducing an interface that has an overloaded handleEvent (one that takes Event, like EventListener, and one for the 3-arg version)? |
| 01:30 | <Hixie> | heycam: yeah |
| 01:30 | <Hixie> | heycam: oh, could do that, yeah |
| 01:30 | <Hixie> | heycam: ok |
| 01:30 | <Hixie> | heycam: thanks |
| 01:30 | <Hixie> | maybe make it inherit from EventListener |
| 01:30 | <Hixie> | cool |
| 01:31 | <Hixie> | thanks |
| 01:31 | <heycam> | Hixie, I'll have to make sure that overloading like that works when you assign a plain Function |
| 01:31 | <Hixie> | k |
| 01:31 | <heycam> | but, assume for now it does |
| 01:31 | <Hixie> | thanks |
| 01:31 | <heycam> | and i'll check on it later at some point |
| 01:31 | <sicking> | do we need this stuff at all? Even for window though? |
| 01:32 | sicking | tries in opera |
| 01:33 | <heycam> | Hixie, pointer to where in the spec this three-argument thing is? |
| 01:34 | <Hixie> | heycam: search for "runtime error" |
| 01:34 | <Hixie> | or "runtime script errors" |
| 01:36 | <heycam> | got it |
| 01:39 | <Hixie> | sicking: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3E%0Awindow.onerror%20%3D%20function%20%28a%2Cb%2Cc%29%20{%0A%20w%28%27onerror%3A%27%20%2B%20a%20%2B%20%27%3B%27%20%2B%20b%20%2B%20%27%3B%27%20%2B%20c%29%3B%0A}%3B%0A%3C%2Fscript%3E%0A%3Cscript%3E-%3C%2Fscript%3E%0A%3Cscript%3E%0A%20var%20x%20%3D%20document.createEvent%28%27Event%27%29%3B%0A%20x.initEvent%28%27error%27%2C%20false%2C%20false%29%3B%0A%20window.dispatchE |
| 01:39 | sicking | also had an 'onerror = function(a, b, c)' |
| 01:39 | <sicking> | Hixie, i think that got cut off :( |
| 01:40 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/ click "download" |
| 01:40 | <Hixie> | the results are in the log at the bottom |
| 01:40 | <sicking> | Hixie, no, the url you pasted me literally ends with ".dispatchE" on this side |
| 01:41 | <sicking> | possibly chatzilla or irc server cutting it off |
| 01:41 | <gavin> | server, but that doesn't change his followup instructions :) |
| 01:41 | <Hixie> | sicking: if you go to that url and click download, you'll see what i tried to paste |
| 01:42 | <sicking> | Hixie, oh, neat |
| 01:43 | <Hixie> | haven't tested IE yet |
| 01:43 | <Hixie> | Firefox does what I described; Webkit doesn't seem to have an onerror at all, and Opera only seems to have a the event handler. |
| 01:43 | <Hixie> | sicking: workers spec updated with new onerror stuff |
| 01:44 | sicking | ponders |
| 01:45 | <Hixie> | ok IE does the 3-argument form |
| 01:45 | <Hixie> | but they don't support DOM Events |
| 01:45 | <Hixie> | so i can't test the other one |
| 01:46 | <sicking> | right |
| 01:47 | <Hixie> | actually the webkit problem seems to be lack of dispatchEvent() support on Window |
| 01:47 | <Hixie> | dunno what that's about |
| 01:48 | <sicking> | Hixie, however you can't set onerror to an EventListener |
| 01:48 | <sicking> | Hixie, so spec is still not correct |
| 01:48 | <sicking> | err |
| 01:48 | <sicking> | nevermind |
| 01:49 | <sicking> | Hixie, right, you can't set onerror to an EventListener |
| 01:50 | <Hixie> | ? |
| 01:50 | <sicking> | Hixie, how do i do the upload magic? |
| 01:50 | <Hixie> | click "upload" |
| 01:50 | <Hixie> | it'll replace whatever's in the clipboard |
| 01:51 | <sicking> | done |
| 01:51 | <Hixie> | i don't understand what you are trying to show |
| 01:51 | <sicking> | Hixie, if I try to set onerror to an eventhandler, i would have expected to receive 2 events |
| 01:51 | <sicking> | Hixie, but i receive a string and an event |
| 01:52 | <sicking> | so attribute EventListener onerror; is not correct |
| 01:52 | <sicking> | basically onerror is a JS function |
| 01:52 | <Hixie> | why would you expect that? |
| 01:52 | <Hixie> | a JS function always implements any Callback interface |
| 01:53 | <Hixie> | the number of parameters you put in the signature has no effect |
| 01:53 | <sicking> | right |
| 01:53 | <sicking> | ok, so simplified example |
| 01:54 | <sicking> | given the definition in the idl, i would have expected the onerror function to receive a Event object |
| 01:55 | <sicking> | but it receives a string |
| 01:55 | <Hixie> | the runtime script errors section explicitly says to just call with three arguments |
| 01:55 | <Hixie> | there is no event a this point |
| 01:55 | <sicking> | but then it's not an EventListener |
| 01:55 | <Hixie> | it's a totally unrelated callback |
| 01:55 | <Hixie> | indeed |
| 01:55 | <Hixie> | it's an EventListenerOrErrorHandler |
| 01:55 | <Hixie> | which inherits from EventListener and also has a handleEvent() overloaded with three arguments |
| 01:56 | <sicking> | it's never an EventListener |
| 01:56 | <sicking> | So just call it ErrorHandlerCallback or some such |
| 01:56 | <Hixie> | it has to be an EventListener otherwise it wouldn't work with event dispatch |
| 01:56 | <sicking> | hmm.. actually, that's not true either i guess |
| 01:57 | <sicking> | right |
| 01:57 | <sicking> | actually |
| 01:57 | sicking | tries something else |
| 01:58 | <sicking> | ok, uploaded new example |
| 01:59 | <sicking> | if that was an EventListenerOrErrorHandler i would have expected the example to work |
| 01:59 | <sicking> | but it's really just a JS function, that we sometimes call with one parameter, and sometimes with 3 |
| 01:59 | <Hixie> | the EventListenerOrErrorHandler interface is marked with [Callback=FunctionOnly] |
| 02:00 | <Hixie> | (actually i think i'll just call it ErrorHandler, EventListenerOrErrorHandler is too long) |
| 02:00 | <sicking> | ugh, that's really wierd |
| 02:00 | Hixie | points at the topic |
| 02:00 | <sicking> | an interface with two functions, but that can't be implemented by an object? |
| 02:00 | <Hixie> | i didn't make this up, i'm just describing what happens |
| 02:01 | <sicking> | well, not really |
| 02:01 | <sicking> | you're describing something that looks mostly the same |
| 02:01 | <sicking> | what it really is is just a plain JS function |
| 02:01 | <Hixie> | how is it distinguishable? |
| 02:01 | <Hixie> | it's not _just_ a plain JS function, since it works with DOM Events |
| 02:01 | <sicking> | it's possibly not, but yours is more convoluted |
| 02:02 | <Hixie> | and that wouldn't be compatible with other languages, either |
| 02:02 | <sicking> | there is an eventhandler that calls into the JS function |
| 02:02 | <Hixie> | that's just as convoluted |
| 02:03 | <Hixie> | except it only works in JS |
| 02:03 | <Hixie> | actually what i'm describing is pretty terse in the spec |
| 02:03 | <Hixie> | i'm just putting the finishing touches on it |
| 02:04 | <sicking> | it's way uglier than a simple onerror EventListener though |
| 02:04 | <sicking> | but i agree we'll have to do something like it for the window object |
| 02:06 | <sicking> | btw, is this updated in a draft somewhere? still looks like |attribute EventListener onerror| when i reload the webapps draft |
| 02:10 | <Hixie> | why would that change? |
| 02:10 | <Hixie> | i was only going to change the HTML5 draft |
| 02:10 | <Hixie> | though i just noticed another problem |
| 02:10 | <sicking> | because it's an EventListenerOrErrorHandler or ErrorHandler, no? |
| 02:10 | <Hixie> | not on the workers...? |
| 02:11 | <Hixie> | the whole point of the earlier change was to get rid of the error handler stuff |
| 02:11 | <Hixie> | wasn't that what you wanted? |
| 02:11 | <Hixie> | i'm confused |
| 02:11 | <sicking> | sorry, i said webapps, meant html5 |
| 02:11 | <Hixie> | oh |
| 02:11 | <sicking> | i didn't know the whatwg spec was called that too :) |
| 02:12 | <Hixie> | there are two specs. workers and html5. "webapps" and "whatwg" are working groups not specs :-P |
| 02:12 | <sicking> | ah :) |
| 02:12 | <sicking> | i guess this does make sense for the window object, though i'm not really sure if we'd be able to implement it that way |
| 02:12 | <Hixie> | html5 in the whatwg used to be called Web Apps 1.0, but we renabed it before the webapps wg started, iirc |
| 02:12 | <Hixie> | the problem i just noticed is that actually none of the so-called EventListener objects are EventListeners really |
| 02:12 | <sicking> | ok |
| 02:13 | <Hixie> | they're all functions |
| 02:13 | <Hixie> | that then get wrapped and the wrapper is addEventListener'ed implicitly |
| 02:13 | <Hixie> | the wrapper does things like handle return values |
| 02:13 | <Hixie> | which EventListeners don't normally have |
| 02:13 | <sicking> | yep |
| 02:14 | <Hixie> | so i think actually what i need to do (contrary to what heycam and i just discussed) is just change EventListener to something else in every IDL block |
| 02:14 | <Hixie> | in html5 |
| 02:14 | <Hixie> | (and maybe workers) |
| 02:14 | <sicking> | hmm.. wait a minute |
| 02:14 | Hixie | waits |
| 02:14 | <sicking> | this doesn't happen for things other than onerror, no? |
| 02:14 | <Hixie> | what is "this"? |
| 02:15 | <sicking> | the dealing with return values and such |
| 02:15 | <sicking> | oh, wait |
| 02:15 | <sicking> | that's not true either |
| 02:15 | <Hixie> | it happens for everything |
| 02:15 | <sicking> | i guess that happens spottily |
| 02:15 | <sicking> | at least in gecko |
| 02:15 | <Hixie> | it's different for onbeforeunload, onmouseover, and onerror |
| 02:15 | <Hixie> | but the others all support return false; to cancel |
| 02:16 | <sicking> | we don't actually support that in a bunch of places |
| 02:17 | <sicking> | but all the places I can think of only fires non-cancelable events |
| 02:17 | <Hixie> | well some events can't be canceled |
| 02:17 | <sicking> | right |
| 02:17 | <Hixie> | my plan is to unify all event handling across all elements so that all elements and Window have the same set of event handler attributes |
| 02:18 | <Hixie> | thus making it all much simpler to implement |
| 02:18 | <Hixie> | no special cases (other than the three i just mentioned) |
| 02:18 | <sicking> | don't think that'll work on Window where you have magic undefined-by-default things |
| 02:19 | <Hixie> | well that might be a fourth exception |
| 02:21 | <Hixie> | heycam: yeah don't worry about the earlier issue, i'll deal with it differently |
| 02:23 | <Hixie> | going for dinner |
| 03:07 | <heycam> | Hixie, ok |
| 03:24 | <hallvors> | sicking: Opera doesn't support window.onerror , I guess you figured that out by testing. |
| 03:25 | <sicking> | hallvors, that's about as far as I got yeah :) |
| 04:50 | <MikeSmith> | hendry: you around? |
| 04:57 | <Papus> | hello ? |
| 05:05 | <Papus> | hi ? |
| 05:05 | <Papus> | dolske |
| 05:09 | <dolske> | yes? |
| 07:57 | <ap> | Hixie: ayt? for some questions about offline cache |
| 07:58 | <Hixie> | here |
| 07:58 | <ap> | Hixie: did you get my e-mail about updating obsolete caches yesterday? I was having some network troubles, so I'm not sure if it got through |
| 07:59 | <Hixie> | yeah, i got it. added it to my pile, since iirc there was nothing urgent. i can look it up if you have a question you need a reply on right away |
| 08:00 | <Hixie> | i agree that the text is confusing and will make it better at some point |
| 08:00 | <ap> | Hixie: I'm discussing this with dcamp now, so it could help to have the spec updated |
| 08:00 | <ap> | anyway, question #2 |
| 08:01 | <Hixie> | i'll add it to my list for this week, ping me friday if i still haven't done anything |
| 08:01 | <ap> | Hixie: it's not quite clear to me how documents for new master resources are associated with caches |
| 08:02 | <ap> | Hixie: say, we're opening a new frame with a document that has a manifest URL, and there is already a cache for this URL, but the master resource is not in cache |
| 08:02 | <ap> | Hixie: when will the document be associated to the cache? |
| 08:03 | <ap> | Hixie: it looks like it will not be until reload with the current spec, which is weird |
| 08:03 | <ap> | Hixie: the document will be flagged as a candidate, but candidates are only associated when an initial cache attempt finishes |
| 08:04 | <Hixie> | "Otherwise, invoke the application cache update process for the given manifest URL, with the browsing context being navigated, and with the Document as the new master resource." |
| 08:04 | <Hixie> | step 2 of the relevant variant of the application cache selection algorithm |
| 08:04 | <ap> | Hixie: yes, that will mark the document as candidate in step 1.3 of update process |
| 08:05 | <ap> | Hixie: but nothing more than that afaict |
| 08:05 | <Hixie> | the sentence that says that, in section 1.3, says what the effect is |
| 08:06 | <Hixie> | and links straight to the relevant step |
| 08:06 | <Hixie> | step 23 |
| 08:06 | <Hixie> | "Associate any Document objects that were flagged as candidates for this manifest URL's caches with cache." |
| 08:06 | <ap> | Hixie: precisely, and step 23 starts with "If this is a cache attempt, then" |
| 08:06 | <Hixie> | oh |
| 08:07 | <Hixie> | yeah i'm just being slow today sorry! |
| 08:07 | <ap> | Hixie: besides, step 23 is never reached for upgrade attempts |
| 08:07 | <Hixie> | it isn't1? |
| 08:07 | <Hixie> | s/1// |
| 08:08 | <Hixie> | i should move that sentence to just before step 23 as far as i can tell |
| 08:08 | <Hixie> | so it happens in both cases |
| 08:08 | <ap> | Hixie: step 6 says "If this is an upgrade attempt and the newly downloaded manifest is byte-for-byte identical to the manifest found in cache" ... "Abort the update process" |
| 08:08 | <ap> | Hixie: long before step 23 :) |
| 08:08 | <Hixie> | oh, yeah, i didn't think of that case |
| 08:09 | <Hixie> | oh, hey, step 6 even waits for all these downloads to finish |
| 08:09 | <Hixie> | i just need to make sure step 23's sentence is in that list too |
| 08:10 | <Hixie> | can you send a mail or file a bug saying to make that sentence in step 23 happen before step 23 for upgrad attempts too, and to say to make it happen in step 6 after waiting also? |
| 08:10 | <ap> | Hixie: I'm also not sure about error and obsolete cases - will the candidate be associated with its cache in that case? |
| 08:11 | <Hixie> | in the obsolete case, a new cache will be created from scratch |
| 08:11 | <Hixie> | obsolete caches are never consulted again |
| 08:11 | <Hixie> | in the error case, the result should be no change to anything |
| 08:11 | <ap> | Hixie: I mean, if the cache is found out to be obsolete when there is a candidate |
| 08:12 | <Hixie> | i guess it matters if the author then xhr's the document? |
| 08:12 | <ap> | Hixie: we're opening a new frame, it master resource is not in cache, and it has a manifest attribute, and the manifest turns out to be 404 |
| 08:12 | <ap> | Hixie: as it works in WebKit now, the document will be associated to the obsolete cache, and it will get an "obsolete" event |
| 08:13 | <Hixie> | yeah the only way that can actually matter is if the document like xhr's itself or some such right |
| 08:13 | <Hixie> | i mean, whether the document is actually added to the cache or not |
| 08:13 | <Hixie> | i think if we mark it obsolete we should also disable the network blocking |
| 08:13 | <Hixie> | and unassociate the cache |
| 08:13 | <ap> | Hixie: I don't see how this is related to xhr |
| 08:13 | <ap> | Hixie: hmm |
| 08:13 | <Hixie> | xhr would be the only way to get a copy of the document again |
| 08:14 | <Hixie> | without xhr, or <img> or some such, it doesn't matter if you add the doc to the cache or not |
| 08:14 | <ap> | Hixie: yes, I was thinking about being associated to the cache for the purposes of blocking other loads, not just the master resource |
| 08:15 | <ap> | Hixie: but indeed, it isn't quite clear when master resources are added to the cache either |
| 08:16 | <Hixie> | i think the obsolete case should be fixed by just disassociating from the cache |
| 08:16 | <Hixie> | so it works as if there hadn't been one |
| 08:16 | <Hixie> | if there's a new master doc |
| 08:17 | <Hixie> | (if it came from the cache, that's a different matter) |
| 08:19 | <Hixie> | does that make sense? |
| 08:19 | <ap> | Hixie: currently, WebKit associates the new master resource to an existing cache earlier, before invoking the update process |
| 08:19 | <Hixie> | well so long as you take it out again in case of error, and so long as you don't block network loads until it's done, that's fine |
| 08:19 | <ap> | Hixie: I think that it is reasonable behavior - and what you said is reasonable, too |
| 08:20 | <ap> | Hixie: what's the problem with not taking it out in case of error, and starting blocking immediately? |
| 08:21 | <ap> | Hixie: our behavior just makes new master resources for existing caches behave as if they were already in cache |
| 08:21 | <Hixie> | both of those would be detectably different behavior than strict implementations of the spec |
| 08:21 | <ap> | Hixie: so, opening them for the first time works exactly like re-opening |
| 08:21 | <Hixie> | oh the reason why the spec does it this way is to avoid race conditions |
| 08:22 | <Hixie> | and for consistency between the case of going to a page for the first time whether or not it already has a manifest marked |
| 08:22 | <Hixie> | i guess if there's already a cache the consistency case isn't that important |
| 08:23 | <ap> | Hixie: right - if there is already a cache, it's more consistent to associate it right away, even if te master resource wasn't loaded from it |
| 08:23 | <Hixie> | makes sense |
| 08:23 | <Hixie> | makes the spec simpelr too |
| 08:40 | hsivonen | wishes C++ compilers figured out inlining on their own... |
| 08:43 | <Philip`> | They usually do |
| 08:52 | <Hixie> | ap: please file a bug or send mail about the above so i don't forget to do it |
| 08:53 | <ap> | Hixie: I sent an e-mail a few minutes ago |
| 08:53 | <Hixie> | ok cool thanks |
| 09:03 | <Hixie> | sicking: ok i checked in my fix for event handler attributes. i think it's in line with reality. |
| 09:05 | <Hixie> | ok my next task is working out how to handle the crazy wackiness around window.onload/document.onload/<body onload=""> and the like (onhashchange, onstorage, etc) |
| 09:37 | <annevk> | are we getting a new EventListener thingie for onX attributes? |
| 09:38 | <annevk> | that will affect XMLHttpRequest |
| 09:38 | <Hixie> | to match reality |
| 09:38 | <annevk> | k |
| 09:41 | <annevk> | jezus christ, to pay for a NOK 280 (= EUR 30) transaction they charged me EUR 20 |
| 09:43 | <annevk> | Problem: Want to reuse format consumed by browsers. Solution: Change the format to be XML-like. |
| 09:43 | <annevk> | it's not clear to me how some TAG members make that jump |
| 09:44 | <hsivonen> | annevk: huh? where's that from? |
| 09:44 | <annevk> | though admittedly, before HTML5 it is somewhat sensible as HTML was not predictable |
| 09:44 | <annevk> | hsivonen, it's not a literal quote |
| 09:44 | <jgraham> | annevk: You have to love scandinavia, right :) |
| 09:44 | <annevk> | it seems to be gist of http://lists.w3.org/Archives/Public/www-tag/2009Jan/0069.html |
| 09:45 | <annevk> | jgraham, I suppose, I think my bank charged EUR 5 and the bank charged EUR 15 and I had to pay for both |
| 09:46 | <Hixie> | annevk: before html5, it would have been as right (or wrong) as now, except that an additional solution would have existed: "write html5" :-P |
| 09:46 | <annevk> | jgraham, I suppose they are flat fees which become ridiculous when the amount of money is small |
| 09:46 | <annevk> | Hixie, :) |
| 09:47 | <Hixie> | annevk: a flat fee costs the same regardless of how much you're paying, so if it's ridiculous for one amount, it's ridiculous for another too. |
| 09:47 | <annevk> | the gist of, even |
| 09:48 | <annevk> | Hixie, I just mean that If I were to pay EUR 2000, EUR 20 is fine |
| 09:48 | <annevk> | Hixie, or at least neglicable |
| 09:48 | <Hixie> | it's 20 EUR |
| 09:48 | <Hixie> | it the same as if you're paying EUR 10 |
| 09:48 | <jgraham> | annevk: According to economists you are wrong |
| 09:48 | <Hixie> | still 20 EUR |
| 09:50 | <jgraham> | You should apparently always think about the absolute amount of money. It's just that most people are more disappointed if they pay $6 for something that they could have got for $1 rtahn if the numbers are $1E6, $1E6+5 |
| 09:50 | <annevk> | jgraham, I just realized that, as I had read that link Hixie posted some time ago, but I suppose I think in relative amounts of money :) |
| 09:51 | <Philip`> | annevk: Converting between HTML and XML in the toolchain doesn't seem like a good solution in that situation, since the conversion is lossy (in both directions) - e.g. you can't write a web crawler that parses HTML then stores it in an XML database to do a load of querying on the data, because the translation will destroy some of the data |
| 09:51 | <jgraham> | annevk: That's a problem called "being human" which economists have difficulty with |
| 09:51 | <jgraham> | Philip`: The conclusion seems to be that storing things in an XML datatbase is not a good idea |
| 09:52 | <jgraham> | (at least things that may not be XML) |
| 09:52 | <annevk> | Philip`, I never said that to convert anything, you can use XML on the infoset level... |
| 09:53 | <annevk> | s/that// |
| 09:54 | <Philip`> | annevk: I would imagine any XML toolchain is very likely to serialise to XML at some point, so you've got to restrict yourself to well-formed documents |
| 09:55 | <annevk> | <!doctype html><title>test</title><p>test can still be used within an XML toolchain |
| 09:55 | <Hixie> | can't we just assume that the html5 documents will be conforming? non-conforming html documents surely aren't something we want to deal with |
| 09:55 | Hixie | ducks |
| 09:55 | <gsnedders> | Hixie: Can we remove section 8.2 then? |
| 09:55 | <Philip`> | jgraham: Rather, the conclusion is that there is a benefit if the document format is compatible with the tools you use (without needing ugly munging in the middle), so it'd be good if all were HTML or all were XML or all were anything else |
| 09:56 | <Philip`> | annevk: That's why I said "e.g. you can't write a web crawler ...", because there are cases where you have no control over the input HTML but you want to make use of useful tools that already exist (and that today are mostly designed for XML) |
| 09:57 | <annevk> | the web crawler based on an HTML parser would surely be far more successful than one based on an XML parser |
| 09:57 | <annevk> | s/the/a/ |
| 09:58 | <Philip`> | annevk: That's why I said "e.g. you can't write a web crawler that parses HTML then stores it in an XML database to do a load of querying on the data" |
| 09:59 | <jgraham> | Philip`: OK, let's be clearer. "Storing web pages from the public internet in an XM database is not a good idea". |
| 09:59 | <jgraham> | *XML |
| 09:59 | <Hixie> | i wonder if there's a correlation between how closely search engines' parsers conform to html5 and how much market share the search engine has |
| 09:59 | <annevk> | and doesn't HTML5 define a way to handle those layer problems? |
| 09:59 | <hsivonen> | Hixie: but which way does the causation go? :-) |
| 10:00 | <Philip`> | annevk: because you've got to use an HTML parser, but then there are other useful tools you'd like to use, and you don't want to have to deal with weird artifacts introduced by the HTML-to-well-formed-XML translation process |
| 10:00 | <Hixie> | hsivonen: that's the next question :-) |
| 10:00 | <annevk> | obviously one based on an XML parser will be superior, because it's much faster |
| 10:00 | <jgraham> | Specifically I don't understand why "the value of the layering is not primarily for the browsing-only |
| 10:00 | <jgraham> | scenario. It's to give you the opportunity of using HTML documents with a |
| 10:00 | <jgraham> | " |
| 10:00 | <jgraham> | lot of additional tools and in additional scenarios |
| 10:00 | <jgraham> | Because it doesn't actually do that. |
| 10:01 | <jgraham> | s/why/why he thinks/ |
| 10:02 | <annevk> | Philip`, why is http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#coercing-an-html-dom-into-an-infoset not a solution? |
| 10:02 | <Philip`> | jgraham: As I read it, Noah was describing an advantage of XHTML and of its use of layering on XML, which is that such a language would give you that opportunity (in the hypothetical case that people used that language) |
| 10:03 | <Philip`> | jgraham: and it does indeed seem to be an advantage of XHTML, even if it's overshadowed by the fact that nobody uses XHTML |
| 10:03 | <Hixie> | xhtml has many advantages |
| 10:03 | <jgraham> | Philip`: I guess that could be true. But as you say, since no one uses XHTML it's really quite irrelevant |
| 10:04 | <jgraham> | And therefore not worthwhile to discuss in a way that suggests it is a real world consideration |
| 10:04 | <Philip`> | annevk: If I write something that e.g. downloads a load of random pages and then tries to count the most common attributes, using some XML database that provides nice easy-to-use efficient querying features, I don't want to be told that there's lots of attributes named "xlinkU0003Ahref" because that's just an artifact of the translation process |
| 10:05 | <annevk> | so you translate back when you display |
| 10:05 | <Philip`> | annevk: Also it might irreversibly drop 'xmlns' attributes, so it's impossible to translate the results back accurately |
| 10:07 | <annevk> | yeah ok, so you cannot use an XML toolchain for all use cases |
| 10:07 | <Philip`> | The problems aren't insurmountable, they're just a bit of a pain and it'd be nicer if they weren't problems |
| 10:07 | <annevk> | but for the case Noah was talking about, switching to using XHTML as a storage format for Web pages, it doesn't seem worth the effort |
| 10:07 | <Hixie> | jgraham: the tag is not about real world considerations, it's about architecture. (And I don't mean that sarcastically -- the whole point of the TAG is to discuss how things should be designed, not to deal with the realities of how things got screwed up.) |
| 10:08 | Philip` | aways |
| 10:09 | <jgraham> | Hixie: "How things should be designed" does not seem to be a particularly useful thing to discusss when there are insurmountable problems that prevent them ever from actually being designed in that way (not to mention the fact that it tends to lead to overengineerining, poor usability considerations, etc.) |
| 10:10 | <annevk> | oh nice, twitter.com uses tables for layout |
| 10:11 | <Hixie> | i wasn't making value judgements about whether or not the work of the tag was useful, i was just explaining that your statement was a non-sequitur for the tag. |
| 10:13 | <Philip`> | annevk: I think I forgot whether I was trying to argue for any particular point, but I guess the point was that it seems better to say "HTML not being XML is indeed a problem because it makes it hard to interoperate with XML tools, but it's an unfixable problem so we'll have to reduce its impact and live with it" rather than saying "that's not a problem at all, just stick an HTML parser on your toolchain" |
| 10:14 | <Philip`> | but anyway I'm away :-) |
| 10:19 | <annevk> | I think in practice those sentences are near identical (i.e. both are true), but you're away now... |
| 11:26 | <annevk> | Hixie, shouldn't the specification define what happens when the hyperlink cannot be parsed? |
| 11:26 | <Hixie> | ? |
| 11:26 | <annevk> | e.g. <a href="http://example,org/">test</a>; |
| 11:27 | <annevk> | what happens when you "follow a hyperlink" like that |
| 11:29 | <Hixie> | it's defined |
| 11:29 | <Hixie> | navigation algorithm, step 4. |
| 11:30 | <annevk> | ah, thanks |
| 11:31 | <annevk> | is it correct that Firefox not treating <a href="http://a b/">test</a> as a hyperlink is considered a bug? |
| 11:31 | <Hixie> | per the current spec, yes. |
| 11:32 | <jgraham> | Hixie: That doesn't seem quite right because the TAG often have an opinion on how real things are defined and try to apply principles that they derived from abstract considerations to those situations |
| 11:33 | <Hixie> | jgraham: ah well if the discussion was about an application of their principles to a real-world situation, then clearly real-world concerns must also be considered. |
| 11:42 | <Hixie> | right |
| 11:42 | <Hixie> | bet time |
| 11:42 | <Hixie> | nn |
| 11:42 | <annevk> | nn |
| 11:44 | annevk | finds http://flickr.com/photos/rohaan03/2311303100/ |
| 11:46 | <annevk> | hmm, is the <body onload> trick that simple? |
| 11:47 | <hsivonen> | annevk: on the face of it, it does look rather questionable |
| 11:48 | <annevk> | especially as some UAs also support document.onload and such |
| 11:52 | <hsivonen> | "Cookies shouldn't used as a means to identify say distinct shopping carts between users (though I'm sure it's done)" |
| 11:52 | <hsivonen> | http://lists.w3.org/Archives/Public/www-tag/2009Jan/0022.html |
| 11:52 | <hsivonen> | good luck with that |
| 11:52 | <annevk> | sessionStorage :) |
| 11:53 | <annevk> | hmm, guess I need to study all that event handler attribute text again to see what to do about XMLHttpRequest... |
| 11:54 | <annevk> | it would actually be good if WebIDL defined a binding for it, e.g. EventHandlerAttribute so most of the wording can be moved elsewhere and shared accross specs |
| 11:55 | <annevk> | heycam, ^^ |
| 12:05 | <jgraham> | annevk: It seems like seesionStorage would be just as bad from that point of view |
| 12:07 | <Philip`> | The web doesn't need architecturally impure constructs like shopping carts anyway |
| 12:13 | <Philip`> | "Cookies shouldn't used as a means to identify say distinct shopping carts between users (though I'm sure it's done) - different resources should be blessed with different URI names." doesn't sound so helpful when I want the URI http://www.amazon.co.uk/ to show me my own shopping cart |
| 12:15 | <annevk> | even the W3C uses user credentials to show people different content at the same URL |
| 12:15 | <annevk> | and it seems like a perfectly sane thing to do |
| 12:45 | <zcorpan> | Hixie: "Must be invoked whenever a beforeunload event is targeted at or bubbles through the element or object." - s/element or // |
| 12:54 | <zcorpan> | http://blog.whatwg.org/styling-ie-noscript#comment-35694 - spam? |
| 13:04 | <Lachy> | zcorpan, when I moderated that comment, I checked the site, and it didn't fit the profile of a typical spam website and seemed to be web development related, even though the comment isn't really on topic |
| 13:06 | <zcorpan> | so more a case of self-promotion |
| 13:06 | <Lachy> | yeah, that's what I thought |
| 13:07 | <Lachy> | I could mark it as spam if you think that's a better course of action, but I try to reserve that for real spam sites instead of resorting to anything that could be conceived as censorship |
| 13:08 | <zcorpan> | i don't really care either way, it just triggered my spamometer so i thought i'd mention it |
| 13:11 | <jgraham> | That's spam |
| 13:12 | <jgraham> | At best it is designed to get people to visit the mostly useless website to click on Google Ads |
| 13:14 | <Lachy> | fixed |
| 13:15 | <Dashiva> | "DTD based SGML parsers", where are these used? |
| 13:17 | <Lachy> | Dashiva, OpenSP is the major one, but its use is limited mainly to validators or non-HTML uses |
| 13:22 | <MikeSmith> | more than that, SP is the only open-source SGML parse, as far as I know |
| 13:23 | <Dashiva> | So there's little reason why a language that doesn't lend itself to DTD-based validation should support it |
| 13:23 | <MikeSmith> | well, we should be killing DTD-validation |
| 13:23 | <MikeSmith> | at every chance possible |
| 13:24 | <MikeSmith> | James Clark himself said as much |
| 13:24 | <MikeSmith> | some years ago |
| 13:25 | <MikeSmith> | "we need to put a knife in the back of SGML" (or something along those lines) |
| 13:25 | <MikeSmith> | he said |
| 13:26 | <MikeSmith> | some might say that it's fairly absurd that in 2009 the W3C Validator is still doing DTD-based validation |
| 13:26 | <Dashiva> | I agree, but I don't think people who want to support DTDs will |
| 13:26 | <Dashiva> | So a more pragmatic argument might be in order :) |
| 13:28 | <MikeSmith> | some might say that, seeing as this is the year 2009 (not 1989), people who want to support DTDs should probably not be our highest concern |
| 13:29 | <MikeSmith> | maybe the rule should be that if you mention the term "DTD" un-ironically, you get knee-capped |
| 13:32 | <Philip`> | Lachy: Judging by the university mailing lists I'm on, "spam" just means any message that you aren't personally interested in, so on the blog you should just delete any comments that don't seem to add anything useful to the post |
| 13:32 | <Lachy> | the problem is that DTD based validation has been the only reasonably reliable HTML4 validation method for many years, people have grown accustomed to them |
| 13:32 | <Dashiva> | You'd have to invent a machine that lets you kneecap people over the internet first |
| 13:33 | <Philip`> | Dashiva: Who said it has to be a machine? You could use something like Mechanical Turk to farm the work out |
| 13:33 | <Lachy> | Dashiva, the alternative is to simply send the offending person an email virus or perform a DOS attack on them |
| 13:34 | <Lachy> | or should we setup virtualkneecap.com? |
| 13:35 | <Dashiva> | I suppose a DOS attack is similar to kneecapping, in online terms |
| 13:39 | <MikeSmith> | Lachy: RELAX NG has been around since 2000 or so. .. problem was that nobody involved with HTML did much with it until 2006 or so, when fantasai (and then hsivonen) started work on whattf schema for HTML5 & WF2 |
| 13:47 | <Lachy> | MikeSmith, yes, but there's also the stigma attatched to the DTD as being the only official validation method endorsed by the spec, and alternative validators using different techniques and which didn't strictly adhere to the spec were seen as inferior |
| 13:49 | <Lachy> | even if their results were more useful in practice, like claiming unimplemented SGML shorthand features were invalid |
| 13:49 | Philip` | never even heard of any HTML validators other than validator.w3.org |
| 13:50 | <MikeSmith> | Lachy: if such sentiment exists, better to just ignore it it without comment |
| 13:50 | <MikeSmith> | Philip`: we have this thing called validator.nu |
| 13:51 | <Lachy> | Philip`, http://validator.w3.org/docs/help.html#others |
| 13:51 | <MikeSmith> | v.nu represents a corruption of the ideals |
| 13:51 | <Lachy> | there are other ones too, but I can't remember their names or URLs |
| 13:52 | <Lachy> | MikeSmith, HTML5 in general represents a corruption of many people's ideals |
| 13:52 | <Dashiva> | And of idealism in general :) |
| 13:52 | <MikeSmith> | HTML5 is an abomination |
| 13:54 | <Lachy> | it's ironic that 4 or 5 years ago, I shared the ideals of many who are complaining about HTML5 today. Though I've since been corrupted myself :-) |
| 13:54 | <MikeSmith> | Lachy: that is a sign that you beliefs are changed to easily |
| 13:55 | <MikeSmith> | next year, you'll believe something different |
| 13:55 | <Lachy> | MikeSmith, no, changing my beliefs is never easy. I'm really quite stubborn |
| 13:55 | <MikeSmith> | you? |
| 13:55 | <MikeSmith> | stubborn? |
| 13:56 | <MikeSmith> | I can't believe it |
| 13:56 | <Lachy> | yes. Don't you think so? |
| 13:56 | <MikeSmith> | no, you are the most reasonable person in the world |
| 13:56 | <MikeSmith> | you should get a special aware |
| 13:56 | <Lachy> | award? |
| 13:57 | <MikeSmith> | the Tactful and most Thougtfully Considered Opinions Award |
| 14:00 | <Lachy> | I wanted to win the Smeghead award |
| 14:01 | <MikeSmith> | too bad |
| 14:01 | <Philip`> | MikeSmith: I mean, before I was involved with HTML5 I'd never even heard of any HTML validators other than validator.w3.org |
| 14:01 | <Lachy> | although I didn't think "smeg" referred to a kind of cheese http://lastweekinhtml5.blogspot.com/2009/01/bonnie-prince-cheesie.html |
| 14:02 | <MikeSmith> | Philip`: that's of course because there are none |
| 14:02 | <MikeSmith> | or were none before hsivonen appeared |
| 14:03 | <MikeSmith> | Lachy: Mr Last Week clearly wants to have sex with you |
| 14:03 | <MikeSmith> | with you in particular |
| 14:03 | <MikeSmith> | so you can choose to accept that and make it happen, or you |
| 14:03 | <Lachy> | what?! |
| 14:03 | <MikeSmith> | can politely decline |
| 14:04 | <MikeSmith> | read between the lines, genius |
| 14:04 | <Dashiva> | Or he can lie, merely using it as a tool to figure out the secret identity of you-know-who |
| 14:05 | <Lachy> | I'm sure we'll figure out the identity of Mr Last Week one day. There's no rush though |
| 14:05 | <MikeSmith> | Lachy: your IQ is clearly greater than that of former US President George W. Bush |
| 14:05 | <MikeSmith> | which puts you in a special class |
| 14:06 | <MikeSmith> | run with it |
| 14:06 | <MikeSmith> | take advantage of it |
| 14:06 | <Dashiva> | Lachy: What if he just stops posting and disappears? Then it'll be too late |
| 14:06 | <Lachy> | woo hoo! I join the elite 90% of the world's population with an IQ greater than Bush. |
| 14:06 | <MikeSmith> | Lachy: strike while the iron is H O T hot |
| 14:08 | <MikeSmith> | Lachy: you are clearly the sorta super exemplar of our group |
| 14:08 | <MikeSmith> | tall, poised |
| 14:08 | <MikeSmith> | represent us well to the world, please |
| 14:09 | <MikeSmith> | take your responsibilities seriously |
| 14:13 | <Lachy> | what responsibilities does this new role of mine include? |
| 14:14 | <MikeSmith> | Lachy: mostly, you have to provide sexual services to any lonely ladies in need of special attention |
| 14:14 | <MikeSmith> | (as far as I read the contract at least) |
| 14:15 | <Lachy> | oh, so I'm a gigalo then |
| 14:44 | <Philip`> | The problem with http://www.w3.org/2005/10/Process-20051014/groups.html#three-month-rule is that there is no defined error-handling for the cases where the "must" requirement is violated |
| 14:44 | <Philip`> | (or if there is any then it's not implemented in practice) |
| 15:13 | <Philip`> | Quite a lot of people write <meta http-equiv="refresh" content="4" url="/index.html"> |
| 15:13 | <Philip`> | all with content="4" in particular |
| 15:17 | <Philip`> | zcorpan: Assuming you meant http-equiv=refresh (not name=refresh), it seems already work fine in Opera 9.63, so I'm not sure why you'd need to change your implementation |
| 15:54 | <karlcow> | [08:46] <MikeSmith> Lachy: RELAX NG has been around since 2000 or so. .. problem was that nobody involved with HTML did much with it until 2006 or so, when fantasai (and then hsivonen) started work on whattf schema for HTML5 & WF2 |
| 15:54 | <karlcow> | not fully true. |
| 15:55 | <karlcow> | Olivier has been exploring ways of integrating new methods of validation for a loooooooong time with NVDL and Schematron. Unfortunately nobody had the resources to create a full new engine. The issue always nails down to resources (time, and people) |
| 15:58 | <karlcow> | ;) At least if in the past Bush had been part of the W3C Team, There would have been an easy way to apologize. |
| 15:58 | <karlcow> | Damn |
| 16:26 | <jgraham> | http://codespeak.net/pipermail/lxml-dev/2009-January/004311.html |
| 16:26 | <jgraham> | I guess that competes for "worst idea ever" |
| 16:27 | <hsivonen> | jgraham: he needs OWL sameAs |
| 16:31 | <jgraham> | hsivonen: And an XSLT engine that understands OWL? |
| 16:39 | <Philip`> | Amazon EC2's HTTP API is versioned, and if your request uses e.g. ...&Version=2008-12-01&... then the response has xmlns="http://ec2.amazonaws.com/doc/2008-12-01"; |
| 16:40 | <Philip`> | I'd guess it encourages consumers to just ignore the namespace entirely, because otherwise it's more effort to update it every time you want to start using a newer API version |
| 17:04 | <Philip`> | I think http://lensco.be/ is the first place I've seen anyone write "<!Doctype html>" |
| 17:08 | Philip` | follows some links from there |
| 17:08 | <Philip`> | http://cameronmoll.com/archives/2009/01/12_resources_for_html5/ - "HTML 5 differences from HTML 4 [link to html5-diff]. Not surprising: frame and frameset no longer allowed in HTML 5. Surprising: A document from the W3C that’s actually fairly readable." |
| 17:09 | <Philip`> | "The Web Developer’s Guide to HTML 5 by W3C. I’ve not read this one yet, but it’s got colored boxes — a rarity from the W3C. That must mean it’s good." |
| 17:10 | <zcorpan> | oh, the page has this: |
| 17:10 | <zcorpan> | <META HTTP-EQUIV="refresh" content="01; url='http://aac.recruitsoft.com/servlets/CareerSection?art_ip_action=FlowDispatcher&flowTypeNo=13&pageSeq=1&art_servlet_language=en&csNo=2'>; |
| 17:10 | <zcorpan> | i.e no close " |
| 17:11 | <Philip`> | Ah, that sounds less typical |
| 17:11 | <zcorpan> | the spec bug still applies though |
| 17:12 | <Philip`> | url='...' does seem common enough that the spec needs to handle it |
| 17:15 | <zcorpan> | and we might want to discard what's after the '...' |
| 17:32 | <zcorpan> | should i blog about why people should not use the new elements (i.e. it constrains what useful stuff browsers can do with them)? |
| 17:33 | <zcorpan> | do we have such examples other than styling of headings? |
| 17:34 | <Philip`> | Seems a bit late now to tell people to stop using HTML5 elements, after they've got all excited about them |
| 17:35 | <zcorpan> | maybe |
| 17:35 | <beowulf> | i don't think it's too late, in the 'burbs people are only just discovering html5 |
| 17:35 | <Philip`> | You could just look at the extensive list of use cases that were required before the new elements were allowed into HTML5 |
| 17:36 | <zcorpan> | although i'm slightly sceptical to styling of headings anyway |
| 17:36 | <Philip`> | which surely must include more than just having a second way to style headings |
| 17:36 | <zcorpan> | digging the archives is a lot of effort :) |
| 17:37 | <smedero> | It is seems fair to raise concerns that implementors have with encountering the new elements in the wild. An explanation of what the state of support is today and why it may or may not continue to work in the future. |
| 17:37 | <smedero> | a full out call to stop using them doesn't seem good though. |
| 17:38 | <zcorpan> | yeah i didn't have in mind writing a "using html5 elements considered harmful" article |
| 17:38 | <Philip`> | It seems quite a few people have already discussed the issues browsers have with the new elements, and appropriate workarounds when necessary, so there's probably not much point writing another one of those |
| 17:39 | <zcorpan> | Philip`: but that's with current browsers, it hasn't been widely discussed what happens when browsers implement the parsing rules and apply styling etc |
| 17:40 | <zcorpan> | e.g. right now you can do <p>foo <section>bar</section> baz</p> (as a silly example) |
| 17:43 | <beowulf> | zcorpan: in the future would you not be able to do that? |
| 17:43 | <zcorpan> | beowulf: no, the <section> would imply </p> |
| 17:43 | <beowulf> | i did not know this |
| 17:43 | <zcorpan> | if you omit the last </p> the validator wouldn't complain so it might be hard to detect you're relying on it |
| 17:44 | <beowulf> | do you mean a ua would close off the para around foo and start a new one on bar? |
| 17:44 | <beowulf> | or that the validator would complain? |
| 17:44 | <zcorpan> | beowulf: no the <section> start tag would just imply a </p> before it |
| 17:45 | <zcorpan> | so it's equivalent to <p>foo </p><section>bar</section> baz</p> |
| 17:45 | <zcorpan> | which in turn is equivalent to <p>foo </p><section>bar</section> baz<p></p> |
| 17:45 | <beowulf> | cool |
| 17:45 | <zcorpan> | and the validator would complain about the stray </p> |
| 17:46 | <zcorpan> | (so the knee-jerk reaction would be to remove the </p> to silence the validator but it would still break in browsers later) |
| 17:46 | <Philip`> | Maybe the validator should emit a warning when a <section> causes a </p> to be generated |
| 17:46 | <zcorpan> | hsivonen: consider commenting out new elements in the parser until browsers support them to make the validator messages more helpful |
| 17:47 | <jgraham> | Philip`'s idea sounds better |
| 17:47 | <zcorpan> | Philip`: yeah, there's a bug about that in b.v.nu iirc |
| 17:47 | <zcorpan> | (or at least about warning about tag inference in general) |
| 17:48 | <Philip`> | Warning in general would be annoying for people who like tag inference |
| 17:48 | <zcorpan> | i agree |
| 17:48 | <Philip`> | but warning in the cases where it differs from current/legacy browser behaviour would still be useful to those people |
| 17:48 | <jgraham> | Trying to stop people using HTML 5 is a bad idea. If we dangle nice stuff in front of them and say "oh but you can't have it because it will be bad for you in the future" people are likely to just get annoyed with the whole thing |
| 17:49 | <Philip`> | People switched to using XHTML 1.0 despite it offering them no advantages whatsoever and causing subtle problems in the future, so they're bound to do the same with HTML5 |
| 17:50 | <Philip`> | See e.g. people using <section> and adding script hacks to make it work in IE, despite it being a waste of time and unnecessary complexity |
| 17:50 | <Philip`> | when <div class=section> works much better in some UAs, and no worse in any current ones |
| 17:50 | <zcorpan> | maybe we should make hsivonen emit messages about things people need to look out for and we can tell people the importance of validation :) |
| 17:50 | <jgraham> | Without the early adopters there will be no mainstream HTML5 |
| 17:51 | <jgraham> | And we already have had enough bad publicity about unreasonably long schedules |
| 17:51 | <zcorpan> | maybe it's just time for browsers to implement the new elements |
| 17:52 | <jgraham> | zcorpan: Indeed. But I guess it is much easier to say "we need to implement x that people want to use" than to just say "well x is in the spec so we should do it" |
| 17:53 | <Philip`> | If the browsers all implement it today, I guess it'd still be a year before they're released |
| 17:53 | <jgraham> | Well if they did it *today* I guess it would be sooner :) |
| 17:54 | <jgraham> | (but only if they put it in their soon-to-be-released branches which seems unlkely) |
| 17:54 | <jgraham> | s/unlkley/impossible/ |
| 17:54 | <zcorpan> | why would it be impossible? |
| 17:55 | <Philip`> | I mean if they wrote the code today, and then put it into wherever they put patches that aren't in the thing that's going to be released very soon and is too late for new features that could have significant web compatibility issues |
| 17:55 | <jgraham> | zcorpan: Because several major browsers are in feature freeze for imminent releases? |
| 17:56 | <jgraham> | (dunno what the ? was for) |
| 17:56 | <zcorpan> | jgraham: yeah but still not impossible - i think it has happened before that features have gone in after feature freeze |
| 17:57 | <Philip`> | But it seems like a pretty irresponsible thing to do, particularly for a feature that nobody cares about that much |
| 17:57 | <zcorpan> | yes :) |
| 17:57 | jgraham | should go |
| 18:17 | <zcorpan> | Philip`: http://fonts.philip.html5.org/ - very nice! :) |
| 19:02 | <Philip`> | zcorpan: The main problem is that it's a terribly ugly site :-) |
| 19:03 | <Philip`> | (The other main problem is that the code is very buggy, but I've been fixing some of those issues so hopefully it'll become slightly less rubbish) |
| 22:28 | <heycam> | annevk, fwiw batik doesn't implement @color-profile rules (or the corresponding DOM 2 Style interfaces) |
| 22:28 | <heycam> | (or the SVGColorProfileRule interface from SVG, i mean) |
| 23:37 | <annevk> | hmm, wow, Google is down |
| 23:40 | <roc> | google.co.nz is up |
| 23:41 | <annevk> | and it's over |
| 23:42 | <jcranmer> | how many corporations thought their networks were broken as a result? |
| 23:42 | <annevk> | though maybe not everything is up yet |
| 23:43 | annevk | restarted his browser... |
| 23:43 | <annevk> | slightly worrisome |
| 23:45 | <annevk> | actually, parts still seem down, e.g. reader and gmail |
| 23:45 | <annevk> | oh well, past bedtime anyway |
| 23:46 | <roc> | gmail's up for me |
| 23:46 | <roc> | maybe some datacenter blew up |
| 23:47 | <jcranmer> | with walls moving 6 inches? |