| 00:09 | <dbaron> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=15033 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=15035 got put in "other Hixie specs" instead of "HTML5 spec" for some reason |
| 00:09 | <dbaron> | (they both came from the whatwg spec comment form, I think) |
| 01:33 | <MikeSmith> | man, the hover behavior and popups in the Firefox built-in Inspect tool are way awesome |
| 01:34 | <paul_irish> | so hot |
| 01:35 | <MikeSmith> | yeah |
| 01:35 | <MikeSmith> | nice clean simple UI |
| 01:36 | <MikeSmith> | responsiveness is great |
| 01:36 | <MikeSmith> | the way that inspectors in other browsers have been doing it now seems backwards |
| 01:37 | <MikeSmith> | I think you more often want to go from the rendered view and find the part of the HTML source that corresponds to that |
| 01:37 | <MikeSmith> | rather than the other way around |
| 01:38 | <MikeSmith> | definitely much better if all you need to do is, say, just see if a particular part of the page has an id, and what the id is |
| 01:40 | <MikeSmith> | wondering if the plan is for this to ship in Firefox 10 |
| 01:41 | <TabAtkins> | Ooh, it has improved! |
| 01:41 | <MikeSmith> | yeah |
| 01:42 | <MikeSmith> | I said Firefox but I meant Minefield of course |
| 01:42 | <MikeSmith> | er, Nightly now I guess |
| 01:47 | <MikeSmith> | really nice to have built-in debugging tools in Firefox |
| 01:58 | <zewt> | hmm |
| 01:59 | <zewt> | how would a spec go about interpreting the first argument (if any) of an "any..." argument as a particular WebIDL dictionary type |
| 02:01 | <zewt> | eg. getContext("webgl", { alpha: true }) |
| 02:03 | <heycam> | zewt, good question. you at least want to invoke the conversion steps for JS value to IDL dictionary value. |
| 02:04 | <heycam> | there's nothing in the spec currently that lets you say to do this conversion without saying "take the JS value that was passed as the second argument and _convert_ it to an IDL value of type MyDictionary". |
| 02:04 | <zewt> | been poking around looking for prior art |
| 02:04 | <heycam> | yeah I'm not sure there is any |
| 02:04 | <zewt> | (not to dictionary--it's too new--but to any type) |
| 02:05 | <heycam> | any… is probably just used for setTimeout and friends? |
| 02:05 | <heycam> | where it doesn't do any explicit conversion of JS to IDL values of those any… things |
| 02:05 | <zewt> | canvas.getContext uses it |
| 02:05 | <zewt> | because the arguments are context-type-specific |
| 02:05 | <heycam> | but does it actually use it for '2d'? |
| 02:05 | <zewt> | nope, it ignores any arguments |
| 02:06 | <zewt> | (i'm trying to get this cleaned up in webgl; it's a bit ad hoc right now) |
| 02:07 | <heycam> | so the quoted sentence I give above would be ok. it is language specific (but who cares). |
| 02:07 | <zewt> | can "JS" just be dropped? "take the value ..." |
| 02:08 | <heycam> | yeah maybe. you want it to be clear though that it's a particular language value, and not an IDL value. |
| 02:09 | <heycam> | also if you want _convert_ to go somewhere useful you've only got specific language binding conversions in web idl. there's no generic "convert" definition that says "if the value is JS, follow the steps in this section. if it's java, follow these other steps." |
| 02:09 | <zewt> | there's also the error case (TypeError)... |
| 02:10 | <heycam> | on my todo list is to add IDL-level exceptions with those names, and map them to the same things in JS |
| 02:11 | <zewt> | might be hard to market this as an improvement if i have to do that, plus "if the conversion is illegal, throw this exception and terminate these steps", starts to get bloaty |
| 02:12 | <heycam> | if you do link _convert_ to the relevant steps, then you get the exception thrown automatically |
| 02:12 | <zewt> | hmm |
| 02:12 | <heycam> | so you shouldn't need to mention it |
| 02:13 | <zewt> | are there any calls-out-to-algorithms where the algorithm throws an exception and terminates the caller algorithm? |
| 02:13 | <zewt> | don't think i've ever seen that |
| 02:13 | <heycam> | in other specs? I am not too sure, but the rules I use for the algorithms within Web IDL is that exceptions propagate out of algorithms and can terminate them. |
| 02:14 | <zewt> | i'd be surprised by that, since if I'm reading an algorithm in isolation I'm not expecting that any call to another algorithm might terminate it (unless the algorithm says so explicitly) |
| 02:15 | <zewt> | ("do this thing, and terminate these steps on failure" or something) |
| 02:15 | <heycam> | is that what the html spec does? |
| 02:15 | <zewt> | i've never seen called-algorithms-terminating-the-caller in html |
| 02:16 | <heycam> | ok |
| 02:16 | <heycam> | does html have called algorithms throw particular exceptions? |
| 02:17 | <zewt> | i don't remember seeing it, but ping @ hixie |
| 02:22 | <jamesr_> | how much work does webidl do to support non-js impls? |
| 02:22 | <heycam> | jamesr_, there's a whole java binding appendix. but it's going to get ripped out. :o |
| 02:22 | <jamesr_> | and that's the only other binding? |
| 02:22 | <heycam> | yes |
| 02:23 | <jamesr_> | i guess it's time for the java bindings to be... (puts on csi:miami sunglasses) .... garbage collected |
| 02:23 | <heycam> | ha |
| 02:23 | <zewt> | found one example, the "XML fragment serialization algorithm" can throw an exception, and the place it's used explicitly mentions that it might throw (havn't found one like this that's part of a list of steps, though) |
| 02:25 | <heycam> | zewt, ok, yeah I want to see when an algorithm is invoked whether it notes that an exception might come out of it |
| 02:25 | <Hixie> | i hope that every time i throw an exception in a child algorithm, i catch it / say to propagate it |
| 02:25 | <Hixie> | file bugs if i screwed that up anywhere |
| 02:26 | <Hixie> | i do have some algorithms that (without exceptions) explicitly abort their caller |
| 02:26 | <Hixie> | media resource loading or whatever it's called may be one of them |
| 02:26 | <heycam> | Hixie, and you mention that in the calling algorithm |
| 02:27 | <heycam> | ? |
| 02:27 | <zewt> | Hixie: having trouble finding an algorithm that does that--anything off-hand to search for? |
| 02:27 | <Hixie> | heycam: i wouldn't guarantee it |
| 02:28 | <Hixie> | zewt: try looking for "abort the" |
| 02:29 | <zewt> | ah here's one, in structured clone |
| 02:30 | <zewt> | (for exceptions from user code rather than an algorithm, but close enough) |
| 02:32 | <heycam> | sounds like maybe I should do it then |
| 02:32 | <heycam> | zewt, if you're on the list would you mind mailing public-script-coord requesting it? |
| 02:32 | <zewt> | i'm not on that one |
| 02:35 | <heycam> | ok nm i'll just note it locally |
| 02:35 | <zewt> | how big is the difference between [Callback] interface and a dictionary? (have to weigh how much time to spend in convincing people to make changes, heh) |
| 02:36 | <zewt> | webgl has "[Callback] interface WebGLContextAttributes", where similar stuff with event constructors has a dictionary for the data passed from the user and an interface for the resulting class |
| 02:36 | <heycam> | zewt, if it's just for taking in an argument to a function, then not that different. dictionary members can be "not present" though, which might be useful. |
| 02:36 | <heycam> | and you can specify default values in the idl |
| 02:36 | <zewt> | webgl definitely intends for arguments to be omitted |
| 02:37 | <heycam> | with hard coded defaults? |
| 02:37 | <zewt> | they specify the defaults in prose |
| 02:37 | <heycam> | but yeah if some can be omitted and the defaults aren't just the result of converting undefined to the right type, you'll need to use a dictionary |
| 02:38 | <heycam> | i think that's not valid then, you can't say what happens if there's no property for [Callback] objects |
| 02:39 | <zewt> | if the properties were nullable (which they're not, but putting that aside) i'd have guessed that the properties would read as null |
| 02:39 | <heycam> | yes |
| 02:39 | <zewt> | though i don't think they want those to be nullable anyway, so it'd want to be a separate type anyway |
| 02:40 | <zewt> | i like programming better; if i don't know how something works, I just try it and see what blows up |
| 02:41 | <heycam> | this is more like try something, wait a few months and see if i blow up |
| 02:42 | <zewt> | heh |
| 02:42 | <zewt> | thanks to both; will think about it some more |
| 02:42 | <heycam> | kcool |
| 02:53 | <zewt> | erg, another thing is that this is part of a sub-algorithm itself (the context creation called by getContext in step 6) |
| 02:53 | <zewt> | getContext itself is not defined as throwing an exception in that step |
| 02:54 | <zewt> | (@ hixie) |
| 03:01 | <zewt> | heycam: so, "Convert" would ref http://dev.w3.org/2006/webapi/WebIDL/#es-dictionary ? |
| 03:04 | <heycam> | zewt, yes |
| 03:05 | <heycam> | or http://dev.w3.org/2006/webapi/WebIDL/#dfn-convert-ecmascript-to-idl-value |
| 03:05 | <heycam> | the latter is where all "convert"s within the spec link to actually |
| 03:06 | <heycam> | either would be fine |
| 03:07 | <Hixie> | zewt: file bugs (using the widget thing) |
| 03:13 | <zewt> | ok |
| 07:24 | <hsivonen> | aargh. MTWF FAIL: http://paulirish.com/2011/moving-the-web-forward/#comment-96808 |
| 09:02 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=15095 - how do you check the origin of a worker? |
| 09:05 | <zcorpan> | event.origin |
| 09:06 | <hsivonen> | writing character encoding related UI strings is hard |
| 09:06 | <hsivonen> | particularly for a browser |
| 09:07 | <hsivonen> | where for perf reasons you don't want to check if the page actually contains non-ASCII |
| 09:07 | <hsivonen> | and where you can't be sure whether the page author or a user ends up reading the UI string |
| 09:09 | <zcorpan> | i guess xhr/websocket/eventsource can expose the origin in a worker, too |
| 12:41 | <codeho> | blergh.. this new mouse lock api is going to be hell |
| 13:03 | <hsivonen> | codeho: in what way? |
| 13:03 | <codeho> | i fear its gonna be abused |
| 13:04 | <codeho> | ad-blocks that trap your mouse |
| 13:04 | <codeho> | whole pages that trap your mouse |
| 13:04 | <codeho> | ect.. |
| 13:04 | <hsivonen> | codeho: aren't there safeguards against that? |
| 13:06 | <codeho> | in the current spec i don't see any |
| 13:07 | <codeho> | it'll need the same approach as for pop-ups |
| 13:07 | <jgraham> | No one is going to implement it without safeguards |
| 13:07 | <codeho> | fullscreen and geoloc |
| 13:07 | <jgraham> | irre3spective of what the spec says |
| 13:07 | <jgraham> | I'm also rather sure this has been discussed |
| 13:07 | <codeho> | ost likely |
| 13:07 | <codeho> | +m |
| 13:09 | <codeho> | current chromium only allows it in fullscreen mode |
| 13:09 | <codeho> | thats good :) |
| 13:19 | <hsivonen> | https://twitter.com/#!/MattWilcox/status/144765119203774464 |
| 13:33 | <smaug____> | codeho: I think also Firefox implementation allows it only in fullscreen mode |
| 13:34 | <smaug____> | (I'm more worried about misusing fullscreen mode, since it doesn't require any permission ) |
| 13:42 | <smaug____> | codeho: if you're testing mouse lock, feel free to test FF builds http://vocamus.net/dave/?p=1388 |
| 13:43 | <codeho> | smaug____: thanks! currently i'm just interested in the code, looking' at your repo if thats ok :) |
| 13:47 | <smaug____> | codeho: not my code :) |
| 13:47 | <codeho> | i know |
| 13:47 | <codeho> | :) |
| 13:48 | <codeho> | (now) :) |
| 14:08 | <smaug____> | does webkit support event ctors for other than Event and CustomEvent |
| 14:08 | smaug____ | has never understood why DOM4 has CustomEvent |
| 14:14 | <zcorpan> | Hixie: hmm. now it's non-trivial to find the partial Document interface (previously HTMLDocument) by following xrefs |
| 14:15 | zcorpan | filed a bug |
| 14:36 | <bga> | http://funkyimg.com/u2/1081/563/9373757.png |
| 14:36 | <bga> | mozilla^ |
| 14:38 | <hsivonen> | bga: looks like Content-Disposition in action |
| 14:38 | <hsivonen> | bga: and the user having set Opera as the default app for .xhtml |
| 14:39 | <bga> | m |
| 14:39 | <bga> | only opera open this url |
| 14:40 | <bga> | stupid browsers |
| 14:43 | <bga> | anyway this svg demo does not work even in FF |
| 14:43 | <bga> | ah |
| 14:44 | <bga> | saving, rename to .xhtml and now work |
| 14:45 | <bga> | works only FF heh |
| 14:45 | <bga> | * +in |
| 15:23 | <bfrohs> | Is it allowed to specify multiply [type] values for a form <input>? Or is there a less specific date value that allows for choosing a month or a day? Usage: Published Date for book. Publishers sometimes only specify a month (esp. if it's released on multiple days in different areas of the world), but allow for a specific day (e.g. released same day across timezones) |
| 15:24 | <zcorpan> | use two inputs |
| 15:27 | <bfrohs> | If you mean a Month and Date input, that has the downside of requiring a script to check for validation (having required on both would lock the form), as well as possible user confusion when selecting a date (when multiple fields are present, people want to fill both out, even if they're for the same thing) |
| 15:27 | <bfrohs> | The other possibility is using [pattern], but that removes the date picker |
| 15:29 | <zcorpan> | what UI do you want? a date picker that can select either a month or a date? |
| 15:30 | <bfrohs> | Yes, that would be great. Even if it could choose a year as well (date, with every part excluding year optional). And requiring the month could be taken care of with [pattern] (however, without a 'date-optional' [type], this is not possible without a script) |
| 15:31 | <zcorpan> | i guess you should list the use cases for such a thing in a bug |
| 15:31 | <bfrohs> | Where would be the best place to submit it? |
| 15:32 | <zcorpan> | the comment form in the spec files a bug |
| 15:32 | <zcorpan> | you need an account on w3c bugzilla if you want to comment on the bug further |
| 15:32 | <zcorpan> | alternatively, send an email to whatwg⊙wo (need to subscribe) |
| 15:34 | <bfrohs> | Thank ya |
| 16:08 | <smaug____> | does anyone know which all event ctors webkit supports |
| 16:08 | <smaug____> | I haven't manage to install any latest webkit builds to this machine, so I can't test |
| 16:08 | <smaug____> | though, I think only Event and CustomEvent has ctor mentioned in any spec |
| 16:11 | <zewt> | webgl has one, which I doubt is implemented anywhere yet |
| 16:12 | <zewt> | there was a thread about using it with indexeddb months ago, but I guess that hasn't happened yet |
| 16:13 | <zewt> | and other noise about updating dom3 events, which I guess also hasn't happened |
| 16:14 | <zewt> | is webgl really the only spec outside of dom4 itself using it yet? heh |
| 16:30 | <annevk5> | smaug____: they implemented most I think |
| 16:30 | <annevk5> | smaug____: I mean for most event interfaces they have |
| 16:30 | <annevk5> | smaug____: and then filed bugs on the specs |
| 16:30 | <annevk5> | smaug____: the HTML spec has event constructors defined for all its event interfaces |
| 16:30 | <smaug____> | well, one needs to know the order of stuff in the dictionaries |
| 16:31 | <smaug____> | ah |
| 16:31 | smaug____ | looks at HTML spec |
| 16:38 | <SIDKID87> | Question surrounding the MetaExtensions. When I include these (i.e. HandheldFriendly) in my HTML document I get validation errors. How do I avoid this? |
| 16:43 | <karlcow> | <annevk> my b is that I sort of feel that long term bandwidth will be less of an issue and everything will be 300ppi |
| 16:43 | <karlcow> | maybe the issue is slightly different for the b case |
| 16:44 | <karlcow> | it's not that much the absolute bandwidth of cell networks |
| 16:44 | <karlcow> | but the different between cables and wireless networks. |
| 16:44 | <karlcow> | if wireless gets higher speed, but cables go on a trend of super high speed |
| 16:44 | <annevk5> | smaug____: the order should not be important... |
| 16:44 | <karlcow> | there will still be the issue |
| 16:45 | <annevk5> | karlcow: not if you not go beyond 300ppi |
| 16:45 | <karlcow> | annevk5: bigger size images :) if people can 10Mb they will, no? |
| 16:45 | <annevk5> | karlcow: or do you expect us to transmit raw camera images from a Canon 1D or some such? |
| 16:45 | <karlcow> | * can use |
| 16:46 | <karlcow> | annevk5: people will |
| 16:46 | <jgraham> | (1D images are way bigger than that) |
| 16:46 | <jgraham> | (at least my 7D images are like 20Mb each and I guess the 1D is even bigger) |
| 16:47 | <annevk5> | karlcow: maybe reasonable, unless cables to home go away entirely |
| 16:47 | <karlcow> | so basically the speed difference in between different type of user experiences/networks. |
| 16:47 | <annevk5> | is a compressed JPEG for 300ppi much much larger than one for 150ppi today? |
| 16:47 | <smaug____> | annevk5: order is important |
| 16:47 | <smaug____> | because of getters |
| 16:48 | <annevk5> | smaug____: ah right |
| 16:48 | <annevk5> | smaug____: hopefully the dictionaries are interface order |
| 16:48 | <annevk5> | I wonder if Web IDL makes that crystal clear to everyone |
| 16:49 | <smaug____> | IIRC it does |
| 16:50 | <smaug____> | but I need to re-review |
| 16:51 | <SIDKID87> | <meta name="HandheldFriendly" content="True"> breaks validation, what's up with that? |
| 16:51 | <karlcow> | annevk5: already the case for some regions of the world. Or more exactly the cable was never the main delivery channel |
| 16:51 | <karlcow> | "Most people on #Internet in #Africa access thru mobile web - 85m of 110m web users - #IsisNyong'o of #InMobi at #ConvergenceAfrica #Nairobi" — http://twitter.com/tamihultman/status/144757444575375361 |
| 16:52 | <annevk5> | SIDKID87: per http://wiki.whatwg.org/wiki/MetaExtensions it's only a proposal and might not be implemented yet in the validator |
| 16:52 | <annevk5> | karlcow: I know |
| 16:53 | <annevk5> | karlcow: and there's claims of 80mbit mobile, which is pretty close to the 120mbit I get at home |
| 16:53 | <annevk5> | (via cable) |
| 16:53 | <annevk5> | and everyone hates cables |
| 16:54 | <jgraham> | It is not really clear if you will get that in rural areas though |
| 16:54 | <jgraham> | The range will be very short |
| 16:54 | <jgraham> | Still, maybe it will happen eventually |
| 16:54 | <SIDKID87> | annevk5: Thanks - that makes sense. :) |
| 16:54 | karlcow | doesn't hate cables, but that is another topic :) |
| 16:55 | <jgraham> | In any case being able to select on screen size can be good even if both images are the same number of pixels |
| 16:55 | <jgraham> | But speculative prefetching with <picture> or similar solutions could be interesting |
| 16:55 | jgraham | wonders what happens with <video> roday |
| 16:55 | <jgraham> | *today |
| 17:07 | <zewt> | heh, i've sort of wondered about tighter integration with progressive JPEGs and resource fetching, though I'm certain it'll never happen (and not sure it would work well anyway) |
| 17:08 | <zewt> | for example, if you have a 300 DPI, 3-pass interlaced JPEG and you're on a much lower-resolution display, request just the first two passes from the server |
| 17:09 | <zewt> | then you have a single file with no waste serving multiple resource sizes (but of course the server-side complexity is way too high) |
| 17:10 | <karlcow> | http://pypi.python.org/pypi/NodeTree |
| 17:11 | <zewt> | well, I suppose all you *really* need is an index file ("1 pass: 10000 bytes; 2 passes: 30000 bytes; 3 passes: 100000 bytes"), then the client can use Content-Range (still too complex) |
| 17:13 | <zewt> | annevk5: another thing to consider: no matter how much bandwidth you have, waste on mobile costs |
| 17:14 | <zewt> | downloading 10x the amount of data and then decoding a much larger file will *always* mean, at the least, more battery use |
| 17:19 | <karlcow> | was trying to find more information about nodetree not quite ready yet http://arcriley.blogspot.com/2011/12/nodetree-02-released.html |
| 17:22 | <annevk5> | zewt: so far though the images that use more bandwidth make the most sense on phones |
| 17:23 | <annevk5> | there's no desktop nearing 300ppi yet in wide use |
| 17:23 | <ZXY> | is there any at all? |
| 17:23 | <ZXY> | consumer/pro grade |
| 17:23 | <annevk5> | I thought IBM had made something at one point |
| 17:23 | <annevk5> | well some company |
| 17:24 | <ZXY> | that's not really ibm's thing |
| 17:24 | <ZXY> | they really don't make any consumer products anymore |
| 17:33 | <smaug____> | I hope my event ctor implementation is somewhat compatible what chromium has |
| 17:36 | <TabAtkins_> | smaug____: Ask about it in #webkit |
| 17:36 | <smaug____> | I'd rather test |
| 17:36 | <smaug____> | but I have no idea where to get "nightly" chromium |
| 17:36 | <smaug____> | even the dev version doesn't seem to run on this machine |
| 17:36 | <smaug____> | s/run/install/ |
| 17:36 | <zewt> | chrome's prerelease stuff is a big pain, because (last I tried it) it doesn't let you install them side-by-side |
| 17:36 | <zewt> | and it took a bit of digging to figure out how to go *back* to production when I was done |
| 17:37 | <zewt> | (iirc, going to prerelease builds was one click, going back not so much) |
| 17:37 | <smaug____> | but, I declare my implementation correct and if webkit does something else, I'll file webkit bugs :p |
| 17:37 | <zewt> | cage match |
| 17:39 | <zewt> | i suppose it's the usual neverending question: "do tests exist yet" :P |
| 17:39 | <jgraham> | Why would anyone ever run a production browser? |
| 17:40 | <zewt> | why would anyone ever run a prerelease browser, when everything we do these days depend son it :) |
| 17:40 | <annevk5> | ZXY: I thought "pro" was acceptable too |
| 17:40 | <annevk5> | ZXY: I was thinking of http://en.wikipedia.org/wiki/IBM_T220/T221_LCD_monitors |
| 17:41 | <ZXY> | ah nice |
| 17:41 | <annevk5> | ZXY: still only 200ppi though |
| 17:41 | <ZXY> | I meant to say prosumer actually |
| 17:41 | <ZXY> | but this is really cool |
| 17:43 | <zewt> | then go for it http://www.ebay.com/itm/290642425026 |
| 17:43 | <jgraham> | Well people have been talking about 200ppi monitors for years. It shows no sign of going mainstream though |
| 17:43 | <zewt> | heh 48hz, ouch |
| 17:44 | <ZXY> | they go for like 2-4 k it looks like |
| 17:44 | <zewt> | and I'm sure it's really poor by other modern standards (ghosting, view angle, color accuracy, black level, etc) |
| 17:44 | <ZXY> | plus I think you'd need two dvi connections |
| 17:45 | <ZXY> | everyone knows it's just for cramming more irc windows on your screen |
| 17:45 | <zewt> | i just maximize irc on my side monitor, heh |
| 17:46 | <jgraham> | Anyway if anyone is claiming that we don't need something because this tech will be ubiquitous RSN, I will take it with an ocean full of salt |
| 17:49 | smaug____ | uses http://html5labs.interoperabilitybridges.com/dom4events/ |
| 17:52 | <smaug____> | Ms2ger: what is the expected behavior for bubbles: get () { throw foo } ? :) |
| 17:52 | <annevk5> | jgraham: after iPad3, I expect my laptop to get a similar treatment |
| 17:52 | <Ms2ger> | I was hoping you'd figure that out ;) |
| 17:52 | <Ms2ger> | Let me check |
| 17:53 | <smaug____> | Ms2ger: currently the patch does what the spec say (no exceptions) |
| 17:53 | <smaug____> | I mean DOM4 spec |
| 17:53 | <smaug____> | WebIDL may hint something else |
| 17:53 | <Ms2ger> | Hrm, WebIDL doesn't seem clear |
| 17:55 | <Ms2ger> | "None of the algorithms or processing requirements in the ECMAScript language binding catch ECMAScript exceptions. Whenever an ECMAScript Function is invoked due to requirements in this section and that Function ends due to an exception being thrown, that exception MUST propagate to the caller, and if not caught there, to its caller, and so on." |
| 17:56 | <smaug____> | aha, so exception should propagate |
| 17:56 | <Ms2ger> | Sounds like it |
| 17:59 | <jgraham> | annevk5: I would wait and see about that. Making that kind of screen that size is going to be hugely expensive (due to low yield). I wouldn't expect it in laptops overnight or on desktops for even longer |
| 18:00 | <annevk5> | there's not much else I can do |
| 18:00 | <annevk5> | but if they put that kind of screen on a MacBook Air, yield is going to be high |
| 18:01 | <smaug____> | Ms2ger: thanks, fixed |
| 18:01 | <Ms2ger> | Thank you! |
| 18:07 | <zewt> | i wouldn't expect high dpi desktop/laptop monitors, because there isn't, as far as i know, much demand |
| 18:07 | <zewt> | you need a high dpi display for a phone because the screen's small, but for the vast majority of people (short of perhaps artists, print editors, that narrow category of users), 1920x1200 @ 24" is plenty |
| 18:09 | TobiX | wants to get rid of sub-pixel-AA, because it's ugly for people with good eyes... |
| 18:10 | <zewt> | having an lcd with the text quality of eink would be great, but I wouldn't put my money on it... |
| 18:13 | <karlcow> | hmmm transparent HTTP negotiation |
| 18:13 | <karlcow> | maybe time to implement it after all |
| 18:14 | <karlcow> | http://tools.ietf.org/html/rfc2295 |
| 18:15 | <zewt> | ew |
| 18:15 | <Ms2ger> | Ew at ietf.org? |
| 18:15 | <annevk5> | oh right |
| 18:15 | <annevk5> | I should fix /complete/ |
| 18:15 | <zewt> | if the idea is picking different image sizes at the HTTP level |
| 18:16 | <TabAtkins_> | zewt, smaug____: You can install Chrome Canary side-by-side with normal Chrome. |
| 18:19 | <karlcow> | zewt: the RFC is need. it disclose the choices. I will write about it. It certainly needs reediting because it is an old spec. |
| 18:19 | <karlcow> | but it is a spec which solves also a lot of issues |
| 18:19 | <zewt> | karlcow: maybe it has its uses (only skimmed the intro)--just "ew" if you were suggesting its use for the "responsive images" discussion |
| 18:19 | <karlcow> | for SEO, search engines in multi-lingual contexts |
| 18:19 | <smaug____> | TabAtkins_: where do I get Canary for linux? |
| 18:20 | <smaug____> | and actually, installing even dev failed for some reason |
| 18:22 | <zewt> | tab: looks like that's new since i looked at it last; looks like beta and dev still replace stable |
| 18:23 | <zewt> | new Event(1) should throw TypeError, right? |
| 18:24 | <annevk5> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html is a 404 now but I think it should return some kind of document Philip` made at one point, no? |
| 18:24 | <zewt> | (doesn't in Chrome) |
| 18:24 | <annevk5> | zewt: no |
| 18:24 | <annevk5> | zewt: first argument is a string |
| 18:24 | <zewt> | eh yeah |
| 18:24 | <zewt> | new Event("", 1) then :) |
| 18:24 | <zewt> | (same) |
| 18:25 | <Ms2ger> | Yes |
| 18:26 | <Philip`> | annevk5: It should return a 404 with a script that redirects to whatever page has #video |
| 18:26 | <TobiX> | Hmm. I was wondering. GreaseMonkey added a finalUrl attribute to XMLHttpRequest responses. Would this be useful for regular XHR beside my narrow use case? |
| 18:28 | <zewt> | heh, two spams in two days leaking to the list |
| 18:28 | <zewt> | (don't really care, just unusual) |
| 18:30 | <Hixie> | annevk5: try regenning again, it should be fixed |
| 18:30 | <Hixie> | annevk5: the .htaccess file was still pointing at the complete/ 404 |
| 18:30 | <Hixie> | annevk5: so it got a 301 while trying to serve the 404 |
| 18:31 | <TobiX> | zewt: There is http://crportable.sourceforge.net/ for following dev-builds... |
| 18:31 | <annevk5> | Hixie: it's perfect now |
| 18:32 | <annevk5> | Hixie: it also deletes all files each time around so this problem should be gone in theory |
| 18:32 | <Hixie> | annevk5: cool |
| 18:34 | <annevk5> | hsivonen: just saw your "json" patch got landed, sweet |
| 18:35 | <annevk5> | hsivonen: we have implemented spec-compliant responseType "json" too |
| 18:35 | <annevk5> | hsivonen: in the next version we release |
| 18:39 | <karlcow> | zewt: what I meant with the RFC 2295 http://my.opera.com/karlcow/blog/2011/12/08/responsive-images-and-transparent-content-negotiation-in-http |
| 18:41 | <zewt> | it requires a blocking round-trip? that'll hurt responsiveness a lot in and of itself... |
| 18:42 | <zewt> | (2g is nothing if not latent) |
| 18:42 | <karlcow> | zewt |
| 18:43 | <karlcow> | not necessary |
| 18:43 | <karlcow> | but it could |
| 18:43 | <karlcow> | it depends on how you handle it. |
| 18:45 | <TabAtkins_> | smaug____: search for "chrome canary", or just go to http://tools.google.com/dlpage/chromesxs |
| 18:45 | <TabAtkins_> | zewt: Yes, beta and dev still replace stable; they don't easily coexist. |
| 18:47 | <TabAtkins_> | smaug____: I forget exactly how up-to-date Canary is. I think it's a daily build off of the last green configuration. |
| 18:48 | <zewt> | annevk5: i wonder if the event ctor "for each dictionary member..." should be a separate, referencable algorithm, if this pattern is likely to happen more and more |
| 18:48 | <zewt> | (converting a webidl dictionary parameter to an interface) |
| 18:48 | <smaug____> | TabAtkins that page gives "Your operating system is not supported. " |
| 18:48 | <zewt> | (suggesting the same text for some webgl stuff) |
| 18:50 | <zewt> | heycam: ^ more for you I guess, since I suppose it'd go in webidl rather than dom4 |
| 19:10 | <TabAtkins_> | smaug____: It's possible that Canary is only for windows. |
| 19:10 | <TabAtkins_> | smaug____: In that case, build from the tree yourself? |
| 19:11 | <TabAtkins_> | It's not overly difficult if you follow the Chromium instructions. |
| 19:11 | <smaug____> | TabAtkins: my machine is busy enough compiling Gecko |
| 19:12 | <annevk5> | zewt: file a bug on Web IDL? |
| 19:12 | <annevk5> | zewt: might be a nice construct to have if it turns out to be shorter and clearer |
| 19:13 | <TobiX> | smaug____: http://build.chromium.org/f/chromium/snapshots/ |
| 19:19 | <smaug____> | annevk5: shouldn't nullable DOMStrings have '?' |
| 19:20 | <smaug____> | or Ms2ger |
| 19:20 | smaug____ | is lazy to verify from WebIDL |
| 19:21 | <Ms2ger> | Yeah |
| 19:21 | <smaug____> | k |
| 19:21 | smaug____ | should file a spec bug |
| 19:24 | <annevk5> | back tomorrow most likely |
| 19:24 | Ms2ger | waves |
| 20:14 | <zewt> | "Web Storage is now a Candidate Recommendation and as such, a Call for Implementations was made [CfI]" ... really? |
| 20:14 | <zewt> | sometimes The Process(tm) is just comic |
| 20:36 | <karlcow> | zewt: note that it was not mandatory |
| 20:36 | <karlcow> | I don't know why people still think it is mandatory per se |
| 20:40 | <karlcow> | "Call for Implementations. Note: The Director MAY permit the Working Group to skip this step if the entrance criteria for the next step have already been satisfied." — http://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance |
| 20:40 | <karlcow> | the steps in the process are entrance criterias |
| 20:40 | <karlcow> | if you demonstrate that you met all the requirements for the targeted step |
| 20:40 | <zewt> | just force of habit? heh |
| 20:40 | <karlcow> | you are fine. |
| 20:41 | <karlcow> | zewt: yes! |
| 20:41 | <karlcow> | it's not the process which is comics |
| 20:41 | <Ms2ger> | Well, we don't have tests, of course |
| 20:41 | <karlcow> | it is the people using the process ;) |
| 20:41 | <zewt> | karlcow: well, i feel more comfortable making fun of the process on irc than particular individuals :) |
| 20:41 | <karlcow> | The process is just a tool. |
| 20:41 | <Ms2ger> | Art can handle it :) |
| 20:41 | <karlcow> | hehe |
| 20:43 | <karlcow> | but as a group it is perfectly reasonable that people develop tests and produce an interop report which shows that everything is implemented reasonably according to the group. |
| 20:43 | <karlcow> | and then move on |
| 20:43 | <karlcow> | and this can be done BEFORE entering CR |
| 20:43 | <karlcow> | :) |
| 20:43 | <Ms2ger> | Sure |
| 20:43 | <Ms2ger> | It is perfectly reasonable for people to write tests |
| 20:43 | <karlcow> | heh |
| 20:43 | <Ms2ger> | They just happen not to |
| 20:46 | <karlcow> | Ms2ger: hehe… I. know. that. :) I spent 5 years on trying to convince groups that it was good to prove interops. There is a huge leap compared to what was done before pre-2000. We are still not there yet. |
| 20:46 | <Ms2ger> | We're convinced |
| 20:46 | <Ms2ger> | And lazy |
| 20:46 | <karlcow> | lazy is the definition of a good developer. no? :) |
| 20:46 | <jgraham> | The process is a tool, or the people are tools? :p |
| 20:47 | <zewt> | Ms2ger: i wish we had a webapp for writing tests for webapp apis :P |
| 20:47 | <jgraham> | Surely iPhone has an app for that? |
| 20:47 | <Ms2ger> | Just Android |
| 20:47 | <karlcow> | jgraham: it depends on the circumstances and the quantity of alcohool you drunk before and how many clothes… [redacted] |
| 20:47 | <zewt> | there would be some irony in that |
| 20:47 | <Ms2ger> | Standards and iPhone? You must be kidding |
| 20:49 | <zewt> | Ms2ger: sure, it works like this: "we'll do what we want. then you guys can make a standard out of it" |
| 20:49 | <jgraham> | In other news http://www.youtube.com/watch?v=EhkxDIr0y2U is very very odd. As one would expect. |
| 20:50 | <jgraham> | karlcow: Redacting people's clothes? |
| 20:50 | <karlcow> | where's the emperor |
| 20:51 | <Ms2ger> | Hixie's over there |
| 20:54 | <karlcow> | is he naked |
| 21:00 | <karlcow> | http://www.w3.org/community/autowebtest/ |
| 21:00 | <karlcow> | the group has been created |
| 21:03 | <zewt> | does everything take a community group now? heh |
| 21:11 | <karlcow> | zewt: yup it seems. At least people create groups, but it doesn't mean they are active. Some do, some have a flat ECG |
| 21:12 | <zewt> | karlcow: smells like the usual "i want this to happen but can't/won't do it myself, so i'll create a [forum|mailing list|sourceforge project] and hope somebody will do it for me" |
| 21:12 | <zewt> | aka, noise |
| 21:12 | <karlcow> | yup… silent freedom |
| 21:13 | <zewt> | in this case, i think if someone wanted to create a webapp like this, they'd just ... do it, and mailing lists and CGs and whatever would come after there's something to show |
| 21:14 | <zewt> | (it's not like something that needs buy-in from vendors or anything like that) |
| 21:14 | <karlcow> | the Test automation thing has been started, if I understood correctly, to have a more formal TestAutomation API based on http://code.google.com/p/selenium/wiki/JsonWireProtocol |
| 21:15 | <karlcow> | which is now implemented for most browsers |
| 21:15 | <karlcow> | with at least two officially supported driver Chrome and Opera |
| 21:16 | <zewt> | that's a bit more low-level, yeah that would need UA work |
| 21:16 | <jgraham> | There is already a WG for that |
| 21:16 | <jgraham> | There is a WG to standardise webdriver |
| 21:17 | <jgraham> | and an IG for other testing concerns |
| 21:17 | <jgraham> | Adding a CG isn't obviously helpful unless it supercedes one of the other groups |
| 21:17 | <jgraham> | (and I don't see why it would in this case) |
| 21:18 | <karlcow> | ah jgraham I might have mixed the two, my bad. |
| 21:18 | <zewt> | a page where I could just enter some code, have the code run in a bunch of browsers running in VMs somewhere, and have the results spat back at me would be cool |
| 21:18 | <karlcow> | crossing information with space-time warps and emperor's clothes |
| 21:18 | <zewt> | perhaps with the results being flaggable if they come back inconsistent |
| 21:18 | <karlcow> | long week^W year |
| 21:19 | <zewt> | now i want to hack something like this together |
| 21:21 | karlcow | sees http://lists.w3.org/Archives/Public/public-test-infra/ |
| 21:21 | <karlcow> | and http://lists.w3.org/Archives/Public/public-test-infra/2011OctDec/0031.html |
| 21:21 | <karlcow> | and http://www.w3.org/2011/08/browser-testing-charter.html |
| 21:22 | <jgraham> | Yeah. Mike is also going to use it to standardise the console object |
| 21:22 | <zewt> | eg. let me type in "new Event("", "dogs");</script>", and show the various results (throws "not a constructor" vs. throws TypeError vs. returns an Event) in lots of browsers and browser versions |
| 21:23 | <zewt> | s-</script>-- |
| 21:23 | <jgraham> | zewt: Like the live dom viewer but distributed |
| 21:23 | <zewt> | right |
| 21:23 | <jgraham> | That sounds nice to use and nighmarish to run |
| 21:23 | <zewt> | combined with being able to save lists of cases, to auto-construct test tables, etc |
| 21:24 | <zewt> | yeah, integrating with vms running test browsers would be the annoying part |
| 21:24 | <zewt> | especially when some jerk tries while(1); |
| 21:29 | <zewt> | similarly useful would be rendering HTML in each and returning screenshots and DOM trees |
| 21:32 | <jgraham> | There are services that will do screenshots. I guess you could send them a live dom viewer URL |
| 21:46 | <heycam> | annevk5, yes dictionary members are required to be got from the js object in the order they appear on the dictionary |
| 22:38 | <jamesr> | Hixie: yt? |
| 22:38 | <Hixie> | here |
| 22:38 | <jamesr> | Hixie: potentially dumb question. in http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#list-of-active-timeouts , what removes timer that have fired from the 'list of active timeouts'? |
| 22:39 | <jamesr> | i would expect step 1 of http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#get-the-timed-task to do it |
| 22:39 | <jamesr> | or possibly step 10 of http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#list-of-active-timeouts |
| 22:39 | <jamesr> | but i don't see it |
| 22:39 | <jamesr> | (my real motive here is to figure out how to spec similar behavior in the RAF spec) |
| 22:40 | <Hixie> | um |
| 22:41 | <Hixie> | it would appear that not only is the task never removed from the list of active timeouts |
| 22:41 | <Hixie> | but that the task's presence on the list of active timeouts has no effect |
| 22:41 | <Hixie> | that's embarassing |
| 22:41 | <jamesr> | it's used for lookups in cleartimeout() |
| 22:41 | <jamesr> | if nothing matching that ID is in the list of active timeouts, clearTimeout() does nothing |
| 22:41 | <jamesr> | ok i guess i won't cargo cult this particular mechanism :) |
| 22:42 | <Hixie> | yeah, it seems clearTimeout() as specced does nothing black-box detectable |
| 22:42 | <Hixie> | "oops" |
| 22:42 | <Hixie> | there should be a step before step 10 that checks if the task is still in the list |
| 22:42 | <Hixie> | and if not aborts |
| 22:42 | <jamesr> | also, anyone know what " " is? |
| 22:43 | <Hixie> | en space |
| 22:43 | <Hixie> | http://software.hixie.ch/utilities/cgi/unicode-decoder/character-identifier?keywords=2002 |
| 22:43 | <Hixie> | i'll file a bug on the timeout thing |
| 22:44 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=15120 |
| 22:45 | <jamesr> | fun fun |
| 22:45 | <jamesr> | dammit, someone edited my spec to reference http://www.w3.org/TR/2010/WD-html5-20100624 as its HTML reference :/ |
| 22:45 | <Hixie> | edit it back |
| 22:46 | <Hixie> | and put a comment next to it saying not to edit your spec without speaking to you |
| 22:46 | Hixie | has a number of such comments in his specs |
| 22:46 | <Hixie> | for similar reasons |
| 22:58 | <jamesr> | Hixie: another question - with regards to http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#top-level-browsing-context, is a window.open()'d document a nested browsing context or a separate top-level browsing context? |
| 22:59 | <Hixie> | it's an auxiliary one iirc |
| 22:59 | <Hixie> | why would it be a nested one? |
| 23:00 | <jamesr> | i didn't think it would be, but i can't find window.open() |
| 23:00 | <jamesr> | just want to verify that top level browsing contexts are 1:1 with window/tabs |
| 23:01 | <jamesr> | ah there it is. ok cool |
| 23:02 | <Hixie> | top level browsing contexts are 1:1 with window/tabs to a first approximation |
| 23:02 | <Hixie> | there have been browsers with multiple top-level browsing contexts per window, e.g. in sidebars |
| 23:03 | <jamesr> | right. they're separate enough for my concerns here, i think |
| 23:03 | <jamesr> | i think chromium extension popups are also their own top-level browsing contexts |
| 23:04 | <Hixie> | modulo sandboxing, a top-level browsing context is one where window.top===window |
| 23:04 | <Hixie> | sandboxing makes that harder to guarantee |
| 23:35 | <jamesr> | Hixie: how come http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#list-of-the-descendant-browsing-contexts works but http://www.whatwg.org/html#list-of-the-descendant-browsing-contexts does not? |
| 23:35 | <jamesr> | i was under the impression the latter format should work |
| 23:36 | <Hixie> | jamesr: bug in webkit |
| 23:36 | <jamesr> | >< |
| 23:36 | <jamesr> | bug #? |
| 23:36 | <Hixie> | wait |
| 23:36 | <Hixie> | no |
| 23:36 | <Hixie> | the bug i was referring to was that we lost the frag id on a redirect |
| 23:36 | <jamesr> | http://www.w3.org/TR/html5/browsers.html#active-document works |
| 23:36 | <jamesr> | well, it still links you to a TR |
| 23:36 | <Hixie> | my bad |
| 23:36 | <Hixie> | hold on |
| 23:38 | <Hixie> | looks like anne no longer includes link-fixup.js in his upload |
| 23:38 | <Hixie> | i wonder why |
| 23:38 | <Hixie> | jamesr: minor temporary problem; anne will fix it when he gets back on i imagine |
| 23:39 | <jamesr> | Hixie: ok cool. i'll leave links in place and assume they'll start working via magicks |
| 23:39 | <Hixie> | jamesr: looks like the recent fix to blow away old page in the multipage thing also dropped the link-fixup script |
| 23:39 | <Hixie> | annevk5: ping ^ |
| 23:40 | <Hixie> | in the meantime i can yank it from svn |
| 23:40 | <Hixie> | jamesr: try now |
| 23:40 | <jamesr> | Hixie: wfm! |
| 23:40 | <jamesr> | thanks |
| 23:44 | <Hixie> | ok i made my script put in the link-fixup.js file in itself |
| 23:44 | <Hixie> | so anne doesn't have to do anything |
