| 00:52 | <Hixie> | roc: yt? |
| 00:52 | <roc> | yes |
| 00:53 | <Hixie> | so i'm looking at this feedback regarding startTime and so forth |
| 00:53 | <Hixie> | for video |
| 00:53 | <Hixie> | and i'm trying to work out what timeline we should use |
| 00:54 | <Hixie> | it seems everyone gave about 3 mutually contradictory opinions and everyone agreed and disagreed with everyone else |
| 00:54 | <roc> | paging in data |
| 00:54 | <Hixie> | in the static case of a video file whose timeline is not zero-based, it seems we want to expose the timeline as being 0..duration, regardless of the actual in-video "official" timeline |
| 00:54 | <roc> | that is my belief |
| 00:55 | <Hixie> | for streaming data, presumably we want currentTime=0 to be at least as far back as you can seek |
| 00:55 | <Hixie> | do we ever want it to be further back? e.g. the actual start of the streaming performance? |
| 00:56 | <Hixie> | (do we even have that data in all streaming cases?) |
| 00:56 | <roc> | I don't think so |
| 00:57 | <Hixie> | so basically currentTime=0 should be the earliest seekable point, or whatever the first frame was, if you can't seek before the start of receiving the stream, right? |
| 00:57 | <roc> | I think so |
| 00:58 | <roc> | Actually I don't think it really matters if you can't seek to currentTime=0 |
| 00:58 | <Hixie> | sure |
| 00:58 | <Hixie> | it's just that we don't ever want to seek to currentTime<0 |
| 00:58 | <roc> | Hmm, and I don't want currentTime=0 to change dynamically as what is seekable changes |
| 00:58 | <Hixie> | sure |
| 00:59 | <Hixie> | definitely won't change |
| 00:59 | <roc> | So I think currentTime=0 should be seen as something arbitrary defined by the resource |
| 00:59 | <roc> | with the guarantee that you can't ever seek before it |
| 00:59 | <Hixie> | that seems inconsistent with your earlier statement about non-streaming videos that have internal timeliens |
| 01:01 | <roc> | which statement? |
| 01:01 | <roc> | (I believe you) |
| 01:01 | <Hixie> | that in the static case of a video file whose timeline is not zero-based, we want to expose the timeline as being 0..duration, regardless of the actual in-video "official" timeline |
| 01:02 | <roc> | ah yes |
| 01:02 | <roc> | the basic problem here is dealing with video resources where you can seek to before the start position |
| 01:03 | <roc> | that is something that authors will find difficult to deal with |
| 01:03 | <roc> | I think |
| 01:04 | <roc> | since 99% of resources have the nice properties that a) they start at time 0 and b) all relevant times are between 0 and duration |
| 01:04 | <roc> | so something has to give |
| 01:05 | <Hixie> | agreed |
| 01:05 | <roc> | maybe the best option would be to break the second assumption |
| 01:06 | <roc> | and allow negative seekable times |
| 01:06 | <roc> | that means if the author hasn't accounted for seekable times, they might not handle seeking to negative times, but if they don't care about that, they don't have any trouble |
| 01:06 | <roc> | I mangled that sentence, sorry |
| 01:07 | <Hixie> | allowing negative times seems very dodgy |
| 01:08 | <roc> | it also frees the implementation somewhat. Requiring currentTime=0 to be earlier than any time you can ever seek to might be difficult if it's hard to know in advance what is eventually going to be seekable |
| 01:08 | <roc> | I don't think negative times are particularly dodgy. It's an arbitrary time scale anyway. |
| 01:09 | <roc> | negative *durations* would be dodgy |
| 01:11 | <ojan> | Hixie: do you have opinions on ime-mode (the CSS property) |
| 01:11 | <Hixie> | roc: i'm very skeptical of the ability of web authors to handle drawing good seek bars and buffer-status bars if we have a signed timeline |
| 01:11 | <Hixie> | ojan: not off-hand |
| 01:11 | <ojan> | Hixie: we're considering whether it's worth adding to WebKit and i see you mentioned on the relevant mozilla bug |
| 01:12 | <Hixie> | uri? |
| 01:13 | <ojan> | https://bugzilla.mozilla.org/show_bug.cgi?id=279246 |
| 01:13 | <roc> | ojan: I think it's a reasonable feature |
| 01:14 | <roc> | Hixie: so am I. I expect most authors are going to build UIs that assume only non-negative times |
| 01:14 | <roc> | I think that's OK |
| 01:14 | <ojan> | roc: yeah, i think we might try and add it |
| 01:14 | <Hixie> | ojan: yeah, still have no opinion off-hand |
| 01:14 | <ojan> | Hixie: k |
| 01:15 | <Hixie> | ojan: iirc Jungshik Shin is at google now, try asking him |
| 01:15 | <roc> | Hixie: I mean, it's not great, but I'm also skeptical of authors handling videos that don't start at time 0 |
| 01:15 | <Hixie> | roc: yeah |
| 01:16 | <othermaciej> | ojan: if it's needed for compatibility, it's probably worth adding |
| 01:16 | <Hixie> | roc: then again, how common are videos that don't start at t=0? |
| 01:16 | <roc> | not very |
| 01:16 | <othermaciej> | (I don't understand exactly why you would want to turn off IME support per-field or what that even means, though) |
| 01:17 | <Hixie> | roc: maybe we just honour the explicit timeline if any, and if there isn't one, assert t=0 as being the earliest possible point we're aware of? |
| 01:17 | <roc> | possibly ime-mode would be better done as an HTML5 forms feature these days |
| 01:17 | <roc> | Hixie: can you clarify what that means? |
| 01:18 | <ojan> | othermaciej: yeah. there seem to be some sites that use it. it makes multiform editing easier because there are some form controls you'll always want to start in ascii (e.g. full urls) |
| 01:18 | <othermaciej> | I see |
| 01:18 | <Hixie> | ojan: sounds like it'd be better in html than css, but that ship may have sailed |
| 01:18 | <ojan> | othermaciej: i'm not convinced it's worth implementing. |
| 01:18 | <Hixie> | roc: which part? |
| 01:19 | <roc> | "maybe we just honour the explicit timeline if any" |
| 01:19 | <ojan> | but it does seem useful. |
| 01:19 | <Hixie> | roc: we set t=0 to be wherever the video file has t=0 |
| 01:20 | <othermaciej> | ojan: I wonder how plausible it is to implement this on Mac, since current input method is a system-wide setting |
| 01:20 | <Hixie> | roc: going back to what you said earlier, if we allow negative numbers then we definitely need some way to establish what the earliest known time is, so that it is possible to know how to draw the seek bar, right? |
| 01:20 | <othermaciej> | ojan: strikes me as dodgy to change it system-wide (even if temporarily) based on tabbing around in form fields |
| 01:20 | <Hixie> | roc: eh, i'll poke around and see what i come up with |
| 01:20 | <roc> | Hixie: well, I still don't want the initial time of the video to be nonzero |
| 01:20 | <Hixie> | initial time? |
| 01:21 | <roc> | the start time I guess |
| 01:21 | <ojan> | othermaciej: FF mac appears to modify the system-wide setting permanently :)_ |
| 01:21 | <Hixie> | roc: you mean in the absence of an explicit seek at the start? |
| 01:22 | <Hixie> | roc: if you can seek to before t=0, i don't see what the importance of anchoring anything at t=0 is, really |
| 01:22 | <roc> | Hixie: for example, if the player is displaying the current time, the duration (if any), the seekable ranges, and the buffered ranges, then at any moment it can take the minimum and the maximum of all relevant times and use that to scale its display bar |
| 01:22 | <othermaciej> | also there's no such thing as "no input method", at least from the UI perspective - "U.S." or "French" are no different than Kotoeri Hiragana (which is one of the more likely Japanese settings) |
| 01:23 | <othermaciej> | There is also Kotoeri Romaji which you could validly consider "no input method" (since ASCII keys type ASCII) |
| 01:23 | <othermaciej> | changing the system setting permanently seems highly bogus |
| 01:24 | <othermaciej> | on Mac it's super easy to toggle between different input methods (just hit cmd+space if you have more than one enabled) so maybe this ime-mode feature only really makes sense on Windows |
| 01:24 | <othermaciej> | certainly our international text folks in and/or from Japan have never asked for it |
| 01:25 | <Hixie> | doesn't cmd-space do spotlight? |
| 01:27 | <othermaciej> | I guess it does with default settings (which I have changed cause I don't Spotlight much) |
| 01:27 | <ttepasse> | ctrl-space ist keyboard layout switching, if I remember correctly |
| 01:28 | <roc> | Hixie: I'm guessing that authors who implement "play from the beginning" are going to do it by setting currentTime=0 |
| 01:29 | <othermaciej> | I believe if you pick US english and don't add any input methods it is spotlight |
| 01:29 | <nessy> | Hixie, roc: are dealing with durations or with end times? - if we deal with start and end times, then the seekable ranges are wrong when we use the maximum of all end times for seeeking |
| 01:29 | <nessy> | and scale the display bar |
| 01:31 | <roc> | Hixie: I'm also guessing that authors are going to create players with an initial UI state that assumes the video starts at the left end of the bar |
| 01:31 | <nessy> | Hixie, roc: another question - if we have a media fragment URI like http://ex.com/video.webm?t=50,80 - wouldn't it be more useful to display a bar with 50-80? |
| 01:32 | <nessy> | (note: I haven't made up my mind which is better - just trying to find examples where displaying from 0 might not be so useful) |
| 01:32 | <roc> | nessy: I think we should have another attribute which maps 'currentTime' to a time for display |
| 01:34 | <nessy> | roc: is this also for the case where you may have created a playlist and want to keep track of how long you have actually played? |
| 01:34 | <roc> | I don't know about that case |
| 01:36 | <Hixie> | nessy: ?t=50,80 or #t=50,80? |
| 01:36 | <nessy> | the first case - the second one is just a byte range out of the full file, so I would expect the transport bar to display from 0 to end time, but jump straight to the time offset |
| 01:37 | <Hixie> | the first case would depend entirely on what the server sent back, the UA wouldn't be awware of it, presumably |
| 01:37 | <nessy> | I was making the assumption that the server would create a shortened video from the long one that is just 30 sec long and starts at 50sec and has that information in the binary media resource |
| 01:38 | <nessy> | if you cannot get the time offset out of the media resource, then displaying the time offset is basically impossible |
| 01:38 | <Hixie> | oh that reminds me of the other question i wanted to ask |
| 01:39 | <Hixie> | it was suggested that we have a startTimeOffset that returns a Date object representing the actual date/time of t=0 |
| 01:39 | <Hixie> | if we force the first frame to t=0, should we have a startTimeOffset-like attribute to return the offset in seconds from t=0 to the original media timeline? |
| 01:40 | <nessy> | that is possible where the media resource has the actual real-world clock time that is associated with t=0 stored |
| 01:40 | <Hixie> | i guess i'd rather just expose the original media timeline, since it'll be so rare |
| 01:41 | <nessy> | is that startTimeOffset attribute an attribute that the author of the webpage provides or just a readonly exposing a media resource state? |
| 01:41 | <Hixie> | the latter |
| 01:41 | <nessy> | ok, good |
| 01:42 | <nessy> | when you say "expose the original media timeline" do you mean to expose what is stored in the media resource? |
| 01:43 | <Hixie> | yes |
| 01:43 | <nessy> | ok, I think I agree with that |
| 02:16 | <llrcombs> | @ http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#devices <-- as for generic-ness, it seems as though USB support would be fine (as long as permission is asked of the user), IMHO |
| 02:16 | <llrcombs> | ++1 for asking permission before getting an AV stream |
| 02:21 | <Hixie> | ooh, USB, good idea |
| 02:26 | <nessy> | I assume you saw https://labs.ericsson.com/blog/beyond-html5-implementing-device-and-stream-management-webkit |
| 02:55 | <llrcombs> | no, I haven't |
| 02:55 | llrcombs | reads |
| 03:00 | <llrcombs> | nessy: how is that applicible to USB/other non-video support? |
| 03:01 | <llrcombs> | that's cool and all |
| 03:01 | <llrcombs> | working <device> support |
| 03:02 | <llrcombs> | Hixie: is USB support honestly something that hasn't been brought up, or was that sarcasm? |
| 03:04 | <nessy> | yeah, I just wanted to point out that somebody implemented <device> support - not directly related to your usb discussion |
| 03:04 | <llrcombs> | alright |
| 03:04 | llrcombs | wants the code |
| 03:06 | <llrcombs> | https://labs.ericsson.com/blog/beyond-html5-audio-capture-web-browsers <-- when did audio_capture get added to the type enum? |
| 03:06 | <llrcombs> | https://labs.ericsson.com/blog/beyond-html5-full-duplex-conversational-voice-and-video-browsers-and-web-runtimes <-- same with video_capture |
| 03:09 | <nessy> | might be just Ericsson's way of solving that problem - might be a good idea to add, actually! |
| 03:22 | <llrcombs> | well, there's a media device |
| 03:33 | <Hixie> | llrcombs: not sarcasm, i just added it to the list of things <device> might be used for in the spec |
| 03:33 | <Hixie> | llrcombs: http://html5.org/tools/web-apps-tracker?from=5311&to=5312 |
| 03:42 | <llrcombs> | cool! |
| 05:06 | <karlcow> | http://reading20.posterous.com/tentative-draft-bib10-schedule |
| 05:06 | <karlcow> | Tentative Schedule |
| 05:06 | <karlcow> | Books in Browsers 2010 / October 21-22 |
| 05:06 | <karlcow> | Internet Archive - San Francisco, CA |
| 06:13 | <paul_irish> | where could i look for an indication of the default styling of <canvas>? |
| 06:13 | <paul_irish> | in particular.. display inline or block. |
| 06:13 | <paul_irish> | (I'm 90% it should be inline, but want some backup on this. :) |
| 06:14 | <aho> | inline (like img) |
| 06:19 | <aho> | paul_irish, http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#flow-content-0 |
| 06:22 | <aho> | oh zomg... noscript in head was legalized... (worked everywhere anyway) http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-noscript-element |
| 06:22 | <aho> | :o |
| 06:23 | <paul_irish> | aho: but i didnt think flow content implied inline. |
| 06:23 | <paul_irish> | div and h1 are flow content , for example. |
| 06:23 | <aho> | mh. good point |
| 06:24 | <aho> | http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#phrasing-content |
| 06:24 | <aho> | phrasing content, however, does imply inline (i think) :> |
| 06:25 | <paul_irish> | looks like a winner |
| 06:25 | <paul_irish> | thanks aho! |
| 06:25 | <aho> | :) |
| 06:31 | <micheil> | paul_irish: oh look, it's paul irish. |
| 06:31 | <micheil> | hi there |
| 06:31 | <paul_irish> | hey micheil! |
| 06:33 | <micheil> | paul_irish: hmm.. why do I get the feeling that canvas questions may be related to js1k? |
| 06:34 | <paul_irish> | oh believe me, they arent. :) i'd get my ass whooped. |
| 06:34 | <paul_irish> | though qFox gave me the idea of doing jQuery in 1k of js.... which i _may_ do. |
| 06:35 | <micheil> | paul_irish: that could be interesting |
| 06:35 | micheil | is currently struggling with YUI to write a webapp. |
| 08:42 | <annevk5> | lol |
| 08:42 | <annevk5> | shelby moore vs adam barth |
| 08:43 | <annevk5> | someone could easily do another one of those glazou blog posts with selective quotes |
| 08:47 | <annevk5> | http://diveintohtml5.org/peeks-pokes-and-pointers.html |
| 08:53 | <annevk5> | "As we have done with other standards-based features, opacity is implemented so that the same markup used in other browsers just works in IE9?s standard mode." -- they keep trying hard with that "same markup" nonsense |
| 08:54 | <annevk5> | oh lol, at the end they endorse w3schools |
| 08:57 | <Rik`> | annevk5: why nonsense ? |
| 09:06 | <annevk5> | Rik`, it's not about markup |
| 09:22 | <MasJono> | Hi there |
| 10:15 | <Rik`> | annevk5: yeah, not it's not markup but is that important ? :) |
| 10:16 | <annevk5> | no, it's just nonsense |
| 10:16 | <annevk5> | anyway, http://www.w3.org/2010/08/09-ab-minutes (W3C Member-only, quite interesting) |
| 10:36 | <annevk5> | http://www.xanthir.com/diagrams/scrollwidth-clientwidth.html is really quite nice |
| 10:46 | <MikeSmithX> | so I'm doing an appendChild within a script and I wanted to know when it's actually finished loading the node... how to check? |
| 10:47 | <MikeSmith> | the deal is that right after that appendChild, I'm doing a getElementById on the current document, with the id I'm looking for being in the node I just appended |
| 10:49 | <annevk5> | appendChild happens directly |
| 10:49 | <Ms2ger> | MikeSmith, WFM |
| 10:49 | <annevk5> | but I'm not quite sure what you are saying since if you have the node already why do you need another reference to it? |
| 10:51 | <MikeSmith> | Ms2ger: don't seem to be working for me in this case.. maybe could be because the node I'm appending is 1MB+ |
| 10:52 | <Ms2ger> | MikeSmith, what do you mean by it being 1MB+? |
| 10:52 | <MikeSmith> | annevk5: the node is contents of a file read from XHR into a newly created node |
| 10:53 | <MikeSmith> | Ms2ger: the contents of the file I'm reading in is ~1.1MB |
| 10:53 | <annevk5> | so what do you do? |
| 10:53 | <annevk5> | node.textContent = xhr.responseText |
| 10:53 | <annevk5> | then appendChild(node) |
| 10:54 | <annevk5> | then getElementById(searchInNodeForId(node)) ?! |
| 10:54 | <MikeSmith> | yeah |
| 10:54 | <MikeSmith> | and then I get an error because the ID can't be found |
| 10:55 | <MikeSmith> | but then if I check again right after that, it *can* be found |
| 10:55 | <MikeSmith> | which perhaps naively led me to believe the first ID check was getting executed for the appendChild had completed loading |
| 10:56 | <annevk5> | this happens in all browsers? |
| 10:56 | <annevk5> | sounds like a bug of some sorts |
| 10:56 | <MikeSmith> | lemme doublecheck |
| 10:56 | <annevk5> | you could find the id first and then append... |
| 10:57 | <Rik`> | I heard that browsers were single threaded :) |
| 10:57 | <MikeSmith> | hmm, yeah, true |
| 10:58 | <MikeSmith> | Rik`: just like Emacs, and just like God intended |
| 11:00 | <MikeSmith> | dammit.. how do I turn off caching temporarily in Minefield? |
| 11:01 | <MikeSmith> | start Private Browsing mode? |
| 11:01 | MikeSmith | tries that |
| 11:02 | <Rik`> | MikeSmith: web developer toolbar |
| 11:03 | <Rik`> | or about:config -> browser.cache.disk.enable, browser.cache.memory.enable |
| 11:05 | <MikeSmith> | thanks |
| 11:22 | <MikeSmith> | annevk5: this is probably a really dumb question... but how do I find an ID in a node without first appending it to the document and using getElementById? |
| 11:22 | <annevk5> | if you have a node object you can do all normal operations on it |
| 11:23 | <annevk5> | in fact, if your finding function just takes a string you can do it on responseText directly |
| 11:23 | <annevk5> | but I'm not quite sure what you are doing, no pointer? |
| 11:30 | <MikeSmith> | code is in my workspace.. gimme a second and I'll pastebin it |
| 11:34 | <annevk5> | hmm |
| 11:35 | <annevk5> | maybe CSSValue.type should be a space-separated list of all interfaces that are implemented |
| 11:35 | <annevk5> | or rather, a DOMStringList or some such |
| 11:35 | <MikeSmith> | http://pastebin.ca/1919359 |
| 11:36 | <MikeSmith> | annevk5: ↑ |
| 11:36 | <annevk5> | somewhat unorthodox but it at least allows for the crazy extensions CSS does all the time |
| 12:25 | <annevk5> | sorry MikeSmith |
| 12:25 | <annevk5> | looking now |
| 12:28 | <annevk5> | MikeSmith, I don't really understand how fileContents is used |
| 12:40 | <Ms2ger> | MikeSmith, you the element you return from initDfn doesn't have an id attribute yet |
| 12:41 | <MikeSmith> | Ms2ger: yeah, I'm not checking that anyway.. not at this point at least |
| 12:42 | <MikeSmith> | annevk5: fileContents is a bunch of <div> index entries, with IDs on each of them |
| 12:42 | <MikeSmith> | I look for an ID and show the contents of that div |
| 12:43 | <MikeSmith> | trying something else now, inside the callback |
| 12:44 | <MikeSmith> | so when I do an xhr.onreadystatechange = function () {...} can I pass parameters to the function? |
| 12:44 | <jgraham> | MikeSmith: closures |
| 12:46 | <MikeSmith> | jgraham: I've tried hard to avoid any need to learn about closures... I suppose I can't escape it |
| 12:46 | <jgraham> | MikeSmith: Nothing to be scared of |
| 12:48 | <Philip`> | Well, there's a few things to be scared of |
| 12:48 | <annevk5> | you can do function() { test(.., .., ..) } |
| 12:50 | <annevk5> | MikeSmith, aah, when do you check if the <div> is there? |
| 12:50 | <annevk5> | MikeSmith, you can only assume the <div> is there after the resource has been fetched |
| 12:51 | <annevk5> | MikeSmith, because the fetching happens asynchronously |
| 12:52 | <MikeSmith> | annevk5: yeah, I have since (re)discovered that |
| 12:52 | MikeSmith | is rewriting his code now |
| 12:52 | <annevk5> | these things bite people all the time |
| 12:53 | <annevk5> | earlier today I checked a testcase someone wrote that fetched an image and assumed it was loaded by the time he got to invoke ctx.createPattern |
| 12:53 | <Ms2ger> | annevk5, easy, just use sync XHR :) |
| 12:54 | <MikeSmith> | holy crap... I actually just made it work |
| 12:54 | <jgraham> | Ms2ger: You know there is a special level of hell reserved for people who say things like that — even in jest |
| 12:55 | <MikeSmith> | jgraham: It seems I already understood what closures are, but was trying to make it more complicated by explicitly passing args to the inner function when I didn't really need to |
| 12:55 | <jgraham> | I say "level" |
| 12:55 | <jgraham> | It's more like a whole wing |
| 12:55 | <Ms2ger> | jgraham, I do |
| 12:55 | <MikeSmith> | maybe I could get into the Daily WTF as "The Man Who Discovered Closures" |
| 12:57 | <annevk5> | maybe in MikeSmith's Daily WTF |
| 12:57 | <annevk5> | great name for a blog |
| 13:01 | Ms2ger | would read that |
| 13:03 | <MikeSmith> | heh |
| 13:09 | <MikeSmith> | OK, fwiw, here's the updated source that now actually seems to work - |
| 13:09 | <MikeSmith> | http://pastebin.ca/1919394 |
| 13:10 | <MikeSmith> | gimme a minute to commit it and you can have the pleasure of seeing it in action |
| 13:36 | <Peter`> | The HTML5 specification often refers to data: URIs, sometimes even require it, but doesn't have a reference to rfc2397. Neither is it documented when data: URIs are expected to work (for images, scripts, stylesheets, entire documents?). Is this intentional? |
| 13:41 | <annevk5> | Peter`, don't think so |
| 13:42 | <Peter`> | should I write a mail to the whatwg list about it? |
| 13:43 | <annevk5> | yeah |
| 13:44 | <annevk5> | or file a bug or some such, the idea is for the document to not be vague on these things :) |
| 13:45 | <Peter`> | alright, thanks |
| 13:56 | <jgraham> | Peter`: I assume data: uris should work eeverywhere URIs should work unless stated otherwise |
| 14:13 | <MikeSmith> | OK, if anybody has a couple minutes, please try http://dev.w3.org/html5/spec-author-view/dom.html |
| 14:13 | <MikeSmith> | or anything other multipage file in the author view of the spec there |
| 14:13 | <MikeSmith> | and click on a boldfaced term -- any dfn |
| 14:13 | <MikeSmith> | and let me know if it works for you |
| 14:14 | <annevk5> | seems to work |
| 14:15 | <jgraham> | MikeSmith: Slow and the styleheet changes? |
| 14:15 | <jgraham> | The status annotations become red at least |
| 14:15 | <jgraham> | rather than blue |
| 14:15 | <MikeSmith> | hmm.. the stylesheet shouldn't be changing.. dunno why it is |
| 14:15 | <MikeSmith> | annevk5: if you click another term now, it should no longer be slow |
| 14:16 | <MikeSmith> | should be immediate, hopefully |
| 14:16 | <MikeSmith> | the first time you click on a term, it loads a 1.2MB file and appends it to the document |
| 14:16 | <jgraham> | MikeSmith: I complained about the slowness |
| 14:17 | <jgraham> | Yeah, it is fast the second time |
| 14:17 | <MikeSmith> | oh |
| 14:17 | <MikeSmith> | OK |
| 14:17 | <jgraham> | But it is *really* slow the first time |
| 14:17 | <MikeSmith> | yeah |
| 14:17 | <jgraham> | Like "I wonder if this actually works" slow |
| 14:17 | <jgraham> | "oh no it doesn't" |
| 14:17 | <MikeSmith> | yeah.. I'm not sure what to do about that -- except maybe to provide a better status indicator |
| 14:18 | <jgraham> | "oh wait yes it does" |
| 14:18 | <jgraham> | MikeSmith: Why is it loading 1.2 MB of data? |
| 14:18 | <jgraham> | surely the cross references aren't that big? |
| 14:18 | <MikeSmith> | the alternative is to slurp in the whole 1.2MB on document load every time |
| 14:18 | <MikeSmith> | jgraham: yeah, they are |
| 14:18 | <MikeSmith> | hang on a minute, I'll give you a link |
| 14:19 | <MikeSmith> | or in the mean time you can use a DOM inspector and see |
| 14:19 | <Rik`> | http://dev.w3.org/html5/spec-author-view/index-of-terms.html ? |
| 14:19 | <MikeSmith> | Rik`: bingo |
| 14:20 | <Workshiva> | What about requesting just the term clicked? |
| 14:20 | <MikeSmith> | it's a static index of every hyperlinked reference to a dfn in the spec |
| 14:20 | <jgraham> | MikeSmith: Surely a sensible file format + compression would solve this? |
| 14:20 | <Philip`> | Can't you store it in a much more efficient format and generate the markup client-side, instead of downloading as HTML? |
| 14:20 | <MikeSmith> | yeah, I guess I could |
| 14:21 | <Rik`> | either store in a more compact format or only serve the part you need |
| 14:21 | <MikeSmith> | but I'm being lazy and just reusing the same index that I'm adding to the full version of the spec |
| 14:21 | <MikeSmith> | yeah |
| 14:21 | <Philip`> | Rik`: Or both :-) |
| 14:21 | <Workshiva> | Sounds like a job for XSLT! |
| 14:21 | <MikeSmith> | heh |
| 14:21 | <MikeSmith> | I figured this was good enough for a proof of concept at least |
| 14:21 | <annevk5> | wfm |
| 14:21 | <Rik`> | Philip`: well, sending only the relevant part directly in HTML should be faster overall |
| 14:21 | <annevk5> | it's funny, when you give people more bandwidth, they'll use it |
| 14:22 | <jgraham> | Do you think MikeSmith wears a lycra outfit with a big X on the chest when coding XSLT? |
| 14:22 | <MikeSmith> | anyway, as a consequence, the full version of the spec now has an index of terms also - |
| 14:22 | <MikeSmith> | http://dev.w3.org/html5/spec-author-view/spec.html#index-of-terms |
| 14:23 | <MikeSmith> | I wear a dunce cap when coding XSLT |
| 14:23 | <MikeSmith> | but I still do it |
| 14:23 | <MikeSmith> | I'm a glutton for punishment |
| 14:24 | <MikeSmith> | so at least this is better than nothing, hopefully |
| 14:24 | <MikeSmith> | "nothing" being that previously, the dfn pop-ups didn't work at all in the multipage version of the spec |
| 14:24 | <MikeSmith> | baby steps |
| 14:25 | <Workshiva> | Yeah, don't be dissuaded by high expectations :) |
| 14:25 | <MikeSmith> | me being the baby, doing the coding |
| 14:25 | <Philip`> | It may not be better for people who are charged per megabyte for traffic and who accidentally click on a definition |
| 14:26 | <MikeSmith> | Philip`: sure it will be |
| 14:26 | <MikeSmith> | it'll be a "learning moment" for them |
| 14:26 | <Philip`> | It'll learn them not to read the spec? |
| 14:26 | <jgraham> | Not to tust things written by MikeSmith maybe |
| 14:26 | <jgraham> | *trust |
| 14:26 | <MikeSmith> | heh |
| 14:28 | <MikeSmith> | maybe we can have a WBS survey to ask people which they find more frustrating: This vs Trying to load the full single-page version of the spec |
| 14:29 | <annevk5> | or maybe "This" vs "That" |
| 14:30 | <jgraham> | Can we have an option for "I have never tried to open the spec" |
| 14:32 | <Philip`> | MikeSmith: "Less frustrating than loading the single-page spec" is not really a great challenge |
| 14:32 | <MikeSmith> | heh |
| 14:32 | <Philip`> | Printing the spec onto paper and then dropping all the sheets and getting them all out of order is likely to be less frustrating than opening the single-page version |
| 14:33 | <MikeSmith> | what about if it's windy? |
| 14:33 | <Philip`> | since at least it won't freeze everything else you're currently working on |
| 14:34 | <Philip`> | and you won't have people telling you that you're silly for using obsolete (i.e. publicly released) browser versions |
| 14:37 | <MikeSmith> | I think what we need as a solution to this is a new "This page best viewed in..." button: "This page best viewed in any browser that doesn't crash or freeze every time you try to view it." |
| 14:38 | <Philip`> | The Acid3 test should have contained a <iframe src="http://whatwg.org/c">; to more strongly encourage browser developers to optimise for it |
| 14:40 | <MikeSmith> | <snicker> |
| 14:40 | <MikeSmith> | Rik`: loading only the relevant part would be my preferred solution |
| 14:41 | <MikeSmith> | but lacking a standard way to load fragments of another document, I guess I'd need to write some server-side way to do it |
| 14:41 | <MikeSmith> | as far as I can see |
| 14:42 | <MikeSmith> | annevk5: does XHR2 enable addressing and loading of document fragments? |
| 14:43 | <Philip`> | MikeSmith: Could you just split the index into one static .html file per letter? |
| 14:43 | <Rik`> | MikeSmith: can't you use html5lib for that ? :) |
| 14:44 | <MikeSmith> | Philip`: yeah, I guess I could |
| 14:52 | <MikeSmith> | apparently there are about 1060 dfn instances in the spec |
| 14:53 | <MikeSmith> | would it be too obnoxious to just have the doc build write a separate file for each? |
| 14:53 | <MikeSmith> | (in a subdirectory of course) |
| 14:55 | <Workshiva> | That would certainly be cache-friendly :) |
| 14:55 | <MikeSmith> | hmm, yeah -- that too |
| 14:56 | <annevk5> | MikeSmith, that seems like something for the server to implement |
| 14:57 | <Philip`> | MikeSmith: Who would find it obnoxious? |
| 14:57 | <cheeser> | ugh. reading the hybi list is making me sad. |
| 14:57 | <Philip`> | I assume users wouldn't care, because they'll only download the files they need (which will usually be 0 or 1) |
| 14:57 | <cheeser> | websockets used to be such a simple protocol. |
| 14:58 | <jgraham> | cheeser: You should say that on the list |
| 14:58 | <annevk5> | the evil part of Google ran away with it |
| 14:59 | <Philip`> | Maybe it wouldn't be fun on the server side if you have to commit a thousand files to an SVN repository on every change, but if they're just static files then I don't see why it'd be a problem |
| 14:59 | <cheeser> | jgraham: good call. will do. i'll probably get flamed but hey. i'm trying to implement all this so i should say something. |
| 14:59 | <annevk5> | there's a few people arguing for keeping the initial version simple |
| 15:00 | <jgraham> | I was quite sad when I was having a conversation with someone from Google on the list and he basically said "if it doesn't work for Google-sized installations in V1 it is useless because all end-user value comes from Google-sized companies" |
| 15:00 | <annevk5> | Ian Hickson, Martin Thompson, myself, ...? |
| 15:00 | jgraham | raises hand |
| 15:00 | <gsnedders> | I didn't see that. |
| 15:00 | <boblet> | regard ing the epic <time> for year & year-month debate, did anyone mention formatting Japanese dates as a use case? eg 18-8-2010 is 2010年8月18日… (ping: Hixie) |
| 15:00 | <gsnedders> | You liar. |
| 15:00 | <jgraham> | gsnedders: Me? |
| 15:01 | <gsnedders> | yeah. |
| 15:01 | <jgraham> | Why? |
| 15:01 | <gsnedders> | jgraham: I didn't see you raise your hand. |
| 15:01 | <jgraham> | Oh I thought you meant about the Google thing |
| 15:01 | <annevk5> | boblet, formatting does not seem to have anything to do with it |
| 15:02 | <boblet> | annevk5: Hixie wrote one of the three primary use cases was “The ability to restyle dates that contain a "day" component so that they follow user conventions (2000-12-31 vs 31-12-2000 vs 12-31-2000).” |
| 15:02 | <boblet> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html |
| 15:03 | <annevk5> | yeah, via CSS |
| 15:03 | <boblet> | so possibly related given adding the year, month, day kanji are Japanese user conventions |
| 15:03 | <jgraham> | (for the record, he probably didn't say "all" but used words like "weighted". But the message was basically the same) |
| 15:03 | <annevk5> | only the input format is considered relevant for HTML |
| 15:03 | <annevk5> | jgraham, wasn't it more like it's of no use to Google if there's no multiplexing? |
| 15:04 | <boblet> | annevk5: wouldn’t this use case apply equally to 8-2010 and 2010-8? |
| 15:04 | <jgraham> | annevk5: Yeah, but then he said that it being no use to Google meant that it was useless in general because end users mostly get value from Google and similarly large companies |
| 15:04 | <jgraham> | It is true that those people provide value |
| 15:05 | <cheeser> | sent |
| 15:05 | <annevk5> | boblet, i almost never see that tbh |
| 15:05 | <jgraham> | It is not true that adding support for their needs in V2 is a disaster |
| 15:05 | <annevk5> | wow really? |
| 15:05 | <annevk5> | glad i missed that |
| 15:06 | <MikeSmith> | Philip`: OK, I'll tweak it to have the build also generate separate files and give it a try that way as well |
| 15:06 | <MikeSmith> | Philip`: the means I'm using for generating the index is a patch i wrote for anolis |
| 15:06 | <annevk5> | cheeser, +1 to you |
| 15:07 | annevk5 | is somewhat interested in Microsoft/Apple/Mozilla voicing their opinion |
| 15:08 | <smaug____> | I prefer simple protocol for v1 |
| 15:08 | <smaug____> | though the v76 is still ugly as hell |
| 15:08 | <jgraham> | smaug____: You feel like saying that on the list? |
| 15:08 | <jgraham> | (v76 is outdated) |
| 15:08 | <jgraham> | (although the handshake is still there) |
| 15:08 | <annevk5> | smaug____, I think everyone is agreed upon that what v76 did is not very great |
| 15:08 | <smaug____> | well, whatever is the v76 like protocol nowadays |
| 15:08 | <boblet> | annevk5: if you mean yyyy-mm that’s the common order in Japan (eg Japanese blog archives etc) |
| 15:09 | <annevk5> | smaug____, you mean you don't like the non-sentinel design either? |
| 15:09 | <jgraham> | The only serious alternative to the handshake is abarth's SSL stuff |
| 15:09 | <smaug____> | the handshake is the ugly part |
| 15:09 | <annevk5> | kk |
| 15:09 | <jgraham> | although the hybi people hate the 8 bytes |
| 15:09 | <jgraham> | s/hybi/server/ |
| 15:09 | <MikeSmith> | smaug____: when you say it on the list, please also say that are certain the Apple and Microsoft fully agree with you.. then they will be compelled to comment in some way at least -- even if it's only to contradict you |
| 15:10 | <jgraham> | or some of them at least |
| 15:10 | <annevk5> | I don't really understand the cross-protocol issues well enough to come forward with a better handshake... |
| 15:10 | <smaug____> | it is a big problem that google is pushing very hard something they want |
| 15:10 | <smaug____> | imo |
| 15:11 | <annevk5> | yeah, that's why the other Ian was better, he doesn't care about Google |
| 15:12 | <annevk5> | Ian Fette basically said at the meeting that whatever complexity was needed to buy them a few milliseconds was worth it |
| 15:13 | Philip` | wonders if it's partly a consequence of performance being easy to measure and complexity being hard to measure |
| 15:14 | <Philip`> | (It's easy to provide numerical evidence arguing for an extra feature, and hard to say more than "I don't like that because it looks a bit complicated to me" against it) |
| 15:14 | <annevk5> | Similarly Google has proposed a bunch of TLS extensions to increase performance |
| 15:15 | <annevk5> | I wonder if at some point you can only compete if you have some ridiculously complex setup. That'd be really bad. |
| 15:16 | <jgraham> | Philip`: Do you know what is supposed to happen about rounding in drawImage()? |
| 15:17 | <Philip`> | jgraham: Implementation-defined, I think - conceptually the canvas has infinite resolution and you approximate it to a finite grid of pixels using whatever antialiasing and filtering you fancy |
| 15:18 | <jgraham> | So if you have something that is epsilon outside of the image you can raise INDEX_SIZE_ERR or draw it? |
| 15:20 | <Philip`> | jgraham: Oh - if it's about exceptions rather than rendering, I'd expect you'd convert the arguments to 32-bit floats (per WebIDL) and then do an exact comparison against the image's (integer) size |
| 15:20 | <cheeser> | i think complicating the spec to suppor the random 6TB frame is the wrong thing to do. |
| 15:21 | <jgraham> | cheeser: Most of the complication doesn't come from large frame sizes does it? |
| 15:21 | <Philip`> | so you'd get an exception if the epsilon is large enough to make a representable difference after conversion to 32-bit float |
| 15:21 | <cheeser> | e.g., i see websocket as a great replace for XHR for ajax. |
| 15:21 | <cheeser> | well, there's the whole framing debate going on right now. |
| 15:21 | <jgraham> | It seems that framentation and all the mandatory but empty extension stuff adds most of the complexity |
| 15:21 | <cheeser> | an initial 7 bits plus an option 64 if the first 7 == 127 blahblahlbah |
| 15:21 | <jgraham> | and the variable-but-not-very frame length |
| 15:22 | <cheeser> | i liked the 64 frame length delimiter. makes it every straight forward to parse. |
| 15:22 | <Philip`> | jgraham: (and WebIDL seems to define precisely how you round during conversion to 32-bit float) |
| 15:22 | <cheeser> | if you need more than that in your frame, fragment it. |
| 15:22 | <jgraham> | Philip`: Hmm, OK |
| 15:22 | <cheeser> | that'd solve the blocking of subsequent requests behind larger ones. |
| 15:22 | <jgraham> | Philip`: There is an obvious race to the bottom here if someone gets it wrong though... |
| 15:23 | <cheeser> | as it is, that's a huge payload anyway |
| 15:23 | <Philip`> | jgraham: Yeah - I don't like it when algorithms depend on floating-point values and have discontinuities in the output |
| 15:24 | <Philip`> | (like drawing an arc vs not drawing an arc, or drawing an image vs throwing an exception, based on epsilon changes to arguments) |
| 15:24 | <Philip`> | I don't know if it's feasible to avoid those situations entirely, though |
| 15:24 | <jgraham> | Philip`: Possibly not, but we have a bug report on this one :) |
| 15:25 | <jgraham> | I'm not sure if we are wrong; I need to check the WebIDL |
| 15:25 | <jgraham> | spec |
| 15:25 | <Philip`> | I suppose the non-discontinuous behaviour would be for drawImage to interpret pixels outside the image as transparent |
| 15:25 | <Philip`> | since then it won't matter if you are slightly over the edge or not |
| 15:26 | <Philip`> | jgraham: A bug from real code that breaks, or from an artificial test case? |
| 15:27 | <jgraham> | I think real code |
| 15:27 | <gsnedders> | real code |
| 15:29 | <Philip`> | I guess it might not be too late to redefine drawImage to be less dangerous, since hopefully people don't rely on it throwing exceptions |
| 15:31 | <payman> | Philip`: This is the test case: http://www.jigzone.com/xmockup/oCanvasBug.php |
| 15:36 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3Ew%28%2879%2F7%29*6%20%2B%2079%2F7%20-%2079%29%3C%2Fscript%3E |
| 15:36 | <Philip`> | Looks like Opera's computing the same value as Firefox |
| 15:37 | <Philip`> | floats only do ~6 digits so 79.00000000000001 == 79 so it sounds like an Opera bug if they're handled differently |
| 15:37 | <Philip`> | (in the implementation of the WebIDL layer) |
| 15:38 | <jgraham> | Philip`: Agreed |
| 15:38 | <Philip`> | I guess that kind of code could still trigger an exception after the correct float conversion, if it was sufficiently unlucky |
| 15:40 | <Philip`> | Actually, maybe it couldn't |
| 15:41 | Philip` | shrugs |
| 15:43 | <payman> | Philip`: Are there any tests for float conversion? |
| 15:43 | <payman> | (in WebIDL or the canvas test suite) |
| 15:45 | <Philip`> | payman: I don't think I have any tests that rely on the float rounding |
| 15:45 | <Philip`> | I have no idea whether WebIDL has any tests at all |
| 15:45 | <jgraham> | payman: I don't know if anyone has really tried to write a WebIDL testsuite. I'm not even sure how easy that would be, in general |
| 15:46 | Philip` | supposes he could add some to his tests, at some unknown point in the future |
| 15:47 | <masjonosumitro> | hi |
| 15:48 | <Peter-> | jgraham (re: dataurl): I agree, I would expect them to work at all, but if it's not written down it's an assumption. Right now IE differs from other browsers by only supporting data URLs for <script> and <img> |
| 15:48 | <gsnedders> | jgraham: Someone had something that checked WebIDL bindings |
| 15:48 | <jgraham> | gsnedders: Checked what? |
| 15:49 | <gsnedders> | jgraham: http://suika.fam.cx/www/webidl2tests/readme |
| 15:49 | <jgraham> | YOu can check stuff like readonly fairly easilly |
| 15:49 | <Philip`> | Peter-: Should it be written down that you can use http: and ftp: and file: and etc, in each one of those places? |
| 15:49 | <payman> | Philip`: You can always add it to your TODO...like you did to my tests about non-finite clockwise ;) |
| 15:49 | <gsnedders> | jgraham: Checked quite a lot, I think |
| 15:49 | <Philip`> | payman: I have done so :-) |
| 15:49 | <Philip`> | Unlike most of my todo lists, I occasionally even read this one |
| 15:51 | <annevk5> | Peter-, HTML5 should prolly not require data: URL support specifically; and if it does only for certain conformance classes |
| 15:51 | <Peter-> | Philip`: section 2.5.1 defines the aglorithm for url parsing, according to rfc 3987 (iri) |
| 15:56 | <Peter-> | annevk5: I'm not sure if data: URLs validate against URI or IRI references |
| 15:57 | <Peter-> | annevk5: if not, then they technically aren't valid values for the attributes |
| 15:57 | <AryehGregor> | Peter-, we went through this here once before -- IIRC, the conclusion was that data: and javascript: aren't legitimate URIs. |
| 15:58 | <Peter-> | require them, I'm not sure, haven't been around long enough to make such a judgement call, but listing them as valid values certainly would help |
| 16:00 | <jre> | Aryeh, why would a "data" URI not be legitimate? |
| 16:01 | <AryehGregor> | It doesn't match the production given in the RFC. |
| 16:01 | <jre> | and how concluded that? |
| 16:01 | AryehGregor | looks it up again |
| 16:01 | <jre> | I don't believe that's true |
| 16:01 | <AryehGregor> | http://tools.ietf.org/html/rfc3986 |
| 16:02 | <jre> | if it was, there should be an erratum on RFC 2397. |
| 16:02 | <jre> | yes? |
| 16:02 | <annevk5> | Peter-, all valid URIs are valid IRIs |
| 16:02 | <AryehGregor> | I'm looking for the exact section. |
| 16:02 | <Peter-> | annevk5: ok, thanks |
| 16:03 | <AryehGregor> | URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] |
| 16:03 | <AryehGregor> | hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty |
| 16:03 | <annevk5> | jre, so script or refresh? |
| 16:03 | <jre> | Anne, occasional refreshs |
| 16:03 | <AryehGregor> | But data: and javascript: allow arbitrary strings after the ":", including those that don't match any of those four hier-part descriptions. |
| 16:03 | <Peter-> | But if data: and javacript: URIs aren't valid, that would imply that any document using them wouldn't validate against HTML5 |
| 16:04 | <AryehGregor> | Possibly. I dunno. |
| 16:04 | <jre> | they match one of the path- productions. |
| 16:04 | <AryehGregor> | Which one? |
| 16:04 | <jre> | path-rootless, I'd say |
| 16:04 | <annevk5> | AryehGregor, browser usually does the percent-escaping |
| 16:04 | <AryehGregor> | Certainly not the first, there's no authority. Nor path-absolute, that must start with "/". Nor path-empty. |
| 16:04 | <AryehGregor> | Hmm. |
| 16:05 | <AryehGregor> | If you percent-escaped them they'd be path-rootless, yes. |
| 16:05 | <annevk5> | data:text/html,<!doctype html> works fine, but only valid when escaped |
| 16:05 | <AryehGregor> | So you could argue that they're really URIs but we just don't escape them because we're lazy? |
| 16:05 | <annevk5> | but that also goes for http://example.org/path with spaces/ |
| 16:05 | <jre> | do you really believe RFC 3986 would be a full internet standard with a bug like that? |
| 16:05 | <AryehGregor> | Sure, why not? Plenty of specs have gaping errors. |
| 16:06 | <annevk5> | AryehGregor, in a way |
| 16:06 | <jre> | Not this one :-). |
| 16:06 | <annevk5> | should prolly just allow a bunch more characters when there's no harm |
| 16:06 | <annevk5> | kind of curious to see what abarth comes up with |
| 16:07 | <AryehGregor> | Yeah, I don't see why schemes shouldn't be allowed to just say that the stuff after the colon is opaque. |
| 16:07 | <AryehGregor> | There's no sense in requiring escaping in that case. |
| 16:08 | <annevk5> | the escaping might be needed if e.g. you have a space-separated list of them |
| 16:09 | <annevk5> | but that requirement should not come from the URL spec imo |
| 16:13 | <umbrae> | Just curious your guys' opinion on this: I have blog entry (as an <article>), and a pull quote that is repeated inside of this article for visual distinction. Should that pull quote go inside of an <aside>, or a <figure>? Or something else? |
| 16:14 | <AryehGregor> | The spec specifically suggests <aside> for pull quotes. |
| 16:16 | <umbrae> | I feel like aside is right as well, just questioned myself a bit because figure doesn't explicitly say 'media', so I was curious what the consensus might be. |
| 16:18 | <AryehGregor> | Aside and figure are pretty similar in concept. |
| 16:19 | <umbrae> | Seems so. I still think the distinction is semantically useful, though. |
| 17:17 | <badcat> | hello guys! Not sure if this is the right channel to ask, but I'm looking for a javascript library that helps me a bit with the html5 canvas - basically something that makes having interactive scenes/interfaces with canvas a bit easier |
| 17:18 | <badcat> | qt (the c++ framework) has a graphics scene class that allows me to add and manipulate objects in real time and have events dispatched whenever the user drag/drops or clicks on scene items |
| 17:21 | <annevk5> | you might wanna look at SVG instead |
| 17:22 | <badcat> | annevk5: why? |
| 17:23 | <annevk5> | it has objects and events et al |
| 17:24 | <badcat> | annevk5: canvas has that too, also I have to visualize data and objects that I receive as JSON via ajax, so that might be a problem |
| 17:26 | <Ms2ger> | Why would that be a problem? The WG likes to call it Scriptable Vector Graphics, after all... |
| 17:27 | <badcat> | hmm, i'll take a look into that. but I really loved the fact that I could simply parse the JSON data, and iterate over the javascript objects to draw my objects to the canvas. unfortunately making it interactive is a whole different story |
| 17:29 | <umbrae> | Are you looking to help contribute code, badcat? Carena looks a bit like what you're talking about but is still incredibly early in development: http://github.com/tmpvar/carena |
| 17:30 | <badcat> | umbrae: not really, I'm looking for something that already exists. I've found progressing.js, but it doesn't seem like what I need |
| 17:49 | <vsedach> | hello |
| 17:49 | <vsedach> | I have a question about canvas clipping regions |
| 17:50 | <Ms2ger> | vsedach, just ask |
| 17:50 | <Philip`> | badcat: You can interate over the JSON data to draw your objects by using DOM functions to construct an SVG document |
| 17:50 | <Philip`> | *iterate |
| 17:50 | <vsedach> | as far as I can see from the spec, there's no way to reset a clipping region, only add to it |
| 17:50 | <vsedach> | so the way to manage clipping regions is save/restore |
| 17:50 | <vsedach> | is that correct? |
| 17:51 | <vsedach> | if so, that's pretty annoying |
| 17:51 | <Philip`> | vsedach: Yes |
| 17:51 | <badcat> | Philip`: I'm reading about it right now.. looking for some concrete examples |
| 17:52 | <vsedach> | are there plans to add a resetClip method? |
| 17:52 | <Philip`> | vsedach: Why is it annoying to use save/restore? |
| 17:53 | <vsedach> | Philip`: if you want to change the clipping region but keep the rest of the state the same, you basically end up with your own save/restore clip region method that fakes resetClip |
| 17:54 | <vsedach> | this isn't a problem with new code, but I'm working on an application that generates drawing commands assuming there's a resetClip (it's written for cairo) |
| 17:56 | <Philip`> | There's some vague desire to redesign the path API, which I guess includes the clipping, but I don't think that's been worked out in any detail |
| 17:58 | <vsedach> | Philip`: thanks for the info! I guess I'll have to make do :) |
| 19:04 | <Hixie> | so... video and Content-Type headers |
| 19:04 | <Hixie> | are we calling a time of death and requiring well-defined interoperable sniffing? |
| 19:05 | <Hixie> | i don't even know where to begin to test what browsers do with this |
| 19:09 | <Hixie> | i searched for a random webm file |
| 19:09 | <Hixie> | first one i found was text/plain |
| 19:09 | <Hixie> | that bodes well |
| 19:14 | <AryehGregor> | Why does anyone care if browsers sniff here, again? Other than theoretical purity? As long as they're not interpreting non-scripted content as scripted . . . |
| 19:16 | <Hixie> | i'm not aware of any reason other than theoretical purity |
| 19:17 | <Philip`> | AryehGregor: It helps users who see a <video> that plays, and right-click and say "open in new tab", and get a load of text/plain garbage displayed instead |
| 19:17 | <AryehGregor> | Philip`, they can sniff on direct viewing too. |
| 19:17 | <AryehGregor> | It's a pain, but servers just don't set MIME types right, so . . . |
| 19:17 | <Hixie> | Philip`: they wouldn't get text/plain garbage |
| 19:17 | <Hixie> | Philip`: since we're already sniffing in that case |
| 19:30 | <karlushi> | I do not think it is "servers that just don't set MIME types right" but more "servers administrators/configuration UIs make it hard for users to add MIME types" (when new stuff is coming). |
| 19:30 | <AryehGregor> | Are you saying that users should be required to manually add new MIME types to their server for stuff to work properly? |
| 19:30 | <AryehGregor> | That seems undesirable. |
| 19:31 | <AryehGregor> | People should be able to just dump stuff from FTP and have it work, if possible. |
| 19:31 | <AryehGregor> | To some extent that's not possible, of course. |
| 19:31 | <Hixie> | i don't really see the point of MIME types for binary data types |
| 19:32 | <karlushi> | :) FTP is not part of the Web, the failure of mime type on the Web is partly because of that :) but that is a long story. |
| 19:32 | <AryehGregor> | Maybe we should just officially switch from MIME types to file extensions. The latter are probably much more reliable for random files . . . |
| 19:32 | <AryehGregor> | But for binary types, sniffing is usually fairly easy, if the formats are designed to support it. |
| 19:32 | <karlushi> | I would expect that yes for some hosting platform giving the possibilities for users to set up some mime types might be useful and will distribute the management of issues. |
| 19:33 | <AryehGregor> | Or you could just not require MIME types to be set up at all. Practically speaking, why is that not the better solution? |
| 19:33 | <Hixie> | AryehGregor: file extensions are as bad as mime types as far as i can tell |
| 19:33 | <AryehGregor> | You shouldn't have to know what a MIME type is to put up some video on your website. |
| 19:33 | <Hixie> | possibly worse since the receiver specifies it |
| 19:33 | <karlushi> | AryehGregor, you might want to put things online without file extension. |
| 19:33 | <AryehGregor> | Hixie, they can't be as bad as MIME types, because servers usually base the MIME type on the extension. At least extensions work without server configuration. |
| 19:34 | <AryehGregor> | (I'm not talking about stuff that passes through scripts, though.) |
| 19:34 | <AryehGregor> | karlushi, well, so then use MIME. |
| 19:34 | <karlushi> | AryehGregor, exactly :) |
| 19:34 | <AryehGregor> | But most people use file extensions. |
| 19:34 | <AryehGregor> | Even for well-known types, it will usually be served with a MIME type that's just inferred from the extension. |
| 19:34 | <Hixie> | whatever solution we use, we definitely want something that the is picked by the sender, not the receiver |
| 19:35 | <karlushi> | but if you use the bloggers, the tumblr, etc. of this world. You enter in issues on configuration for new mime types such as WebM |
| 19:35 | <AryehGregor> | Who are the sender and receiver here? |
| 19:35 | <Hixie> | ideally something that can't be wrong, e.g., defined sniffing for binary data |
| 19:35 | <AryehGregor> | Sniffing for binary data can be wrong, see GIFAR. |
| 19:36 | <karlushi> | Maybe it could be mime types config file distribution ala SpamAssassin (sa-update), We could have a mime type update mt-update |
| 19:36 | <AryehGregor> | Which people on shared hosting will deploy how? |
| 19:36 | <Hixie> | GIFARs rely on undefined sniffing |
| 19:36 | <AryehGregor> | Well, if every binary format chose a unique binary string to prefix the file, then sniffing would always work. |
| 19:37 | <AryehGregor> | It's too bad that's not a universally-accepted standard. |
| 19:37 | <Hixie> | we don't have a universally-accepted standard :-) |
| 19:37 | <AryehGregor> | But the cat is out of the bag with JAR anyway, so a WebMAR vulnerability makes no difference at this point. |
| 19:37 | <karlushi> | There is a lot of social engineering which could be put in place to improve the situation (not fixing everything but improving) |
| 19:38 | <AryehGregor> | Or you could skip the social aspect, acknowledge it's a technical problem, and go with an easy-to-deploy technical solution without demanding special effort from anyone. |
| 19:38 | <AryehGregor> | Which seems like the best option here. |
| 19:39 | <AryehGregor> | Although sniffing on a large scale is massively headache-inducing. I reported a bug to freedesktop.org because it would sniff any file beginning with "--" as a VHDL document. |
| 19:39 | <karlushi> | http://www.w3.org/TR/chips/#gl7 |
| 19:39 | <AryehGregor> | But in the limited context of a web browser having to figure out how to handle a small number of types, I guess it's feasible. |
| 19:39 | <AryehGregor> | Yes, great, let's try to resurrect content negotiation. Have fun with that. |
| 19:40 | <ojan> | Hixie: http://www.w3.org/TR/html401/struct/global.html#h-7.5.3 This distinction doesn't exist in HTML5 right? |
| 19:40 | <karlushi> | :) we do not have to resurrect it. We already use it :) |
| 19:40 | <AryehGregor> | ojan, it does, it's just not called that. |
| 19:41 | <AryehGregor> | Probably because it's confusing, since the same terms are used by CSS. |
| 19:41 | <AryehGregor> | HTML5 calls them "flow content" and "phrasing content" or something. |
| 19:41 | <ojan> | AryehGregor: specifically, i'm wondering whether it's valid to put block-level elements inside inlines |
| 19:41 | <Hixie> | ojan: we have a slightly different distinction |
| 19:41 | <AryehGregor> | ojan, check each element for what its content model is. |
| 19:41 | <AryehGregor> | It says in the spec what any given element can contain. |
| 19:42 | <AryehGregor> | karlushi, for compression options, maybe. It's not generally used for serving entirely different data formats from the same URL. |
| 19:42 | <Hixie> | ojan: some elements that used to be "inline" (e.g. <a>) are allowed to contain elements that used to be "block" (e.g. <p>), but as AryehGregor says, best to just look at the spec's content models to get a precise answer. |
| 19:43 | <ojan> | Hixie, AryehGregor: thx. we're trying to figure out what sort of rules webkit's editing code should use |
| 19:43 | <karlushi> | "not generally used" :) generally is important here. Some people are using it ;) Some people do not use it :) that's fine by me. |
| 19:43 | <AryehGregor> | Content negotiation is used by a few standards diehards as a proof-of-concept, but not actually used by any nontrivial number of production sites. |
| 19:43 | <AryehGregor> | I will grant that its adoption probably exceeds that of XHTML2, for example. |
| 19:44 | <AryehGregor> | But by any reasonable metric of success, content negotiation was and is a failure, and it should be treated as such. |
| 19:44 | karlushi | wonders why do you hate so much freedom :) |
| 19:45 | <AryehGregor> | Yes, of course, I hate freedom. Also puppies, and charity. |
| 19:45 | Hixie | hands karlushi some more straw to help him make his strawmen :-) |
| 19:45 | <karlushi> | puppies! |
| 19:46 | <karlushi> | what I meant is that it is possible to use it. :) It doesn't hurt anyone. The only thing I wish is that some server config UIs give more freedom to people than just the sys admin. |
| 19:47 | <karlushi> | I have no issues with it, because I roll my own |
| 19:47 | <karlushi> | but I have control on my server. |
| 19:47 | <AryehGregor> | It doesn't hurt anyone, but it's a failure, as a standard. Our goal here is to come up with specs that are not failures. |
| 19:47 | <karlushi> | not everyone has this freedom :) |
| 19:47 | <Hixie> | content negotiation does "hurt" people; it costs bytes on every single HTTP transaction |
| 19:47 | <AryehGregor> | Therefore we should be citing content negotiation solely as something to avoid. |
| 19:47 | <AryehGregor> | (that too) |
| 19:48 | <Hixie> | in general though it's water under the bridge, it's only relevant as a technology from which to learn what mistakes to avoid when making new ones |
| 19:48 | <Hixie> | anyway, time to go |
| 19:48 | <Hixie> | bbiab |
| 19:48 | <karlushi> | AryehGregor, I guess I'm less… hmmm… absolutist? (not sure it is the right word) |
| 19:48 | <AryehGregor> | "Less interested in making specs that are actually adopted and not just a waste of implementer resources"? |
| 19:50 | <karlushi> | AryehGregor, more on the line of "it is not possible a specification which is 100% perfect" (utopia) and there are some features which are used by minorities which do not necessary create issues for the larger crowd. |
| 19:50 | <AryehGregor> | It looks like the enum reflection logic in HTML5 is lifted from IE, and not implemented by any other browser at all. |
| 19:51 | <karlushi> | (*) possible to create |
| 19:52 | <AryehGregor> | karlushi, in this case, the minority is like <0.001% of users/authors, and the effect of content negotiation could be replicated even if it didn't exist. Implementers do not want to spend their time on such features. They have limited time, and have more important things to do. |
| 19:52 | <AryehGregor> | Things that, say, 80% of people will find useful instead of <0.001%. |
| 19:53 | <AryehGregor> | If an implementer spends time creating your niche feature instead of one that's useful to the majority, then yes, that feature does hurt the majority. |
| 19:55 | <jgraham> | Accept-Language has the same problems (hardly used, adds bytes to every request) and also makes user fingerprinting easier |
| 19:55 | <AryehGregor> | Accept-Encoding is used in practice, though. |
| 19:55 | <AryehGregor> | (very widely) |
| 19:55 | <karlushi> | This will be very hard for discussing because we will turn in a series of useless arguments about new features of the specification which are not implemented at all, or not used at all (in a meaningful way) but still in the spec. :) If we stay on the initial question, we were talking about content negociation which is already implemented. |
| 19:56 | <AryehGregor> | And it was a waste of time. We'd all be better off if it had not been implemented (except for encodings, maybe). |
| 19:56 | <karlushi> | … |
| 19:57 | <AryehGregor> | :) |
| 19:57 | karlushi | repeat repeat the cycle: wash, rinse and dry. Not sure there is a solution in the discussion. running into circles. |
| 19:58 | <AryehGregor> | Yep! |
| 19:58 | <AryehGregor> | Thankfully, the question is pretty much settled in the WHATWG, and people who disagree can just go off and write their own specs and be ignored. |
| 19:58 | karlushi | is happily using content negociation ;) as long as it is here. |
| 19:58 | <AryehGregor> | But if you're participating in the WHATWG, then citing content negotiation as anything but a failure is unlikely to convince anyone. |
| 20:00 | <karlushi> | … hmmm. interesting. The only thought I have right now is "Peace". |
| 20:59 | <miketaylr> | is there any reason that reading pixels via ctx.getImageData() from an image with svg doc set as its source should raise a security exception (same domain, etc) |
| 20:59 | <miketaylr> | http://paulirish.com/i/f4c0.png is what i'm looking at |
| 21:02 | miketaylr | scratches head |
| 23:55 | <Hixie> | well, the conclusion from this afternoon's work is that browsers suck except for firefox |
| 23:55 | <Hixie> | and possibly opera |
| 23:57 | <daedb> | what do they suck at? |
| 23:57 | <Workshiva> | All browsers suck, really |
| 23:57 | <Workshiva> | It's just a question of magnitude |
| 23:58 | <Hixie> | http://hixie.ch/tests/adhoc/html/video/001.html - temporarily hangs safari, chrome sniffs but lets the mime type affect UI behaviour, opera sniffs (per html spec), and firefox refuses to sniff at all (per http spec) |
| 23:58 | <Hixie> | haven't been able to test IE9 |
| 23:59 | daedb | tests IE9... |
