| 00:28 | <marcosc_> | Hixie: regarding currentSrc, would it be enough to get a few +1 from vendors even if they are noncommittal? What would you like to see in particular? |
| 00:29 | <Hixie> | well for anything, what we need is "we're implementing this" |
| 00:30 | <Hixie> | since there's not much point speccing something they don't implement :-) |
| 00:53 | <marcosc_> | Hixie: understood. Who has made commitments on img@srset so far? |
| 00:53 | <TabAtkins> | I think we're implementing (webkit). |
| 00:54 | <marcosc_> | TabAtkins, ok cool. I'll see if I can find a bug number. |
| 00:54 | <marcosc_> | TabAtkins, if you know who I can ask about supporting img.currentSrc, that would be great. |
| 00:55 | <TabAtkins> | marcosc_: Dunno, sorry. :/ |
| 00:55 | <TabAtkins> | But poke around in #webkit? |
| 00:55 | <marcosc_> | ok, will do :) |
| 01:10 | <Hixie> | GPHemsley: if you're still around, one thing to check is a PNG that is sent with Content-Type: that is blank followed by a Content-Type that says text/html |
| 01:10 | <Hixie> | GPHemsley: seems some browsers don't handle that well |
| 01:11 | <GPHemsley> | Hixie: You mean, two Content-Type headers? |
| 01:11 | <Hixie> | yeah |
| 01:11 | <Hixie> | first one blank |
| 01:11 | <Hixie> | second one text/html |
| 01:11 | <Hixie> | data is a PNG |
| 01:12 | <Hixie> | someone here just pointed me to some internal file where chrome is doing bad things when that's loaded in an iframe |
| 01:12 | <GPHemsley> | oy |
| 01:12 | <GPHemsley> | what a convoluted situation |
| 01:12 | <GPHemsley> | according to the spec as it stands now, it's supposed to be treated as text/html, I believe |
| 01:12 | GPHemsley | checks |
| 01:13 | <GPHemsley> | Hixie: Yeah, according to the current draft of the spec, that will never be detected as a PNG. |
| 01:14 | <GPHemsley> | The spec treats the last Content-Type header as the supplied one |
| 01:15 | <GPHemsley> | and text/html is only checked to see whether it's a feed |
| 01:15 | <GPHemsley> | otherwise, it's treated as HTML |
| 01:24 | <GPHemsley> | I can't seem to get Apache to send an empty header |
| 01:25 | <GPHemsley> | but I can confirm that a PNG file sent as text/html is treated as HTML by Gecko |
| 01:26 | <kmbarnhart> | Hi, I'm working on the webvtt parser. Right now I'm writting test. |
| 01:28 | <GPHemsley> | (not even with PHP??) |
| 01:29 | <kmbarnhart> | I'm working on the cue settings. The syntax rules state that there can be no duplicates of a setting in a cue. However, the parser has to check and will process duplicate settings. Should I write tests to make sure duplicate settings are parsed, or leave duplicate settings as unknown behaviour. |
| 01:29 | <kmbarnhart> | Is there some sort of precedence, so I'm I best of writing to the mailing list. |
| 01:30 | <kmbarnhart> | *or not so |
| 01:30 | <kmbarnhart> | *am I no I'm |
| 01:30 | <Hixie> | GPHemsley: you'll probably have to test with a .asis or something |
| 01:30 | <Hixie> | GPHemsley: but yeah, i think different browsers get it different |
| 01:30 | <kmbarnhart> | Is there some sort of precedence, or am I best off writing to the mailing list. |
| 01:30 | <GPHemsley> | Hixie: Even PHP won't let me send multiple Content-Type headers... or at least, not an empty one |
| 01:31 | GPHemsley | sighs and wanders off to watch TV... |
| 01:33 | <doublec> | kmbarnhart: probably best to ask on the mailing list |
| 01:33 | <kmbarnhart> | Thank you |
| 01:34 | <zewt> | (the syntax rules say what authors should do, but that doesn't conflict with the parser rules telling implementations what to do) |
| 02:04 | <marcosc_> | Hixie, sorry. One last question: in the img@srcset spec it says that density is "a valid floating-point number giving a number greater than zero". However, in the parsing algorithm, there is no check positive floats so parsing srcset="foo -1.0x" still gives me a density of -1.0 for the candidate. Is that correct or am I missing something? |
| 03:30 | <Hixie> | marcosc: i think you're probably right. |
| 03:30 | <Hixie> | marcosc: probably works identically to 0x in practice (which is likely identical to 1x) |
| 06:28 | <zcorpan> | GPHemsley: didn't you get the memo? if you're trying to test weird http headers with apache, you're gonna have a bad time. |
| 06:29 | <zcorpan> | (asis might work) |
| 06:32 | <zcorpan> | kmbarnhart: dup settings is tested in http://w3c-test.org/html/tests/submission/Opera/media/track/webvtt/parsing/001.html |
| 06:33 | <zcorpan> | kmbarnhart: it's specified in the parser which one wins (iirc, the last one that has a valid value) |
| 06:36 | <zcorpan> | Hixie: isn't it better to drop items with negative and zero densities? |
| 07:04 | <hsivonen> | oh. there’s XForms 2.0 being developed: https://twitter.com/johnboyerphd/status/233252670285168641 |
| 08:00 | <Ms2ger> | XForms 2, eh? |
| 08:00 | <Ms2ger> | From @johnboyerphd |
| 08:01 | Ms2ger | remembers something about people who put "PhD" after their name |
| 08:06 | Ms2ger | curses Chrome |
| 08:23 | <hsivonen> | i18n Y U reopen bugs? |
| 09:37 | <annevk> | Ms2ger: the other John Boyer has some funny tweets https://twitter.com/johnboyer |
| 09:38 | <annevk> | "This message was not sent to Spam because of a filter you created." <- How do I tell Gmail my filters saved the day? |
| 09:41 | <annevk> | hsivonen: I was hoping you wouldn't be interested :-) |
| 10:20 | <annevk> | hmm, IDL now has RegExp? |
| 10:20 | <darobin> | annevk: yup \o/ |
| 10:24 | <jgraham> | Hmm, I fail at changing mail subject lines |
| 10:27 | <annevk> | meh, I keep replying from the @WHATWG twitter account accidentally |
| 10:32 | <darobin> | "WHATWG caught up in sex scandal after Twitter leak" |
| 10:37 | <annevk> | heh |
| 10:37 | <annevk> | http://roy.gbiv.com/talks/201008_Open_Development.pdf is pretty interesting |
| 10:42 | <JibberJim> | It better be worth it the length of time it's taking to download! |
| 10:43 | <Ms2ger`> | Wait |
| 10:44 | <Ms2ger`> | DId he just put "Credibility with world-class people." next to a picture of himself? |
| 10:56 | <annevk> | oh, meta-object protocol is not used in the specification, I thought just the abbreviation wasn't |
| 10:56 | <annevk> | so how do I find out about it if it's not actually there? |
| 10:57 | <annevk> | I guess the idea is that the platform should mostly use "Ordinary Object Internal Methods and Internal Data Properties" and not "Built-in Exotic Object Internal Methods and Data Fields" or "Proxy Object Internal Methods and Internal Data Properties"? |
| 10:58 | <Ms2ger`> | Sorry, too many capitals |
| 10:59 | <annevk> | I do like the precision of the ES drafts |
| 10:59 | <annevk> | we could learn something from the style |
| 11:00 | <jgraham> | Pretty sure you disagreed with me last time I said that |
| 11:00 | <jgraham> | Although I might be imagining things |
| 11:01 | <annevk> | jgraham: maybe my opinion changes over time? |
| 11:03 | <annevk> | Pretty sure I changed my mind on <tr href="">, but I believe there is more :-) |
| 11:04 | <JibberJim> | "Issue tracker instead of ?just ask Bob to fix this?" - yes, never trust Bob, he's lousy. |
| 11:04 | <jgraham> | Dunno, I suppose it's possible. All I know is than when I dreamt I was in a classroom and someone was trying to teach character encodings, you were there and kept correcting them. |
| 11:04 | <jgraham> | But I'm not sure you can tell anything from that |
| 11:08 | <annevk> | haha |
| 11:12 | <annevk> | JibberJim: yeah, I don't think it's anything new, but it was interesting to understand that not everyone works this way |
| 11:27 | <JibberJim> | Oh indeed annevk - you're too young, you've not seen the horrors that go on some places : |
| 12:09 | <Lachy> | annevk, I finished the initial import of Selectors API into DOM4. Do you want to take a look and give any feedback before I do a pull request? |
| 12:10 | <Lachy> | https://github.com/lachlanhunt/dom/tree/selectorsapi |
| 12:13 | <annevk5> | Lachy, later today; fwiw, last I looked I thought an additional section was overkill |
| 12:14 | <annevk5> | Maybe Ms2ger can have a look |
| 12:14 | <Lachy> | annevk5, considering that the methods are mostly shared by 3 interfaces, and there's quite a few algorithms that go with it, I though it made more sense to do a separate section than to duplicate it all under Document, DocumentFragment and Element. |
| 12:15 | <Lachy> | also, there's been a lot more added since you last looked. |
| 12:16 | <annevk5> | Okay, getting a haircut at the moment and need to do a few other things, give me a few hours |
| 12:18 | <annevk5> | We need to find a more generic solution as more methods/attributes are shared |
| 12:19 | <annevk5> | Getting somewhat messy |
| 12:21 | <zcorpan> | implements? |
| 12:22 | <annevk5> | Maybe as simple as that |
| 12:44 | <Lachy> | an old draft of selectors API used to define something like a NodeSelector interface, and then said that was implemented by the other 3 interfaces. But that was changed to use partial interfaces for some technical reasons that I can't remember |
| 12:55 | <annevk> | Lachy: those reasons should be gone, provided you use NoInterfaceObject |
| 12:56 | <Lachy> | I was using NoInterfaceObject at the time. I will look into it though and find out what the reasons were exactly. |
| 12:56 | <annevk> | What I think we need to is what zcorpan suggested. Introduce ElementContainer and probably ElementContainerOrSibling |
| 12:56 | <annevk> | then move the mutation stuff under those |
| 12:56 | <annevk> | and put Selectors along with getElementsByTagName() and such there too |
| 12:57 | <Lachy> | ok, we can do that. |
| 12:57 | <annevk> | oh also, you can contribute under CC0? that's fine? |
| 12:57 | <Lachy> | I hope so. |
| 12:58 | <Lachy> | I'll check with Lars Erik, just to be sure |
| 12:59 | <annevk> | concepts I have now |
| 12:59 | <annevk> | RootNode |
| 12:59 | <annevk> | that's for Document/DocumentFragment/Element |
| 12:59 | <annevk> | and ChildNode |
| 12:59 | <annevk> | for DocumentType/Element/CharacterData |
| 13:02 | <annevk> | I guess we can turn those into actual interfaces |
| 13:02 | <annevk> | Ms2ger / Ms3ger: ^^ |
| 13:08 | <annevk> | zcorpan: fwiw, I'll implement your other suggestion too at that point, the one about nextElementSibling and such |
| 13:11 | <zcorpan> | annevk: was that to make them available on all nodes that can have element siblings? |
| 13:11 | <annevk> | yup, ChildNode above |
| 13:12 | <Lachy> | annevk, http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0039.html |
| 13:14 | <annevk> | Lachy: I'm pretty sure on the interface itself and implements + NoInterfaceObject are the same these days |
| 13:16 | <annevk> | Lachy: as for review, where should I put review comments? |
| 13:18 | <Lachy> | I guess I'll just do a pull request for both dom and xrefs with the new selectors references and you can put them there. |
| 13:19 | <annevk> | the only problem with the pull request thing is that it results in many commits :/ |
| 13:19 | <annevk> | here are a few to start |
| 13:19 | <annevk> | * needs domintro |
| 13:20 | <annevk> | * if you define something called a flag, have it be set or unset, don't give it values |
| 13:20 | <annevk> | * Element node -> concept-element |
| 13:24 | <annevk> | (no domintro boxes needed for querySelector btw if the goal is that people use find) |
| 13:46 | <Ms2ger`> | Lachy, do you have the selectorsapi branch somewhere I can look at it? |
| 13:47 | <Lachy> | Ms2ger`, http://lachy.id.au/temp/dom-core.html |
| 13:48 | <Ms2ger`> | Ta |
| 13:50 | <Ms2ger`> | There's a [[!SELECTORS4]] left |
| 13:50 | <Lachy> | oh, oops . where? |
| 13:50 | <Lachy> | ah, in namespaces. |
| 13:50 | <Ms2ger`> | Yep |
| 13:52 | <Lachy> | annevk, re the many commits problem, I'll sort that out once I resolve all the issues. I can rebase it and squash all the commits down to just one later and do another pull request. |
| 13:53 | <Lachy> | annevk, though it would be more useful if we had Critic set up for review comments |
| 13:59 | <foolip> | annevk, still there? |
| 13:59 | <annevk> | foolip: yeah |
| 13:59 | <foolip> | my conclusion from that time is that any kind of inline load of javascript: is pretty useless |
| 14:00 | <foolip> | but are you asking with regard to parsing and such for the URL standard? |
| 14:01 | <annevk> | foolip: where to handle it, my idea was to put it in the "navigate" layer and have it just be an error if it reaches "fetch" |
| 14:01 | <annevk> | Lachy: sounds good |
| 14:01 | <foolip> | right now it's somewhere around top-level browsing contexts in the HTML spec, isn't it? |
| 14:03 | <foolip> | annevk, maybe that's the navigate layer you mean, since url.spec.whatwg.org doesn't talk about navigation? |
| 14:03 | <annevk> | foolip: it's in "fetch" currently, which is mostly about turning a URL into a resource, but it includes inline loads |
| 14:04 | <annevk> | foolip: yeah not sure what url.spec.whatwg.org should say about this, there's so many layers :-) |
| 14:04 | <annevk> | Lachy: might also be interesting to talk to the CSS folks and have them define all Selector parsing |
| 14:05 | <annevk> | Lachy: ah, there's an issue to that effect doh |
| 14:05 | <foolip> | annevk, as far as I know, it would make sense to handle it the navigation of browsing contexts, and trying to fetch certainly could be an error |
| 14:05 | <annevk> | k, thanks |
| 14:05 | <foolip> | I'm not sure if there's any compat issues with not treating the return value of javascript: as a new document, might want to look into that |
| 14:05 | <SimonSapin> | annevk: what about selector parsing? |
| 14:05 | <foolip> | seemed fine to drop it for inline loads at least |
| 14:06 | <foolip> | gotta go |
| 14:07 | <Ms2ger`> | "These groups of selectors should not use namespace prefixes that need to be resolved." |
| 14:08 | <Ms2ger`> | That "should" looks weird there |
| 14:08 | <SimonSapin> | that’s easy: just say that no ns declarations are in scope |
| 14:08 | <SimonSapin> | prefix declarations |
| 14:09 | <SimonSapin> | Selectors already says that using an undeclared prefix is invalid |
| 14:12 | <Ms2ger`> | And it would be nice to introduce RootNode or whatever before introducing the selectors stuff |
| 14:15 | <SimonSapin> | In fact selectors-api doesn’t need to say anything: "The mechanism by which namespace prefixes are declared should be specified by the language that uses Selectors. If the language does not specify a namespace prefix declaration mechanism, then no prefixes are declared." http://www.w3.org/TR/selectors/#nsdecl |
| 14:16 | <SimonSapin> | Although it can, to make this more explicit |
| 14:20 | <annevk> | if that's the case a note should suffice |
| 14:23 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1928 seems like safari and chrome throw a SecurityError |
| 14:33 | <annevk> | zcorpan_: URL parser already does encodeURIComponent although I guess if you use newlines and tab it might be useful |
| 14:43 | <zcorpan_> | annevk: i was thinking more of # |
| 14:45 | <Lachy> | annevk, I already emailed www-style and spoke to fantasai and TabAtkins about doing that during TPAC. |
| 14:46 | <annevk> | Lachy: k |
| 14:46 | <Lachy> | http://lists.w3.org/Archives/Public/www-style/2012Oct/0832.html |
| 14:46 | <annevk> | Lachy: do you want me to copy the comments I made earlier into the pull request thingie or is it okay like this? |
| 14:46 | annevk | is trying to write his IDNA piece and is getting lost in it |
| 14:47 | <Lachy> | it's ok here. I'll make a note of them. |
| 14:57 | <annevk> | Lachy: the idiom "return the result of running x" is okay, but I'd try to factor out algorithm itself as much as possible, that doesn't match the style we use afaik |
| 14:57 | <annevk> | Lachy: the word algorithm, that is |
| 14:59 | <annevk> | Lachy: also, I guess the best approach here is I first make the changes with respect to RootNode / ChildNode and that you then integrate based on that |
| 14:59 | <annevk> | Ms2ger`: you okay with RootNode / ChildNode? |
| 15:00 | <annevk> | Ms2ger`: Lachy: my thinking is subsection of "Node tree" |
| 15:00 | <annevk> | (subsections) |
| 15:01 | <Lachy> | annevk, ok |
| 15:01 | <Ms2ger`> | annevk, yeah, sounds good |
| 16:10 | <annevk> | Ms2ger, we should also make the switch away from Hixie-style algorithms towards JavaScript-style algorithms |
| 16:10 | <annevk> | Ms2ger, no more "terminate these steps" but just return / throw / ... and say when the steps are not terminated |
| 16:11 | <annevk> | Ms2ger, not entirely sure how we should start with that, do we even explain the current rules somewhere? |
| 16:12 | <gsnedders> | othermaciej: What would I do if not pedant your comments? ;P |
| 16:12 | <odinho_> | annevk: You do that already though, don't you? |
| 16:12 | <annevk> | odinho_: some specs do, some specs don't, some do both I guess |
| 16:13 | gsnedders | wants to know how to avoid introducing ambiguity without making it so hard to parallelize the spec's algorithms |
| 16:13 | <annevk> | odinho_: maybe I should just change as I come across stuff |
| 16:13 | <annevk> | gsnedders: is that in reference to this conversation because I'm not sure what you're saying |
| 16:13 | <annevk> | gsnedders: ? |
| 16:14 | <gsnedders> | annevk: Pretty much. See what dbaron was saying wrt Servo a while back and various forms of specs. |
| 16:15 | <annevk> | gsnedders: 1) I need a pointer for dbaron's thing 2) This is only about changing style, not substance |
| 16:15 | <jgraham> | I think that servo has the constraint that it has to be indistinguishable from a non-parallel implementation except in areas where there is no compat constraint |
| 16:16 | <gsnedders> | jgraham: I think the aim was for it to be indistringuishable in general, just given large amounts of prose it's not entirely clear how you transform that algorithm to something with concurrent steps. |
| 16:16 | <jgraham> | Yes, that is a hard problem of course |
| 16:17 | <jgraham> | But easier if you have an implementation than if you are just trying to write specs |
| 16:17 | <gsnedders> | annevk: http://dbaron.org/log/20120827-specification-style |
| 16:19 | <annevk> | Ah yeah, I did read that. Unfortunately I couldn't think of anything to do different |
| 16:20 | <gsnedders> | I wonder whether it's possible to give everything as a list of constraints. |
| 16:20 | <gsnedders> | Well, obviously it's possible. |
| 16:20 | <gsnedders> | But feasible? |
| 16:21 | <gsnedders> | I'm not saying we should throw everything out, but still. |
| 16:21 | <annevk> | It seems unlikely I'm going to rewrite the URL Standard in terms of constraints, or anything really. |
| 16:21 | <jgraham> | I don't even know what it would mean to rewrite the parsing algorithm, for example, in terms of constraints |
| 16:22 | <annevk> | jgraham: right |
| 16:22 | <jgraham> | Or that it would translate nicely to rust if you did |
| 16:22 | <gsnedders> | Parsing I think makes sense as a state machine. |
| 16:22 | <jgraham> | In that case the obvious parallelisation points are well known i.e. you can run the tokenizer in one task and the treebuilder in another |
| 16:22 | <jgraham> | I don't think you can do better than that |
| 16:23 | <gsnedders> | Is that feasible? I thought there was some conclusion that that wasn't doable without duplicating several stacks. |
| 16:23 | <jgraham> | Well gecko does that already |
| 16:23 | <gsnedders> | I thought I remembered something from foreign content that made it difficult |
| 16:26 | <gsnedders> | Though maybe that was just the change that meant you had to keep at least some information about the current stack to do so. |
| 16:41 | <GPHemsley> | zcorpan: Oh, I got the memo. I just ignored it, because of the apparent hassle to use something else. (And I've been able to work around every other problem I've encountered so far.) |
| 16:43 | <GPHemsley> | Ms2ger: Chrome Ph.D.? |
| 16:44 | <GPHemsley> | Wasn't XForms support just removed from Gecko? |
| 16:46 | <jwalden> | think so, yes |
| 16:46 | GPHemsley | wonders how/why annevk was on IRC while getting a haircut. |
| 16:47 | <GPHemsley> | Has anybody drawn a map of the interaction of all the different Web specs? |
| 16:51 | <darobin> | GPHemsley: yup, http://kwz.me/S5 |
| 16:52 | <GPHemsley> | darobin: You're such a character. |
| 16:52 | <darobin> | GPHemsley: I prefer "code point" |
| 16:52 | <GPHemsley> | :) |
| 16:55 | jwalden | approves of this punning |
| 17:13 | <dglazkov> | good morning, Whatwg! |
| 17:13 | <SimonSapin> | good evening dglazkov |
| 17:20 | <odinho_> | dglazkov: When you say good morning, it's always a good time to think about going home from work. ... But then staying another 2-3 hours anyway. :D |
| 17:20 | <dglazkov> | odinho_: happy to be your alarm clock! :) |
| 17:26 | <odinho_> | dglazkov: http://dpaste.com/hold/837784/ You're around 17.30 or 17.40, but if not those, then 18.10 is a popular time for you. (for me) :] |
| 17:34 | <jgraham> | odinho_: Graph plz :p |
| 17:34 | <dglazkov> | jgraham++ |
| 18:07 | GPHemsley | is glad we don't have to standardize the response to CTCP TIME |
| 18:07 | <GPHemsley> | s/standardize/spec/ |
| 18:16 | <annevk> | So I made that change to the DOM |
| 18:16 | <annevk> | If partial is indeed different from implements / [NoInterfaceObject], I might have introduced a problem, but then I want something better from IDL |
| 18:17 | <annevk> | Oh, timbl just retweeted https://twitter.com/manusporny/status/273124335953268736 lol |
| 18:18 | <annevk> | Maybe I should unfollow timbl, he doesn't reply to my queries and tweets almost exclusively about Linked Data / RDF |
| 19:01 | <TabAtkins> | Can someone with a better DOM understanding of why sync events are usually bad respond in the "Scheduling multiple types of end-of-(micro)task work" thread? |
| 19:05 | <Hixie> | all events are sync in one sense or another :-) |
| 19:05 | <Hixie> | sync relative to what? |
| 19:05 | <Hixie> | dom changes? |
| 19:06 | <Hixie> | ah, crap, i lost my big e-mail about menu i was working |
| 19:06 | <Hixie> | ah well |
| 19:06 | <Hixie> | will have to write it again |
| 19:06 | <TabAtkins> | Syncrhonrous with response to layout changes. |
| 19:07 | <Hixie> | yikes! |
| 19:07 | <TabAtkins> | Hixie: I recommend using a real email client. ^_^ |
| 19:07 | <Hixie> | you can't do stuff sync with layout changes! |
| 19:07 | <TabAtkins> | Exactly. |
| 19:07 | <astearns> | why is the resize event sync? |
| 19:08 | <TabAtkins> | Legacy error. |
| 19:08 | <TabAtkins> | And a bad, annoying one, given how easy it is to accidentally get into a cyclic situation. |
| 19:08 | <Hixie> | do we even have a spec fore resize? |
| 19:08 | <Hixie> | anyway, resize isn't sync with layout |
| 19:08 | <Hixie> | it's sync with the user interaction event |
| 19:09 | <Hixie> | layout just happens to be sync with every task |
| 19:11 | <astearns> | I think Andrei is thinking that most triggers for regionlayoutupdate will happen with a resize, so it makes sense to have one regionlayoutupdate per resize event, and make them sync with each other |
| 19:19 | <smaug____> | annevk: ah "And here I was hoping nobody would notice." is the way to write specs :) |
| 19:19 | <annevk> | bz uncovered my secret! |
| 19:19 | <gsnedders> | :o |
| 19:20 | <Hixie> | astearns: making an event sync with resize is fine by me |
| 19:20 | <Hixie> | astearns: just don't tie it to layout |
| 19:20 | <smaug____> | resize event is quite odd one |
| 19:20 | <astearns> | unfortunately, it's tied to the results of layout |
| 19:21 | <Hixie> | astearns: :-( |
| 19:22 | <Hixie> | i strongly recommend making sure people like roc are in the loop on this |
| 19:22 | <Hixie> | and ms2ger |
| 19:22 | <smaug____> | https://bug457862.bugzilla.mozilla.org/attachment.cgi?id=355244 is a testcase for resize event |
| 19:23 | <smaug____> | looks like FF can handle it, chrome and opera can't |
| 19:23 | <astearns> | Hixie: I would definitely like to get their input |
| 19:24 | <smaug____> | (I thought chrome or some version of webkit did handle that case ok) |
| 19:25 | <gsnedders> | smaug____: I believe they can when it is resize events on plugins |
| 19:27 | <smaug____> | astearns: FYI, Gecko used to fire resize async, well of a timer, but it was considered as a bug. https://bugzilla.mozilla.org/show_bug.cgi?id=457862 |
| 19:31 | <smaug____> | ah, that testcase is too tricky for Gecko too :( |
| 19:44 | <annevk> | What bz mentions is actually a problem with many HTML APIs too I think. At least I have not done a thorough review of HTML (and SVG) to see if they make sense in context of mutation observers. |
| 19:44 | <annevk> | the context* |
| 19:45 | <annevk> | Of course, if the DOM itself doesn't handle it there's even less hope for others to get it right... |
| 20:29 | GPHemsley | notes it is a sad day for User-Agent strings |
| 20:32 | <Hixie> | new ones getting invented? |
| 20:36 | <miketaylr> | every day is a sad day for UA strings |
| 21:12 | smaug____ | wonders what <a href="javascript: new Date()" download="foo.txt">foo</a> should do |
| 21:14 | <smaug____> | no darin |
| 21:14 | <smaug____> | he might remember what chrome does |
| 21:14 | <smaug____> | and why |
| 21:23 | <jgraham> | Wait, what? |
| 21:23 | <jgraham> | download=""? |
| 21:23 | <jgraham> | Did I slip into a time warp and arrive in the future? |
| 21:23 | <jgraham> | Or why have I not heard of this? |
| 21:27 | <Hixie> | it's been in the spec for months now |
| 21:28 | <Hixie> | r6318 2011-07-22 |
| 21:28 | <Hixie> | years even! |
| 21:29 | <MikeSmith> | where "years" means one year and a few months |
| 21:30 | <annevk> | is that what "months" means or are you referring to something else? |
| 21:30 | <annevk> | in other news, writing domintro boxes is boring |
| 21:30 | <MikeSmith> | hah |
| 21:31 | <annevk> | Hixie: we should apply WHATWG to Google Summer of Code so we get some interns that can write domintro boxes |
| 21:31 | <MikeSmith> | oh I bet by "years" Hixie must mean the multiple possible representations of the single resource "year" |
| 21:31 | <annevk> | Hixie: in case it turns out they're smarter than us we can reverse the roles |
| 21:34 | <jgraham> | Hixie: The ping attribute has been in the spec since the dawn of time (or thereabouts) but that doesn't mean anyone knows it exists |
| 21:37 | <annevk> | smaug____: you don't mind if where the spec currently talks about "Text, ProcessingInstruction, or Comment node" I replace that with "CharacterData node" right? |
| 21:37 | <annevk> | same question for anyone else |
| 21:37 | <smaug____> | annevk: right |
| 21:38 | <smaug____> | annevk: well, the spec talks in some cases only about Text and Comment |
| 21:38 | <smaug____> | in cases where I think it should say CharacterData |
| 21:38 | <annevk> | smaug____: well if it's different it can't be replaced, but we should probably fix those cases per the Gecko bug |
| 21:38 | <annevk> | smaug____: is it really as simple as just replacing Text/Comment with CharacterData there? |
| 21:39 | <smaug____> | when talking about Range, Comment and PI should be - perhaps - handled the same way |
| 21:40 | <annevk> | yeah that makes sense to me |
| 21:40 | <smaug____> | not sure what the spec says about them in other contexts |
| 21:40 | <annevk> | they're typically grouped, unless ProcessingInstruction.target is important |
| 21:43 | <annevk> | smaug____: I'll add ProcessingInstruction to the cases in Range now, and won't make the change to rename those instances to CharacterData (at least for now) |
| 21:46 | <smaug____> | k |
| 21:54 | <annevk> | It seems there's potential for further cleanup in ranges looking at the comments AryehGregor wrote |
| 21:55 | <annevk> | It seems he didn't dare putting a stake in the ground where he might have been able to a few times, but I'm not sure if it's worth cleaning up either... |
| 21:58 | <annevk> | smaug____: https://github.com/whatwg/dom/commit/677350850145097fc83d8dfe54e5f644f0adcc21 |
| 21:59 | <smaug____> | looking in a minute |
| 22:02 | <smaug____> | annevk: is it possible to see more context in github commits? |
| 22:02 | smaug____ | prefers to see at least 8 lines before and after the change |
| 22:03 | <annevk> | I don't know, I've been wondering the same |
| 22:03 | <annevk> | https://help.github.com/articles/search?q=diff+context euh fail |
| 22:05 | <smaug____> | looks good. (a bit hard to review) |
| 22:06 | <smaug____> | would be nice to have some tool for spec change reviewing |
| 22:09 | <annevk> | there's also https://github.com/whatwg/dom/commit/677350850145097fc83d8dfe54e5f644f0adcc21.patch apparently |
| 22:11 | <annevk> | smaug____: yeah, if someone wants to setup critic that's fine with me, I guess for now we rely on GitHub's infrastructure |
| 23:42 | <TabAtkins> | Hixie: Yo, I need to talk about <ruby>. |
| 23:42 | <Hixie> | shoot |
| 23:43 | <TabAtkins> | The current Ruby model doesn't work well for a few cases - namely, inlining ruby, jukugo ruby groups withing a larger ruby span, and multiple ruby. |
| 23:44 | <TabAtkins> | There's some simple changes that can be made that solve all of these, that fantasai has been working on and asked me to sell to you. ^_^ |
| 23:44 | <TabAtkins> | I can write up an email with details, or bring them up here, but I want to see first if you're willing to mess with the current spec on it. |
| 23:46 | <Hixie> | i believe all use cases that have been presented actually have been resolved by now |
| 23:46 | <Hixie> | at least, all those the i18n groups presented |
| 23:47 | <TabAtkins> | I have evidence to the contrary. ^_^ |
| 23:47 | <Hixie> | including inlining ruby, jukugo ruby groups within a larger ruby span, and multiple ruby |
| 23:47 | <Hixie> | cool. please file a bug :-) |
| 23:47 | <TabAtkins> | Okay, can do. |