/irc-logs / freenode / #whatwg / 2011-11-11 / end

Options:

# Session Start: Fri Nov 11 00:00:00 2011
# Session Ident: #whatwg
# [00:00] * Quits: cgcardona (~cgcardona@unaffiliated/cgcardona) (Quit: cgcardona)
# [00:01] * Quits: smaug____ (~chatzilla@cs181151161.pp.htv.fi) (Ping timeout: 258 seconds)
# [00:08] * Quits: Morphous (jan@unaffiliated/amorphous) (Read error: Operation timed out)
# [00:10] * Quits: gwillen (~gwillen@unaffiliated/gwillen) (Remote host closed the connection)
# [00:10] * Joins: gwillen (~gwillen@adsl-66-218-37-112.dslextreme.com)
# [00:10] * Quits: gwillen (~gwillen@adsl-66-218-37-112.dslextreme.com) (Changing host)
# [00:10] * Joins: gwillen (~gwillen@unaffiliated/gwillen)
# [00:14] <wilhelm> Hm. How would you mark up the block of text “Sherlock Holmes–his limits” in this document? http://en.wikisource.org/wiki/Page%3AA_study_in_scarlet.djvu/26
# [00:15] * Quits: dbaron (~dbaron@mozilla.vlan426.asr1.sfo1.gblx.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [00:17] <TabAtkins> With <hgroup>?
# [00:17] <TabAtkins> Or, hm, no, never mind.
# [00:17] * Joins: cpearce_ (~chatzilla@60.234.54.74)
# [00:17] <TabAtkins> Now that I'm reading the passage, it's just a normal heading.
# [00:17] * Quits: erlehmann (~erlehmann@89.204.137.101) (Quit: Ex-Chat)
# [00:18] * Quits: ap (~ap@2620:149:4:1b01:7807:fee:5af2:b54b) (Quit: ap)
# [00:18] <TabAtkins> <section><h1><span class='name'>Sherlock Holmes</span> - his limits.</h1> <ol>...</ol></section>
# [00:19] <wilhelm> It's a normal heading in a subdocument that shouldn't appear in the table of contents or document outline.
# [00:19] <wilhelm> Hence my mild confusion. (c:
# [00:19] <TabAtkins> subdocuments can't be marked up very well in HTML.
# [00:20] <wilhelm> Indeed.
# [00:20] * Quits: cpearce (~chatzilla@60.234.54.76) (Ping timeout: 256 seconds)
# [00:20] * cpearce_ is now known as cpearce
# [00:20] <TabAtkins> <iframe srcdoc> ^_^
# [00:21] * wilhelm cries.
# [00:22] * Joins: ap (~ap@2620:149:4:1b01:e19a:5fca:ef0c:4e)
# [00:24] * Quits: tantek (~tantek@udp089946uds.ucsf.edu) (Quit: tantek)
# [00:25] * Joins: smaug____ (~chatzilla@GGZYYMYCCCXLIV.gprs.sl-laajakaista.fi)
# [00:25] * Joins: jennb (~jennb@74.125.59.65)
# [00:26] * Joins: Morphous (jan@unaffiliated/amorphous)
# [00:27] * Joins: tantek (~tantek@udp089946uds.ucsf.edu)
# [00:29] * Quits: tantek (~tantek@udp089946uds.ucsf.edu) (Client Quit)
# [00:30] <dglazkov> why is there a distinction between TextTrack and HTMLTrackElement?
# [00:30] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [00:30] <rillian_> HTMLTrackElement is a <track> you put in the document
# [00:30] <rillian_> under a media element
# [00:30] <rillian_> like <audio> or <video>
# [00:31] <rillian_> to reference a text track file
# [00:31] <rillian_> a TextTrack is a pure js object representing the result of parsing that file
# [00:32] <rillian_> or, if you prefer, an HTMLTrackElement handles the plumbing between a TextTrack object and a MediaElement which is supposed to play it back
# [00:32] * Quits: erichynds (~ehynds@venkman.brightcove.com)
# [00:32] <Hixie> dglazkov: you cna also get TextTracks straight from the media file
# [00:32] <Hixie> dglazkov: or indeed create one out of whole cloth in the DOM
# [00:33] <dglazkov> ohhhh. That makes sense. The media itself can have a TextTrack embedded in it
# [00:34] <dglazkov> I was confused why the API for adding TextTracks isn't just adding an HTMLTrackElement child.
# [00:34] * eric_carlson is now known as ericc|afk
# [00:35] <dglazkov> ok cool. Thanks, rillian_ and Hixie
# [00:35] * Quits: ben_alman (~cowboy@75-150-66-249-NewEngland.hfc.comcastbusiness.net) (Read error: Operation timed out)
# [00:35] <Hixie> HTMLTextTrack is just for external text tracks
# [00:35] <Hixie> if you're creating on dynamically, you don't need the element
# [00:36] * Quits: drublic (~drublic@frbg-5d84f07a.pool.mediaWays.net) (Ping timeout: 248 seconds)
# [00:36] <rillian_> right, you can get a TextTrack from the parent's media file, from a separate HTMLTextTrack's file, or you can create it yourself
# [00:36] <rillian_> e.g. from data you slurped out of your cms
# [00:37] * Joins: drublic (~drublic@frbg-4d029337.pool.mediaWays.net)
# [00:37] * Quits: necolas (~necolas@5e04326b.bb.sky.com) (Remote host closed the connection)
# [00:38] <Hixie> smaug____: what are all these bugs about?
# [00:39] <TabAtkins> Hixie: Ignore them for now - there's still ongoing discussion about them on webapps.
# [00:39] <Hixie> should they be closed, reassigned to smaug____, something else...?
# [00:40] <TabAtkins> I suppose reassigned to smaug____ for resolution when we figure out what we want to do.
# [00:41] <smaug____> Hixie: sorry
# [00:41] <smaug____> Hixie: the main bug is just about remove handleEvent
# [00:41] <smaug____> and =FunctionOnly
# [00:42] <smaug____> I started to file them one by one, but then noticed that there are too many
# [00:43] <Hixie> what's wrong with handleEvent?
# [00:43] <Hixie> i'm confused
# [00:43] <smaug____> silly name
# [00:43] <smaug____> those interfaces have nothing to do with events
# [00:43] <Hixie> i'm confused
# [00:44] <smaug____> ?
# [00:44] <Hixie> how about you pretend i haven't seen any of the bugs, nor any of the mailing list discussion, and you start over from the top :-)
# [00:44] <smaug____> Hixie: in the interface you have handleEvent
# [00:44] <Hixie> what interface
# [00:45] * Joins: smaug3G (~chatzilla@YYDLXXVI.gprs.sl-laajakaista.fi)
# [00:45] <smaug3G> Hixie: in some callback interfaces you have method handleEvent
# [00:45] <Hixie> yes
# [00:45] <smaug3G> although the interface has nothing to do with events
# [00:45] <Hixie> sure it's just a callback
# [00:45] <smaug3G> there is no reason to have wrong name for the method
# [00:46] <Hixie> doesn't matter what the name is
# [00:46] <jamesr_> there's no reason to have _any_ name for the method 95% of the time
# [00:46] <smaug3G> especially, if and when =FunctionOnly will be removed
# [00:46] <Hixie> could be fooBarBaz
# [00:46] <Hixie> FunctionOnly is being removed?
# [00:46] * Quits: ap (~ap@2620:149:4:1b01:e19a:5fca:ef0c:4e) (Quit: ap)
# [00:46] <smaug3G> that is the other part
# [00:46] <jamesr_> without FunctionOnly the name does matter, i suppose
# [00:46] <Hixie> some languages need a name, even for interfaces marked FunctionOnly, because they don't have method pointers
# [00:46] <smaug3G> there is no reason for =FunctionOnly
# [00:47] * Joins: jdaggett (~jdaggett@ad009033.dynamic.ppp.asahi-net.or.jp)
# [00:47] <smaug3G> except perhaps for backwards compatibility in onfoo handlers
# [00:47] <Hixie> surely if we default to only accepting function pointers this will cause all kinds of back-compat issues
# [00:48] <smaug3G> I don't understand
# [00:48] * Quits: smaug____ (~chatzilla@GGZYYMYCCCXLIV.gprs.sl-laajakaista.fi) (Ping timeout: 245 seconds)
# [00:48] <Hixie> there are web pages that assume, e.g., that you can pass { handleEvent: function (event) { } } to addEventListener
# [00:48] <TabAtkins> Yes, there is code in the wild that expects to be able to pass an object with a 'handleEvent' property to a callback.
# [00:48] <smaug3G> so far most (all?) implementations just pretend that there is no =FunctionOnly
# [00:48] <smaug3G> except for onfoo handlers
# [00:49] <smaug3G> Hixie: yes, there are pages and good use cases for { handleEvent: function() {}} and there is no reason to not allow the same with other callbacks
# [00:50] <Hixie> oh, i see, you're not proposing defaulting to FunctionOnly, you're proposing forcing all APIs to support both function pointers _and_ objects with a single method for the callback
# [00:50] * Joins: ap (~ap@2620:149:4:1b01:e980:b4a0:17cd:ec25)
# [00:50] <Hixie> well if we do the latter then we definitely still need a name for the method!
# [00:51] <smaug3G> How else would I want to remove FunctionOnly o_O
# [00:51] <Hixie> i assumed you wanted to remove the ability to use objects. that's why i use functiononly, to simplify the api by only accepting one type.
# [00:51] * Joins: davidb_ (~davidb@bas1-toronto06-2925210074.dsl.bell.ca)
# [00:52] <Hixie> if you're saying i should use FunctionOnly less, that's a fine suggetion. File a bug on that with the use cases.
# [00:52] <smaug3G> I don't understand what that simplifies
# [00:52] <smaug3G> I did file a bug to remove =FunctionOnly
# [00:52] <smaug3G> is there a usecase for =FunctionOnly ?
# [00:53] <Hixie> you need a use case for additional abilities, not for lack of abilities
# [00:53] <Hixie> the ability to use an object for a callback is an ability
# [00:53] <Hixie> i mean we could also support strings as callbacks, the way setTimeout does
# [00:53] <Hixie> we could also support URLs as callbacks
# [00:53] <Hixie> or MessagePort objects
# [00:53] <Hixie> or any number of other mechanisms
# [00:53] <smaug3G> I'd say you need a reason to explicitly remove functionality
# [00:54] <Hixie> the reason to remove functionality is always the same: make the platform simpelr
# [00:54] <smaug3G> =FunctionOnly doesn't make platform simpler
# [00:54] <Hixie> well i'm not really interested in arguing the point
# [00:55] <Hixie> it seems self-evident that having two features is less simple than having one
# [00:55] <Hixie> whether you agree or not, however, that is the reasoning for trying to limit the number of features
# [00:55] <smaug3G> from implementation point of view making explicit limitations to the default handling is less simple
# [00:56] <smaug3G> also from authoring point of view, since { handleEvent} is anyway supported in event listeners
# [00:56] <smaug3G> and in fact with other non-legacy callbacks in most of current implementations
# [00:58] <Hixie> that's the kind of information you should include in the bug, yes
# [00:58] * smaug3G so much wishes we could get some consistency to the platform
# [00:59] <Hixie> says the person arguing for different names for different callbacks :-P
# [01:00] * Quits: ap (~ap@2620:149:4:1b01:e980:b4a0:17cd:ec25) (Quit: ap)
# [01:00] <Hixie> anyway, i could only find one =FunctionOnly that needed to be changed, the drag-and-drop one
# [01:00] * Joins: roc_ (~chatzilla@60.234.54.74)
# [01:00] <Hixie> did i miss anything?
# [01:00] <Hixie> (the WebRTC stuff is likely to be removed so i'm ignoring that here)
# [01:00] * Quits: davidb_ (~davidb@bas1-toronto06-2925210074.dsl.bell.ca) (Quit: davidb_)
# [01:02] <smaug3G> most of them were in webrtc yes
# [01:02] <smaug3G> I want consistency to callback method names: the method name should indicate what is the reason it is called.
# [01:02] <smaug3G> also, same object can implement several callback interfaces
# [01:03] * Quits: roc (~chatzilla@60.234.54.76) (Ping timeout: 240 seconds)
# [01:03] * roc_ is now known as roc
# [01:03] <Hixie> i'm marking the webrtc bugs rejected since you filed them in the htmlwg component but the htmlwg doesn't have those interfaces
# [01:03] <Hixie> i've changed them in the whatwg copy
# [01:03] <smaug3G> { handleEvent: function(e) {}, handleMutations: function() {param} } ....
# [01:03] <Hixie> i expect that text will be killed soon though
# [01:04] <Hixie> since it looks like mozilla and google are looking at the webrtc wg at the w3c rather than the whatwg text
# [01:04] <TabAtkins> smaug3G: That's being debated right now in webapps. It's somewhat premature to file bugs advocating one particular method yet.
# [01:04] * Hixie really doesn't understand why anyone would use an object for a callback when a closure does everything you would want, better
# [01:04] <smaug3G> TabAtkins: I know it is being debated there. It has been debated several times before
# [01:05] <smaug3G> it is handy to keep some state in the object, and you get right 'this' handling in the callback
# [01:06] <smaug3G> (without need to do any additional JS stuff )
# [01:06] <TabAtkins> smaug3G: Sure, and that can all be done with a closure or .bind().
# [01:06] <smaug3G> that .bind() is something additional
# [01:07] <TabAtkins> Your preference for {handleFoo:...} over .bind seems arbitrary.
# [01:07] <Hixie> you don't get the right "this"
# [01:07] <TabAtkins> Both are parts of the language.
# [01:07] <Hixie> you get the "this" of the object passed to the method
# [01:07] <Hixie> not the "this" of whatever object is setting all the callbacks
# [01:07] <Hixie> which is typically the one you want
# [01:08] <smaug3G> var o = { handleEvent: function(e) {}};
# [01:08] * Quits: ezoe (~ezoe@61-205-124-252f1.kyt1.eonet.ne.jp) (Ping timeout: 248 seconds)
# [01:08] <smaug3G> when handleEvent is called, this == o;
# [01:08] <Hixie> zcyes
# [01:08] <Hixie> yes
# [01:08] <Hixie> which is the wrong this
# [01:08] * Quits: astearns (~anonymous@192.150.22.5) (Ping timeout: 258 seconds)
# [01:08] <smaug3G> which is the right one
# [01:08] <Hixie> no
# [01:09] <smaug3G> if you don't want that, you can use function() {} as a callback
# [01:09] <Hixie> you want "this" to be the "this" that applies in the code that set the callback
# [01:09] * Quits: tndH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.87-rdmsoft [XULRunner 1.9.0.1/2008072406])
# [01:09] <smaug3G> no
# [01:09] <smaug3G> well, depends on the case
# [01:09] <TabAtkins> Hixie: You could want either. Luckily JS has mechanisms to handle them both easily.
# [01:09] * Quits: mkanat (mkanat@nat/google/x-hrmsxjgsfjtnkvsf) (Ping timeout: 244 seconds)
# [01:10] * Joins: ap (~ap@2620:149:4:1b01:6c6f:2dbd:8c7f:ea21)
# [01:10] <smaug3G> and since implementations handle both cases anyway, there is no need to limit it
# [01:10] <Hixie> TabAtkins: do you have an example of when you would want what smaug says?
# [01:10] <Hixie> TabAtkins: i cannot recall ever wanting that, but i'd love to see an example
# [01:10] * Quits: devfil (~dfiloni@ubuntu/member/devfil) (Remote host closed the connection)
# [01:11] <TabAtkins> Hixie: If you're just holding onto some state shared across multiple callbacks.
# [01:12] <smaug3G> you could look at Firefox UI source code for example. It is using { handleEvent: function() {}} style all the time
# [01:14] <smaug3G> ...because it wants to keep some state across the calls
# [01:15] <Hixie> TabAtkins: why would you need a "this" at all then? surely you'd just have the state in the closure.
# [01:15] <TabAtkins> Hixie: That's another way to do it, sure.
# [01:16] <TabAtkins> The object is basically a public closure for these purposes.
# [01:16] <Hixie> i wonder when you'd do that
# [01:16] <Hixie> or rather, why i've never ended up wanting that
# [01:17] <Hixie> i guess the way i always do it is i have a public object that then sets the callbacks, i don't create the object specifically for the handlers
# [01:17] <Hixie> seems like creating it just for the handlers would be rather constraining, e.g. what if you later need two types of handlers?
# [01:17] <Hixie> seems like poor style to me
# [01:19] * Joins: smaug____ (~chatzilla@ZYYYCCXVII.gprs.sl-laajakaista.fi)
# [01:19] * Quits: smaug3G (~chatzilla@YYDLXXVI.gprs.sl-laajakaista.fi) (Ping timeout: 260 seconds)
# [01:24] * Quits: othermaciej (~mjs@17.245.88.94) (Quit: othermaciej)
# [01:26] * Joins: jamesr (jamesr@nat/google/x-aoqlojpziwpdhfrj)
# [01:31] * Joins: MacTed (~Thud@c-71-233-244-175.hsd1.ma.comcast.net)
# [01:31] * Joins: tantek (~tantek@udp090256uds.ucsf.edu)
# [01:37] * heycam is now known as heycam|away
# [01:38] * Quits: Telling (~unknown@80-71-135-15.u.parknet.dk) (Quit: ...)
# [01:39] <TabAtkins> Hixie: Your commit message was incorrectly snarky. Closures hide the data inside them unless you specifically provide methods to export them. Objects expose the data inside them.
# [01:40] <Hixie> closures don't hide data that's public
# [01:40] <Hixie> they just take existing variables and let you access them later, whether they are private or public
# [01:41] <Hixie> (i wrote the checkin comment before you explained the use case, though, so you're right that it was excessively snarky, sorry about that)
# [01:41] <TabAtkins> Ah, right, sorry. Was thinking of the common practice of using closures specifically to hide static vars.
# [01:42] * Joins: mkanat (mkanat@nat/google/x-abroyvueawxxydwu)
# [01:43] * Quits: smaug____ (~chatzilla@ZYYYCCXVII.gprs.sl-laajakaista.fi) (Ping timeout: 276 seconds)
# [01:43] <jernoble> Hixie: i have a question about your response to the MediaController bug
# [01:43] <Hixie> which one?
# [01:43] <Hixie> oh the one with the states
# [01:43] <jernoble> Hixie: right
# [01:43] <Hixie> shoot
# [01:43] <jernoble> Hixie: so if a group of slaved media elements' ready states go from a minimum value of 1 to a minimum value of 3
# [01:44] <jernoble> Hixie: do the events for 2 & 3 fire, or just the event for 3?
# [01:44] <jernoble> Hixie: Because i don't think the answer is clear from those two tables.
# [01:44] <jernoble> Hixie: (or I'm just being dense.)
# [01:44] <Hixie> the second table is non-normative so it doesn't help answer the question oen way or the other
# [01:44] <Hixie> let me see though
# [01:46] * Quits: KillerX (~anant@nat/mozilla/x-xdjkswpojtitndca) (Quit: KillerX)
# [01:46] <Hixie> so if a group of media elements are in states 1,1,3 and go to the state 1,3,3, nothing happens
# [01:46] <Hixie> then if they go to the state 3,3,3 in one go
# [01:47] <Hixie> you start off at "When the ready state of a media element whose networkState is not NETWORK_EMPTY changes, the user agent must follow the steps given below"
# [01:47] <Hixie> in step one you go to "If the previous ready state was HAVE_CURRENT_DATA or less, and the new ready state is HAVE_FUTURE_DATA"
# [01:47] <Hixie> so you queue up canplay on the media element
# [01:48] <Hixie> (and maybe 'playing')
# [01:48] <Hixie> then you go to step 2
# [01:48] <Hixie> report the controller state
# [01:48] <Hixie> new readiness state is now 3
# [01:48] <Hixie> so you fire canplay on the media controller in step 2
# [01:48] <Hixie> so the answer is, you don't fire the event for 2
# [01:49] <Hixie> jernoble: does that answer your question?
# [01:49] <jernoble> Hixie: okay, that's what i thought. the second table confused me though; but since it's non-normative, looks like that settles it then. :)
# [01:49] <jernoble> Hixie: thanks!
# [01:50] * Joins: Rik` (~Rik`@80.187.209.54)
# [01:50] <Hixie> jernoble: yeah the second table's wording is maybe not ideal
# [01:50] <Hixie> jernoble: not sure how to improve it really
# [01:51] <Hixie> oh actually i slightly misspoke when i went through the steps above, though it doesn't affect the final answer
# [01:51] <Hixie> on the media element you do queue up tasks to fire loadeddata then canplay
# [01:51] <Hixie> because you hit "If the previous ready state was HAVE_METADATA and the new ready state is HAVE_CURRENT_DATA or greater"
# [01:51] <Hixie> maybe i should make it do the same for MediaController
# [01:52] <Hixie> jernoble: i think maybe it _should_ fire the intermediate events
# [01:52] <jernoble> Hixie: i think that's where the reviewer got confused.
# [01:53] <Hixie> jernoble: otherwise someone listening to one event might miss it if the network is especially fast, or whatnot
# [01:53] <jernoble> Hixie: especially since there's no accessor for readyState, authors would have to add listeners for /all/ the events, even if they only cared about a single state.
# [01:53] <Hixie> yeah
# [01:54] <Hixie> ok let me make the intermediate events fire while i'm here
# [01:54] <jernoble> Hixie: and i'll change the implementation while /I'm/ here.
# [01:54] <Hixie> heh, in the spec source under the first paragraph for step 2 it says:
# [01:54] <Hixie>
# [01:54] <Hixie> :-/
# [01:55] <jernoble> chuckle. :)
# [01:58] * Joins: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [01:59] <Hixie> ok i changed the spec to fire all the events when incrementing
# [02:00] <Hixie> but when decrementing it just fires the new state
# [02:00] <Hixie> that works right?
# [02:00] <jernoble> Hixie: yup. seems to.
# [02:01] <Hixie> ok it's checked in
# [02:03] * Joins: dbaron (~dbaron@207.239.114.206)
# [02:04] <jernoble> Hixie: cool, thanks.
# [02:05] <hober> yay
# [02:08] * Joins: nonge (~nonge@p5B326802.dip.t-dialin.net)
# [02:08] * nunnun_away is now known as nunnun
# [02:11] * Joins: erlehmann (~erlehmann@82.113.121.140)
# [02:12] * Joins: sicking (~chatzilla@mozilla.vlan426.asr1.sfo1.gblx.net)
# [02:12] * Quits: pererik (~pe@unaffiliated/pererik) (Read error: Operation timed out)
# [02:15] * Quits: ap (~ap@2620:149:4:1b01:6c6f:2dbd:8c7f:ea21) (Quit: ap)
# [02:24] * Quits: rillian_ (~rillian@184.71.182.138) (Read error: Connection reset by peer)
# [02:24] * Joins: rillian_ (~rillian@184.71.182.138)
# [02:25] * nunnun is now known as nunnun_away
# [02:27] * Joins: scor (~scor@drupal.org/user/52142/view)
# [02:27] * Quits: rillian_ (~rillian@184.71.182.138) (Remote host closed the connection)
# [02:27] * Joins: agektmr (~Adium@2401:fa00:4:1012:fa1e:dfff:fee6:d74e)
# [02:32] * Quits: dbaron (~dbaron@207.239.114.206) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [02:41] * Joins: pererik (~pe@unaffiliated/pererik)
# [02:41] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 260 seconds)
# [02:42] * Quits: riven (~riven@pdpc/supporter/professional/riven) (Ping timeout: 256 seconds)
# [02:48] * Quits: andyg (~andyg@CPE-124-189-148-81.sqcy1.win.bigpond.net.au) (Quit: andyg)
# [02:55] * Quits: tantek (~tantek@udp090256uds.ucsf.edu) (Quit: tantek)
# [02:55] * Quits: ojan (ojan@nat/google/x-pjzawfbqqxucosww) (Quit: ojan)
# [02:58] * Joins: andyg (~andyg@CPE-124-189-148-81.sqcy1.win.bigpond.net.au)
# [03:08] * Quits: Rik` (~Rik`@80.187.209.54) (Ping timeout: 258 seconds)
# [03:13] * Quits: jamesr (jamesr@nat/google/x-aoqlojpziwpdhfrj) (Quit: jamesr)
# [03:23] * Quits: drublic (~drublic@frbg-4d029337.pool.mediaWays.net) (Remote host closed the connection)
# [03:24] * Joins: roc_ (~chatzilla@60.234.54.74)
# [03:24] * Joins: cpearce_ (~chatzilla@60.234.54.74)
# [03:26] * Quits: cpearce (~chatzilla@60.234.54.74) (Ping timeout: 252 seconds)
# [03:27] * cpearce_ is now known as cpearce
# [03:27] * Quits: roc (~chatzilla@60.234.54.74) (Ping timeout: 240 seconds)
# [03:27] * roc_ is now known as roc
# [03:44] * Joins: gavinc_ (~gavin@50-0-138-90.dsl.dynamic.sonic.net)
# [03:47] * Quits: gavinc (~gavin@50-0-138-90.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
# [03:50] * Quits: dave_levin (dave_levin@nat/google/x-zjratjubkkpdrysm) (Quit: dave_levin)
# [03:52] * Quits: erlehmann (~erlehmann@82.113.121.140) (Quit: Ex-Chat)
# [03:55] * Quits: PrgmrBill (~PrgmrBill@unaffiliated/prgmrbill) (Remote host closed the connection)
# [04:00] * Quits: mkanat (mkanat@nat/google/x-abroyvueawxxydwu) (Quit: Ex-Chat)
# [04:02] * Joins: mpt (~mpt@canonical/mpt)
# [04:09] * Joins: rniwa_ (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
# [04:10] * Quits: rniwa_ (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Client Quit)
# [04:12] * Quits: rniwa (~rniwa@216.239.45.130) (Ping timeout: 248 seconds)
# [04:12] * Joins: PrgmrBill (~PrgmrBill@prgmrbill.com)
# [04:12] * Quits: PrgmrBill (~PrgmrBill@prgmrbill.com) (Changing host)
# [04:12] * Joins: PrgmrBill (~PrgmrBill@unaffiliated/prgmrbill)
# [04:16] * Quits: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
# [04:17] * Joins: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
# [04:20] * Joins: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp)
# [04:21] * Quits: _bga (~bga@ppp78-37-228-240.pppoe.avangarddsl.ru) (Read error: Connection reset by peer)
# [04:31] * Quits: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Remote host closed the connection)
# [04:31] * Joins: rniwa (~rniwa@216.239.45.130)
# [04:37] * Quits: sicking (~chatzilla@mozilla.vlan426.asr1.sfo1.gblx.net) (Ping timeout: 248 seconds)
# [04:38] * Joins: erlehmann (~erlehmann@82.113.121.140)
# [04:39] * Quits: jacobolus (~jacobolus@c-50-131-57-2.hsd1.ca.comcast.net) (Remote host closed the connection)
# [04:49] * Joins: jdong_ (~quassel@222.126.155.250)
# [04:54] * Joins: jdong__ (~quassel@222.126.155.250)
# [04:57] * heycam|away is now known as heycam
# [04:58] * Joins: MikeSmith_ (~MikeSmith@EM1-112-230-21.pool.e-mobile.ne.jp)
# [05:01] * Quits: MikeSmith (~MikeSmith@EM114-48-137-215.pool.e-mobile.ne.jp) (Ping timeout: 256 seconds)
# [05:01] * MikeSmith_ is now known as MikeSmith
# [05:08] * Quits: jdaggett (~jdaggett@ad009033.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
# [05:15] * Joins: danielfilho_ (~daniel@187.31.77.7)
# [05:17] * Quits: danielfilho (~daniel@187.31.77.7) (Ping timeout: 255 seconds)
# [05:17] * danielfilho_ is now known as danielfilho
# [05:18] * Quits: agektmr (~Adium@2401:fa00:4:1012:fa1e:dfff:fee6:d74e) (Quit: Leaving.)
# [05:27] * Quits: jdong__ (~quassel@222.126.155.250) (Remote host closed the connection)
# [05:31] * Joins: nonge_ (~nonge@p5B326748.dip.t-dialin.net)
# [05:32] * Quits: roc (~chatzilla@60.234.54.74) (Ping timeout: 240 seconds)
# [05:34] * Quits: nonge (~nonge@p5B326802.dip.t-dialin.net) (Ping timeout: 240 seconds)
# [05:38] * Quits: cpearce (~chatzilla@60.234.54.74) (Ping timeout: 260 seconds)
# [05:39] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [05:47] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
# [05:51] * Joins: ben_alman (~cowboy@pool-74-104-156-115.bstnma.fios.verizon.net)
# [05:52] * Quits: erlehmann (~erlehmann@82.113.121.140) (Quit: Ex-Chat)
# [05:53] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 240 seconds)
# [05:53] * Joins: temp02 (~temp01@unaffiliated/temp01)
# [05:56] * Quits: slartsa (~slartsa@alpha.pumppumedia.com) (Ping timeout: 258 seconds)
# [05:58] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 258 seconds)
# [06:16] * Joins: slartsa (~slartsa@alpha.pumppumedia.com)
# [06:29] * Quits: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90) (Quit: ChatZilla 0.9.87-3.1450hg.fc15 [XULRunner 7.0.1/20110930134335])
# [06:31] * Joins: Areks (~Areks@rs.gridnine.com)
# [06:37] * Parts: ericc|afk (~eric@2620:149:4:1b01:ddc8:ef91:b6da:dfdf)
# [06:40] * Quits: yutak (~yutak@2401:fa00:4:1004:baac:6fff:fe99:adfb) (Quit: Ex-Chat)
# [06:46] * Joins: yutak (~yutak@2401:fa00:4:1004:baac:6fff:fe99:adfb)
# [06:49] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
# [07:24] * Joins: rillian_ (~rillian@mist.thaumas.net)
# [07:38] * Joins: mpt (~mpt@76.14.69.234)
# [07:38] * Quits: mpt (~mpt@76.14.69.234) (Changing host)
# [07:38] * Joins: mpt (~mpt@canonical/mpt)
# [07:40] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Remote host closed the connection)
# [07:43] * Quits: benjoffe_ (~benjoffe_@CPE-121-216-39-241.lnse1.ken.bigpond.net.au) (Remote host closed the connection)
# [08:01] * Quits: bensmithett (~bensmithe@115.146.71.1) (Quit: bensmithett)
# [08:10] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 260 seconds)
# [08:20] * Joins: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net)
# [08:21] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
# [08:24] * Joins: benjoffe_ (~benjoffe_@CPE-121-216-39-241.lnse1.ken.bigpond.net.au)
# [08:25] * Joins: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se)
# [08:31] * Joins: mpt (~mpt@76.14.69.234)
# [08:31] * Quits: mpt (~mpt@76.14.69.234) (Changing host)
# [08:31] * Joins: mpt (~mpt@canonical/mpt)
# [08:31] * Joins: jochen___ (jochen@nat/google/x-fdlcvaaihywjosir)
# [08:35] * Quits: jochen__ (jochen@nat/google/x-tatbyublvvyphwdd) (Ping timeout: 244 seconds)
# [08:35] * jochen___ is now known as jochen__
# [08:37] * Quits: bzed (~bzed@devel.recluse.de) (Ping timeout: 244 seconds)
# [08:39] * Joins: bzed (~bzed@devel.recluse.de)
# [08:42] * Joins: mishunov (~spliter@77.88.72.162)
# [08:45] * Joins: FlorianX (~Dimitri@p4FCF6E57.dip.t-dialin.net)
# [08:47] * Quits: rillian_ (~rillian@mist.thaumas.net) (Remote host closed the connection)
# [08:48] * Joins: jochen___ (jochen@nat/google/x-sgqrqsmrvhjwlccm)
# [08:51] * Quits: jochen__ (jochen@nat/google/x-fdlcvaaihywjosir) (Ping timeout: 240 seconds)
# [08:51] * jochen___ is now known as jochen__
# [08:52] <annevk> hah, slept until 8:30
# [08:55] <wilhelm> You beat the jet lag already?
# [08:58] <annevk> I doubt that, but I did sleep normal hours, although much longer than usual
# [09:03] * Quits: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Quit: othermaciej)
# [09:04] * heycam is now known as heycam|away
# [09:04] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 258 seconds)
# [09:08] * Quits: foolip_ (u3586@gateway/web/irccloud.com/x-jssnczdfjrlqzngt) (Quit: Connection closed for inactivity)
# [09:17] * heycam|away is now known as heycam
# [09:21] <annevk> zcorpan: lol, trying to incite a riot on twitter :p
# [09:22] * Joins: rtuin (~rtuin@213.125.175.250)
# [09:22] <Hixie> wtf, why is twitter CSS-free for me today
# [09:22] <Hixie> huh, fixed itself when i logged in
# [09:22] <annevk> they seem to be rolling out some updates
# [09:25] * Joins: jacobolu_ (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net)
# [09:26] * Quits: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net) (Ping timeout: 276 seconds)
# [09:28] * Quits: Druid_ (~Druid@p5B05DAE8.dip.t-dialin.net) (Ping timeout: 260 seconds)
# [09:31] * Joins: Druid_ (~Druid@p5B05D65A.dip.t-dialin.net)
# [09:33] * Joins: virtuelv (~virtuelv_@pat-tdc.opera.com)
# [09:35] <annevk> heh, just discovered mattur has a bunch of twitter lists
# [09:48] * Joins: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net)
# [09:52] <hsivonen> is xhr.status 200 when the respose was cached? e.g. if the server said not modified?
# [09:53] <hsivonen> I've identified a new risk with adding HTML support to XHR:
# [09:54] <hsivonen> existing code that treats checking responseXML for null as a surrogate for checking HTTP success when expecting XML on success
# [09:54] <hsivonen> and errors come with a text/html body
# [09:56] <annevk> search for "conditional"
# [09:58] * Joins: ezoe (~ezoe@203-140-91-149f1.kyt1.eonet.ne.jp)
# [09:58] <hsivonen> annevk: thanks
# [09:59] <hsivonen> I wonder if I should make Firefox pretend it doesn't support HTML parsing when status isn't a success or if I should land support for parsing error bodies and see how much the Web breaks
# [10:00] <hsivonen> or require responseType = "document" to force parsing of error bodies
# [10:02] <annevk> the middle of those is the intent of the spec
# [10:02] <annevk> and is what happens if error bodies come with XML
# [10:02] <hsivonen> annevk: what do you mean?
# [10:03] <annevk> if a server has a text/xml 500 status page
# [10:03] * Quits: rtuin (~rtuin@213.125.175.250) (Quit: Leaving)
# [10:03] * Joins: rtuin (~rtuin@213.125.175.250)
# [10:03] * heycam is now known as heycam|away
# [10:03] <annevk> responseXML will be populated with its contents
# [10:03] <hsivonen> annevk: I mean what's "the middle"?
# [10:03] <annevk> that should work for text/html too
# [10:03] <annevk> hsivonen: you gave three options, I prefer #2
# [10:04] <hsivonen> annevk: I see
# [10:04] <hsivonen> the scary part is that I found out about this by reading the code of our extension update code
# [10:04] <hsivonen> s/update code/updates/
# [10:07] * Joins: dragon__ (~dragon@59-190-54-232f1.hyg2.eonet.ne.jp)
# [10:13] <annevk> omg
# [10:13] <annevk> we're getting document.find now?
# [10:14] * Joins: necolas (~necolas@80.169.28.3)
# [10:14] <annevk> sicking: why not simply use Array?
# [10:15] <annevk> nm
# [10:15] * annevk missed something obvious
# [10:16] * Parts: annevk (~annevk@5355737B.cm-6-6b.dynamic.ziggo.nl)
# [10:16] * Joins: annevk (~annevk@5355737B.cm-6-6b.dynamic.ziggo.nl)
# [10:18] * Joins: roc (~chatzilla@121.98.230.221)
# [10:19] * Joins: riven (~riven@53518387.cm-6-2c.dynamic.ziggo.nl)
# [10:19] * Quits: riven (~riven@53518387.cm-6-2c.dynamic.ziggo.nl) (Changing host)
# [10:19] * Joins: riven (~riven@pdpc/supporter/professional/riven)
# [10:20] * Quits: payman (~payman@88.131.66.80) (Ping timeout: 260 seconds)
# [10:26] * Joins: Necrathex (~nectop@82-170-160-25.ip.telfort.nl)
# [10:32] * Quits: ezoe (~ezoe@203-140-91-149f1.kyt1.eonet.ne.jp) (Ping timeout: 240 seconds)
# [10:36] * Joins: connrs (~connrs@conners.plus.com)
# [10:38] * Quits: Areks (~Areks@rs.gridnine.com) (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/)
# [10:39] * Joins: Areks (~Areks@rs.gridnine.com)
# [10:39] * Parts: Areks (~Areks@rs.gridnine.com)
# [10:40] * Quits: connrs (~connrs@conners.plus.com) (Ping timeout: 260 seconds)
# [10:42] * Quits: benjoffe_ (~benjoffe_@CPE-121-216-39-241.lnse1.ken.bigpond.net.au) (Remote host closed the connection)
# [10:43] * Joins: benjoffe_ (~benjoffe_@CPE-121-216-39-241.lnse1.ken.bigpond.net.au)
# [10:46] * Joins: connrs (~connrs@conners.plus.com)
# [10:55] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Remote host closed the connection)
# [10:55] * jgraham notes that document.find seems like a very confusing name
# [10:56] <jgraham> But whatever
# [10:58] * Joins: MikeSmith_ (~MikeSmith@EM111-191-216-98.pool.e-mobile.ne.jp)
# [11:01] * Quits: MikeSmith (~MikeSmith@EM1-112-230-21.pool.e-mobile.ne.jp) (Ping timeout: 258 seconds)
# [11:01] * MikeSmith_ is now known as MikeSmith
# [11:04] * Quits: rniwa (~rniwa@216.239.45.130) (Quit: rniwa)
# [11:06] * Joins: cpearce (~chatzilla@ip-118-90-36-154.xdsl.xnet.co.nz)
# [11:28] * Quits: shepazu (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net) (Read error: Connection reset by peer)
# [11:28] * Joins: shepazu (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net)
# [11:31] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
# [11:34] * jacobolu_ is now known as jacobolus
# [11:39] * Joins: drublic (~drublic@frbg-5d84f84b.pool.mediaWays.net)
# [11:45] * Quits: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se) (Remote host closed the connection)
# [11:46] * Joins: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se)
# [11:48] * Quits: jdong_ (~quassel@222.126.155.250) (Remote host closed the connection)
# [11:51] * Joins: david_carlisle (~chatzilla@86.188.197.189)
# [11:59] * Quits: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
# [12:06] * Joins: Ms2ger (~Ms2ger@91.181.168.54)
# [12:15] * tomaw is now known as theia
# [12:15] * theia is now known as tomaw
# [12:20] * Joins: bga_ (~bga@ppp78-37-228-240.pppoe.avangarddsl.ru)
# [12:38] * temp02 is now known as temp01
# [12:48] <zcorpan> i wonder if steve and the chairs feel good about wasting Mike[tm]'s time
# [12:50] <jgraham> I wonder if they care
# [12:52] <Ms2ger> Time isn't relevant, they need to assert authority
# [12:52] <Philip`> Short-term loss for long-term gain
# [12:52] <annevk> Philip`: what is the gain?
# [12:53] * Ms2ger adds scare quotes
# [12:53] <jgraham> annevk: 05:47 < Ms2ger> [...] authority
# [12:53] <Philip`> annevk: Nebulous
# [12:54] * Quits: FlorianX (~Dimitri@p4FCF6E57.dip.t-dialin.net) (Quit: Leaving.)
# [12:55] * Quits: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se) (Ping timeout: 260 seconds)
# [12:56] * Joins: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se)
# [12:56] <hsivonen> I don't like wasting MikeSmith's time, but dropping <time> the way Hixie dropped it was still a bad move.
# [12:58] <jgraham> AFAICT everyone apart from MikeSmith benefited from this
# [12:58] * Quits: ben_alman (~cowboy@pool-74-104-156-115.bstnma.fios.verizon.net) (Ping timeout: 252 seconds)
# [12:58] <jgraham> If Hixie hadn't dropped time, the people who want the new, different, time would never have got it
# [12:58] <zcorpan> poor guy
# [12:59] <hsivonen> jgraham: how did I benefit?
# [12:59] <jgraham> and the charis wouldn't have got to show us how effective they are
# [12:59] <jgraham> *chairs
# [12:59] <annevk> ineffective*
# [12:59] <zcorpan> hsivonen: the spec will better match use cases people want
# [13:00] <jgraham> hsivonen: Well since new-<time> is different from old-<time> it's not really clear that you would have had less validator changes to make in either case
# [13:01] <jgraham> (the other case being "new time was morphed from old time without an intermediate stage")
# [13:01] <jgraham> (ignoring the fact that that would probably not have happened)
# [13:02] <Ms2ger> Also, Gecko supports outerHTML now!
# [13:02] <Ms2ger> hsivonen++
# [13:03] <annevk> welcome to 2000
# [13:04] <Ms2ger> Why thank you
# [13:04] <jgraham> meow?
# [13:04] * Quits: temp01 (~temp01@unaffiliated/temp01) (Disconnected by services)
# [13:04] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [13:06] <hsivonen> Ms2ger: thank you for writing most of the code for that patch
# [13:06] <Ms2ger> And thank you for writing the hard code :)
# [13:07] <hsivonen> I think the really noteworthy thing here is that IE4 didn't use vendor prefixes for this stuff, so there isn't now msOuterHTML, webkitOuterHTML, oOuterHTML and now a new mozOuterHTML to evangelize
# [13:07] <hsivonen> so when we implement IE4 features, they just start working
# [13:08] * Joins: temp02 (~temp01@unaffiliated/temp01)
# [13:08] <hsivonen> when we implement WebKit features, we deliberately self-sabotage them so that additional evangelism is needed
# [13:09] * Quits: temp01 (~temp01@unaffiliated/temp01) (Disconnected by services)
# [13:09] * temp02 is now known as temp01
# [13:09] <hsivonen> (actually, I'm not sure if outerHTML was an IE4 or IE5 feature, but that's not the point)
# [13:11] <roc> that works OK when the non-prefixed feature was introduced with reasonable behavior
# [13:11] <roc> it doesn't work so well when the non-prefixed feature is introduced with utterly broken behavior
# [13:12] <zcorpan> like drag and drop?
# [13:12] <roc> hmm yeah
# [13:12] <roc> and contenteditable
# [13:13] <roc> and the entire CSS box model, basically
# [13:13] <roc> we pay for that one by writing <!DOCTYPE HTML> until the end of time
# [13:14] <hsivonen> roc: OTOH, it makes no sense for transforms to be supported in all the 4 engines but with different prefix in each one to foil interop
# [13:14] <roc> you should ask dbaron if he thinks the behavior differences warrant the prefixing
# [13:15] <hsivonen> roc: in retrospect, we should have made IE's box model the default and used box-sizing to opt into the different behavior
# [13:15] <hsivonen> roc: same thing for <img> and line height
# [13:15] <roc> that's probably true
# [13:16] <roc> however, there was a lot of other brokenness there
# [13:17] <zcorpan> we could have made the brokeness the compliant behavior like with the html parser
# [13:17] <roc> for situations like transforms I think there is a case for saying "we think this model is close enough to right, let's rip off the prefixes now and tidy up the differences later, because the cost of the prefixes outweighs the cost of the behavior changes for interop"
# [13:18] <roc> zcorpan: reverse engineering hasLayout and all the rest of the IE brokenness is not something anyone has ever wanted to do
# [13:18] <zcorpan> roc: other browsers don't have hasLayout in quirks mode
# [13:18] <roc> yeah
# [13:18] <roc> browsers don't interoperate in quirks mode
# [13:19] <roc> to make quirks mode the compliant behavior, we'd have to fix that
# [13:19] <hsivonen> roc: don't Gecko/WebKit/Presto interop remarkably far in quirks mode, though?
# [13:19] <hsivonen> even if IE is totally different
# [13:19] <roc> I honestly don't know
# [13:19] <annevk> it's getting closer and closer afaik
# [13:20] <roc> IE being totally different is enough to sink the proposition
# [13:20] <hsivonen> so does Mango ship the IE 5.5 mode for quirks or do they have a Gecko/WebKit/Presto-like quirks mode based on the IE9 engine snapshot?
# [13:20] <roc> if we interoperate closely in quirks mode, it's because our quirks modes aren't very different to our standards modes, which are converging
# [13:20] <annevk> having quirks mode interop between non-IE browsers is still worth it
# [13:20] <hsivonen> I should find access to a Mango phone and do some community service
# [13:20] <annevk> roc: yeah that's definitely part of it
# [13:21] <annevk> roc: but we also take quirks mode into account now, e.g. for the HTML parser
# [13:21] * Joins: temp02 (~temp01@unaffiliated/temp01)
# [13:21] <roc> we recently eliminated the difference between quirks mode and standards mode text decorations
# [13:23] <roc> hsivonen: an important question is: if we rip off prefixes while we know behavior changes will be needed for interop, will various browsers actually make those changes to unprefixed property behavior?
# [13:23] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 248 seconds)
# [13:23] <roc> I'm not confident they all will
# [13:23] <hsivonen> roc: depends on the magnitude of changes and the amount of existing content
# [13:24] <roc> yes
# [13:24] <hsivonen> roc: I think requestAnimationFrame could be unprefixed immediately and the second argument or the return value be bikeshedded later
# [13:24] <roc> yeah
# [13:25] <jgraham> FWIW opera frequently gets screwed over by prefixes
# [13:25] <roc> we should do more to ship the subset of commonly-agreed behavior quickly without prefix
# [13:25] <jgraham> Where people write -webkit-foo and -moz-foo but forget -o-foo
# [13:25] <roc> on mobile, everyone who's not Webkit gets screwed over by prefixes
# [13:25] <jgraham> So it looks like we don't support cool stuff that we do
# [13:25] <hsivonen> jgraham: Firefox for Android suffers from -webkit-
# [13:26] <hsivonen> I think it sucks that Mozilla, Opera and Microsoft agree to work against their interest and the interest of Web authors, because it's supposedly the right thing to do
# [13:27] <hsivonen> the only beneficiary of the situation is WebKit, ATM
# [13:27] <hsivonen> I should blog about this, but I want to get HTML in XHR ready for review first
# [13:27] * Quits: temp02 (~temp01@unaffiliated/temp01) (Ping timeout: 245 seconds)
# [13:28] <jgraham> I should remember to see if that's correlated with who is pro "prefixes until CR or later" next time this comes up
# [13:28] <hsivonen> "CR or later" is hurting the Web
# [13:30] <jgraham> Yeah, the current situation is insane
# [13:31] * Joins: temp01 (~temp01@unaffiliated/temp01)
# [13:32] <roc> hsivonen: I look forward to that blog post!
# [13:34] * annevk read CR and was thinking CRLF
# [13:34] <Ms2ger> annevk, obviously that's the only useful expansion :)
# [13:37] <Taggnostr> hsivonen, the other day I was looking for some html5 test cases and I found your thesis/website
# [13:42] <hsivonen> Taggnostr: did you find the test cases you were looking for?
# [13:43] <hsivonen> annevk: CR in the CRLF sense is hurting the Web, too
# [13:43] <Taggnostr> hsivonen, nope, but I found the description of the parsing algorithm in the html5 draft
# [13:43] <Taggnostr> I'm working on a parser and I was trying to determine how it should handle broken html
# [13:44] <hsivonen> Taggnostr: "just" implement the parsing algorithm
# [13:44] <hsivonen> Taggnostr: what programming language are you using?
# [13:45] <Taggnostr> python, I'm trying to improve the html parser included in the stdlib to make it follow the html5 standard, possibly while preserving backward compatibility
# [13:45] <hsivonen> Taggnostr: are you aware of https://code.google.com/p/html5lib/ ?
# [13:46] <Taggnostr> yes, I actually found this channel while looking at that page
# [13:46] <jgraham> Taggnostr: (please look at HEAD, not at the lat release)
# [13:46] <jgraham> *last
# [13:46] <Taggnostr> but including a new module in the stdlib is not easy, so I was trying to fix the existing one
# [13:48] <jgraham> Well… good luck. It isn't clear how you would fix the existing one without writing a roughly equivalent amount of code to html5lib
# [13:49] * Quits: david_carlisle (~chatzilla@86.188.197.189) (Ping timeout: 256 seconds)
# [13:49] <Taggnostr> I haven't looked closely at html5lib but from what I've seen it seems more complicated than I expected, especially compared to the html parser used by python
# [13:49] <jgraham> Also, strictly speaking, a SAX-style API doesn't work with HTML
# [13:49] <zcorpan> parsing html is complicated
# [13:50] <jgraham> Since various things alter the parts of the tree that have already been emitted
# [13:50] <jgraham> e.g. <table><div>
# [13:50] <zcorpan> you can have non-streaming SAX or fatal SAX
# [13:50] <jgraham> or <body a=b><body c=d>
# [13:51] <jgraham> The HTMLParser model doesn't have any extensions to allow fixup of the existing tree
# [13:51] <jgraham> and I presume fatal SAX would not be regarded as useful
# [13:51] <hsivonen> jgraham: XML folks love fatal SAX :-)
# [13:52] <hsivonen> jgraham: maybe not that useful for HTML, though
# [13:52] <jgraham> hsivonen: Yes well. Look how that turned out
# [13:53] <Taggnostr> the main goal here is to provide a parser able to parse broken HTML -- it doesn't have to be an HTML5 parser, but since HTML5 defines how to parse broken HTML and that is what browsers do, it seems better to do the same rather than coming up with our own decisions/algorithm
# [13:53] <hsivonen> jgraham: Validator.nu uses fatal SAX for HTML
# [13:53] <hsivonen> Taggnostr: coming up with ways to parse HTML that aren't the HTML5 algorithm is a terrible idea
# [13:54] <wilhelm> I've heard regular expressions are great for parsing HTML.
# [13:54] <Taggnostr> that's already the current situation, the idea is to make the algorithm closer to HTML5
# [13:58] <jgraham> wilhelm: In the interests of playing nice with the visitor, I will loan you my sarcasm end tag: </sarcasm>
# [13:58] <wilhelm> jgraham: Oh, sorry. Thanks. (c:
# [13:59] <jgraham> Taggnostr: There is little point is being "close to" HTML 5 when you could just do what the standard says
# [13:59] <Taggnostr> I'm not sure if that's doable though, the parser should be backward-compatible
# [14:00] <jgraham> hsivonen: The validator is a special case. The only reaon it doesn't stop at the first error regardless of streamability is that it wouldn't be very user friendly
# [14:00] <Taggnostr> also it already has a specific API, and I'm not sure implementing the parser described by the HTML5 draft would work with it
# [14:00] * Quits: virtuelv (~virtuelv_@pat-tdc.opera.com) (Quit: Ex-Chat)
# [14:01] * Joins: virtuelv (~virtuelv_@pat-tdc.opera.com)
# [14:02] <jgraham> Taggnostr: Well it wouldn't since HTML isn't streamable in general
# [14:02] <Ms2ger> MikeSmith, thanks
# [14:03] <jgraham> (without some representation of tree fixup in the stream)
# [14:03] <jgraham> You can do what hsivonen does and die at the first non-streamable error
# [14:03] <jgraham> But there are a pile of sites where that will break
# [14:03] <Taggnostr> what do you mean exactly with streamable?
# [14:05] <Ms2ger> <table>Foo
# [14:05] <Ms2ger> That'll return a tree with the Foo text node before the table
# [14:05] <jgraham> You can't represent it with an api that announces various token types (start tag, end tag) and build the correct tree without significant domain knowledge in the treebuilding layer
# [14:06] <zcorpan> you could extend SAX with fixup events
# [14:06] <hsivonen> Taggnostr: the Validator.nu parser supports all of HTML with the SAX API by first buffering everything into a tree model
# [14:06] * Joins: FlorianX (~Dimitri@p4FCF6E57.dip.t-dialin.net)
# [14:06] <jgraham> If HTMLParser is actually supposed to be an HTMLTokenizer and doesn't try to make all the tags balance or anything, that can be represented as a set of events
# [14:07] <jgraham> But it is only half the work (or less) of actually parsing
# [14:07] <Taggnostr> yes, it doesn't balance anything
# [14:08] <jgraham> Oh, well in that case look at the tokenizer.py code in html5lib
# [14:08] <Taggnostr> in that case it will announce a <table> start tag, and then Foo
# [14:08] <Taggnostr> that's where I looked :)
# [14:09] <jgraham> It does almost what you want but you will need to add an interface that emits HTMLParser-compatible events
# [14:09] <Taggnostr> is there a reference implementation of the parser described by HTML5?
# [14:09] <jgraham> No
# [14:10] <Taggnostr> so they just wrote down the algorithm without having a real implementation and without testing it?
# [14:10] <jgraham> But html5lib, Gecko (+validator.nu), Webkit and Presto all have implementations that are knopwn to be close to spec
# [14:10] <jgraham> Taggnostr: "they" == "we" and no
# [14:11] <hsivonen> Taggnostr: it has had plenty of testing
# [14:11] <jgraham> The algorithm was arrived at by careful study of what browsers did
# [14:11] <jgraham> Plus feedback from browser vendors when they broke pages
# [14:11] <jgraham> Plus inspiration for how to fix difficult problems in an acceptable way
# [14:12] <jgraham> (misnested formatting elements, parsing comments in scripts)
# [14:12] <Taggnostr> so it wasn't written from scratch
# [14:12] <jgraham> That depends what you mean
# [14:12] * Joins: erichynds (~ehynds@venkman.brightcove.com)
# [14:12] <jgraham> Hixie didn't fabricate it from unicorn horn and pony hair
# [14:13] <jgraham> But no one had ever written it down before
# [14:13] <jgraham> And it isn't quite like what any one browser had before
# [14:13] <Taggnostr> ok
# [14:15] <zcorpan> jgraham: that's one of the more hilarious statements i've seen about the parsing algorithm
# [14:16] * Joins: ezoe (~ezoe@203-140-91-208f1.kyt1.eonet.ne.jp)
# [14:18] * Joins: david_carlisle (~chatzilla@dcarlisle.demon.co.uk)
# [14:19] <gsnedders> Taggnostr: Reference implementations are problematic if they're normative, because any bug in the reference implementation is then part of the standard. Informative reference implementations are no more or less useful than having the four implementations we already have.
# [14:20] <Ms2ger> 4?
# [14:21] <gsnedders> html5lib, Gecko, WebKit, Presto.
# [14:21] <hsivonen> gsnedders: WebKit isn't compliant
# [14:22] <hsivonen> David Flanagan's parser is probably more compliant than WebKit by now
# [14:22] * Quits: ezoe (~ezoe@203-140-91-208f1.kyt1.eonet.ne.jp) (Quit: And Now for Something Completely Different.)
# [14:23] <hsivonen> I wonder how compliant IE10 is
# [14:23] <gsnedders> Last I heard not massively
# [14:25] <zcorpan> what does webkit do wrong?
# [14:25] <hsivonen> zcorpan: MathML stuff at least
# [14:26] <hsivonen> zcorpan: generally anything that has been fixed in the spec since the Chrome 8 release train left the station
# [14:26] <zcorpan> ok
# [14:28] * Philip` wonders if anyone pointed Taggnostr at http://code.google.com/p/html5lib/source/browse/#hg%2Ftestdata%2Ftokenizer yet
# [14:31] <Taggnostr> I wonder if those are usable with HTMLParser (assuming that the license allows me to use them)
# [14:32] <gsnedders> HTMLParser?
# [14:32] <jgraham> Taggnostr: MIT license
# [14:32] <Philip`> (http://wiki.whatwg.org/wiki/Parser_tests for documentation)
# [14:32] <Taggnostr> thanks for the pointers Philip`
# [14:33] <Taggnostr> jgraham, did you write those tests?
# [14:33] <Taggnostr> gsnedders, the parser I'm working on
# [14:33] <gsnedders> Taggnostr: They're written by many different people
# [14:33] <Philip`> I think they're used by all HTML5 parser implementations
# [14:34] <Philip`> (so they ought to be pretty correct relative to the spec, unless a dozen people all made exactly the same misreading of the spec)
# [14:36] <gsnedders> (or have all failed to update their impls to some spec change)
# [14:46] * Joins: plutoniix (~plutoniix@ppp-58-11-228-225.revip2.asianet.co.th)
# [14:50] * Quits: MacTed (~Thud@c-71-233-244-175.hsd1.ma.comcast.net)
# [15:02] <karlcow> http://twitter.com/fraunhoferfokus/status/134983678513254402
# [15:02] <karlcow> "We have something in the pipes for online video codec standardization but can't talk about it yet", Hoschka, W3C #MWS11 #video #codec #W3C
# [15:03] * Quits: virtuelv (~virtuelv_@pat-tdc.opera.com) (Ping timeout: 260 seconds)
# [15:07] <Philip`> Like a new codec, so half the world can standardise on that one while the other half standardises on WebM?
# [15:08] <Workshiva> 10% discount on h264 licenses
# [15:13] * Quits: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net) (Quit: tomasf)
# [15:14] * Joins: scor (~scor@drupal.org/user/52142/view)
# [15:17] * Joins: payman (~payman@pat.se.opera.com)
# [15:20] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [15:26] * Joins: smaug____ (~chatzilla@193-64-22-187-nat.elisa-mobile.fi)
# [15:31] * Quits: smaug____ (~chatzilla@193-64-22-187-nat.elisa-mobile.fi) (Ping timeout: 258 seconds)
# [15:34] * Joins: davidb_ (~davidb@66.207.208.98)
# [15:37] <Ms2ger> Hmm, sicking doesn't realize that public-html is a politics-only list?
# [15:38] * Joins: MacTed (~Thud@63.119.36.36)
# [15:45] <jgraham> What did he post there?
# [15:45] * Joins: astearns (~anonymous@c-50-132-63-33.hsd1.wa.comcast.net)
# [15:46] * Joins: smaug____ (~chatzilla@GYYYMMMCMLXV.gprs.sl-laajakaista.fi)
# [15:46] <Ms2ger> http://lists.w3.org/Archives/Public/www-archive/2011Nov/0021.html
# [15:50] <annevk> man
# [15:50] <annevk> why is Steam for the Mac such a disaster
# [15:50] <annevk> I only wanted to play Portal
# [15:52] <Philip`> Is it not just equivalent to the Windows version?
# [15:52] * Joins: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com)
# [15:53] <Workshiva> s/Steam/any port/
# [15:55] <jgraham> Ms2ger: You may say he's a dreamer but... well actually I guess he is the only one in this case. Nevermind.
# [15:55] <Ms2ger> jgraham++
# [15:55] * Quits: necolas (~necolas@80.169.28.3) (Remote host closed the connection)
# [15:55] * Quits: smaug____ (~chatzilla@GYYYMMMCMLXV.gprs.sl-laajakaista.fi) (Ping timeout: 276 seconds)
# [15:56] * Quits: drublic (~drublic@frbg-5d84f84b.pool.mediaWays.net) (Remote host closed the connection)
# [16:07] <annevk> getting portal for the xbox might be less of a hassle
# [16:10] <Philip`> Depending on how much of a hassle it is, running it in Wine might be less of a hassle
# [16:10] <hsivonen> eww. IE blog has ugly URLs
# [16:11] * Quits: benjoffe_ (~benjoffe_@CPE-121-216-39-241.lnse1.ken.bigpond.net.au) (Remote host closed the connection)
# [16:12] <hsivonen> oh. it's HTTPS Everywhere that makes IE blog URLs ugly
# [16:13] * Quits: david_carlisle (~chatzilla@dcarlisle.demon.co.uk) (Ping timeout: 240 seconds)
# [16:15] * Quits: mishunov (~spliter@77.88.72.162) (Quit: mishunov)
# [16:18] <hsivonen> Does someone happen to know who came up with vendor prefixes and when?
# [16:19] <annevk> maybe around the same time standards mode happened?
# [16:19] * Joins: smaug____ (~chatzilla@MKDXLII.gprs.sl-laajakaista.fi)
# [16:21] <hsivonen> Did IE5 for Mac have vendor-prefixed stuff?
# [16:22] <gsnedders> Certainly most of it's CSS3 support wasn't
# [16:23] * Joins: Rik` (~Rik`@p54BD146F.dip0.t-ipconnect.de)
# [16:23] <annevk> at least as far as CSS 2 was concerned it was post 98
# [16:23] <hsivonen> did the CSS positioning fiasco start this all?
# [16:24] * Quits: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan)
# [16:24] <annevk> http://lists.w3.org/Archives/Member/w3c-css-wg/1998OctDec/0008.html seems to be about where it started
# [16:25] <annevk> (W3C Member-only)
# [16:26] <hsivonen> whoa. Do we have [redacted] to blame about this *too*?
# [16:27] <Ms2ger> [Redacted].
# [16:27] <annevk> http://www.w3.org/Style/Group/1998/09/f2f.html (W3C Member-only)
# [16:28] <Philip`> Yeah, [redacted] is certainly a [redacted]
# [16:28] <gsnedders> hsivonen: Very much positioned for non-specified properties, though, not for draft-standards.
# [16:29] <annevk> http://lists.w3.org/Archives/Member/w3c-css-wg/1998JulSep/0298.html is also relevant
# [16:29] <annevk> also has the winning notation
# [16:30] <hsivonen> annevk: thanks
# [16:31] <gsnedders> Up to 3k unread emails on whatwg. Time to give up soon?
# [16:33] <jgraham> http://www.w3.org/Style/Group/1998/09/f2f.html
# [16:33] <jgraham> Oh yo0u posted that
# [16:33] <zewt> trying to explain the difference between opengl prefixing and web prefixing to the webgl guys seems like a futile effort
# [16:34] <hsivonen> wow. important problems were foreseen when this mess started
# [16:40] * Philip` isn't sure what OpenGL prefixing is
# [16:40] <Philip`> Don't they normally do suffixing (with _ARB/_EXT etc)?
# [16:40] * Joins: Rik`_ (~Rik`@p54BD146F.dip0.t-ipconnect.de)
# [16:40] * Quits: smaug____ (~chatzilla@MKDXLII.gprs.sl-laajakaista.fi) (Ping timeout: 240 seconds)
# [16:41] * Quits: annevk (~annevk@5355737B.cm-6-6b.dynamic.ziggo.nl) (Ping timeout: 240 seconds)
# [16:41] * Quits: Rik` (~Rik`@p54BD146F.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
# [16:41] <zewt> vendor prefixing, GL_NV_*, GL_ATI_, etc
# [16:42] * Joins: annevk (~annevk@5355737B.cm-6-6b.dynamic.ziggo.nl)
# [16:42] * Quits: annevk (~annevk@5355737B.cm-6-6b.dynamic.ziggo.nl) (Client Quit)
# [16:42] <zewt> but it's not used the same as web prefixing
# [16:42] * Joins: annevk (~annevk@5355737B.cm-6-6b.dynamic.ziggo.nl)
# [16:45] <zewt> (for extensions I mean, functions and constants are suffixed)
# [16:47] <Philip`> I suppose one main difference is that it's normal for a vendor to implement extensions from competing vendors' namespaces
# [16:48] <zewt> that's what brought it up, yeah, though there are other differences
# [16:48] <Philip`> (NVIDIA implements GL_ATI_texture_float, AMD implements GL_NV_primitive_restart, etc)
# [16:49] * Philip` wonders if it's considered bad etiquette to write code using a reverse-engineered undocumented GL extension
# [16:49] * Joins: jdong_bot_ (~jdong_bot@114.112.44.153)
# [16:51] <zewt> being prefixed is the normal, expected final product for most opengl extensions, where with web apis it's usually just a development/compatibility thing that you expect to go away in the finished product
# [16:51] * nunnun_away is now known as nunnun
# [16:51] <zewt> far more inherently hardware-specific extensions with opengl, different development processes with opengl, etc
# [16:53] <Philip`> Isn't it fairly common for the expectation to be that the extension will move from vendor prefixes to ARB and maybe eventually to core?
# [16:53] <zewt> common but minority
# [16:54] <Philip`> Ah
# [16:54] <zewt> the issue was with gecko implementing an extension developed in webkit, whether they should implement it as WEBKIT or rename it; i was arguing that, unlike OpenGL practices and like Web APIs, they should
# [16:54] <annevk> well well
# [16:55] <annevk> Xbox finally updated
# [16:55] <annevk> maybe I get to play a game today after all
# [16:55] <zewt> they decided to dodge the issue by abruptly promoting the extension out of _WEBKIT
# [16:55] <jgraham> Now it will explode
# [16:58] <zewt> and without an extension in front of us pressing the issue, the discussion won't go anywhere, so I'll get to rehash it down the line when the next extension comes around
# [16:58] <zewt> oh well. heh
# [16:58] * Joins: MikeSmith_ (~MikeSmith@EM114-48-135-59.pool.e-mobile.ne.jp)
# [16:59] * Joins: Rik` (~Rik`@p54BD146F.dip0.t-ipconnect.de)
# [16:59] * Joins: david_carlisle (~chatzilla@dcarlisle.demon.co.uk)
# [17:00] * Quits: Rik`_ (~Rik`@p54BD146F.dip0.t-ipconnect.de) (Ping timeout: 245 seconds)
# [17:00] <hsivonen> oh so the SVG WG has gone from being vehemently against SVG in HTML to wanting to put SVG in the HTML namespace
# [17:00] <dglazkov> good morning, Whatwg!
# [17:00] <hsivonen> dglazkov: good evening
# [17:01] <Ms2ger> 'Afternoon
# [17:01] <shepazu> hsivonen: we were never against putting SVG in HTML, we lobbied for it...
# [17:01] * Quits: MikeSmith (~MikeSmith@EM111-191-216-98.pool.e-mobile.ne.jp) (Ping timeout: 258 seconds)
# [17:01] * MikeSmith_ is now known as MikeSmith
# [17:01] <hsivonen> shepazu: oh yes, you (SVG WG, maybe not you personall) were at Mandelieu TPAC
# [17:02] <shepazu> hsivonen: I think you're misremembering
# [17:03] <shepazu> we always wanted to have SVG in HTML… the devil of how to do that was in the details
# [17:04] <hsivonen> shepazu: there were elements in the SVG WG who were horrified by the idea of not using a full XML parser for parsing SVG
# [17:04] <shepazu> and conditions have now changed, so we are adapting to what seems like the best way forward is from where we are now
# [17:04] <shepazu> hsivonen: that's a detail
# [17:04] <hsivonen> shepazu: I disagree about it being a detail
# [17:05] * Joins: necolas (~necolas@80.169.28.3)
# [17:05] <hsivonen> shepazu: it's nice that the SVG WG sees the error in its ways, but changing things now would break what we've reached interop on
# [17:06] <hsivonen> shepazu: I'd much rather see Web authors start using SVG now than scare them off for another 5 years or so
# [17:06] <shepazu> before Adobe and Inkscape, the 2 major SVG authoring-tool vendors, were engaged in the SVG WG, we had no way of knowing if those tools would adapt to new SVG syntax… now, they are both engaged, and conditions are different
# [17:06] <shepazu> hsivonen: I don't think there is unanimity in the SVG WG about what namespace SVG elements would be in
# [17:07] <hsivonen> shepazu: and now we have a new condition that we've reached interop on doing SVG in HTML the way the HTML spec says
# [17:07] <shepazu> yup
# [17:08] * Quits: rtuin (~rtuin@213.125.175.250) (Read error: Connection reset by peer)
# [17:10] <jgraham> It is not clear to me that there is enough legacy here to make it too late to break
# [17:10] <jgraham> I don't know what IE9 does
# [17:10] <jgraham> But it is not very HTML5 compliant in general, so it doesn't obviously block this change
# [17:11] <hsivonen> jgraham: IE9 tokenizes SVG scripts per HTML5 for practical purposes (there may be edge cases that are different)
# [17:12] <hsivonen> jgraham: even if there isn't existing content, if we start changing how SVG works in browsers, we reset the clock again on the "when can I use SVG" question from the Web author POV
# [17:13] <jgraham> I wonder how important IE 9 is though. Once 10 is out the people using 9 might all move to 10 rather fast, and the people stuck on lower versions might remain there
# [17:13] <jgraham> I wouldn't be surprised to see a pattern like that
# [17:14] <jgraham> Also, I'm not entirely sure I understand how much content would be affected in this case
# [17:14] <hsivonen> we can't break interop every time we reach interop depending on the current politics at the SVG WG
# [17:14] <hsivonen> if we want adoption some day
# [17:14] <jgraham> Agreed
# [17:15] <jgraham> But that doesn't mean that doing it once is unworkable
# [17:15] <hsivonen> jgraham: are you talking about style and script tokenization or about putting SVG elements in the HTML namespace?
# [17:17] * Joins: hasather_ (~hasather_@84.38.144.96)
# [17:19] <jgraham> The first. The second seems like a very nice change but much more worrying compat-wise
# [17:20] <hsivonen> IE isn't the only boat archor browser BTW. There's also the Android stock browser that could cause trouble for at least 3 years or so.
# [17:21] <Ms2ger> "Boat anchor browser" is a nice term
# [17:24] * Joins: TabAtkins_ (~TabAtkins@76-253-1-30.lightspeed.sntcca.sbcglobal.net)
# [17:24] <TabAtkins_> What's an example of a current spec that takes an options object, and exposed a XXXDict interface so you can feature-detect what's available?
# [17:25] <annevk> dictionaries are not exposed
# [17:26] <TabAtkins_> I was pretty sure that *someone* did what I just asked for.
# [17:27] * Joins: saba (~foo@unaffiliated/saba)
# [17:31] <Ms2ger> WebRTC hasn't figured out dicts yet
# [17:33] * Joins: J_Voracek (~J_Voracek@71.21.195.70)
# [17:33] * Quits: J_Voracek (~J_Voracek@71.21.195.70) (Read error: Connection reset by peer)
# [17:38] * Quits: plutoniix (~plutoniix@ppp-58-11-228-225.revip2.asianet.co.th) (Quit: Leaving)
# [17:38] * Quits: jdong_bot_ (~jdong_bot@114.112.44.153) (Remote host closed the connection)
# [17:40] * Joins: scor (~scor@drupal.org/user/52142/view)
# [17:40] * Joins: plutoniix (~plutoniix@ppp-58-11-252-122.revip2.asianet.co.th)
# [17:42] * Quits: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com) (Quit: Reading http://davidwalsh.name)
# [17:43] <zewt> i suppose that's one benefit to the "defaults in the dictionary" approach (rather than in algorithms); it'd be easier to generically expose the attributes and their defaults as an object
# [17:44] <zewt> i suppose exposing the defaults isn't terribly important, though, so much as just which keys are understood
# [17:47] <TabAtkins_> zewt: Yeah, that's the primary benefit. Exposing defaults is a lucky accident.
# [17:48] <zewt> TabAtkins: but the defaults aren't always in the IDL dictionary
# [17:48] <zewt> (ever, now? not sure)
# [17:50] * Quits: Rik` (~Rik`@p54BD146F.dip0.t-ipconnect.de) (Remote host closed the connection)
# [17:52] * Joins: smaug____ (~chatzilla@YZMYDCCCXXXII.gprs.sl-laajakaista.fi)
# [17:52] * Joins: drublic (~drublic@frbg-5d84f84b.pool.mediaWays.net)
# [17:54] * Joins: rillian_ (~rillian@mist.thaumas.net)
# [17:55] * Quits: astearns (~anonymous@c-50-132-63-33.hsd1.wa.comcast.net) (Quit: astearns)
# [17:58] * Quits: dragon__ (~dragon@59-190-54-232f1.hyg2.eonet.ne.jp) (Quit: Leaving...)
# [17:59] * Quits: nonge_ (~nonge@p5B326748.dip.t-dialin.net) (Quit: Verlassend)
# [18:01] * Quits: plutoniix (~plutoniix@ppp-58-11-252-122.revip2.asianet.co.th) (Quit: Leaving)
# [18:02] * Joins: bensmithett (~bensmithe@115.146.71.1)
# [18:11] * Joins: plutoniix (~plutoniix@ppp-124-120-248-223.revip2.asianet.co.th)
# [18:29] <AryehGregor> jgraham, IE9 works on Vista and IE10 doesn't, no? Of course, maybe there aren't enough people using Vista to matter.
# [18:35] * Quits: Druid_ (~Druid@p5B05D65A.dip.t-dialin.net)
# [18:40] * Joins: dave_levin (dave_levin@nat/google/x-ymyphxjcwybmgbbs)
# [18:45] * Quits: payman (~payman@pat.se.opera.com) (Ping timeout: 260 seconds)
# [18:46] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
# [18:47] * Joins: payman (~payman@pat.se.opera.com)
# [18:47] * Joins: astearns (~anonymous@192.150.22.5)
# [18:47] * Quits: rillian_ (~rillian@mist.thaumas.net) (Remote host closed the connection)
# [18:51] * Joins: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net)
# [18:52] * Joins: erlehmann (~erlehmann@82.113.121.140)
# [18:54] * Joins: ap (~ap@2620:149:4:1b01:d804:5305:814a:a888)
# [18:56] * Quits: necolas (~necolas@80.169.28.3) (Remote host closed the connection)
# [19:02] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
# [19:02] * Joins: dbaron (~dbaron@mail.questnewmarket.co.nz)
# [19:04] * Quits: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Client Quit)
# [19:04] * Joins: rillian_ (~rillian@mist.thaumas.net)
# [19:05] * Joins: Druid_ (~Druid@p5B05D65A.dip.t-dialin.net)
# [19:05] * Quits: rillian_ (~rillian@mist.thaumas.net) (Remote host closed the connection)
# [19:11] * Quits: smaug____ (~chatzilla@YZMYDCCCXXXII.gprs.sl-laajakaista.fi) (Ping timeout: 252 seconds)
# [19:13] * Joins: mkanat (mkanat@nat/google/x-mdvdobuohmvuspwl)
# [19:16] * Quits: jernoble (~jernoble@2620:149:4:1b01:9d1d:6a28:927e:f7f4) (Remote host closed the connection)
# [19:18] * Joins: jernoble (~jernoble@2620:149:4:1b01:2d77:fcf7:4f39:56d7)
# [19:20] <jgraham> AryehGregor: Maybe. I was thinking of XP vs others and enterprise vs sane
# [19:20] <AryehGregor> Maybe.
# [19:20] * Quits: david_carlisle (~chatzilla@dcarlisle.demon.co.uk) (Ping timeout: 260 seconds)
# [19:22] * Quits: TabAtkins_ (~TabAtkins@76-253-1-30.lightspeed.sntcca.sbcglobal.net)
# [19:23] * Quits: jochen__ (jochen@nat/google/x-sgqrqsmrvhjwlccm) (Ping timeout: 244 seconds)
# [19:24] <jgraham> AryehGregor: It looks like Vista has at best 1/3 of the share of either XP or 7 so it's not clear that will be a big effect
# [19:26] * Joins: smaug____ (~chatzilla@YGMMDCCXXI.gprs.sl-laajakaista.fi)
# [19:40] * Quits: hasather_ (~hasather_@84.38.144.96) (Remote host closed the connection)
# [19:46] * Joins: ojan (ojan@nat/google/x-lokjrjkfaojuxvsd)
# [19:51] * Joins: rniwa (rniwa@nat/google/x-athrxcaawprvuanj)
# [19:52] <smaug____> annevk: sicking: got crazy idea. Could we support the new XHR response types only in async XHR (I'm talking about the Window context, not Worker context)
# [19:53] <sicking> smaug____: it's been shipping for a while in various browsers, but quite possibly yeah
# [19:53] <jamesr_> ooo
# [19:56] * smaug____ files a spec bug
# [19:57] <smaug____> jamesr_: do you think webkit would be willing to make such change?
# [19:58] <jamesr_> smaug____, as a way to encourage authors to move away from sync, right?
# [19:58] <smaug____> yes
# [19:58] <smaug____> sync is bad in the UI thread
# [19:58] <jamesr_> i personally think it's a great idea. i'm not sure what our implementation status
# [19:58] <jamesr_> yeah sync is the worst
# [19:58] <smaug____> unfortunately it is used quite ofter for text and xml responses
# [19:59] <jamesr_> i know :(
# [19:59] <smaug____> Google Docs was using it allover at some point
# [19:59] <jamesr_> hell yeah let's do it
# [20:00] <jamesr_> smaug____, do you have a mozilla bug i can cite in the webkit bug report?
# [20:00] <jgraham> "if the sync flag is true throw ERR_YOURE_DOING_IT_WRONG"
# [20:00] <Ms2ger> COME_ON_ERR?
# [20:01] <smaug____> jamesr_: not yet
# [20:01] <smaug____> I'm just sending email to webapps
# [20:01] * Joins: jernoble_ (~jernoble@17.212.152.13)
# [20:01] <smaug____> XHR2 doesn't seem to have bugzilla component
# [20:02] * Quits: jernoble (~jernoble@2620:149:4:1b01:2d77:fcf7:4f39:56d7) (Ping timeout: 240 seconds)
# [20:02] * jernoble_ is now known as jernoble
# [20:02] <Ms2ger> There's just one for XHR1 and 2, no?
# [20:02] <jamesr_> filed https://bugs.webkit.org/show_bug.cgi?id=72154 (partially as a way to solicit feedback from other WebKit devs)
# [20:03] * Quits: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net) (Ping timeout: 258 seconds)
# [20:03] <jamesr_> somebody would have to figure out the compat risks of changing things depending on how long each type has been supported, i'm not personally familiar
# [20:03] <jamesr_> but i love the idea
# [20:03] <smaug____> Ms2ger: I couldn't find any component
# [20:03] <smaug____> perhaps just looked at some wrong place
# [20:04] <smaug____> Ms2ger: er, now I see it
# [20:04] <smaug____> XHR1 and XHR2
# [20:04] <Ms2ger> Good :)
# [20:04] * Joins: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net)
# [20:04] * Joins: rillian_ (~rillian@mist.thaumas.net)
# [20:05] * Joins: cgcardona (~cgcardona@unaffiliated/cgcardona)
# [20:05] * Quits: Ms2ger (~Ms2ger@91.181.168.54) (Quit: nn)
# [20:08] * Quits: sicking (~chatzilla@c-98-210-155-80.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
# [20:09] * Quits: FlorianX (~Dimitri@p4FCF6E57.dip.t-dialin.net) (Ping timeout: 260 seconds)
# [20:11] * Joins: KillerX (~anant@nat/mozilla/x-qlwszfpvixfhfavs)
# [20:11] * Joins: Peter` (~peter@nishino.lvp-media.com)
# [20:11] <smaug____> http://www.w3.org/Bugs/Public/show_bug.cgi?id=14773 https://bugzilla.mozilla.org/show_bug.cgi?id=701787
# [20:12] * Joins: foolip_ (u3586@gateway/web/irccloud.com/x-cjhbzbmtwahekqba)
# [20:20] * Quits: erlehmann (~erlehmann@82.113.121.140) (Quit: Ex-Chat)
# [20:32] * Joins: david_carlisle (~chatzilla@dcarlisle.demon.co.uk)
# [20:32] * Joins: jacobolu_ (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net)
# [20:35] * Quits: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net) (Ping timeout: 276 seconds)
# [20:36] * Quits: rillian_ (~rillian@mist.thaumas.net) (Remote host closed the connection)
# [20:37] <smaug____> hmm, XHR doesn't really define how responseText and responseXML map to each other while loading
# [20:37] <smaug____> I mean, does something require that parsing needs to be synchronous or not
# [20:38] * Joins: rillian_ (~rillian@mist.thaumas.net)
# [20:38] * Quits: rillian_ (~rillian@mist.thaumas.net) (Remote host closed the connection)
# [20:41] * Quits: dbaron (~dbaron@mail.questnewmarket.co.nz) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [20:41] * Joins: _bga (~bga@ppp78-37-210-153.pppoe.avangarddsl.ru)
# [20:44] * Quits: bga_ (~bga@ppp78-37-228-240.pppoe.avangarddsl.ru) (Ping timeout: 252 seconds)
# [20:47] * Joins: arv (u4269@gateway/web/irccloud.com/x-hjpsmrvjscknpads)
# [20:49] * Quits: Druid_ (~Druid@p5B05D65A.dip.t-dialin.net)
# [21:02] * Joins: Druid_ (~Druid@p5B05D65A.dip.t-dialin.net)
# [21:05] * Quits: roc (~chatzilla@121.98.230.221) (Ping timeout: 240 seconds)
# [21:10] * Quits: drublic (~drublic@frbg-5d84f84b.pool.mediaWays.net) (Remote host closed the connection)
# [21:27] * Joins: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90)
# [21:31] <zewt> personally i think any use of window-synchronous xhr should force the page to comic sans
# [21:34] * Joins: rillian_ (~rillian@mist.thaumas.net)
# [21:36] * Joins: smaug_____ (~chatzilla@GZMMDCCLXXII.gprs.sl-laajakaista.fi)
# [21:37] * Joins: jamesr (jamesr@nat/google/x-pjcogwjgmgyhhilt)
# [21:37] * Quits: smaug____ (~chatzilla@YGMMDCCXXI.gprs.sl-laajakaista.fi) (Ping timeout: 255 seconds)
# [21:37] * smaug_____ is now known as smaug____
# [21:38] * Joins: othermaciej (~mjs@17.245.88.157)
# [21:41] * Quits: AryehGregor (~Simetrica@mediawiki/simetrical) (Ping timeout: 240 seconds)
# [21:43] * Joins: AryehGregor (~Simetrica@cpe-68-175-61-233.nyc.res.rr.com)
# [21:43] * Quits: AryehGregor (~Simetrica@cpe-68-175-61-233.nyc.res.rr.com) (Changing host)
# [21:43] * Joins: AryehGregor (~Simetrica@mediawiki/simetrical)
# [21:53] * Quits: saba (~foo@unaffiliated/saba) (Ping timeout: 260 seconds)
# [22:03] * jernoble is now known as jernoble|afk
# [22:11] * Quits: MacTed (~Thud@63.119.36.36)
# [22:12] * Quits: othermaciej (~mjs@17.245.88.157) (Quit: othermaciej)
# [22:14] * Joins: othermaciej (~mjs@17.245.88.157)
# [22:14] * Quits: gavinc_ (~gavin@50-0-138-90.dsl.dynamic.sonic.net) (Remote host closed the connection)
# [22:16] * Quits: jamesr (jamesr@nat/google/x-pjcogwjgmgyhhilt) (Quit: jamesr)
# [22:17] * Joins: sicking (~chatzilla@nat/mozilla/x-wkdwxsqslosixtji)
# [22:17] * Joins: jamesr (jamesr@nat/google/x-irrcefkulyjgypbc)
# [22:23] * jernoble|afk is now known as jernoble
# [22:23] * Joins: agektmr (~Adium@p2156-ipbf5107marunouchi.tokyo.ocn.ne.jp)
# [22:24] * Joins: virtuelv (~virtuelv_@247.183.189.109.customer.cdi.no)
# [22:26] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [22:27] <jamesr_> sicking, on the .findAll() thread i missed why the return type needs something in addition to Array.prototype on the prototype chain
# [22:28] <jamesr_> what would go on [some type].prototype ?
# [22:28] * Joins: necolas (~necolas@5e04326b.bb.sky.com)
# [22:29] <sicking> jamesr_: See point to in the goals list in the beginning of the mail
# [22:29] <TabAtkins> jamesr_: .findAll again, for example.
# [22:30] <sicking> jamesr_: it's a future extension point so that we can hang things at it later
# [22:31] <sicking> jamesr_: like .findAll, or .remove (to remove all the nodes from their parent), or .merge to merge two NodeArrays together and produce a sorted NodeArray
# [22:31] <sicking> jamesr_: jquery has a host of functions on their equivalent of NodeArray, many of these would make sense on NodeArray too
# [22:31] <TabAtkins> It has basically the entire Element API on their nodelists.
# [22:32] <TabAtkins> Which is super-useful.
# [22:32] * Joins: MacTed (~Thud@63.119.36.36)
# [22:33] <sicking> document.findAll(...).addEventListener would be neat
# [22:33] <jamesr_> that operates on each element in the array?
# [22:33] <sicking> yes
# [22:33] <_bga> :(
# [22:34] <_bga> dont invent jq again
# [22:34] <_bga> plz
# [22:34] <TabAtkins> Sorry, _bga, but you're wrong. jQuery's interface is *really* useful.
# [22:34] <_bga> doc.findAll(...).forEach(...)
# [22:35] * Quits: virtuelv (~virtuelv_@247.183.189.109.customer.cdi.no) (Quit: Ex-Chat)
# [22:35] <TabAtkins> _bga: That doesn't let you do very useful things like run .findAll on the results and get back a unioned-and-document-sorted nodelist.
# [22:35] <sicking> _bga: the fact that jQuery is seeing so much use is a pretty good indication that it's doing something right
# [22:37] <_bga> TabAtkins jq api isnt orhogonal but ok if you want. anyway nobody need add event listerer to many nodes bucause event delegation by class is better
# [22:38] <TabAtkins> _bga: Possible so. But once you've added 50% of the Element API to it, you might as well add the rest for consistency.
# [22:40] <dglazkov> sicking: that smells like a language thing to me:
# [22:41] <sicking> dglazkov: what does?
# [22:41] <TabAtkins> dglazkov: Lifting functions over an array is something the language can make easier, but it doesn't always go far enough.
# [22:41] <TabAtkins> Like with the el.findAll().findAll() example.
# [22:41] <dglazkov> sicking: document.findAll(..)..->addEventListener or something...
# [22:41] * Quits: david_carlisle (~chatzilla@dcarlisle.demon.co.uk) (Ping timeout: 258 seconds)
# [22:42] <sicking> dglazkov: you mean the ability to apply a function call to all elements in an array?
# [22:42] * Quits: erichynds (~ehynds@venkman.brightcove.com)
# [22:42] <dglazkov> sicking: yah
# [22:42] <sicking> they already have that as a library, but the syntax is clunky
# [22:43] <sicking> array.map(function(e) { e.doStuff(...) });
# [22:43] <dglazkov> yup
# [22:43] <sicking> possibly lambda expressions will help
# [22:43] <TabAtkins> lift(doStuff)(array)
# [22:43] <TabAtkins> Damn focus on methods and 'this' makes that hard.
# [22:44] <sicking> right
# [22:44] <_bga> i had els._do('addEventListener', [_fn, false])
# [22:44] * TabAtkins wishes once again that he could just program lisp in the browser...
# [22:44] <dglazkov> array/:=(addEvenListener
# [22:44] <_bga> * els._do('addEventListener', [type, _fn, false])
# [22:44] <dglazkov> a sad hitler shorthand
# [22:45] * Quits: davidb_ (~davidb@66.207.208.98) (Quit: davidb_)
# [22:47] <_bga> TabAtkins anyway you(whole committee) must populate widget model, not jq spagetti code
# [22:47] * TabAtkins can't parse that sentence.
# [22:47] <_bga> sorry
# [22:47] <sicking> _bga: well.. first step is to come up with a concrete proposal
# [22:48] <sicking> _bga: once you have that we can talk :)
# [22:48] <sicking> _bga: next step would be to TC39 and pitch it
# [22:48] * sicking is about to pitch weak references to TC39
# [22:49] <TabAtkins> sicking: Like, right now?
# [22:49] <sicking> TabAtkins: no, need to do a couple of more rounds through dhermans brain
# [22:49] <TabAtkins> Oh, okay. Wasn't sure how immediate the "about" was.
# [22:49] <sicking> TabAtkins: but the first round went better than other things I've pitched him
# [22:52] <TabAtkins> The current thing I'm most excited about is private Names and decoupling . and [] semantics.
# [22:54] <_bga> TC39 has wrong way imho. i stopped reading mailing list half year ago
# [22:55] <hsivonen> smaug____: parsing in XHR does not need to be synchronous. responseXML isn't available until parsing has ended.
# [22:56] * Quits: FireFly (firefly@firefly.xen.prgmr.com) (Changing host)
# [22:56] * Joins: FireFly (firefly@unaffiliated/firefly)
# [22:58] * Joins: MikeSmith_ (~MikeSmith@EM114-48-199-216.pool.e-mobile.ne.jp)
# [23:02] * Quits: MikeSmith (~MikeSmith@EM114-48-135-59.pool.e-mobile.ne.jp) (Ping timeout: 258 seconds)
# [23:02] * MikeSmith_ is now known as MikeSmith
# [23:02] <smaug____> hsivonen: ah
# [23:03] <hsivonen> smaug____: however, I did intentionally stall progress events until the charset is known, because responseText is supposed to accumulate during progress events
# [23:03] <smaug____> yeah, that is ok-ish
# [23:04] <smaug____> at least I don't have any better solution
# [23:04] <hsivonen> smaug____: I have an alternative solution, but I don't want to bother unless Web compat requires
# [23:05] <hsivonen> smaug____: the alternative is to expose stuff in the ASCII range in responseText before the encoding has been decided
# [23:05] <dglazkov> arv: did you see the conversation about a lifting shorthand in JS?
# [23:05] <hsivonen> i.e. start stalling at the first non-ASCII character
# [23:05] * Joins: mpt (mpt@nat/google/x-ucuzrvkuknsovryn)
# [23:05] * Quits: mpt (mpt@nat/google/x-ucuzrvkuknsovryn) (Changing host)
# [23:05] * Joins: mpt (mpt@canonical/mpt)
# [23:06] * Parts: mpt (mpt@canonical/mpt)
# [23:06] <hsivonen> smaug____: but I thought it's not worthwhile to add that kind of complexity without a clear demonstartion of Web compat issues with the way I wrote the patch
# [23:06] <arv> dglazkov: lifting shorthand?
# [23:06] * Quits: othermaciej (~mjs@17.245.88.157) (Quit: othermaciej)
# [23:06] <dglazkov> arv: to provide jquery-like lift facilities in the language
# [23:06] <smaug____> hsivonen: I agree
# [23:06] <arv> dglazkov: reading irc backlog now
# [23:07] <hsivonen> smaug____: what I'm most worried about in terms of Web compat is the situation that the extension manager had showing up on the Web
# [23:07] <dglazkov> arv: I remember you mentioning something about this
# [23:07] <hsivonen> smaug____: that is, XHR users expecting HTTP text/html 404 or other error pages to give null responseXML
# [23:07] <smaug____> yeah
# [23:07] <hsivonen> smaug____: but again, I think it doesn't make sense to solve that problem without a demonstration that it's a real Web compat problem
# [23:08] <smaug____> hsivonen: could we not give responseXML at all for text/html documents
# [23:08] <smaug____> only response
# [23:08] <hsivonen> smaug____: if it becomes a problem, we could only give responseXML when the status code is 2xx
# [23:09] <smaug____> but why do we need to give HTML document from responseXML
# [23:09] <smaug____> responseXML is legacy
# [23:09] <hsivonen> smaug____: responseXML is the way you obtain a Document from XHR
# [23:10] <hsivonen> smaug____: but yeah, if it becomes a problem, we could limit availability to the xhr.response
# [23:10] <smaug____> hsivonen: you can get document using .response
# [23:11] <smaug____> so, is there any reason to get document from responseXML
# [23:11] <hsivonen> smaug____: I was following the spec
# [23:11] <smaug____> right
# [23:11] <arv> TabAtkins: Like this: http://traceur-compiler.googlecode.com/svn/trunk/example/collection.html
# [23:11] <smaug____> the spec is possibly wrong
# [23:12] <smaug____> (specs are always wrong :p )
# [23:12] <hsivonen> smaug____: to me, it seems logical to offer the document via responseXML
# [23:12] <arv> dglazkov: ES6 will have real iterators and a for-of loop for them
# [23:12] <smaug____> even if the document has nothing to do with XML?
# [23:12] <TabAtkins> arv: Yeah.
# [23:12] <hsivonen> smaug____: I suggest we try to find out if offering it via resposeXML breaks the Web
# [23:12] <hsivonen> smaug____: we have innerHTML on XML docs
# [23:13] <arv> dglazkov: Me and Jacob talked about .{ for chaining. es-discuss didn't like it much though
# [23:13] <smaug____> hsivonen: and that is unfortunate, but too late to fix
# [23:13] <TabAtkins> arv: What does that do, run the block on the list or something?
# [23:13] <dglazkov> arv: nifty demo!
# [23:13] <TabAtkins> Or is that the "set multiple properties as an expression" thing?
# [23:14] * dglazkov slaps es-discuss with a trout
# [23:14] <arv> TabAtkins: expr.{a: b, c: d} desugars to something like $tmp = expr; tmp.a = b; $tmp.c = d
# [23:14] <hsivonen> smaug____: I suggest landing without more spec violations than the ones I've made already for not honoring <meta> for responseType == "text" and seeing what happens
# [23:14] <TabAtkins> Yeah, what I thought. Not sure how that's relevant to what we were talking about, though.
# [23:14] <arv> TabAtkins: very much like css hierarchies
# [23:15] <hsivonen> smaug____: if bad stuff happens, let's make spec change suggestions
# [23:15] <smaug____> hsivonen: we can do that
# [23:15] <smaug____> hsivonen: and removing the support for .responseXML is easy
# [23:15] <TabAtkins> arv: We're talking about things like el.findAll().remove() or whatnot.
# [23:16] <smaug____> I probably would want responseText and responseXML to support only legacy types
# [23:16] <smaug____> (only those types which should be allowed to be used with sync XHR)
# [23:17] <arv> TabAtkins: It allows chaining... https://mail.mozilla.org/pipermail/es-discuss/2011-November/018268.html
# [23:17] <arv> TabAtkins: without restructuring the whole API to use methods that return THE jQuery obejct
# [23:19] <arv> TabAtkins: For that I would just use a for of loop but expanding NodeList to implement Node is an exercise we have done. It seems to mostly work
# [23:19] <hsivonen> smaug____: the reason the patch doesn't leak is that the parser always delivers DOMContentLoaded if we get as far as using the event listener
# [23:19] * Quits: agektmr (~Adium@p2156-ipbf5107marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving.)
# [23:20] <smaug____> hsivonen: what releases the listener?
# [23:20] <TabAtkins> arv: I see. It's using a slightly different syntax between the {} to allow method calls.
# [23:20] <hsivonen> smaug____: whoa. I'm not sure.
# [23:21] <arv> TabAtkins: This is kind of pushing the limits of syntax and some people really dislike this direction
# [23:21] * Quits: MacTed (~Thud@63.119.36.36)
# [23:21] <hsivonen> smaug____: I need to take a better look at your comments at daytime
# [23:21] <smaug____> k
# [23:21] <TabAtkins> arv: I can see why. ^_^
# [23:22] <TabAtkins> Definitely a bit difficult to read.
# [23:24] * Joins: othermaciej (~mjs@17.244.11.15)
# [23:24] * Joins: smaug_____ (~chatzilla@GZDCCLVI.gprs.sl-laajakaista.fi)
# [23:24] * smaug_____ kicks this 3G connection
# [23:25] * Quits: smaug____ (~chatzilla@GZMMDCCLXXII.gprs.sl-laajakaista.fi) (Ping timeout: 260 seconds)
# [23:25] * smaug_____ is now known as smaug____
# [23:27] <arv> TabAtkins: no harder than jquery =P I also find the closing curly brace a lot cleaner than jquery's begin(). ... .end()
# [23:27] <TabAtkins> Agree on that last point.
# [23:34] * Quits: astearns (~anonymous@192.150.22.5) (Ping timeout: 248 seconds)
# [23:40] <dglazkov> TabAtkins: where's a good summary of the latest and greatest on CSS variables?
# [23:40] <dglazkov> TabAtkins: "in my head" is an acceptable answer
# [23:40] <TabAtkins> http://dev.w3.org/csswg/css-variables
# [23:41] * Quits: smaug____ (~chatzilla@GZDCCLVI.gprs.sl-laajakaista.fi) (Quit: ChatZilla 0.9.86.1 [Firefox 10.0a1/20111029031036])
# [23:46] * Joins: smaug____ (~chatzilla@GZKCDXVII.gprs.sl-laajakaista.fi)
# [23:49] <dglazkov> TabAtkins: this is gorgeous
# [23:51] <TabAtkins> Damn, if you remove all the examples, the whole useful part of the spec is *just* over two screenfuls.
# [23:52] <sicking> TabAtkins: had you been involved in the accessibility-for-canvas API?
# [23:52] <dglazkov> I thought exmaples_were_ the useful part :)
# [23:52] <sicking> TabAtkins: i think someone said you had been present during those discussions at tpac?
# [23:52] <TabAtkins> sicking: Only in shouting for use-cases.
# [23:52] <TabAtkins> No, I was not in the tpac discussions.
# [23:53] <TabAtkins> Though my spirit may have been hovering in the room.
# [23:53] <TabAtkins> Glooming at everyone.
# [23:53] <sicking> hah
# [23:54] <dglazkov> accessibility for ALL the canvases!
# [23:54] <sicking> TabAtkins: i think the use case is basically to existing use of canvas accessible. I realize that a lot of canvas use today can be done in a differe, more accessible way, using completely different APIs
# [23:54] <sicking> TabAtkins: but i think asking people to completely redo what they are doing, especially if the win is "just" accessibility, isn't going to have any effect
# [23:55] <TabAtkins> I agree.
# [23:55] <smaug____> that reminds me... since I know nothing about canvas+a11y, I was wondering few days ago why imagemaps couldn't be used with canvas
# [23:56] <sicking> smaug____: the problem is that it's a completely different API. If you're drawing something on screen with canvas, you'll need a completely different code-path to also create an imagemap
# [23:56] <smaug____> I was told that it has been decided that imagemaps don't work well enough in that case, but does anyone happen to have links to where that discussion has happened
# [23:56] <sicking> smaug____: so it's just too inconvenient
# [23:57] <sicking> smaug____: additionally, there is no way to associate an element with a particular image-map area
# [23:57] * Joins: ezoe (~ezoe@203-140-91-161f1.kyt1.eonet.ne.jp)
# [23:57] <sicking> TabAtkins: but working based on examples of how people use canvas today is definitely a good idea
# [23:58] <smaug____> sicking: I don't quite buy that all. Something new could be added to maps
# [23:58] <smaug____> but, as I said, I'm not really familiar with a11y+canvas
# Session Close: Sat Nov 12 00:00:00 2011

The end :)