| 01:25 | <estellevw> | While autofocus should only be used once per document, if there were more than one in the document, the autofocus attribute used to target the last element with the autofocus attribute. I tested 3 months ago, and all browsers tested did this. testing again today, Chrome and Firefox now give focus to the first occurrence of autofocus. Did the spec change. I’ve failed to successfully Google any discussion on that topic. |
| 01:34 | <caitp> | > If the user agent has already reached the last step of this list of steps in response to an element being inserted into a Document whose top-level browsing context's active document is the same as target's top-level browsing context's active document, abort these steps. |
| 01:34 | <caitp> | I take that to mean, for a given browsing context, only autofocus the first control with an autofocus attribute? |
| 01:35 | <estellevw> | started in chrome 34 |
| 01:35 | <estellevw> | they used to all focus on the last occurence of autofocus |
| 01:36 | <estellevw> | 34+ focuses on the first instead |
| 01:36 | <estellevw> | yes |
| 01:37 | <caitp> | you can probably find discussion on it if you svn/git blame it |
| 01:38 | <caitp> | github doesn't feel it's worth its effort though :> |
| 01:39 | <estellevw> | can’t even find it in svn — then, of course, not sure of the exact range to inspect |
| 01:41 | <caitp> | might be able to find mention of it in implementation code, too |
| 01:41 | <caitp> | not sure if that would live in parsing or DOM though, otoh |
| 01:43 | <estellevw> | trying to figure out if it’s a bug or feature. The spec doesn’t clarify it for me http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autofocusing-a-form-control:-the-autofocus-attribute |
| 06:03 | <annevk> | Figuring out context is hard :-( |
| 06:14 | <jungkees> | annevk: During the SW registration process, which is not a task as you told, |
| 06:14 | <jungkees> | annevk: If I resolve a promise in a step.. |
| 06:14 | <jungkees> | annevk: is it queued as a microtask? |
| 06:14 | <annevk> | jungkees: no, but unless you change state as well, that is fine, as a promise can only be observed from a microtask |
| 06:18 | <jungkees> | annevk: I don't think I understood the term "state" you explained. Is it a term defined in a spec or general word to designate platform state? |
| 06:19 | <annevk> | jungkees: general; like changing properties, dispatching events |
| 06:20 | <annevk> | jungkees: I think we should define asynchronous as a term to make this whole thing more clear, but Hixie disagrees so far |
| 06:22 | <jungkees> | annevk: then in SW registration I just mentioned, when I resolve a promise in step A, the fulfillment cb is executed first? or the subsequent steps in the algorithm executed first? |
| 06:22 | annevk | looks |
| 06:23 | <annevk> | jungkees: oh, if the algorithm is asynchronous, you can't predict that |
| 06:25 | <jungkees> | annevk: yeah.. it seems if the asynch part of the algorithm is a definitive task in a queue, it'll be clearer to reason it about |
| 06:25 | <annevk> | jungkees: you don't want your algorithms to interfere with the main thread |
| 06:26 | <annevk> | jungkees: the event loop is off limits, it's synchronous code |
| 06:26 | <annevk> | jungkees: delaying painting and whatnot |
| 06:27 | <jungkees> | annevk: weird you express the event loop is synchronous code though.. |
| 06:28 | <annevk> | jungkees: why? It's just a queue of bits of code run after each other, nothing goes in parallel |
| 06:28 | <jungkees> | annevk: so you meant the queue implement itself.. the while loop |
| 06:29 | <annevk> | jungkees: you lost me |
| 06:32 | <annevk> | jungkees: the rules are very simple, specification algorithms run in parallel (unless they're super cheap and can be done synchronous) and only ever queue tasks or microtasks to set a property or dispatch an event |
| 06:33 | <SamB> | and, yes, the event loop is in fact a loop |
| 06:33 | <jungkees> | annevk: SamB alright |
| 06:44 | <jungkees> | annevk: is there any reason you don't queue a task to fire events in XHR? it just fire events without queuing a task |
| 06:44 | <jungkees> | annevk: I've done the same in SW registration |
| 06:45 | <jungkees> | annevk: think it should queue a task instead? |
| 06:54 | <annevk> | jungkees: XMLHttpRequest queues tasks for events, pointer? |
| 06:56 | <annevk> | jungkees: it also does a bunch of other stuff on such tasks usually |
| 07:00 | <jungkees> | annevk: like step11.2 in http://xhr.spec.whatwg.org/#dom-xmlhttprequest-send |
| 07:01 | <jungkees> | annevk: maybe because it's in main thread? |
| 07:03 | <jungkees> | annevk: then in SW case, I think I need to queue a task for firing the events |
| 07:26 | <annevk> | jungkees: yeah, that's synchronous |
| 07:28 | <SamB> | wait, are they seriously using segmentation for NaCl? |
| 07:29 | <annevk> | jungkees: it's also necessary for updating .state |
| 07:30 | <jungkees> | annevk: yeah, i'll do that; queue a task to update .state and fire events on the object |
| 07:31 | <SamB> | ECHAN |
| 07:40 | <jungkees> | annevk: per https://github.com/w3ctag/promises-guide#queue-tasks-to-invoke-user-code, when asynchronously running algorithm do "resolve p with x", it seems do "queue a task to call the callback cb with x," |
| 07:41 | <jungkees> | annevk: is this fulfillment cb queued in task queue? or microtask queue? |
| 07:42 | <annevk> | jungkees: if you resolve a promise from asynchronous code it's callbacks will run in the next available microtask slot; so the latter |
| 07:42 | <annevk> | jungkees: it's the same really as whenever you'd resolve a promise from synchronous code |
| 07:43 | <annevk> | jungkees: however, if you change state on an object, such as a property, and announce that also through a promise, you need to queue a task to change state and resolve |
| 07:44 | <jungkees> | annevk: Okay |
| 10:23 | <jungkees> | annevk: An asynchronously running steps in algorithm A declared a variable foo and queued a task (B) in a subsequent step; Does it make sense the queued task B set a value to A's foo? |
| 11:44 | <annevk> | jungkees: so 1. Let /foo/ be X. 2. Queue a task to set /value/ to /foo/? That could make sense |
| 11:48 | <jungkees> | annevk: oh i see |
| 11:50 | <annevk> | jungkees: unfortunately the best way to get knowledge of this stuff is to carefully study algorithms in HTML, XMLHttpRequest, Notifications, etc. |
| 11:50 | <annevk> | jungkees: while keeping in mind that none of those is perfect |
| 11:53 | <annevk> | jungkees: I'll be away for three weeks or so, hopefully this is enough for now, otherwise I recommend asking Hixie or Domenic |
| 11:53 | <jungkees> | annevk: thanks for help |
| 11:53 | <jungkees> | annevk: going on a vacation? |
| 11:54 | <jungkees> | annevk: Enjoy your holidays and let's sync-up when you get back |
| 11:55 | <jungkees> | annevk: I think I'll refine the algorithms better till then though I'll may take a week off during the time |
| 13:32 | <annevk> | jungkees: yes & sounds good |
| 14:16 | <wilhelm> | "The RDF Working Group [1] is now closed." |
| 14:22 | Ms2ger | wonders if the CSSWG is still open |
| 14:24 | <wilhelm> | Yes, they just got their charter renewed. :P |
| 14:35 | <annevk> | So we need to split request's context into two things |
| 14:35 | <annevk> | The first is more or less like context is now, the second will be the browsing context "type" |
| 14:36 | <annevk> | contextSource == "hyperlink" && contextFrame == "top-level" |
| 14:36 | <annevk> | Anyone want to bikeshed, jgraham? |
| 14:37 | <jgraham> | Why are we bikeshedding me? |
| 14:38 | <jgraham> | annevk: Well apart from the obvious fact that js needs an enum type, assuming that does what it sounds like it seems like a reasonable choice of names |
| 14:38 | <jgraham> | I don't have more context than that line though |
| 14:39 | <annevk> | If you want more context (hah!) you could read https://github.com/slightlyoff/ServiceWorker/issues/352 |
| 14:39 | <annevk> | Might be hard to introduce an enum type now IDL settled on strings |
| 14:40 | <jgraham> | Strings are pretty terrible :( |
| 14:41 | <jgraham> | I guess frame is somewhat misleading |
| 14:41 | <jgraham> | Could be contextType or something |
| 14:42 | <jgraham> | (because it doesn't tell you what actual frame you used, just what type of browsing context it was) |
| 14:53 | <annevk> | context frame type |
| 14:53 | <annevk> | and just context I guess, you don't always need/use context frame type |
| 15:20 | <annevk> | Hmm, need more contexts to complete the context alphabet |
| 15:25 | <annevk> | Oh my, even <embed> can create a nested browsing context! |
| 15:25 | <annevk> | SVG, WHYYYYYY |
| 16:26 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=26247#c14 |
| 16:29 | <jgraham> | annevk: I guess I could read the spec, but if [i]frame and hyperlink are orthogonal it's not clear what happens with <iframe name=bar> and <a href="foo" target=bar> |
| 18:51 | <annevk> | jgraham: they're not, the former would be setting their src attribute |
| 18:52 | <annevk> | for this to be defined in detail requires all end points to be in terms of fetch however |
| 19:09 | <cmr> | Hixie: whatwg.org is down |
| 20:42 | <Hixie> | cmr: there was some issue a couple of hours ago, yeah. seems resolved. |
| 20:44 | <cmr> | Hixie: indeed it does, thanks |
| 22:05 | <SamB> | wha, why does the background give out in the middle of the section http://perldoc.perl.org/perlmodlib.html#Asia here ... |
| 22:06 | <SamB> | well, part of it starts there, part of it gets a bit further |
| 22:11 | <caitp> | huh? |
| 22:21 | <SamB> | caitp: does that not happen for you? |
| 23:35 | <zewt> | typed "background: none" into a style in the FF inspector ... got "background: none; -repeatndoundkface-visibility" |
| 23:35 | <zewt> | ^5 braindamaged autocomplete |