| 00:32 | <Hixie> | what's an example of a url that can't be parsed even given the parsing rules in html? |
| 00:33 | <Hixie> | "::"? |
| 00:34 | <Hixie> | no, browsers parse that... |
| 00:58 | <zewt> | going in circles with joao and not sure why |
| 01:28 | <jarek> | Hi |
| 01:28 | <annevk> | Hixie, yeah, concept-event is the preferred way of talking about Event or something that inherits from it |
| 01:28 | <jarek> | in CSS2.1 spec, why A is defined like this: |
| 01:28 | <jarek> | A a|\\0{0,4}(41|61)(\r\n|[ \t\r\n\f])? |
| 01:28 | <jarek> | while Z is defined like this: |
| 01:28 | <jarek> | Z z|\\0{0,4}(5a|7a)(\r\n|[ \t\r\n\f])?|\\z |
| 01:29 | <jarek> | the difference is the last part, why '\\z' should be treated as Z but '\\a' might not be treated as A? |
| 01:32 | <jarek> | 124\\cm is a valid LENGTH token, while 124c\\m is not? |
| 01:32 | <Hixie> | annevk: ah, because of the inheritance, ok |
| 01:32 | <Hixie> | annevk: it would be helpful imho if the dom core spec said that somewhere |
| 01:32 | <Hixie> | annevk: i thought they were different (the way "text track" and "TextTrack" are different) |
| 01:35 | <annevk> | oh, "text track" being the concept and "TextTrack" exposing it? |
| 01:35 | <annevk> | I guess it's pretty similar, but I'll make a clarification |
| 01:42 | <Hixie> | gah |
| 01:43 | <Hixie> | the semantic web guys have a way of thinking that is so utterly foreign to me it's mind blowing |
| 01:54 | <MikeSmith> | Hixie: something in particular you reading at the moment? |
| 01:54 | <MikeSmith> | bug report? |
| 01:55 | <annevk> | I guess for http://html5.org/r/6707 the pedant way would currently be /event listeners/ whose /capture/ variable is false |
| 01:56 | <annevk> | we should probably make it a "capture flag" given that it's a boolean, but that would actually make defining it more verbose |
| 01:56 | <annevk> | Hixie, fwiw, "DOM Range" is gone and part of DOM4 now |
| 01:58 | <jarek> | I have done some testing and it turns out that chars from 'a' to 'f' might not be escaped with '\' in CSS |
| 01:58 | <jarek> | why is it so? |
| 01:59 | <annevk> | because \ is also used for Unicode character escapes |
| 02:02 | <jarek> | is it allowed to have Unicode character escapes *anywhere* in the stylesheets? |
| 02:02 | <annevk> | pretty much |
| 02:02 | <jarek> | I thought those were allowed only inside strings |
| 02:03 | <annevk> | no CSS is crazy |
| 02:03 | <annevk> | they did not go with simplest syntax possible |
| 02:03 | <jarek> | that's going to complicate tokenizer implementation :/ |
| 02:03 | <annevk> | oh yes |
| 02:03 | <annevk> | that's why at-rules are defined as @{N}{A}{M} etc. |
| 02:04 | <annevk> | each of those characters can be escaped |
| 02:04 | <annevk> | why? |
| 02:04 | <annevk> | because crazy |
| 02:04 | <jarek> | I think I have an idea |
| 02:04 | <jarek> | I will run the stylesheet through a processor that converts all escapes into regular signs before tokenization |
| 02:05 | <jarek> | it's also lame that comments are allowed everywhere, even between '!' and 'important' |
| 02:05 | <jarek> | what was the point of that? |
| 02:06 | <jarek> | is something like '! /* this is important flag*/ !important' really needed? |
| 02:16 | <annevk> | even -/**/2em |
| 02:16 | <annevk> | there is no point |
| 02:16 | <annevk> | it's just how that tokenizer language works to some extent I believe |
| 02:17 | <annevk> | I think we can still get away with making it much much simpler, but nobody is really interested in it I guess |
| 02:54 | <Hixie> | MikeSmith: the task force |
| 02:54 | <MikeSmith> | ah |
| 02:54 | <Hixie> | MikeSmith: jeni dragged me into some thread about multiple types |
| 02:55 | <Hixie> | MikeSmith: so i asked what the use case was |
| 02:55 | <Hixie> | MikeSmith: and basically the answer was "hope" |
| 02:55 | <MikeSmith> | I see |
| 02:55 | <MikeSmith> | I think somebody filed a spec bug about that yesterday |
| 02:55 | <Hixie> | "we're publishing data because we hope one day it'll be used, and we need multiple types because we're trying to use as many types as possible" |
| 02:55 | <annevk> | Hixie, you want a bug on removing DOMRANGE? |
| 02:55 | <Hixie> | annevk: send mail |
| 02:55 | <Hixie> | annevk: trying to get bugs to zero so i can get back to mail, i'm way behind on mail :-) |
| 02:56 | <Hixie> | course this means that right now if you file a bug it'll get done faster :-) |
| 02:58 | <annevk> | it's not like removing an obsolete reference is high priority :) |
| 02:58 | <Hixie> | :-) |
| 03:16 | <annevk> | god |
| 03:16 | <annevk> | sometimes I wonder why I even bother trying to get people their API design correct |
| 03:16 | <zewt> | fighting the fight |
| 03:16 | <annevk> | and at the same time take a lot of flack for not having constructors in the DOM |
| 03:18 | <annevk> | there's this urge in people that says "you know, I know better than all these other guys, lets do the API this way" and many web developer kittens die |
| 03:18 | <zewt> | heh, i prefer python's design--there are no constructors and everything's just a factory |
| 03:18 | <annevk> | but this person does not think about the kittens |
| 03:18 | <annevk> | only about his own sense of style |
| 03:18 | <annevk> | this was not about the constructors btw, I think we should have more of them |
| 03:19 | <annevk> | this was about having constants for strings, which are intrinsically meaningful |
| 03:19 | <annevk> | oh, I know how to solve this, remove string constants from IDL |
| 04:59 | <TabAtkins_> | Does anyone know off the top of their head what spec box-sizing appears in? |
| 05:01 | <jarek> | TabAtkins: http://www.w3.org/TR/css3-ui/#box-sizing0 |
| 05:01 | <jarek> | TabAtkins: I use this site for finding where the properties come from: http://meiert.com/en/indices/css-properties/ |
| 06:05 | <annevk> | I wonder if the people talking about querySelector realize that you cannot simply substring on ":scope" |
| 06:06 | <annevk> | Still seems like a bad idea to me to design it in a way that does not look at the entire tree |
| 06:15 | <annevk> | If A inherits from B, B is a ??? of A |
| 06:15 | <annevk> | (with respect to interfaces) |
| 06:18 | <annevk> | oh well, went with verbosity instead |
| 06:21 | <Hixie> | B is a superclass |
| 06:21 | <Hixie> | or I guess superinterface, if A and B are interfaces? |
| 06:34 | <annevk> | "I can't believe the politics involved in the OWL for JSON mailing list." didn't know there was such a thing |
| 06:34 | <annevk> | guess I don't want to know more |
| 06:58 | <annevk> | Hixie, btw, given the arguments in the Web Intents thread, Microdata really should use simple string identifiers as well... |
| 06:59 | <annevk> | too late now I guess |
| 06:59 | <Hixie> | simple string identifiers for what? |
| 06:59 | <annevk> | instead of "http://schema.org/Blog"; we should just have "blog" |
| 07:00 | <annevk> | and if Example wants his own blog, they could have "example-blog" or some such |
| 07:01 | <annevk> | because in the end, only a few vocabularies will be supported |
| 07:01 | <Hixie> | well we can still do that i guess |
| 07:01 | <Hixie> | since while the syntax says they're urls, they aren't resolved and they are treated as opaque |
| 07:01 | <Hixie> | the API currently drops non-URL values |
| 07:02 | <Hixie> | still, i don't think it's a big deal |
| 07:02 | <Hixie> | the microdata feature is explicitly intended to be used for lots of vocabs |
| 07:03 | <annevk> | I guess, but simple strings scale too, or simple strings with a prefix |
| 07:04 | <annevk> | but then I have a hard time seeing a lot of people taking the effort to use all this additional markup so I don't really feel that strongly about making it simple |
| 07:05 | <Hixie> | yeah, we could have gone with the rel="" approach as well |
| 07:05 | Hixie | shrugs |
| 07:05 | <Hixie> | best to let it be |
| 07:06 | <annevk> | i guess if in like 5 years only schema.org is adopted we can just alias what they have and make it simple for the masses |
| 07:06 | <annevk> | experiment a bit more first |
| 08:24 | <annevk> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=14516 I wish the IETF held to the same values |
| 08:38 | <annevk> | Well, per my non-scientific twitter survey, it seems web developers would like markup literals |
| 08:38 | <annevk> | The only negative responses thus far were from Arve (says it might break text editors) and glazou (no reason given) |
| 08:43 | <krijn> | E4X! |
| 08:47 | <frank_salim> | annevk: is that something people are asking for? |
| 08:50 | <jacobolus> | annevk: the thing I don't like is that people will try to copy/paste stuff around, and there are all kinds of edge cases that will break |
| 08:51 | <jacobolus> | and the result will be confusion |
| 08:51 | <jacobolus> | things that are conceptually strings should have some delimiters :) |
| 08:53 | <annevk> | they are not conceptually strings |
| 08:54 | <jgraham> | annevk: It's not really clear to me that using strings instead of constants is better btw. Apart from the feature detection issue, constants work better with IDEs for autocompletion |
| 08:55 | <annevk> | jgraham, so you would prefer people type responseType = XMLHttpRequest.RESPONSE_JSON rather than responseType = "json" |
| 08:55 | <jgraham> | annevk: People who use IDEs might prefer the latter certainly |
| 08:55 | <annevk> | I find the IDE argument not really compelling |
| 08:55 | <jgraham> | er former |
| 08:56 | <jgraham> | Any particular reason? |
| 08:56 | <zcorpan> | we *could* have both (making the constant return a string) |
| 08:56 | <annevk> | it makes the code a whole lot harder to read; the only benefit seems to be that it makes it easier to integrate it with existing tools |
| 08:56 | <annevk> | zcorpan, it would return a string |
| 08:57 | <jgraham> | I don't think it is harder to read |
| 08:57 | <annevk> | o_O |
| 08:57 | <jgraham> | It is a bit ugly |
| 08:57 | <jgraham> | But totally comprehensible |
| 08:57 | <annevk> | it's extremely ugly and verbose |
| 08:57 | <zcorpan> | you could write x.responseType = x.RESPONSE_JSON also |
| 08:58 | <jgraham> | In the average js library this is a molecule in a drop in the ocean in terms of the difficulty of understanding what the code does |
| 08:58 | <annevk> | zcorpan, doesn't really make a difference |
| 08:58 | <annevk> | jgraham, if it's in a library there's even less need for constants |
| 08:58 | <zcorpan> | annevk: makes it a bit shorter and less ugly |
| 08:58 | <annevk> | jgraham, because you'd just do requestJson(url) or some such |
| 08:59 | <jgraham> | annevk: By "library" I just meant "body of code" |
| 09:00 | <annevk> | jgraham, it seems people developing large libraries care a lot about brevity still |
| 09:00 | <annevk> | jgraham, ask e.g. Alex Russell |
| 09:00 | <jgraham> | (it is also quite nice to have clear rules about case; everyone knows that constants are always uppercase whereas JSON could be spelt "json" or "JSON" and so could "2d" vs "3D") |
| 09:00 | <annevk> | anyway if you feel like making a case for constants go ahead :) |
| 09:01 | <jgraham> | annevk: Alex Russel seems to be about 50% troll so I have difficulty taking him seriously |
| 09:01 | <jgraham> | *russell |
| 09:02 | <annevk> | I always have the feeling you are about 50% or more against every idea mentioned; still try to take you seriously though :) |
| 09:02 | <jgraham> | Heh |
| 09:02 | <jgraham> | I'm not sure that's true |
| 09:03 | <jgraham> | Although about 50% of the things that I thought were really good ideas turned out to not be :) |
| 09:22 | <annevk> | Hixie, is there some construct for tasks to have conditions? |
| 09:23 | <annevk> | Hixie, like do this task unless something got cancelled along the way? |
| 09:26 | <annevk> | It's funny though how people suddenly jump up to support string constants while there was never a single suggestion for them for either the <canvas> API or XMLHttpRequest |
| 09:27 | <annevk> | This is the reason asking forgiveness is so much better |
| 09:27 | <jgraham> | I find the canvas thing moderately annoying |
| 09:27 | <jgraham> | and don't follow XHR much |
| 09:27 | <jgraham> | So my experience suggests that no-constants doesn't work that well |
| 09:28 | <annevk> | You use an IDE? |
| 09:28 | <jgraham> | Nope |
| 09:28 | <jgraham> | But it really took me a while to remember whether it should be "2d" or "2D" |
| 09:29 | <annevk> | Oh that string |
| 09:29 | <annevk> | enums of that kind should simply always be lowercase |
| 09:29 | <annevk> | simple enough |
| 09:31 | <jgraham> | Yes, but different from either other named constants or the normal english usage of "2D" |
| 09:31 | <annevk> | Is there a browser where HTML is still fast? |
| 09:31 | <annevk> | yeah man, hard times |
| 09:32 | <annevk> | Chrome is superslow these days |
| 09:33 | <annevk> | I guess I can queue a task that says to check "unless cancelled do x |
| 09:33 | <annevk> | " |
| 09:33 | <annevk> | hmm that would still be quite hairy |
| 09:34 | <TabAtkins_> | Anyone got an IE that they can visit http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1214 in? |
| 09:34 | <TabAtkins_> | Any IE will do. |
| 09:35 | <krijn> | TabAtkins_: what do you want to know? |
| 09:35 | <TabAtkins_> | Are the two marquees the same height? And does the text overflow? |
| 09:35 | <krijn> | Yes, no |
| 09:35 | <krijn> | (IE8) |
| 09:35 | <TabAtkins_> | Neither overflows? Interesting. |
| 09:35 | <TabAtkins_> | So both are tall enough to fully contain their text. Huh. |
| 09:35 | <krijn> | No |
| 09:36 | <krijn> | They clip the text |
| 09:36 | <TabAtkins_> | Oh, that's what I meant. ^_^ clipping is an overflow strategy. |
| 09:37 | <krijn> | https://skitch.com/krijnhoetmer/gnfy3/ie8-marquee-stuffs |
| 09:39 | <espadrine> | annevk: About the responseType = XMLHttpRequest.RESPONSE_JSON rather than responseType = "json" argument, wouldn't having Ruby's symbols in JS solve the issue? |
| 09:40 | <annevk> | dunno what Ruby's symbols are |
| 09:40 | <espadrine> | mostly, they behave just like strings |
| 09:40 | <jgraham> | Something like responseType = :json |
| 09:40 | <jgraham> | I think |
| 09:41 | <espadrine> | but they are in some sort of global hashtable |
| 09:41 | <espadrine> | so that we only compare constant integers most of the times |
| 09:41 | <annevk> | I personally don't really see why an IDE can't provide support for strings |
| 09:42 | <annevk> | espadrine, sounds neat if JavaScript had that already :) |
| 09:42 | <espadrine> | that can be fixed… well, within 3 years at least |
| 09:43 | <jgraham> | annevk: it seems like a much harder problem to track that x is a XHR object so that you know that x.responseType should be a string corresponding to an XHR response type than to just know that the global XMLHttpRequest object has some constants |
| 09:45 | annevk | shrugs |
| 09:49 | <zcorpan> | annevk: the thing that cancels should just say to remove the task from the queue, i think |
| 09:50 | <annevk> | so this is for fullscreen |
| 09:51 | <annevk> | you queue a task for each document (cannot do one task because they can be cross-origin) |
| 09:51 | <annevk> | then you do some asynchronous animation which can be aborted |
| 09:51 | <annevk> | at that point one of those tasks might have already done something |
| 09:52 | <zcorpan> | so half of the documents will have run the task and the other half haven't ? |
| 09:52 | <annevk> | that could happen in theory I think |
| 09:52 | <TabAtkins_> | Thanks, krijn . |
| 09:53 | <annevk> | i guess when that happens you notify those documents that things have been changed again |
| 09:53 | <zcorpan> | why can't you just let the rest of the documents run the task too then? |
| 09:53 | <annevk> | so you need to keep track of where events have dispatched |
| 09:53 | <annevk> | zcorpan, yeah, and then dispatch another set of events to notify it has changed again? |
| 09:53 | <annevk> | that might be easiest |
| 09:53 | <zcorpan> | yeah |
| 10:06 | <MikeSmith> | can somebody please visit http://w3c-test.org/framework/test/DUMMY/single/attributes.html/ |
| 10:06 | <MikeSmith> | and just press the Fail button at the bottom |
| 10:07 | <MikeSmith> | test framework is not properly collecting results when I visit it |
| 10:08 | <MikeSmith> | *not properly recording |
| 10:08 | <MikeSmith> | hmm, or more like "not properly reporting" |
| 10:08 | <MikeSmith> | I can see results getting entered into the DB |
| 10:08 | <MikeSmith> | but not getting reported back |
| 10:12 | <zcorpan> | done |
| 10:12 | <zcorpan> | is that for manual tests? |
| 10:13 | <zcorpan> | can there be a button for "this test can be automated, tell the test author to automate it" ? |
| 10:14 | <zcorpan> | maybe w3c-test doesn't keep track of test authors |
| 10:16 | <MikeSmith> | there is a way you can automatically run it and submit the results |
| 10:16 | <MikeSmith> | http://w3c-test.org/framework/suite/DUMMY/ |
| 10:17 | <MikeSmith> | if you go there and select the "Submit test results automatically when possible" option |
| 10:19 | <zcorpan> | seems Hixie is in denial about the name DOM4 |
| 10:20 | <jgraham> | Should of called it DOM4Web Then everyone could have hated on it |
| 10:22 | <annevk> | once we sort out living standards I'll just name it "DOM Standard" like HTML is "HTML Standard" |
| 10:23 | <MikeSmith> | sigh |
| 10:23 | <MikeSmith> | I figured out my problem |
| 10:23 | <annevk> | there's a yay in there too |
| 10:24 | <MikeSmith> | the framework is currently hard-coded to expect every test case to have a spec fragment ID associated with it |
| 10:28 | <annevk> | I updated the Fullscreen specification somewhat |
| 10:28 | <annevk> | I have not yet addressed the problem mentioned above adequately, but I did simplify it a whole lot |
| 10:29 | <annevk> | And addressed the problem of not dispatching fullscreenchange on each document |
| 10:29 | <annevk> | I removed Document.fullscreen as currently it's no different from Document.fullscreenElement |
| 10:30 | <annevk> | I guess I will email the list later as I have to go |
| 10:30 | <annevk> | http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html |
| 10:57 | <decthomas> | hi TabAtkins |
| 10:57 | <decthomas> | just posted this tweet http://twitter.com/#!/decthomas/status/126958851072327680 |
| 10:57 | <decthomas> | can you help me out ? :) |
| 11:04 | <decthomas> | or anyone else for that matter :) |
| 11:27 | <zcorpan> | experience suggests that people will copy examples verbatim even if the example says to change placeholder values - http://www.w3.org/Bugs/Public/show_bug.cgi?id=14117 |
| 11:28 | <annevk> | Ms2ger, do you have better terminology? |
| 11:28 | <annevk> | Ms2ger, I did not get further than "event listener whose capture variable is false" which is what we already have |
| 11:45 | <zcorpan> | enumSupportedValues(XMLHttpRequest, 'responseType') |
| 11:46 | <annevk> | over engineering? |
| 11:47 | <zcorpan> | likely :) |
| 14:16 | <MikeSmith> | this is crashing my Opera 11.52: |
| 14:16 | <MikeSmith> | http://w3c-test.org/framework/test/DUMMY/auto/Range-cloneContents.html/ |
| 14:17 | <miketaylr> | me too, boooooo |
| 14:18 | <wilhelm> | Boom. Indeed. |
| 14:32 | <smaug____> | using range is an easy way to crash any engine |
| 14:33 | <smaug____> | unfortunately |
| 14:33 | <smaug____> | s/crash/crash or hang/ |
| 15:06 | <krijn> | Wil je er zelf een? |
| 15:06 | <krijn> | Whoops |
| 15:08 | <Drogos> | Hi, I have two ideas / suggestions for changes to the html standard, where should I post them? |
| 15:08 | <zcorpan> | whatwg⊙wo |
| 15:08 | <annevk> | (need to subscribe first) |
| 15:10 | <Drogos> | No forum or such where my inbox does not get affected? |
| 15:11 | <annevk> | there's forums.whatwg.org |
| 15:11 | <Drogos> | ah, good, thanks :) |
| 15:14 | <annevk> | AryehGregor, could you please revert http://dvcs.w3.org/hg/webapps/rev/8879ca39afaa |
| 15:14 | <annevk> | AryehGregor, tests are not supposed to be run on dvcs, they are checked out on w3c-test.org |
| 15:30 | <zcorpan> | Drogos: however, spec feedback on the forums usually doesn't get to the spec editor's attention. i'd suggest you file a bug instead if you don't want to subscribe |
| 15:31 | <zcorpan> | "(I killed the useless testharnessreport.js references at the same time, instead |
| 15:31 | <zcorpan> | of updating them. As far as I can tell, we aren't supposed to use it anymore.)" |
| 15:31 | <zcorpan> | we aren't? |
| 15:31 | <zcorpan> | jgraham: ^ |
| 15:36 | <jgraham> | What? |
| 15:36 | <jgraham> | Where is that from? |
| 15:37 | <Drogos> | aha, thanks zcorpan :) |
| 15:40 | <zcorpan> | http://dvcs.w3.org/hg/webapps/rev/8879ca39afaa |
| 15:41 | <jgraham> | AryehGregor: We are still supposed to use testharnessreport.js |
| 15:41 | <jgraham> | AryehGregor: That patch is exactly wrong |
| 15:42 | <jgraham> | using /resources/testharness.js is right and using an absolute url is wrong |
| 15:42 | <jgraham> | The tests work on w3c-test.org |
| 15:52 | <annevk> | just before I asked for a revert |
| 15:52 | <annevk> | changes like that really ought to be discussed first |
| 15:53 | <jgraham> | Where did you ask? |
| 15:54 | <annevk> | here on IRC |
| 15:55 | <jgraham> | I see |
| 15:55 | <jgraham> | I thought maybe there was a mailing list I wasn't on |
| 15:56 | <annevk> | well I'm sure that's true too :) |
| 16:03 | <MikeSmith> | easy enough to roll that change back |
| 16:03 | <MikeSmith> | I can understand why Aryeh made that change |
| 16:03 | <MikeSmith> | I probably would have done the same if I were him and trying to get stuff to work |
| 16:04 | <zewt> | it'd be nice if the spec comment box didn't overlap the spec; it's annoying that whenever you search for text in firefox, the text it finds ends up hidden underneith the comment overlay |
| 16:04 | <MikeSmith> | from the way things are set up, it's not very clear that the tests are intended to be executed from a different host |
| 16:04 | <zewt> | also underneath (why do I always do that?) |
| 16:09 | <MikeSmith> | I like "underneith" better |
| 16:10 | <MikeSmith> | it looks more similar to "Kool Keith" |
| 16:10 | <MikeSmith> | and somehow seems slightly closer to "underthings" as well |
| 16:11 | <zewt> | can I use my native speaker card and declare it a correct alternative |
| 16:11 | <zewt> | google says 311000 vs. 108 million; i guess not :( |
| 16:14 | <jgraham> | MikeSmith: Yes, it is an understandable mistake to make |
| 16:33 | <dglazkov> | good morning, Whatwg! |
| 16:33 | <Drogos> | I was on the html5 code camp in Norway last year, is anyone of the people from that camp here? |
| 17:39 | <Hixie> | annevk5: just start the task with a check for the condition and if it's not true don't do anything |
| 17:40 | <Hixie> | zcorpan: not in denial about the name, i can just never work out what it is, it keeps changing! |
| 17:51 | <smaug____> | interesting. Chrome + Gnome 3 can go to state where you can't even close Chrome |
| 17:51 | <smaug____> | nor actually do anything with it |
| 18:16 | <Hixie> | ok julian has just crossed the threshold from wasting my time to actively harming the spec |
| 18:25 | <hober2> | Hixie: what did he do now? |
| 18:25 | <Hixie> | first he asked for me to move the definition of rel=sidebar to the wiki instead of in the spec |
| 18:26 | <Hixie> | so i did that |
| 18:26 | <Hixie> | now he's asking for the text that actually defines how sidebars work to be removed |
| 18:26 | <Hixie> | which would break the definition of rel=sidebar in the wiki |
| 18:26 | <hober> | is he suggesting that there be a separate sidebar spec? |
| 18:26 | <hober> | or simply that the feature be dropped? |
| 18:26 | <Hixie> | neither, he's just asking for the text to be removed |
| 18:27 | <Hixie> | a separate sidebar spec wouldn't really work since it would have to do invasive patches to the html spec |
| 18:27 | <hober> | indeed |
| 20:12 | <adtykfhyipoh> | Hello |
| 20:13 | <adtykfhyipoh> | Can I have some help here? |
| 20:14 | <adtykfhyipoh> | Hello? |
| 20:21 | <adtykfhyipoh> | MikeSmith do you know about Canavs? I need some help |
| 20:24 | <Philip`> | adtykfhyipoh: You should just ask your question, and then someone might answer it |
| 20:25 | <adtykfhyipoh> | I have been asking for hours but no one answered. Since then, I figured it out myself. Usually I wait for someone to join then ask them so they have the window open and they can see it |
| 20:26 | <adtykfhyipoh> | In fact Philip` I have done that to you in the past |
| 20:30 | <miketaylr> | so what is the actual question? |
| 20:34 | <adtykfhyipoh> | Well I was trying to figure out how to make a canvas object move along a line, but I figured it out. |
| 20:34 | <adtykfhyipoh> | Bye |
| 20:34 | <bga_> | heh |
| 20:34 | <miketaylr> | later |
| 20:34 | <miketaylr> | :) |
| 20:35 | <bga_> | miketaylr but is it real? Opera 12 support window.onerror? |
| 22:19 | <jgraham> | Hixie: I still don't see that a javascript IDE can really know that x.responseType should take the values from XMLHttpRequest.responseType without actually running the code |
| 22:22 | <Hixie> | how can it know it should take the value XMLHttpRequest.WHATEVER? |
| 22:23 | <bga_> | jgraham window.XMLHttpReqest = ... my wrapper |
| 22:24 | <zcorpan> | Hixie: so about onerror. what is unclear? |
| 22:24 | <Hixie> | zcorpan: all of the bugs were way too vague, i had no idea what you meant |
| 22:25 | <zcorpan> | ok |
| 22:25 | <Hixie> | zcorpan: e.g. "If the script is not same-origin, window.onerror should be invoked with arguments ("Script error.", "", 0)" -- which script? same-origin with what? what window? why fire it at all? etc |
| 22:25 | <Hixie> | when should it be fired? |
| 22:25 | <heycam> | jgraham, I expect the argument is that the author will type "XMLHttpRequest." and can then do completion |
| 22:26 | <heycam> | jgraham, but otherwise yes it would require some analysis to work out what function is really being called and what values it can be called with |
| 22:26 | <Hixie> | heycam: that's jgraham's argument. My argument is that the IDE should just guess that x.responseType is the XMLHttpRequest.responseType attribute (based on looking at what |x| is last initialized to, e.g.) and knowing that responseType takes certain strings. |
| 22:27 | <Hixie> | that = that the author will type "XMLHttpRequest." and can then do completion |
| 22:27 | <jgraham> | Hixie: It can't. But it can know that if you type XM then XMLHttpRequest is a valid completion and then if you type . it can list all the other completions |
| 22:27 | <Hixie> | jgraham: that's a pretty lame IDE |
| 22:27 | <jgraham> | Hixie: How can you do better |
| 22:27 | <jgraham> | ? |
| 22:27 | <jgraham> | With javascript? |
| 22:27 | <zcorpan> | Hixie: so it's not actually the scirpt's origin, but the script's *URL's* origin, compared to the script's origin |
| 22:27 | <heycam> | Hixie, I think that is possible too. once you've done the analysis to know that you're using XHR's responseType, you can autocomplete for property names, strings, whatever |
| 22:27 | bga_ | just use notepad++ |
| 22:28 | <Hixie> | zcorpan: don't tell me here, put it in the bug :-) |
| 22:28 | <Hixie> | heycam: right |
| 22:28 | <zcorpan> | will do |
| 22:28 | <Hixie> | jgraham: you don't have to be perfect, you just have to be good enough to handle non-obtuse code |
| 22:28 | <Hixie> | zcorpan: awesome, thanks |
| 22:28 | <heycam> | maybe browsers will expose their type inference results at some point to make this easier |
| 22:28 | <heycam> | Hixie, yeah it wouldn't be the first IDE whose autocomplete you could trick |
| 22:29 | <Hixie> | indeed |
| 22:29 | <jgraham> | Seems like it is at least rather non trivial in any case where you don't declare the variable statically in the same function |
| 22:29 | <Hixie> | tricking an IDE autocomplete is like tricking a bicycle pump |
| 22:29 | <Hixie> | the only loser is yourself |
| 22:29 | <jgraham> | If I write function (x) {x.responseType = |
| 22:30 | <Hixie> | jgraham: you can guess pretty easily that "responseType" might be an XHR responseType, even without looking at the variable it's used on |
| 22:30 | <jgraham> | it seems highly unclear how it can know nything |
| 22:30 | <heycam> | I'm assuming that with the kind of IDE assistance being argued for on the list, you could start typing "x.responseType = Node.", press tab, and get a list of node types |
| 22:30 | <jgraham> | Well yeah it could do that. Sucks if there is more than one possibility though |
| 22:30 | <heycam> | so not completely helpful, you need to know the constant is on XMLHttpRequest |
| 22:31 | <jgraham> | heycam: Node.? where is that from? |
| 22:31 | <jgraham> | Oh I see |
| 22:31 | <heycam> | jgraham, you type it. this is when you're typing some code I assume |
| 22:31 | <jgraham> | Well yes, you need to know what type of object it is |
| 22:32 | <Hixie> | how do you know that Node is the Node we defined? |
| 22:32 | <Hixie> | anyone in JS can override Node |
| 22:32 | <jgraham> | and guess that the object's constants live on its interface object |
| 22:32 | <Hixie> | var Node = null; |
| 22:32 | <heycam> | it's a good question, it'd be another assumption unless you have wicked analysis |
| 22:32 | <jgraham> | Sure, but you can get it right in a lot more situations than with pure strings |
| 22:32 | <Hixie> | if you can just guess that Node is the Node interface we spec, then why not just guess that responseType is is the XHR responseType? |
| 22:33 | <jgraham> | Because one is likely to be right and the other is quite likely to be wrong? |
| 22:33 | <Hixie> | responseType being the one likely to be right and Node likely to be wrong? |
| 22:33 | <jgraham> | Who redefines Node in their code? |
| 22:33 | <jgraham> | I men people add to it |
| 22:33 | <Hixie> | who uses responseType in their code? |
| 22:34 | <Hixie> | it doesn't have to be perfect |
| 22:34 | <Hixie> | just has to be good enough |
| 22:34 | <jgraham> | Seems like a reasonable name to use when you have a response with a type |
| 22:34 | <Hixie> | the drop down can easily just say "XMLHttpRequest.responseType values: \n "this" \n "that" \n FooBar.responseType values: \n "this" \n "that"" |
| 22:34 | <jgraham> | And I'm sure there are other examples where the DOM reuses an attribute name to mean different things on differnet interfaces |
| 22:35 | <Hixie> | i see no problem here |
| 22:35 | <jgraham> | Anyway I don't really know what IDEs actually do |
| 22:35 | <jgraham> | But I would guess they will get the named constants right and not help with the string constants |
| 22:36 | <franksalim> | has anyone mentioned that named constants are discoverable without documentation? |
| 22:36 | <franksalim> | by looking at the object? |
| 22:37 | <jgraham> | franksalim: Yes |
| 22:37 | <franksalim> | ok, good. that seems very compelling to me |
| 22:38 | <jgraham> | heycam: So, in other questions, why are attributes on prototypes not on instances? |
| 22:38 | <jgraham> | zcorpan points out that it can help feature detection |
| 22:38 | <jgraham> | But to me it seems like a very odd setup |
| 22:38 | <heycam> | jgraham, because it's common behaviour across all instances of a particular interface? |
| 22:39 | <heycam> | jgraham, seemed natural to me |
| 22:39 | <jgraham> | heycam: An attribute is a property of an instance |
| 22:39 | <heycam> | jgraham, sure, but I think that modelling really only works if you are using data properties |
| 22:40 | <heycam> | jgraham, I think it's fine for internal state to be modelled with an accessor property coming from a prototype |
| 22:40 | <zcorpan> | heycam: it's not defined what attributes on the prototype should return, or is it? |
| 22:40 | <heycam> | zcorpan, if you do Node.prototype.nodeType? |
| 22:40 | <heycam> | zcorpan, defined to throw |
| 22:40 | <jgraham> | Conceptually it feels wrong to say that the attribute is a property of the prototypical object rather than of the actual object |
| 22:41 | <zcorpan> | heycam: ah |
| 22:41 | <heycam> | jgraham, I can see where you're coming from |
| 22:41 | <heycam> | jgraham, especially if you think of Node.prototype as a prototypical Node |
| 22:41 | <heycam> | jgraham, though in practice of course it's not itself a Node |
| 22:43 | <jgraham> | Right. |
| 22:43 | <jgraham> | My argument is entirely that the model used does not match the most likely mental model of authors |
| 22:44 | <heycam> | probably true |
| 22:45 | <jgraham> | Who might expect some_node.hasOwnProperty("tagName") to be true |
| 22:45 | <heycam> | especially if unfamiliar with accessor properties |
| 22:45 | <jgraham> | s/node/element/ |
| 22:45 | <heycam> | ("tagName" in some_node is true tho) |
| 22:45 | <jgraham> | Yeah |
| 22:45 | <heycam> | an author might also expect some_node.hasOwnProperty("appendChild") to be true for the same reason |
| 22:45 | <heycam> | unless they have some experience with using prototypes to write "classes" |
| 22:46 | <heycam> | such an author probably isn't using hasOwnProperty though :) |
| 22:46 | <jgraham> | Right, but it is easier to understand that shared behaviour is a property of the "superclass" |
| 22:46 | <jgraham> | Well doesn't Crockford promote hasOwnProperty? |
| 22:46 | <jgraham> | At least for enumeration |
| 22:46 | <heycam> | don't know... |
| 22:47 | <jgraham> | for (foo in bar) {if bar.hasOwnProperty(foo) {/*do stuff*/}} |
| 22:47 | <jgraham> | So people might come across it that way |
| 22:48 | <heycam> | ok |
| 22:48 | <heycam> | well, I haven't really had any pushback on what's in the spec at the moment. but you're welcome to start a thread on the list about it! |
| 22:48 | <bga_> | if(!obj.hOP(k)) break is better |
| 22:49 | <jgraham> | bga_: doesn't that make assumptions about the order of enumeration? |
| 22:49 | <jgraham> | I assure you that they are not supported by the spec :) |
| 22:49 | <bga_> | * continue |
| 22:49 | <bga_> | sorry |
| 22:49 | <jgraham> | Ah, OK |
| 22:50 | <bga_> | but break works too |
| 22:50 | <jgraham> | heycam: I fear that list |
| 22:50 | <bga_> | for non IE |
| 22:50 | <jgraham> | :) |
| 22:50 | <heycam> | :) |
| 22:50 | <heycam> | i tend to reply in bursts to minimise exasperation :) |
| 22:51 | <jgraham> | Also, iven zcorpan's point, I'm not sure whether it is worth pushing for a change |
| 22:51 | <bga_> | jgraham i just have Object#_each like Array#forEach |
| 22:51 | <jgraham> | I *think* only gecko implements the current spec |
| 22:51 | <jgraham> | But that is from memory and might be outdated even if it was once true |
| 22:51 | <jgraham> | (my memory is quite terrible) |
| 22:52 | <heycam> | heh |
| 22:53 | <heycam> | pretty sure we do accessors for attributes tho |
| 22:54 | <zcorpan> | Hixie: clearer now? |
| 22:54 | <zcorpan> | webkit and opera don't match the spec |
| 22:54 | <zcorpan> | no idea about ie |
| 22:55 | <heycam> | zcorpan, oh I've been meaning to test, what about the new Opera.next release? |
| 22:55 | <heycam> | zcorpan, since they do ES5 now |
| 22:55 | <zcorpan> | same |
| 22:55 | <heycam> | s/they/you/ :) |
| 22:55 | <heycam> | ok |
| 22:56 | <zcorpan> | i don't object to changing the spec to match opera/webkit/ie (?), the only thing is that it makes it a bit harder for authors to do feature detection |
| 22:56 | <heycam> | zcorpan, how so? |
| 22:56 | <heycam> | beacuse you have to create an instance first? |
| 22:56 | <zcorpan> | yes |
| 22:56 | <heycam> | k |
| 22:57 | <zcorpan> | consider WebSocket |
| 22:57 | <zcorpan> | checking the prototype is a one-liner |
| 22:57 | <zcorpan> | var support = 'binaryType' in WebSocket.prototype; |
| 22:57 | <zcorpan> | creating an instance without side effects is harder |
| 22:58 | <zcorpan> | and not a one-liner :) |
| 22:58 | <bga_> | not so |
| 22:58 | <bga_> | just small wrapper |
| 22:59 | <Hixie> | zcorpan: yeah, much better. thanks. |
| 22:59 | <bga_> | which do real init if you perform real actions |
| 22:59 | <Hixie> | zcorpan: looks like the spec is pretty vague about the onerror arguments right now anyway, so i guess i'll use those bugs as an opportunity to clean it up |
| 23:00 | <zcorpan> | var support = (function() { |
| 23:00 | <zcorpan> | var s = new WebSocket('ws://example.invalid/'); |
| 23:00 | <zcorpan> | return 'binaryType' in s; |
| 23:00 | <zcorpan> | })(); |
| 23:00 | <zcorpan> | ok, not that hard |
| 23:00 | <heycam> | or 'binaryType' in new WebSocket... |
| 23:00 | <heycam> | but yes your point is generally true |
| 23:00 | <franksalim> | zcorpan: does that cause a DNS lookup for invalid? |
| 23:00 | <bga_> | except user will see error in console |
| 23:00 | <zcorpan> | franksalim: yes |
| 23:00 | <Hixie> | you really don't want to be creating a WebSocket just to do feature detection |
| 23:00 | <franksalim> | so it isn't completely side effect free... |
| 23:01 | <zcorpan> | right |
| 23:01 | heycam | gtg |
| 23:06 | <zcorpan> | Hixie: we decided to copy firefox for onerror. webkit always uses empty string as location for setTimeout scripts, otherwise i think they behaved pretty much the same |
| 23:09 | <Hixie> | makes sense |
| 23:10 | <zcorpan> | what part makes sense? copying firefox or using empty string for setTimeout? :) |
| 23:22 | <Hixie> | zcorpan: copying firefox |
| 23:33 | <zcorpan> | ok |
| 23:45 | <Hixie> | heycam|away: advice on the first bullet point of http://www.w3.org/Bugs/Public/show_bug.cgi?id=14037#c29 would be helpful |
| 23:48 | <smaug____> | jgraham: IIRC IE implements most of webidl. at least things like interface.prototype.property handling |
| 23:48 | <Hixie> | annevk5: ping |
| 23:55 | <karlcow> | http://www.amazon.com/gp/feature.html/ref=amb_link_357613442_1?ie=UTF8&docId=1000729901&pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-5&pf_rd_r=0QAERWX4FF6S17ZXDZRR&pf_rd_t=1401&pf_rd_p=1321300302&pf_rd_i=1000729511 |
| 23:59 | <karlcow> | "<?xml?> This tag identifies a document as an XML document" ? |