| 00:00 | <smaug3G> | var o = { handleEvent: function(e) {}}; |
| 00:00 | <smaug3G> | when handleEvent is called, this == o; |
| 00:00 | <Hixie> | zcyes |
| 00:00 | <Hixie> | yes |
| 00:00 | <Hixie> | which is the wrong this |
| 00:00 | <smaug3G> | which is the right one |
| 00:00 | <Hixie> | no |
| 00:01 | <smaug3G> | if you don't want that, you can use function() {} as a callback |
| 00:01 | <Hixie> | you want "this" to be the "this" that applies in the code that set the callback |
| 00:01 | <smaug3G> | no |
| 00:01 | <smaug3G> | well, depends on the case |
| 00:01 | <TabAtkins> | Hixie: You could want either. Luckily JS has mechanisms to handle them both easily. |
| 00:02 | <smaug3G> | and since implementations handle both cases anyway, there is no need to limit it |
| 00:02 | <Hixie> | TabAtkins: do you have an example of when you would want what smaug says? |
| 00:02 | <Hixie> | TabAtkins: i cannot recall ever wanting that, but i'd love to see an example |
| 00:03 | <TabAtkins> | Hixie: If you're just holding onto some state shared across multiple callbacks. |
| 00:04 | <smaug3G> | you could look at Firefox UI source code for example. It is using { handleEvent: function() {}} style all the time |
| 00:06 | <smaug3G> | ...because it wants to keep some state across the calls |
| 00:07 | <Hixie> | TabAtkins: why would you need a "this" at all then? surely you'd just have the state in the closure. |
| 00:07 | <TabAtkins> | Hixie: That's another way to do it, sure. |
| 00:08 | <TabAtkins> | The object is basically a public closure for these purposes. |
| 00:08 | <Hixie> | i wonder when you'd do that |
| 00:08 | <Hixie> | or rather, why i've never ended up wanting that |
| 00:09 | <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 |
| 00:09 | <Hixie> | seems like creating it just for the handlers would be rather constraining, e.g. what if you later need two types of handlers? |
| 00:09 | <Hixie> | seems like poor style to me |
| 00:31 | <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. |
| 00:32 | <Hixie> | closures don't hide data that's public |
| 00:32 | <Hixie> | they just take existing variables and let you access them later, whether they are private or public |
| 00:33 | <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) |
| 00:33 | <TabAtkins> | Ah, right, sorry. Was thinking of the common practice of using closures specifically to hide static vars. |
| 00:35 | <jernoble> | Hixie: i have a question about your response to the MediaController bug |
| 00:35 | <Hixie> | which one? |
| 00:35 | <Hixie> | oh the one with the states |
| 00:35 | <jernoble> | Hixie: right |
| 00:35 | <Hixie> | shoot |
| 00:35 | <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 |
| 00:36 | <jernoble> | Hixie: do the events for 2 & 3 fire, or just the event for 3? |
| 00:36 | <jernoble> | Hixie: Because i don't think the answer is clear from those two tables. |
| 00:36 | <jernoble> | Hixie: (or I'm just being dense.) |
| 00:36 | <Hixie> | the second table is non-normative so it doesn't help answer the question oen way or the other |
| 00:36 | <Hixie> | let me see though |
| 00:38 | <Hixie> | so if a group of media elements are in states 1,1,3 and go to the state 1,3,3, nothing happens |
| 00:38 | <Hixie> | then if they go to the state 3,3,3 in one go |
| 00:39 | <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" |
| 00:39 | <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" |
| 00:39 | <Hixie> | so you queue up canplay on the media element |
| 00:40 | <Hixie> | (and maybe 'playing') |
| 00:40 | <Hixie> | then you go to step 2 |
| 00:40 | <Hixie> | report the controller state |
| 00:40 | <Hixie> | new readiness state is now 3 |
| 00:40 | <Hixie> | so you fire canplay on the media controller in step 2 |
| 00:40 | <Hixie> | so the answer is, you don't fire the event for 2 |
| 00:41 | <Hixie> | jernoble: does that answer your question? |
| 00:41 | <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. :) |
| 00:41 | <jernoble> | Hixie: thanks! |
| 00:42 | <Hixie> | jernoble: yeah the second table's wording is maybe not ideal |
| 00:42 | <Hixie> | jernoble: not sure how to improve it really |
| 00:43 | <Hixie> | oh actually i slightly misspoke when i went through the steps above, though it doesn't affect the final answer |
| 00:43 | <Hixie> | on the media element you do queue up tasks to fire loadeddata then canplay |
| 00:43 | <Hixie> | because you hit "If the previous ready state was HAVE_METADATA and the new ready state is HAVE_CURRENT_DATA or greater" |
| 00:43 | <Hixie> | maybe i should make it do the same for MediaController |
| 00:44 | <Hixie> | jernoble: i think maybe it _should_ fire the intermediate events |
| 00:44 | <jernoble> | Hixie: i think that's where the reviewer got confused. |
| 00:45 | <Hixie> | jernoble: otherwise someone listening to one event might miss it if the network is especially fast, or whatnot |
| 00:45 | <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. |
| 00:45 | <Hixie> | yeah |
| 00:46 | <Hixie> | ok let me make the intermediate events fire while i'm here |
| 00:46 | <jernoble> | Hixie: and i'll change the implementation while /I'm/ here. |
| 00:46 | <Hixie> | heh, in the spec source under the first paragraph for step 2 it says: |
| 00:46 | <Hixie> | <!-- hopefully everyone will understand what this means --> |
| 00:46 | <Hixie> | :-/ |
| 00:47 | <jernoble> | chuckle. :) |
| 00:51 | <Hixie> | ok i changed the spec to fire all the events when incrementing |
| 00:52 | <Hixie> | but when decrementing it just fires the new state |
| 00:52 | <Hixie> | that works right? |
| 00:52 | <jernoble> | Hixie: yup. seems to. |
| 00:53 | <Hixie> | ok it's checked in |
| 00:56 | <jernoble> | Hixie: cool, thanks. |
| 00:57 | <hober> | yay |
| 07:44 | <annevk> | hah, slept until 8:30 |
| 07:47 | <wilhelm> | You beat the jet lag already? |
| 07:50 | <annevk> | I doubt that, but I did sleep normal hours, although much longer than usual |
| 08:13 | <annevk> | zcorpan: lol, trying to incite a riot on twitter :p |
| 08:14 | <Hixie> | wtf, why is twitter CSS-free for me today |
| 08:14 | <Hixie> | huh, fixed itself when i logged in |
| 08:14 | <annevk> | they seem to be rolling out some updates |
| 08:27 | <annevk> | heh, just discovered mattur has a bunch of twitter lists |
| 08:44 | <hsivonen> | is xhr.status 200 when the respose was cached? e.g. if the server said not modified? |
| 08:45 | <hsivonen> | I've identified a new risk with adding HTML support to XHR: |
| 08:46 | <hsivonen> | existing code that treats checking responseXML for null as a surrogate for checking HTTP success when expecting XML on success |
| 08:46 | <hsivonen> | and errors come with a text/html body |
| 08:48 | <annevk> | search for "conditional" |
| 08:50 | <hsivonen> | annevk: thanks |
| 08:51 | <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 |
| 08:52 | <hsivonen> | or require responseType = "document" to force parsing of error bodies |
| 08:54 | <annevk> | the middle of those is the intent of the spec |
| 08:54 | <annevk> | and is what happens if error bodies come with XML |
| 08:54 | <hsivonen> | annevk: what do you mean? |
| 08:55 | <annevk> | if a server has a text/xml 500 status page |
| 08:55 | <annevk> | responseXML will be populated with its contents |
| 08:55 | <hsivonen> | annevk: I mean what's "the middle"? |
| 08:55 | <annevk> | that should work for text/html too |
| 08:55 | <annevk> | hsivonen: you gave three options, I prefer #2 |
| 08:56 | <hsivonen> | annevk: I see |
| 08:56 | <hsivonen> | the scary part is that I found out about this by reading the code of our extension update code |
| 08:56 | <hsivonen> | s/update code/updates/ |
| 09:05 | <annevk> | omg |
| 09:05 | <annevk> | we're getting document.find now? |
| 09:06 | <annevk> | sicking: why not simply use Array? |
| 09:07 | <annevk> | nm |
| 09:07 | annevk | missed something obvious |
| 09:47 | jgraham | notes that document.find seems like a very confusing name |
| 09:48 | <jgraham> | But whatever |
| 11:40 | <zcorpan> | i wonder if steve and the chairs feel good about wasting Mike[tm]'s time |
| 11:42 | <jgraham> | I wonder if they care |
| 11:44 | <Ms2ger> | Time isn't relevant, they need to assert authority |
| 11:44 | <Philip`> | Short-term loss for long-term gain |
| 11:44 | <annevk> | Philip`: what is the gain? |
| 11:45 | Ms2ger | adds scare quotes |
| 11:45 | <jgraham> | annevk: 05:47 < Ms2ger> [...] authority |
| 11:45 | <Philip`> | annevk: Nebulous |
| 11:48 | <hsivonen> | I don't like wasting MikeSmith's time, but dropping <time> the way Hixie dropped it was still a bad move. |
| 11:50 | <jgraham> | AFAICT everyone apart from MikeSmith benefited from this |
| 11:50 | <jgraham> | If Hixie hadn't dropped time, the people who want the new, different, time would never have got it |
| 11:50 | <zcorpan> | poor guy |
| 11:51 | <hsivonen> | jgraham: how did I benefit? |
| 11:51 | <jgraham> | and the charis wouldn't have got to show us how effective they are |
| 11:51 | <jgraham> | *chairs |
| 11:51 | <annevk> | ineffective* |
| 11:51 | <zcorpan> | hsivonen: the spec will better match use cases people want |
| 11:52 | <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 |
| 11:53 | <jgraham> | (the other case being "new time was morphed from old time without an intermediate stage") |
| 11:53 | <jgraham> | (ignoring the fact that that would probably not have happened) |
| 11:54 | <Ms2ger> | Also, Gecko supports outerHTML now! |
| 11:54 | <Ms2ger> | hsivonen++ |
| 11:55 | <annevk> | welcome to 2000 |
| 11:56 | <Ms2ger> | Why thank you |
| 11:56 | <jgraham> | meow? |
| 11:58 | <hsivonen> | Ms2ger: thank you for writing most of the code for that patch |
| 11:58 | <Ms2ger> | And thank you for writing the hard code :) |
| 11:59 | <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 |
| 11:59 | <hsivonen> | so when we implement IE4 features, they just start working |
| 12:00 | <hsivonen> | when we implement WebKit features, we deliberately self-sabotage them so that additional evangelism is needed |
| 12:01 | <hsivonen> | (actually, I'm not sure if outerHTML was an IE4 or IE5 feature, but that's not the point) |
| 12:03 | <roc> | that works OK when the non-prefixed feature was introduced with reasonable behavior |
| 12:03 | <roc> | it doesn't work so well when the non-prefixed feature is introduced with utterly broken behavior |
| 12:04 | <zcorpan> | like drag and drop? |
| 12:04 | <roc> | hmm yeah |
| 12:04 | <roc> | and contenteditable |
| 12:05 | <roc> | and the entire CSS box model, basically |
| 12:05 | <roc> | we pay for that one by writing <!DOCTYPE HTML> until the end of time |
| 12:06 | <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 |
| 12:06 | <roc> | you should ask dbaron if he thinks the behavior differences warrant the prefixing |
| 12:07 | <hsivonen> | roc: in retrospect, we should have made IE's box model the default and used box-sizing to opt into the different behavior |
| 12:07 | <hsivonen> | roc: same thing for <img> and line height |
| 12:07 | <roc> | that's probably true |
| 12:08 | <roc> | however, there was a lot of other brokenness there |
| 12:09 | <zcorpan> | we could have made the brokeness the compliant behavior like with the html parser |
| 12:09 | <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" |
| 12:10 | <roc> | zcorpan: reverse engineering hasLayout and all the rest of the IE brokenness is not something anyone has ever wanted to do |
| 12:10 | <zcorpan> | roc: other browsers don't have hasLayout in quirks mode |
| 12:10 | <roc> | yeah |
| 12:10 | <roc> | browsers don't interoperate in quirks mode |
| 12:11 | <roc> | to make quirks mode the compliant behavior, we'd have to fix that |
| 12:11 | <hsivonen> | roc: don't Gecko/WebKit/Presto interop remarkably far in quirks mode, though? |
| 12:11 | <hsivonen> | even if IE is totally different |
| 12:11 | <roc> | I honestly don't know |
| 12:11 | <annevk> | it's getting closer and closer afaik |
| 12:12 | <roc> | IE being totally different is enough to sink the proposition |
| 12:12 | <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? |
| 12:12 | <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 |
| 12:12 | <annevk> | having quirks mode interop between non-IE browsers is still worth it |
| 12:12 | <hsivonen> | I should find access to a Mango phone and do some community service |
| 12:12 | <annevk> | roc: yeah that's definitely part of it |
| 12:13 | <annevk> | roc: but we also take quirks mode into account now, e.g. for the HTML parser |
| 12:13 | <roc> | we recently eliminated the difference between quirks mode and standards mode text decorations |
| 12:15 | <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? |
| 12:15 | <roc> | I'm not confident they all will |
| 12:15 | <hsivonen> | roc: depends on the magnitude of changes and the amount of existing content |
| 12:16 | <roc> | yes |
| 12:16 | <hsivonen> | roc: I think requestAnimationFrame could be unprefixed immediately and the second argument or the return value be bikeshedded later |
| 12:16 | <roc> | yeah |
| 12:17 | <jgraham> | FWIW opera frequently gets screwed over by prefixes |
| 12:17 | <roc> | we should do more to ship the subset of commonly-agreed behavior quickly without prefix |
| 12:17 | <jgraham> | Where people write -webkit-foo and -moz-foo but forget -o-foo |
| 12:17 | <roc> | on mobile, everyone who's not Webkit gets screwed over by prefixes |
| 12:17 | <jgraham> | So it looks like we don't support cool stuff that we do |
| 12:17 | <hsivonen> | jgraham: Firefox for Android suffers from -webkit- |
| 12:18 | <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 |
| 12:19 | <hsivonen> | the only beneficiary of the situation is WebKit, ATM |
| 12:19 | <hsivonen> | I should blog about this, but I want to get HTML in XHR ready for review first |
| 12:20 | <jgraham> | I should remember to see if that's correlated with who is pro "prefixes until CR or later" next time this comes up |
| 12:20 | <hsivonen> | "CR or later" is hurting the Web |
| 12:22 | <jgraham> | Yeah, the current situation is insane |
| 12:24 | <roc> | hsivonen: I look forward to that blog post! |
| 12:26 | annevk | read CR and was thinking CRLF |
| 12:26 | <Ms2ger> | annevk, obviously that's the only useful expansion :) |
| 12:29 | <Taggnostr> | hsivonen, the other day I was looking for some html5 test cases and I found your thesis/website |
| 12:34 | <hsivonen> | Taggnostr: did you find the test cases you were looking for? |
| 12:35 | <hsivonen> | annevk: CR in the CRLF sense is hurting the Web, too |
| 12:35 | <Taggnostr> | hsivonen, nope, but I found the description of the parsing algorithm in the html5 draft |
| 12:35 | <Taggnostr> | I'm working on a parser and I was trying to determine how it should handle broken html |
| 12:36 | <hsivonen> | Taggnostr: "just" implement the parsing algorithm |
| 12:36 | <hsivonen> | Taggnostr: what programming language are you using? |
| 12:37 | <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 |
| 12:37 | <hsivonen> | Taggnostr: are you aware of https://code.google.com/p/html5lib/ ? |
| 12:38 | <Taggnostr> | yes, I actually found this channel while looking at that page |
| 12:38 | <jgraham> | Taggnostr: (please look at HEAD, not at the lat release) |
| 12:38 | <jgraham> | *last |
| 12:38 | <Taggnostr> | but including a new module in the stdlib is not easy, so I was trying to fix the existing one |
| 12:40 | <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 |
| 12:41 | <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 |
| 12:41 | <jgraham> | Also, strictly speaking, a SAX-style API doesn't work with HTML |
| 12:41 | <zcorpan> | parsing html is complicated |
| 12:42 | <jgraham> | Since various things alter the parts of the tree that have already been emitted |
| 12:42 | <jgraham> | e.g. <table><div> |
| 12:42 | <zcorpan> | you can have non-streaming SAX or fatal SAX |
| 12:42 | <jgraham> | or <body a=b><body c=d> |
| 12:43 | <jgraham> | The HTMLParser model doesn't have any extensions to allow fixup of the existing tree |
| 12:43 | <jgraham> | and I presume fatal SAX would not be regarded as useful |
| 12:43 | <hsivonen> | jgraham: XML folks love fatal SAX :-) |
| 12:44 | <hsivonen> | jgraham: maybe not that useful for HTML, though |
| 12:44 | <jgraham> | hsivonen: Yes well. Look how that turned out |
| 12:45 | <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 |
| 12:45 | <hsivonen> | jgraham: Validator.nu uses fatal SAX for HTML |
| 12:45 | <hsivonen> | Taggnostr: coming up with ways to parse HTML that aren't the HTML5 algorithm is a terrible idea |
| 12:46 | <wilhelm> | I've heard regular expressions are great for parsing HTML. |
| 12:46 | <Taggnostr> | that's already the current situation, the idea is to make the algorithm closer to HTML5 |
| 12:50 | <jgraham> | wilhelm: In the interests of playing nice with the visitor, I will loan you my sarcasm end tag: </sarcasm> |
| 12:50 | <wilhelm> | jgraham: Oh, sorry. Thanks. (c: |
| 12:51 | <jgraham> | Taggnostr: There is little point is being "close to" HTML 5 when you could just do what the standard says |
| 12:51 | <Taggnostr> | I'm not sure if that's doable though, the parser should be backward-compatible |
| 12:52 | <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 |
| 12:52 | <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 |
| 12:54 | <jgraham> | Taggnostr: Well it wouldn't since HTML isn't streamable in general |
| 12:54 | <Ms2ger> | MikeSmith, thanks |
| 12:55 | <jgraham> | (without some representation of tree fixup in the stream) |
| 12:55 | <jgraham> | You can do what hsivonen does and die at the first non-streamable error |
| 12:55 | <jgraham> | But there are a pile of sites where that will break |
| 12:55 | <Taggnostr> | what do you mean exactly with streamable? |
| 12:57 | <Ms2ger> | <table>Foo |
| 12:57 | <Ms2ger> | That'll return a tree with the Foo text node before the table |
| 12:57 | <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 |
| 12:58 | <zcorpan> | you could extend SAX with fixup events |
| 12:58 | <hsivonen> | Taggnostr: the Validator.nu parser supports all of HTML with the SAX API by first buffering everything into a tree model |
| 12:58 | <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 |
| 12:59 | <jgraham> | But it is only half the work (or less) of actually parsing |
| 12:59 | <Taggnostr> | yes, it doesn't balance anything |
| 13:00 | <jgraham> | Oh, well in that case look at the tokenizer.py code in html5lib |
| 13:00 | <Taggnostr> | in that case it will announce a <table> start tag, and then Foo |
| 13:00 | <Taggnostr> | that's where I looked :) |
| 13:01 | <jgraham> | It does almost what you want but you will need to add an interface that emits HTMLParser-compatible events |
| 13:01 | <Taggnostr> | is there a reference implementation of the parser described by HTML5? |
| 13:01 | <jgraham> | No |
| 13:02 | <Taggnostr> | so they just wrote down the algorithm without having a real implementation and without testing it? |
| 13:02 | <jgraham> | But html5lib, Gecko (+validator.nu), Webkit and Presto all have implementations that are knopwn to be close to spec |
| 13:02 | <jgraham> | Taggnostr: "they" == "we" and no |
| 13:03 | <hsivonen> | Taggnostr: it has had plenty of testing |
| 13:03 | <jgraham> | The algorithm was arrived at by careful study of what browsers did |
| 13:03 | <jgraham> | Plus feedback from browser vendors when they broke pages |
| 13:03 | <jgraham> | Plus inspiration for how to fix difficult problems in an acceptable way |
| 13:04 | <jgraham> | (misnested formatting elements, parsing comments in scripts) |
| 13:04 | <Taggnostr> | so it wasn't written from scratch |
| 13:04 | <jgraham> | That depends what you mean |
| 13:04 | <jgraham> | Hixie didn't fabricate it from unicorn horn and pony hair |
| 13:05 | <jgraham> | But no one had ever written it down before |
| 13:05 | <jgraham> | And it isn't quite like what any one browser had before |
| 13:05 | <Taggnostr> | ok |
| 13:07 | <zcorpan> | jgraham: that's one of the more hilarious statements i've seen about the parsing algorithm |
| 13:11 | <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. |
| 13:12 | <Ms2ger> | 4? |
| 13:13 | <gsnedders> | html5lib, Gecko, WebKit, Presto. |
| 13:13 | <hsivonen> | gsnedders: WebKit isn't compliant |
| 13:14 | <hsivonen> | David Flanagan's parser is probably more compliant than WebKit by now |
| 13:15 | <hsivonen> | I wonder how compliant IE10 is |
| 13:15 | <gsnedders> | Last I heard not massively |
| 13:17 | <zcorpan> | what does webkit do wrong? |
| 13:17 | <hsivonen> | zcorpan: MathML stuff at least |
| 13:18 | <hsivonen> | zcorpan: generally anything that has been fixed in the spec since the Chrome 8 release train left the station |
| 13:18 | <zcorpan> | ok |
| 13:20 | Philip` | wonders if anyone pointed Taggnostr at http://code.google.com/p/html5lib/source/browse/#hg%2Ftestdata%2Ftokenizer yet |
| 13:23 | <Taggnostr> | I wonder if those are usable with HTMLParser (assuming that the license allows me to use them) |
| 13:24 | <gsnedders> | HTMLParser? |
| 13:24 | <jgraham> | Taggnostr: MIT license |
| 13:24 | <Philip`> | (http://wiki.whatwg.org/wiki/Parser_tests for documentation) |
| 13:24 | <Taggnostr> | thanks for the pointers Philip` |
| 13:25 | <Taggnostr> | jgraham, did you write those tests? |
| 13:25 | <Taggnostr> | gsnedders, the parser I'm working on |
| 13:25 | <gsnedders> | Taggnostr: They're written by many different people |
| 13:25 | <Philip`> | I think they're used by all HTML5 parser implementations |
| 13:26 | <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) |
| 13:28 | <gsnedders> | (or have all failed to update their impls to some spec change) |
| 13:54 | <karlcow> | http://twitter.com/fraunhoferfokus/status/134983678513254402 |
| 13:54 | <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 |
| 13:59 | <Philip`> | Like a new codec, so half the world can standardise on that one while the other half standardises on WebM? |
| 14:00 | <Workshiva> | 10% discount on h264 licenses |
| 14:29 | <Ms2ger> | Hmm, sicking doesn't realize that public-html is a politics-only list? |
| 14:37 | <jgraham> | What did he post there? |
| 14:38 | <Ms2ger> | http://lists.w3.org/Archives/Public/www-archive/2011Nov/0021.html |
| 14:42 | <annevk> | man |
| 14:42 | <annevk> | why is Steam for the Mac such a disaster |
| 14:42 | <annevk> | I only wanted to play Portal |
| 14:44 | <Philip`> | Is it not just equivalent to the Windows version? |
| 14:45 | <Workshiva> | s/Steam/any port/ |
| 14:47 | <jgraham> | Ms2ger: You may say he's a dreamer but... well actually I guess he is the only one in this case. Nevermind. |
| 14:47 | <Ms2ger> | jgraham++ |
| 14:59 | <annevk> | getting portal for the xbox might be less of a hassle |
| 15:02 | <Philip`> | Depending on how much of a hassle it is, running it in Wine might be less of a hassle |
| 15:02 | <hsivonen> | eww. IE blog has ugly URLs |
| 15:04 | <hsivonen> | oh. it's HTTPS Everywhere that makes IE blog URLs ugly |
| 15:10 | <hsivonen> | Does someone happen to know who came up with vendor prefixes and when? |
| 15:11 | <annevk> | maybe around the same time standards mode happened? |
| 15:13 | <hsivonen> | Did IE5 for Mac have vendor-prefixed stuff? |
| 15:14 | <gsnedders> | Certainly most of it's CSS3 support wasn't |
| 15:15 | <annevk> | at least as far as CSS 2 was concerned it was post 98 |
| 15:15 | <hsivonen> | did the CSS positioning fiasco start this all? |
| 15:16 | <annevk> | http://lists.w3.org/Archives/Member/w3c-css-wg/1998OctDec/0008.html seems to be about where it started |
| 15:17 | <annevk> | (W3C Member-only) |
| 15:18 | <hsivonen> | whoa. Do we have [redacted] to blame about this *too*? |
| 15:19 | <Ms2ger> | [Redacted]. |
| 15:19 | <annevk> | http://www.w3.org/Style/Group/1998/09/f2f.html (W3C Member-only) |
| 15:20 | <Philip`> | Yeah, [redacted] is certainly a [redacted] |
| 15:20 | <gsnedders> | hsivonen: Very much positioned for non-specified properties, though, not for draft-standards. |
| 15:21 | <annevk> | http://lists.w3.org/Archives/Member/w3c-css-wg/1998JulSep/0298.html is also relevant |
| 15:21 | <annevk> | also has the winning notation |
| 15:22 | <hsivonen> | annevk: thanks |
| 15:23 | <gsnedders> | Up to 3k unread emails on whatwg. Time to give up soon? |
| 15:25 | <jgraham> | http://www.w3.org/Style/Group/1998/09/f2f.html |
| 15:25 | <jgraham> | Oh yo0u posted that |
| 15:25 | <zewt> | trying to explain the difference between opengl prefixing and web prefixing to the webgl guys seems like a futile effort |
| 15:26 | <hsivonen> | wow. important problems were foreseen when this mess started |
| 15:32 | Philip` | isn't sure what OpenGL prefixing is |
| 15:32 | <Philip`> | Don't they normally do suffixing (with _ARB/_EXT etc)? |
| 15:33 | <zewt> | vendor prefixing, GL_NV_*, GL_ATI_, etc |
| 15:34 | <zewt> | but it's not used the same as web prefixing |
| 15:37 | <zewt> | (for extensions I mean, functions and constants are suffixed) |
| 15:39 | <Philip`> | I suppose one main difference is that it's normal for a vendor to implement extensions from competing vendors' namespaces |
| 15:40 | <zewt> | that's what brought it up, yeah, though there are other differences |
| 15:40 | <Philip`> | (NVIDIA implements GL_ATI_texture_float, AMD implements GL_NV_primitive_restart, etc) |
| 15:41 | Philip` | wonders if it's considered bad etiquette to write code using a reverse-engineered undocumented GL extension |
| 15:43 | <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 |
| 15:43 | <zewt> | far more inherently hardware-specific extensions with opengl, different development processes with opengl, etc |
| 15:45 | <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? |
| 15:45 | <zewt> | common but minority |
| 15:46 | <Philip`> | Ah |
| 15:46 | <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 |
| 15:46 | <annevk> | well well |
| 15:47 | <annevk> | Xbox finally updated |
| 15:47 | <annevk> | maybe I get to play a game today after all |
| 15:47 | <zewt> | they decided to dodge the issue by abruptly promoting the extension out of _WEBKIT |
| 15:47 | <jgraham> | Now it will explode |
| 15:50 | <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 |
| 15:50 | <zewt> | oh well. heh |
| 15:52 | <hsivonen> | oh so the SVG WG has gone from being vehemently against SVG in HTML to wanting to put SVG in the HTML namespace |
| 15:52 | <dglazkov> | good morning, Whatwg! |
| 15:52 | <hsivonen> | dglazkov: good evening |
| 15:53 | <Ms2ger> | 'Afternoon |
| 15:53 | <shepazu> | hsivonen: we were never against putting SVG in HTML, we lobbied for it... |
| 15:53 | <hsivonen> | shepazu: oh yes, you (SVG WG, maybe not you personall) were at Mandelieu TPAC |
| 15:54 | <shepazu> | hsivonen: I think you're misremembering |
| 15:55 | <shepazu> | we always wanted to have SVG in HTML… the devil of how to do that was in the details |
| 15:56 | <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 |
| 15:56 | <shepazu> | and conditions have now changed, so we are adapting to what seems like the best way forward is from where we are now |
| 15:56 | <shepazu> | hsivonen: that's a detail |
| 15:56 | <hsivonen> | shepazu: I disagree about it being a detail |
| 15:57 | <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 |
| 15:58 | <hsivonen> | shepazu: I'd much rather see Web authors start using SVG now than scare them off for another 5 years or so |
| 15:58 | <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 |
| 15:58 | <shepazu> | hsivonen: I don't think there is unanimity in the SVG WG about what namespace SVG elements would be in |
| 15:59 | <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 |
| 15:59 | <shepazu> | yup |
| 16:02 | <jgraham> | It is not clear to me that there is enough legacy here to make it too late to break |
| 16:02 | <jgraham> | I don't know what IE9 does |
| 16:02 | <jgraham> | But it is not very HTML5 compliant in general, so it doesn't obviously block this change |
| 16:03 | <hsivonen> | jgraham: IE9 tokenizes SVG scripts per HTML5 for practical purposes (there may be edge cases that are different) |
| 16:04 | <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 |
| 16:05 | <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 |
| 16:05 | <jgraham> | I wouldn't be surprised to see a pattern like that |
| 16:06 | <jgraham> | Also, I'm not entirely sure I understand how much content would be affected in this case |
| 16:06 | <hsivonen> | we can't break interop every time we reach interop depending on the current politics at the SVG WG |
| 16:06 | <hsivonen> | if we want adoption some day |
| 16:06 | <jgraham> | Agreed |
| 16:07 | <jgraham> | But that doesn't mean that doing it once is unworkable |
| 16:07 | <hsivonen> | jgraham: are you talking about style and script tokenization or about putting SVG elements in the HTML namespace? |
| 16:11 | <jgraham> | The first. The second seems like a very nice change but much more worrying compat-wise |
| 16:12 | <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. |
| 16:13 | <Ms2ger> | "Boat anchor browser" is a nice term |
| 16:16 | <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? |
| 16:17 | <annevk> | dictionaries are not exposed |
| 16:18 | <TabAtkins_> | I was pretty sure that *someone* did what I just asked for. |
| 16:23 | <Ms2ger> | WebRTC hasn't figured out dicts yet |
| 16:35 | <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 |
| 16:36 | <zewt> | i suppose exposing the defaults isn't terribly important, though, so much as just which keys are understood |
| 16:39 | <TabAtkins_> | zewt: Yeah, that's the primary benefit. Exposing defaults is a lucky accident. |
| 16:40 | <zewt> | TabAtkins: but the defaults aren't always in the IDL dictionary |
| 16:40 | <zewt> | (ever, now? not sure) |
| 17:21 | <AryehGregor> | jgraham, IE9 works on Vista and IE10 doesn't, no? Of course, maybe there aren't enough people using Vista to matter. |
| 18:12 | <jgraham> | AryehGregor: Maybe. I was thinking of XP vs others and enterprise vs sane |
| 18:12 | <AryehGregor> | Maybe. |
| 18:16 | <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 |
| 18:44 | <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) |
| 18:45 | <sicking> | smaug____: it's been shipping for a while in various browsers, but quite possibly yeah |
| 18:45 | <jamesr_> | ooo |
| 18:48 | smaug____ | files a spec bug |
| 18:49 | <smaug____> | jamesr_: do you think webkit would be willing to make such change? |
| 18:50 | <jamesr_> | smaug____, as a way to encourage authors to move away from sync, right? |
| 18:50 | <smaug____> | yes |
| 18:50 | <smaug____> | sync is bad in the UI thread |
| 18:50 | <jamesr_> | i personally think it's a great idea. i'm not sure what our implementation status |
| 18:50 | <jamesr_> | yeah sync is the worst |
| 18:50 | <smaug____> | unfortunately it is used quite ofter for text and xml responses |
| 18:51 | <jamesr_> | i know :( |
| 18:51 | <smaug____> | Google Docs was using it allover at some point |
| 18:51 | <jamesr_> | hell yeah let's do it |
| 18:52 | <jamesr_> | smaug____, do you have a mozilla bug i can cite in the webkit bug report? |
| 18:52 | <jgraham> | "if the sync flag is true throw ERR_YOURE_DOING_IT_WRONG" |
| 18:52 | <Ms2ger> | COME_ON_ERR? |
| 18:53 | <smaug____> | jamesr_: not yet |
| 18:53 | <smaug____> | I'm just sending email to webapps |
| 18:53 | <smaug____> | XHR2 doesn't seem to have bugzilla component |
| 18:54 | <Ms2ger> | There's just one for XHR1 and 2, no? |
| 18:54 | <jamesr_> | filed https://bugs.webkit.org/show_bug.cgi?id=72154 (partially as a way to solicit feedback from other WebKit devs) |
| 18:55 | <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 |
| 18:55 | <jamesr_> | but i love the idea |
| 18:55 | <smaug____> | Ms2ger: I couldn't find any component |
| 18:55 | <smaug____> | perhaps just looked at some wrong place |
| 18:56 | <smaug____> | Ms2ger: er, now I see it |
| 18:56 | <smaug____> | XHR1 and XHR2 |
| 18:56 | <Ms2ger> | Good :) |
| 19:03 | <smaug____> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=14773 https://bugzilla.mozilla.org/show_bug.cgi?id=701787 |
| 19:29 | <smaug____> | hmm, XHR doesn't really define how responseText and responseXML map to each other while loading |
| 19:29 | <smaug____> | I mean, does something require that parsing needs to be synchronous or not |
| 20:23 | <zewt> | personally i think any use of window-synchronous xhr should force the page to comic sans |
| 21:19 | <jamesr_> | sicking, on the .findAll() thread i missed why the return type needs something in addition to Array.prototype on the prototype chain |
| 21:20 | <jamesr_> | what would go on [some type].prototype ? |
| 21:21 | <sicking> | jamesr_: See point to in the goals list in the beginning of the mail |
| 21:21 | <TabAtkins> | jamesr_: .findAll again, for example. |
| 21:22 | <sicking> | jamesr_: it's a future extension point so that we can hang things at it later |
| 21:23 | <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 |
| 21:23 | <sicking> | jamesr_: jquery has a host of functions on their equivalent of NodeArray, many of these would make sense on NodeArray too |
| 21:23 | <TabAtkins> | It has basically the entire Element API on their nodelists. |
| 21:24 | <TabAtkins> | Which is super-useful. |
| 21:25 | <sicking> | document.findAll(...).addEventListener would be neat |
| 21:25 | <jamesr_> | that operates on each element in the array? |
| 21:25 | <sicking> | yes |
| 21:25 | <_bga> | :( |
| 21:26 | <_bga> | dont invent jq again |
| 21:26 | <_bga> | plz |
| 21:26 | <TabAtkins> | Sorry, _bga, but you're wrong. jQuery's interface is *really* useful. |
| 21:26 | <_bga> | doc.findAll(...).forEach(...) |
| 21:27 | <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. |
| 21:27 | <sicking> | _bga: the fact that jQuery is seeing so much use is a pretty good indication that it's doing something right |
| 21:29 | <_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 |
| 21:30 | <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. |
| 21:32 | <dglazkov> | sicking: that smells like a language thing to me: |
| 21:33 | <sicking> | dglazkov: what does? |
| 21:33 | <TabAtkins> | dglazkov: Lifting functions over an array is something the language can make easier, but it doesn't always go far enough. |
| 21:33 | <TabAtkins> | Like with the el.findAll().findAll() example. |
| 21:33 | <dglazkov> | sicking: document.findAll(..)..->addEventListener or something... |
| 21:34 | <sicking> | dglazkov: you mean the ability to apply a function call to all elements in an array? |
| 21:34 | <dglazkov> | sicking: yah |
| 21:34 | <sicking> | they already have that as a library, but the syntax is clunky |
| 21:35 | <sicking> | array.map(function(e) { e.doStuff(...) }); |
| 21:35 | <dglazkov> | yup |
| 21:35 | <sicking> | possibly lambda expressions will help |
| 21:35 | <TabAtkins> | lift(doStuff)(array) |
| 21:35 | <TabAtkins> | Damn focus on methods and 'this' makes that hard. |
| 21:36 | <sicking> | right |
| 21:36 | <_bga> | i had els._do('addEventListener', [_fn, false]) |
| 21:36 | TabAtkins | wishes once again that he could just program lisp in the browser... |
| 21:36 | <dglazkov> | array/:=(addEvenListener |
| 21:36 | <_bga> | * els._do('addEventListener', [type, _fn, false]) |
| 21:36 | <dglazkov> | a sad hitler shorthand |
| 21:39 | <_bga> | TabAtkins anyway you(whole committee) must populate widget model, not jq spagetti code |
| 21:39 | TabAtkins | can't parse that sentence. |
| 21:39 | <_bga> | sorry |
| 21:39 | <sicking> | _bga: well.. first step is to come up with a concrete proposal |
| 21:40 | <sicking> | _bga: once you have that we can talk :) |
| 21:40 | <sicking> | _bga: next step would be to TC39 and pitch it |
| 21:40 | sicking | is about to pitch weak references to TC39 |
| 21:41 | <TabAtkins> | sicking: Like, right now? |
| 21:41 | <sicking> | TabAtkins: no, need to do a couple of more rounds through dhermans brain |
| 21:41 | <TabAtkins> | Oh, okay. Wasn't sure how immediate the "about" was. |
| 21:41 | <sicking> | TabAtkins: but the first round went better than other things I've pitched him |
| 21:44 | <TabAtkins> | The current thing I'm most excited about is private Names and decoupling . and [] semantics. |
| 21:46 | <_bga> | TC39 has wrong way imho. i stopped reading mailing list half year ago |
| 21:47 | <hsivonen> | smaug____: parsing in XHR does not need to be synchronous. responseXML isn't available until parsing has ended. |
| 21:54 | <smaug____> | hsivonen: ah |
| 21:55 | <hsivonen> | smaug____: however, I did intentionally stall progress events until the charset is known, because responseText is supposed to accumulate during progress events |
| 21:55 | <smaug____> | yeah, that is ok-ish |
| 21:56 | <smaug____> | at least I don't have any better solution |
| 21:56 | <hsivonen> | smaug____: I have an alternative solution, but I don't want to bother unless Web compat requires |
| 21:57 | <hsivonen> | smaug____: the alternative is to expose stuff in the ASCII range in responseText before the encoding has been decided |
| 21:57 | <dglazkov> | arv: did you see the conversation about a lifting shorthand in JS? |
| 21:57 | <hsivonen> | i.e. start stalling at the first non-ASCII character |
| 21:58 | <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 |
| 21:58 | <arv> | dglazkov: lifting shorthand? |
| 21:58 | <dglazkov> | arv: to provide jquery-like lift facilities in the language |
| 21:58 | <smaug____> | hsivonen: I agree |
| 21:58 | <arv> | dglazkov: reading irc backlog now |
| 21:59 | <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 |
| 21:59 | <dglazkov> | arv: I remember you mentioning something about this |
| 21:59 | <hsivonen> | smaug____: that is, XHR users expecting HTTP text/html 404 or other error pages to give null responseXML |
| 21:59 | <smaug____> | yeah |
| 21:59 | <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 |
| 22:00 | <smaug____> | hsivonen: could we not give responseXML at all for text/html documents |
| 22:00 | <smaug____> | only response |
| 22:00 | <hsivonen> | smaug____: if it becomes a problem, we could only give responseXML when the status code is 2xx |
| 22:01 | <smaug____> | but why do we need to give HTML document from responseXML |
| 22:01 | <smaug____> | responseXML is legacy |
| 22:01 | <hsivonen> | smaug____: responseXML is the way you obtain a Document from XHR |
| 22:02 | <hsivonen> | smaug____: but yeah, if it becomes a problem, we could limit availability to the xhr.response |
| 22:02 | <smaug____> | hsivonen: you can get document using .response |
| 22:03 | <smaug____> | so, is there any reason to get document from responseXML |
| 22:03 | <hsivonen> | smaug____: I was following the spec |
| 22:03 | <smaug____> | right |
| 22:03 | <arv> | TabAtkins: Like this: http://traceur-compiler.googlecode.com/svn/trunk/example/collection.html |
| 22:03 | <smaug____> | the spec is possibly wrong |
| 22:04 | <smaug____> | (specs are always wrong :p ) |
| 22:04 | <hsivonen> | smaug____: to me, it seems logical to offer the document via responseXML |
| 22:04 | <arv> | dglazkov: ES6 will have real iterators and a for-of loop for them |
| 22:04 | <smaug____> | even if the document has nothing to do with XML? |
| 22:04 | <TabAtkins> | arv: Yeah. |
| 22:04 | <hsivonen> | smaug____: I suggest we try to find out if offering it via resposeXML breaks the Web |
| 22:04 | <hsivonen> | smaug____: we have innerHTML on XML docs |
| 22:05 | <arv> | dglazkov: Me and Jacob talked about .{ for chaining. es-discuss didn't like it much though |
| 22:05 | <smaug____> | hsivonen: and that is unfortunate, but too late to fix |
| 22:05 | <TabAtkins> | arv: What does that do, run the block on the list or something? |
| 22:05 | <dglazkov> | arv: nifty demo! |
| 22:05 | <TabAtkins> | Or is that the "set multiple properties as an expression" thing? |
| 22:06 | dglazkov | slaps es-discuss with a trout |
| 22:06 | <arv> | TabAtkins: expr.{a: b, c: d} desugars to something like $tmp = expr; tmp.a = b; $tmp.c = d |
| 22:06 | <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 |
| 22:06 | <TabAtkins> | Yeah, what I thought. Not sure how that's relevant to what we were talking about, though. |
| 22:06 | <arv> | TabAtkins: very much like css hierarchies |
| 22:07 | <hsivonen> | smaug____: if bad stuff happens, let's make spec change suggestions |
| 22:07 | <smaug____> | hsivonen: we can do that |
| 22:07 | <smaug____> | hsivonen: and removing the support for .responseXML is easy |
| 22:07 | <TabAtkins> | arv: We're talking about things like el.findAll().remove() or whatnot. |
| 22:08 | <smaug____> | I probably would want responseText and responseXML to support only legacy types |
| 22:08 | <smaug____> | (only those types which should be allowed to be used with sync XHR) |
| 22:09 | <arv> | TabAtkins: It allows chaining... https://mail.mozilla.org/pipermail/es-discuss/2011-November/018268.html |
| 22:09 | <arv> | TabAtkins: without restructuring the whole API to use methods that return THE jQuery obejct |
| 22:11 | <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 |
| 22:11 | <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 |
| 22:12 | <smaug____> | hsivonen: what releases the listener? |
| 22:12 | <TabAtkins> | arv: I see. It's using a slightly different syntax between the {} to allow method calls. |
| 22:12 | <hsivonen> | smaug____: whoa. I'm not sure. |
| 22:13 | <arv> | TabAtkins: This is kind of pushing the limits of syntax and some people really dislike this direction |
| 22:13 | <hsivonen> | smaug____: I need to take a better look at your comments at daytime |
| 22:13 | <smaug____> | k |
| 22:13 | <TabAtkins> | arv: I can see why. ^_^ |
| 22:14 | <TabAtkins> | Definitely a bit difficult to read. |
| 22:16 | smaug_____ | kicks this 3G connection |
| 22:19 | <arv> | TabAtkins: no harder than jquery =P I also find the closing curly brace a lot cleaner than jquery's begin(). ... .end() |
| 22:19 | <TabAtkins> | Agree on that last point. |
| 22:32 | <dglazkov> | TabAtkins: where's a good summary of the latest and greatest on CSS variables? |
| 22:32 | <dglazkov> | TabAtkins: "in my head" is an acceptable answer |
| 22:32 | <TabAtkins> | http://dev.w3.org/csswg/css-variables |
| 22:41 | <dglazkov> | TabAtkins: this is gorgeous |
| 22:43 | <TabAtkins> | Damn, if you remove all the examples, the whole useful part of the spec is *just* over two screenfuls. |
| 22:44 | <sicking> | TabAtkins: had you been involved in the accessibility-for-canvas API? |
| 22:44 | <dglazkov> | I thought exmaples_were_ the useful part :) |
| 22:44 | <sicking> | TabAtkins: i think someone said you had been present during those discussions at tpac? |
| 22:44 | <TabAtkins> | sicking: Only in shouting for use-cases. |
| 22:44 | <TabAtkins> | No, I was not in the tpac discussions. |
| 22:45 | <TabAtkins> | Though my spirit may have been hovering in the room. |
| 22:45 | <TabAtkins> | Glooming at everyone. |
| 22:45 | <sicking> | hah |
| 22:46 | <dglazkov> | accessibility for ALL the canvases! |
| 22:46 | <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 |
| 22:46 | <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 |
| 22:47 | <TabAtkins> | I agree. |
| 22:47 | <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 |
| 22:48 | <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 |
| 22:48 | <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 |
| 22:48 | <sicking> | smaug____: so it's just too inconvenient |
| 22:49 | <sicking> | smaug____: additionally, there is no way to associate an element with a particular image-map area |
| 22:49 | <sicking> | TabAtkins: but working based on examples of how people use canvas today is definitely a good idea |
| 22:50 | <smaug____> | sicking: I don't quite buy that all. Something new could be added to maps |
| 22:50 | <smaug____> | but, as I said, I'm not really familiar with a11y+canvas |
| 22:52 | <TabAtkins> | sicking: I have no problem with designing some a11y apis into canvas. My problem is designing things in such a way that authors have to go to extra lengths to use them (because most won't), or designing in the absence of use-cases since that almost always results in solving non-problems or solving real problems wrongly. |
| 22:53 | <TabAtkins> | a11y should be as automatic as possible, even if that means you don't get a perfect solution. |
| 22:54 | <Hixie> | sicking: i wish the people asking for "making canvas accessible" would in fact do as you say and start with real uses of canvas |
| 22:55 | <Hixie> | sicking: currently they just hand-wave the use cases and then design things that would only make sense if you were doing something absurd and cockamamie like implementing a word processor in canvas or something |
| 22:56 | <sicking> | TabAtkins: definitely. My suggestion has been to create a API which builds hit-testing into canvas. Then we can use the hit-testing information to provide a11y |
| 22:56 | <Hixie> | fwiw, hit testing is on my list of things to add to canvas once we do path primitives |
| 22:57 | <Hixie> | which is high on my list to do within the next few momnths |
| 22:57 | <Hixie> | months |
| 22:57 | <sicking> | Hixie: the API i have suggested creates hit-testing without the need for path primitives |
| 22:57 | <zewt> | so far i've had to use HTML elements overlaid on top of a canvas for hit testing (clumsy and limited, but works) |
| 22:58 | <Hixie> | sicking: i think we should avoid adding new features to paths that we'd have to duplicate when we have path primitives, but i'm certainly open to suggestions. mail the list or file a bug. |
| 22:58 | <sicking> | Hixie: of course, i can't compare it to a proposal which does use path primitives until someone makes such a proposal ;-) |
| 22:58 | <sicking> | Hixie: done and done |
| 22:58 | <sicking> | Hixie: the bug is already on file and already links to my proposal |
| 22:58 | <Hixie> | cool |
| 22:58 | <Hixie> | url? |
| 22:59 | <sicking> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176 |
| 22:59 | <sicking> | http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0195.html |
| 22:59 | <Hixie> | ah man, don't use public-canvas-api |
| 22:59 | <Hixie> | who reads that |
| 22:59 | <sicking> | Hixie: dude, it's in the bug, you know how to find it |
| 23:00 | <Hixie> | sure, i'm just saying htat list is a bad place to send feedback in general |
| 23:01 | <Hixie> | yeah your proposal is basically what i had in mind, except i think we should just do it with Path objects instead of continuing to use the existing path stuff |
| 23:02 | <Hixie> | since everything we add to the existing path stuff will have to be duplicated when we add path primitives |
| 23:02 | <Hixie> | it's hard to say how good such a proposal would be for accessibility though |
| 23:03 | <Hixie> | oh actually no, your proposal isn't quite what i had in mind |
| 23:03 | <Hixie> | i missed that you were setting a "drawing mode" |
| 23:03 | <Hixie> | my idea was just to use the path to set the boundary rect |
| 23:03 | <Hixie> | s/rect/shape/ |
| 23:04 | <sicking> | my proposal is to make everything drawn why "setDrawingFor" forward clicks to the underlying element |
| 23:04 | <sicking> | that way people have incentive to use the API |
| 23:04 | <sicking> | the a11y is no longer bolt-on |
| 23:05 | <Hixie> | it's not clear to me that that helps a11y |
| 23:05 | <Hixie> | if the user can click, why does the element matter? |
| 23:06 | <sicking> | making a real connection between pixels and elements has many benefits |
| 23:06 | <sicking> | it means we know where to focus if you tab to said element |
| 23:06 | <Hixie> | to me it looks like this would just encourage people to have lots of empty <div>s in the canvas to use as event listeners |
| 23:06 | <Hixie> | we already have a solution to the focus ring problem |
| 23:07 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#dom-context-2d-drawsystemfocusring |
| 23:07 | <sicking> | one that anyone is using? |
| 23:07 | <sicking> | or implementing? |
| 23:07 | <sicking> | or has expressed like for? |
| 23:07 | <Hixie> | implementors from gecko, opera, and webkit have said they like what the whatwg spec has as far as that goes |
| 23:07 | <Hixie> | in fact it was mostly designed by roc |
| 23:08 | <sicking> | i haven't really head any positive feedback about it |
| 23:08 | <Hixie> | the whatwg api or the richs api? |
| 23:08 | <sicking> | the whatwg API |
| 23:08 | <sicking> | i don't know what richs api is |
| 23:08 | <Hixie> | the richs api is the one in the w3c copy of hte canvas spec, that's self-contradictory |
| 23:09 | <Hixie> | the whatwg one, like i said, was designed mostly by roc, with input from people from opera and webkit who were all supportive at the time it was put in |
| 23:09 | <Hixie> | (iirc, i reached out to microsoft but got no reply) |
| 23:10 | <sicking> | ok |
| 23:10 | <sicking> | i guess your experience is different from mine |
| 23:10 | <Hixie> | well, nobody to my knowledge has implemented it |
| 23:10 | <Hixie> | so my experience doesn't mean much :-) |
| 23:11 | <Hixie> | i'm certainly happy to try other solutions that are more likely to get implemented, including linking focus rings with click regions |
| 23:12 | <sicking> | i haven't given a great deal of thought to focus rings, but it doesn't seem like what we currently have is solving a lot of the problem |
| 23:12 | <Hixie> | what we should do is list the actual concrete examples of usage of canvas that are not accessible, but that are valid sensible uses of canvas, and see what we need to do to make those better |
| 23:12 | <Hixie> | that would help us design solid solutions |
| 23:13 | <zewt> | fwiw, https://zewt.org/curves/ |
| 23:14 | <zewt> | control points created in the curve should really be tabbable (the actual clickable regions are done with HTML, which is a hack) |
| 23:14 | Philip` | has been doing some thing that uses canvas and hit-testing, but it was sufficiently trivial to just store a list of rectangle coordinates and test them manually on mousemove, and he wouldn't want to use the actual drawing paths for hit-testing because it's user-friendlier to give several pixels margin around them |
| 23:14 | <zewt> | (hasn't been updated with crossorigin so it'll only work opening local files) |
| 23:16 | <Hixie> | zewt's example is a perfect example of something where it's not at all clear to me how mapping the clickable regions to elements would make it more accessible |
| 23:17 | <Philip`> | With control-point movement you probably want to detect which point is closest to the mouse, rather than picking whichever is within the radius and happened to be drawn first/last |
| 23:17 | <zewt> | a couple other notable things here: the clickable region of the control points is larger than the points, and the mouse cursor is affected by what's hovered (it would be nice to be able to do that without muddling with the cursor by hand in mousemove/mouseover) |
| 23:17 | <Hixie> | Philip`: indeed |
| 23:18 | <Hixie> | zewt: sounds like a perfect thing for SVG :-) |
| 23:18 | <Hixie> | zewt: (at least the latter part) |
| 23:18 | <zewt> | Philip`: that doesn't matter much in this particular case, since control points can't be that close together (drag within a few pixels and it deletes the point) |
| 23:18 | <zewt> | but in other cases, yes |
| 23:19 | <Hixie> | http://wiki.whatwg.org/wiki/Canvas |
| 23:20 | <zewt> | Hixie: SVG doesn't help if I need 1 feature from SVG and 9 from Canvas, unless they integrate better than I'm aware |
| 23:20 | <zewt> | (eg. a way to create matching paths in SVG and Canvas, or something like that) |
| 23:20 | <Hixie> | what features do you need from canvas? |
| 23:21 | <zewt> | i havn't used SVG enough to know how to do this sort of thing in it |
| 23:21 | <Hixie> | as far as i'm aware, you can do all of this in svg |
| 23:21 | Philip` | likes the "easy-to-use API" feature |
| 23:22 | <Hixie> | can't argue with that |
| 23:23 | <sicking> | Hixie, zewt: In that example you'd call setDrawingFor before/after drawing the draggable markers |
| 23:23 | <Hixie> | no, you'd want the path for the hit zones to be bigger than the markers |
| 23:23 | <Hixie> | sicking: but what element would you forward the clicks to? |
| 23:24 | <sicking> | Hixie: Yeah, I've thought about adding a number argument for getting a bigger area around the drawn figure clickable |
| 23:24 | <sicking> | Hixie: you'd have to create "dummy" elements inside the canvas |
| 23:24 | <sicking> | Hixie: so how would you make that accessible? |
| 23:24 | <Hixie> | (imho best to just have an actual path and just say "within this path is the region") |
| 23:25 | <Hixie> | sicking: i don't know in what sense it is inaccessible |
| 23:25 | <sicking> | Hixie: yeah, you're not the first to suggest that. I'm open to that idea |
| 23:25 | <Hixie> | sicking: certainly a blind person can't use it, but there's not much we can do for them. So presumably we're talking about limited but not zero vision. |
| 23:25 | <zewt> | you can always draw a transparent larger clickable path around your visible part |
| 23:25 | <Hixie> | sicking: or maybe keyboard-only users? |
| 23:26 | <sicking> | Hixie: possibly, i'm not fully sure |
| 23:26 | <Hixie> | zewt: every drawing operation is a transparent area filling the whole canvas, so that doesn't really work :-) |
| 23:26 | <Hixie> | sicking: we can't design an API without knowing what we're trying to solve. |
| 23:26 | <zewt> | i mean, use the transparent path as the clickable part |
| 23:26 | <Hixie> | sicking: (despite what we may see others do) |
| 23:26 | <zewt> | for example, hovering near the path (not over a control point) changes the cursor to cross when you're close enough to click; that clickable region is invisible and complex (follows the curve) |
| 23:26 | <sicking> | Hixie: no, but doing nothing and waiting for the a11y community to come up with something hasn't been terribly successful either |
| 23:27 | <zewt> | (that's just done manually on mousemove, iirc) |
| 23:28 | <zewt> | would be a lot nicer to just draw a thicker invisible path around the line of the curve, give it a cursor style (somehow) and receive mousedown |
| 23:28 | <Hixie> | sicking: replacing one unsuccessful strategy with another is not a win :-) |
| 23:28 | <zewt> | afk |
| 23:28 | <Hixie> | sicking: or even an improvement |
| 23:29 | <Hixie> | sicking: when i get aroudn to this i intend to study what the problems actually are in some depth |
| 23:29 | <sicking> | Hixie: i think the "let's not do anything until we know exactly what to do" strategy is the worst possible strategy since it'll just result in others ignoring us and doing whatever they think is the best |
| 23:29 | <Hixie> | sicking: i didn't say "exactly" |
| 23:31 | <jernoble> | Hixie: more MediaController questions |
| 23:31 | <jernoble> | Hixie: "the playbackRate attribute … on setting, must set the MediaController's media controller playback rate to the new value, then queue a task to fire a simple event named ratechange at the MediaController." |
| 23:31 | <jernoble> | Hixie: Should it also set the playback rate of its slaved media elements? or is that implied? |
| 23:31 | <Hixie> | jernoble: the rates are multiplied -- search for "effective playback rate" |
| 23:32 | Philip` | 's current canvas use is http://zaynar.co.uk/0ad-pub/profiler4.png where every rectangle (including the ~1000 tiny narrow ones along the top) has a tooltip displayed on mouseover containing a load more data |
| 23:32 | <Hixie> | jernoble: actually they're no longer multiplied, the controller just overrides it |
| 23:32 | <jernoble> | Hixie: so it's implied that it directly affects the playback rate of the slaved media elements. |
| 23:32 | <jernoble> | Hixie: right, they're overriden. |
| 23:32 | <Hixie> | jernoble: not implied, it's very explicit |
| 23:33 | <Hixie> | Philip`: yeah, i don't see how a DOM can ever make that more accessible |
| 23:33 | <Hixie> | Philip`: but it would be good to have accessibility experts actually describe what the ideal accessible UI for that would be |
| 23:34 | <Hixie> | sicking: there's a world of difference betwene zero data (what we have now), some data sufficient to actually design a good API (what we need, and can easily obtain by speaking to people with experience in this space), and complete and full knowledge that would design an ideal API (which would take years to collect) |
| 23:34 | <Hixie> | sicking: i'm arguing for the second, not the third. |
| 23:34 | <jernoble> | Hixie: got it. thanks. |
| 23:34 | <Hixie> | sicking: and i plan to do the work to collect the data. |
| 23:34 | <Hixie> | jernoble: np |
| 23:34 | <Hixie> | sicking: (though if others want to help that would be fantastic) |
| 23:36 | <sicking> | Hixie: i haven't been operating with zero data. I've been operating with the examples of canvas that i've seen in the wild. Minus the ones that built an editor in canvas as they weren't good products anyway and would be too much work to make accessible, so we simply can't get good results |
| 23:37 | <Hixie> | sicking: can i convince you to list some of those examples on this wiki page? http://wiki.whatwg.org/wiki/Canvas |
| 23:37 | <Hixie> | sicking: or describe them by e-mail? |
| 23:37 | <sicking> | Hixie: unfortunately most of them i can't find any more :( |
| 23:37 | <Hixie> | sicking: even one would be a start |
| 23:38 | <Hixie> | so far i've added zewt's example |
| 23:38 | <sicking> | Hixie: i'll put some on the wiki |
| 23:38 | <Hixie> | cool, thanks |
| 23:38 | <Hixie> | that would be a huge help |
| 23:41 | <zewt> | looks like WebGL switched their WebGLContextEvent to a constructor, http://www.khronos.org/registry/webgl/specs/latest/#5.14 |
| 23:42 | smaug____ | should implement event ctors |
