| 00:00 | <Hixie> | there's various drafts for various proposals, afaik |
| 00:00 | <jgraham> | Yeah that all fragmented. There's a pointer-events wg although I don't know if they still do stuff |
| 00:01 | <jgraham> | http://lists.w3.org/Archives/Public/public-pointer-events/ |
| 00:01 | <Hixie> | i've been mostly ignoring new proposals on the basis that without a spec for 'keydown' and 'mouseup' and so on, there's not much point looking at making new events |
| 00:02 | <roc> | well, I don't think that's true. There is still value in speccing new events rather than having people go off and do their own things. |
| 00:03 | <Hixie> | i mean "making new events" in the sense of implementing new ones, let alone speccing them |
| 00:05 | <jgraham> | Hixie: [Un]fortunately people violently disagree with you on that |
| 00:05 | <Hixie> | yeah, clearly :-) |
| 00:05 | <jgraham> | Hence the 17 different efforts to specify touch events |
| 00:06 | <jgraham> | OTOH if we want the web to do well on touch-based devices, saying "oh we can't figure out touch because we haven't managed to figure out keyboards in the last 20 years" isn't going to cut it |
| 00:09 | <Hixie> | i'm saying "let's describe what browsers have to implement for keyboard, mouse, and touch events, since those have already shipped, then let's design an input event system that is media-independent so we don't have to do this again in two years" |
| 00:15 | <tantek> | keyboard events is a great way to get embroiled in accessibility and internationalization issue processing. at least that was my experience with the CSS "key-equivalent" property |
| 00:15 | <Hixie> | the key (oops) is to scope your work to exclusively be "specify what needs to be implemented to be interoperable" |
| 00:16 | <Hixie> | then there's no bikeshedding possible |
| 00:17 | <tantek> | interoperable across which devices with which set of keys or buttons? which year of mobile devices with which buttons do you wish to spec? |
| 00:17 | <tantek> | or which year of which laptop(s) or qwertyish handhelds? |
| 00:17 | <tantek> | good times. |
| 00:17 | <tantek> | in which countries? |
| 00:19 | <jgraham> | Since we can't get specific input systems right, the chance of abstracting over all existing and possible future input systems and producing something useful seems remote |
| 00:20 | <tantek> | enjoy: http://www.bing.com/images/search?q=japanese+handheld+keyboards |
| 00:21 | <jgraham> | It's unfortunate that we have always had to be reactive, but not that surprising |
| 02:25 | <SamB> | Hixie: I don't see how not having the old events specced makes having what new events may come into use specced any less useful? |
| 06:37 | <annevk> | Hixie: not much progress on mutation events so far |
| 07:39 | <annevk> | SimonSapin: sad that your query got no replies, but we do need to address that question somehow |
| 08:05 | <foolip> | annevk: did you get the answers you needed in the "Fullscreen API and out-of-process <iframe>" thread? |
| 08:06 | <annevk> | foolip: yeah I guess, still a bit unsure how to spec it |
| 08:07 | <foolip> | is it specifically the racy requestFullscreen problem, or something more general I'm not seeing? |
| 08:07 | <annevk> | foolip: something like requestFullscreen() does a request to resize the browser window; that request either returns it failed, returns it's already done, or returns it succeeds (maybe returns it's in progress for someone else?) |
| 08:08 | <annevk> | I was mostly just wondering what the best way was to update state and such |
| 08:08 | <foolip> | you mean structure it so that the internal resize request can fail, and deal with that by firing fullscreenerror? |
| 08:09 | <annevk> | yeah, that'd be an error I guess |
| 08:09 | <annevk> | not sure about the other conditions |
| 08:09 | <foolip> | well it's actually not the resize that would fail, but another element would already be in fullscreen when we're notified of success |
| 08:09 | <annevk> | what I was also worried is about resizing has completed, but state has not changed and then something happens |
| 08:09 | <annevk> | am* |
| 08:10 | <foolip> | hmm |
| 08:11 | <foolip> | it would be nice to treat two racy requests by imposing an arbitrary order on them, determined by IPC or whatever |
| 08:11 | <annevk> | the "pending element" thing is sorta global in a way too |
| 08:11 | <foolip> | then make them do the same thing that this order of requests would do with plenty of time in between them |
| 08:11 | <annevk> | well the request to resize would be that I guess |
| 08:11 | <foolip> | the pending element is per-document, no more global than that, surely? |
| 08:12 | <annevk> | if A and B are same-origin and invoke requestFullscreen right after each other, what happens? |
| 08:13 | <foolip> | are they sibling or parent-child? |
| 08:13 | <annevk> | I guess the first resizes the window, the second is notified the window is already changed, then the first notifies state change, then the second |
| 08:13 | <annevk> | parent-child |
| 08:14 | <annevk> | I also realized we cannot really make the checks asynchronous, that'd be racy |
| 08:14 | <foolip> | I don't think the answer ought to be different than for cross-origin A and B, even if it's possible to implement differently |
| 08:17 | <foolip> | you mean the fail-checks that will fire fullscreenerror? |
| 08:29 | <SimonSapin> | annevk: about IPv4 address syntax? I’ll try to find Mozilla people who work on related stuff and ask them |
| 09:12 | <annevk> | foolip: yeah |
| 09:14 | <annevk> | foolip: say B invokes requestFullscreen and A removes B's container |
| 09:51 | <foolip> | annevk: not knowing how to spec it, I'd say it should either enter fullscreen sucessfully and then exit again, or fail to enter fullscreen, depending on which event is considered first |
| 09:51 | <foolip> | but... sigh |
| 09:52 | foolip | -> lunch |
| 09:54 | <annevk> | yes, sigh :-) |
| 10:52 | <jgraham> | annevk: The servo people are looking at HTTP at the moment because the Rust HTTP ecosystem is very immature and they have been using a library that doesn't really work |
| 10:52 | <jgraham> | So they are likely very interested in a HTTP spec that you could write an implementation from and actually have it work with real websites |
| 10:53 | <annevk> | Yeah, no doubt. I don't have the bandwidth |
| 10:53 | <Ms2ger> | The other options is to make Manishearth write the spec |
| 10:53 | <Ms2ger> | option* |
| 10:53 | <annevk> | I'm keeping notes on the WHATWG Wiki |
| 10:54 | <annevk> | http://wiki.whatwg.org/wiki/HTTP Not very elaborate so far though |
| 10:54 | <jgraham> | annevk: I'm not saying "you have to write the spec" |
| 10:54 | <jgraham> | I'm saying "they have an interest in this work" |
| 10:54 | <JakeA> | annevk: If WorkerGlobalScope is [Exposed=Worker] and `interface ServiceWorkerGlobalScope : WorkerGlobalScope {` and FormData `Exposed=(Window,Worker)`, doesn't that mean FormData is exposed in ServiceWorkerGlobalScope? |
| 10:54 | <jgraham> | Which might indeed by a way of finding someone else who can justify writing the spec |
| 10:55 | <annevk> | JakeA: you would need [Global=Worker] but that also makes XMLHttpRequest exposed |
| 10:55 | <annevk> | JakeA: which I thought was one of the things we didn't want? And we did not want FileReaderSync which would also have Exposed=Worker |
| 10:56 | <annevk> | jgraham: if you know the relevant people you could point them to http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1542.html |
| 10:56 | <JakeA> | annevk: I don't have a problem with XMLHttpRequest, but yeah, FileReaderSync isn't great |
| 10:57 | <annevk> | JakeA: if you have Global=Worker all those *Sync APIs would be available in service workers too |
| 10:57 | <annevk> | JakeA: if you don't, we'll need to add Exposed=ServiceWorker to some APIs |
| 10:58 | <Ms2ger> | annevk, I'm not drowning him in IETF :) |
| 10:59 | <annevk> | JakeA: we could potentially only use Worker for sane interfaces, and introduce SyncWorker or some such as alias for dedicated worker / shared worker that APIs such as FileReaderSync can use |
| 10:59 | <JakeA> | annevk: hmm or move the sync APIs… yeah, what you said |
| 10:59 | <Ms2ger> | Why don't you want those *Sync interfaces? |
| 10:59 | <annevk> | JakeA: if you have a plan email public-script-coord⊙wo |
| 11:00 | <annevk> | Ms2ger: service workers can't be blocking |
| 11:00 | <JakeA> | Ms2ger: Pretty much the same reason they're not great in a sharedworker. You're blocking |
| 11:00 | <Ms2ger> | I see |
| 11:00 | <JakeA> | actually, they're not great in any worker |
| 11:05 | <annevk> | JakeA: now would be the time to propose such a change, need to get Hixie on board; everyone needs to update syntax usage of [Exposed] a bit anyway |
| 11:06 | <annevk> | JakeA: however, we'll still need to decide what gets to use Worker and what gets to use SyncWorker or some such |
| 11:06 | <JakeA> | annevk: yeah, I'm struggling to find the docs on [Exposed] |
| 11:06 | <JakeA> | SyncWorker should be considered lagacy really |
| 11:06 | <annevk> | JakeA: http://heycam.github.io/webidl/ defines it |
| 11:06 | <JakeA> | heh, or even legacy |
| 11:07 | <JakeA> | cheers |
| 11:07 | <annevk> | JakeA: HTML defines Global=Window, Global=Worker, Global=DedicatedWorker, Global=SharedWorker |
| 11:07 | <annevk> | JakeA: basically we should ask Hixie to also define Sync/LegacyWorker as synonym for DedicatedWorker/SharedWorker |
| 11:08 | <annevk> | JakeA: and then go through all APIs and ensure they are annotated in the correct way |
| 11:08 | <annevk> | JakeA: and SW would define [Global=(Worker,ServiceWorker)] on its global |
| 11:11 | <JakeA> | annevk: why [Global=(Worker,ServiceWorker)] rather than [Global=(ServiceWorker)]? |
| 11:12 | <annevk> | JakeA: I thought you wanted FormData to be exposed as is, and not require updating it to say Exposed=(Window,Worker,ServiceWorker) |
| 11:18 | <JakeA> | annevk: ok, starting to get my head around how [Global] |
| 11:19 | <JakeA> | …works |
| 11:38 | <annevk> | [Global] indicates the name of the global, [Exposed] indicates what is exposed on it |
| 11:38 | <annevk> | [Global] also indicates the class is a global |
| 11:49 | <annevk> | foolip: so I tried to figure out how this would work in JS. In JS, you'd request the resize. Get an event when that's done (stable state) and from there you'd change state and potentially dispatch another event to tell other observers. |
| 11:50 | <annevk> | foolip: the only problem is communicating with the cross-origin bits. |
| 12:55 | <foolip> | annevk: I read your email as well |
| 12:56 | <foolip> | is there anything I can do to help figure this out? I'm not coming up with any brilliant solutions TBH |
| 12:59 | <annevk> | I guess I need to find out what invariants we are trying to preserve |
| 13:00 | <annevk> | E.g. if you have A -> B -> A'. Are A and A' synchronous? |
| 13:01 | <foolip> | you mean if it's possible to do the checks synchronously, or if events should fire in the same task, or something else? |
| 13:01 | <annevk> | If A and A' were same-origin, should they be updated in the same animation frame, yes |
| 13:02 | <foolip> | didn't someone comment that animation frames were synchronized across frames already? |
| 13:02 | <annevk> | They are, but not across origins... |
| 13:03 | <annevk> | And A' cannot reach A I think due to B, though I'm not a 100% sure |
| 13:04 | <foolip> | I'm not sure about that either |
| 13:04 | <foolip> | can A and A' get each others windows or documents in some way? if not, then it doesn't matter |
| 13:05 | <annevk> | It matters a bit for how we phrase things in the specification I guess |
| 13:06 | <foolip> | for the sake of sanity, it's probably best to assume that no two iframes are in the same process, even if they're same-origin |
| 13:06 | <annevk> | So the case I'm concerned with is that a descendant puts something in the animation frame queue of its parent, but then the parent navigates or removes the <iframe> of the descendant |
| 13:06 | <foolip> | I suppose the question is if an API designed around that will have observable racy behavior for same-origin iframes |
| 13:07 | <annevk> | I guess before you update state in an animation frame, you need to make sure your document is still "sane" |
| 13:07 | <foolip> | right... |
| 13:08 | <foolip> | when one believes that a document is in fullscreen, queue the task that is synchronized with animation frames |
| 13:08 | <foolip> | when we get to that task, we will know if the frame we're about to paint is actually a fullscreen frame or not |
| 13:08 | <foolip> | I suppose one could base some decisions on that, and at least let each individual frame have a consistent view of things |
| 13:09 | <annevk> | If you have A -> B -> C |
| 13:10 | <annevk> | B invokes requestFullscreen(), C invokes exitFullscreen() |
| 13:11 | <annevk> | Is it possible that A gets messages about updating its state to exit fullscreen before it updates to fullscreen, whereas the others get it in a different order? |
| 13:12 | <foolip> | if C invokes exitFullscreen() before B has successfully entered fullscreen, it won't do anything, right? |
| 13:12 | <annevk> | Well B could have entered fullscreen, but that does not say anything about A per se |
| 13:13 | <annevk> | Well, unless the IPC queue is global |
| 13:13 | <foolip> | if B has successfully entered fullscreen, then A will have an iframe on the fullscreen element stack and can't enter fullscreen |
| 13:13 | <annevk> | And the IPC queue is ordered |
| 13:13 | <foolip> | the races will be between requests to enter I think, not between enter and exit |
| 13:13 | <beverloo> | JakeA, ping |
| 13:14 | <annevk> | foolip: B can have entered fullscreen, but A does not need to have the message processed that updates its fullscreen element stack |
| 13:14 | <JakeA> | beverloo: pong! |
| 13:14 | <annevk> | foolip: the "worry" was that the message from C could arrive in A before B's message arrives |
| 13:14 | <foolip> | ah yes |
| 13:15 | <annevk> | But assuming a global ordered non-racy IPC queue... |
| 13:15 | <foolip> | well it's ordered for sure, but non-racy in what sense? |
| 13:16 | <foolip> | if two frames wait for Date.now() to be a whole minute or something and then post events, then those two events aren't in a predictable order |
| 13:16 | <foolip> | I guess that's not what you mean thouhg |
| 13:18 | <foolip> | maybe something can be gained from the fact that a request must come from a trusted input event |
| 13:18 | <foolip> | those come from the top-level process after all, so any requests must happen while it's being processed |
| 13:19 | <foolip> | although I'm pretty clueless about input event handling |
| 13:19 | <annevk> | So B invokes requestFullscreen and after some time posts messages to A and C. Then after C gets its message it can invoke exitFullscreen() and post messages to B and A. |
| 13:19 | <annevk> | Can A get C's before B's? |
| 13:20 | <annevk> | Yeah, that helps masking the problem |
| 13:22 | <foolip> | I think no, if B first posts a message to A and after that posts a message to C, nothing that C does in that message can arrive at A before B's message |
| 13:22 | <foolip> | if that's not true assumption, then sanity is nowhere to be found I think |
| 13:23 | <annevk> | I guess we should be okay then... Apart from working out how to synchronize with animation frames |
| 13:24 | <foolip> | Sounds promising |
| 13:24 | <foolip> | I can dig up the order of things in Blink's event synchronizing code if needed |
| 13:25 | <foolip> | the most basic thing is that all events for an animation frame are fired before the requestAnimationFrame callback, but you could probably guess that much |
| 13:25 | <foolip> | I'd be shocked if it's actually spec'd though |
| 13:28 | <jgraham> | It is kind of unfortunate that no one apart from bz seems to have held the web-perf people to account |
| 13:28 | <foolip> | jgraham: what's that about? |
| 13:29 | <jgraham> | foolip: What's what about? |
| 13:30 | <Ms2ger> | webperf |
| 13:30 | <jgraham> | The web-perf people did rAF and various other specs |
| 13:30 | <jgraham> | But is lacking people who are sufficiently aware of the quality requirements for modern web specs |
| 13:31 | <jgraham> | So I am unsurprised that you would be shocked if they had spec something |
| 13:31 | <jgraham> | *speced |
| 13:33 | <annevk> | I wonder what /*sealed*/ means in HTML |
| 13:34 | <Ms2ger> | Nothing |
| 13:34 | <Ms2ger> | It's just a reminded to himself that you can't inherit from global objects |
| 13:36 | <annevk> | Document has it too |
| 13:38 | <Ms2ger> | Huh |
| 13:39 | <beverloo> | annevk, hi |
| 13:39 | <annevk> | hey |
| 13:39 | <beverloo> | so, web notifications and service workers |
| 13:40 | <beverloo> | jake found this document: https://gist.github.com/jungkees/3154398b8deee7c70139 |
| 13:40 | <JakeA> | annevk: the latter half on events is relevant |
| 13:41 | <beverloo> | it answers the event question indeed, and suggest methods to accept an optional service worker argument |
| 13:41 | <beverloo> | since the web notification api would define a property in the init dictionary instead, we could require it to be a ServiceWorker instance |
| 13:42 | <JakeA> | beverloo: it should be the ServiceWorkerRegistration instance, now we have those |
| 13:42 | <JakeA> | (we didn't when the doc was first created) |
| 13:43 | <annevk> | that seems a bit nicer than a scope |
| 13:45 | <annevk> | beverloo: the event name should be notificationclick |
| 13:45 | <JakeA> | The alternative is new serviceWorkerRegistration.Notifiation(), but feels silly to duplicate |
| 13:45 | <beverloo> | annevk, yes |
| 13:45 | <annevk> | (not activate as per email) |
| 13:46 | <beverloo> | agreed :) |
| 13:46 | <Ms2ger> | notificationDOMActivate |
| 13:46 | <annevk> | if you created the Notification object in the service worker |
| 13:46 | <annevk> | what happens then? |
| 13:46 | <annevk> | should it automatically set its serviceWorker member? |
| 13:47 | <annevk> | are events dispatched to both places? |
| 13:47 | <beverloo> | given that the lifetime of a service worker cannot be relied upon, we'd default to serviceWorker=[active ServiceWorkerRegistration] |
| 13:47 | <beverloo> | it does raise questions for |onerror| though |
| 13:48 | <annevk> | is ServiceWorkerRegistration available inside the service worker global environment? |
| 13:48 | <JakeA> | annevk: it could be. Not an unreasonable request. |
| 13:48 | <JakeA> | annevk: events should only be dispatched to one |
| 13:49 | <annevk> | For the API it does not matter much, as long as there's some abstract concept I can associate with |
| 13:49 | <annevk> | JakeA: to either the SW or the object? |
| 13:49 | <JakeA> | annevk: a running serviceworker knows its registration, that's not a problem |
| 13:49 | <annevk> | JakeA: currently events are dispatched to all associated objects |
| 13:50 | <annevk> | I guess I could see an argument for only dispatching events to an SW if one was provided at registration time or if it was created in an SW |
| 13:50 | <JakeA> | annevk: ok, it should be one or the other. If the notification has an associated serviceworker, it should only fire the event in the serviceworker |
| 13:50 | <JakeA> | yep |
| 13:50 | <annevk> | However, that'd argue for exposing all events in the SW, not just two |
| 13:51 | <JakeA> | beverloo: what's the issue with firing all events within the sw? |
| 13:51 | <beverloo> | there's a hypothetical issue with onnotificationshow -- if we'd ever allow delayed notifications it could be used to set precise timers |
| 13:51 | <annevk> | If someone could summarize this on the list that'd be great. I think this works, still trying to sort out some other spec issues, so much to do :/ |
| 13:52 | <annevk> | Unless there's more? |
| 13:52 | <beverloo> | but that's purely hypothetical at this point. there's no issues with onnotificationerror as far as I'm aware |
| 13:52 | <annevk> | Ooh, we probably don't want to boot up the SW for show either |
| 13:53 | <JakeA> | annevk: is that a security issue? |
| 13:53 | <annevk> | Just wasteful I guess |
| 13:54 | <JakeA> | annevk: if people don't addEventListener for it, we don't have to wake it up. But I guess we'll be talking about that later :) |
| 13:54 | <annevk> | But maybe we should do it, yes |
| 13:54 | <annevk> | You'll go into history as the guy who abused the event system beyond repair |
| 13:55 | <JakeA> | can always set which events you want as part of the install event, but I'd rather not |
| 14:20 | <annevk> | beverloo: JakeA: each event would implement NotificationEvent I take it which has a pointer to a Notification object? |
| 14:20 | <JakeA> | annevk: yep |
| 14:20 | <annevk> | could reuse CustomEvent event, but bit weird |
| 14:31 | <JakeA> | annevk: are there any other *Sync APIs aside from filesystem? |
| 14:32 | <JakeA> | I notice the IDB ones have been burned to the ground |
| 14:32 | <annevk> | JakeA: I thought IDB was implemented in Firefox |
| 14:32 | <annevk> | JakeA: XMLHttpRequest has a sync API |
| 14:33 | <annevk> | JakeA: we could disable the sync part of XMLHttpRequest in service workers, or we could not expose XMLHttpRequest at all... |
| 14:34 | <JakeA> | annevk: yeah, I'm happy with disabling the sync part. Losing all of xhr could mean already-existing libraries can't be used in importScripts. (but I can't find any useful worker-compatible scripts that use XHR) |
| 14:35 | <annevk> | Well, if existing libraries use it synchronously that'd break too |
| 14:35 | <JakeA> | true |
| 14:36 | <Ms2ger> | Would you expose importScripts? |
| 14:37 | <annevk> | Ms2ger: only during install or some such... not entirely sure how that is going to be monkey patched up the chain |
| 14:52 | <JakeA> | yeah |
| 15:35 | <Manishearth> | Ms2ger: which spec? HTTP? |
| 15:35 | <Manishearth> | I can ... co-write, maybe. |
| 15:35 | <Manishearth> | Write a whole spec? I'll end up with security bugs in the spec itself. No thanks, don't want to be the next Heartbleed. :P |
| 15:37 | <Manishearth> | Ah, HTTP header parsing errors. Hmm |
| 15:52 | <annevk> | That is where all the security errors would be, mind you ;-) |
| 15:57 | <jgraham> | Manishearth: The possibility of writing security bugs into the spec is a terrible reason not to write the spec. Typically more people read the spec than particular implementations, and having one spec that defines how to handle all possible inputs is a huge net good for reducing security errors |
| 16:00 | <Manishearth> | jgraham: Yeah, but neither am I (a) experienced with spec writing, nor (b) *that* knowledgeable about HTTP headers -- The security bugs was a joke, but seriously speaking I don't think I'd be able to do this alone |
| 16:03 | <jgraham> | Manishearth: Sure, I wouldn't expect you to |
| 16:03 | <Manishearth> | I would love to be part of a joint effort :) |
| 16:03 | <annevk> | Manishearth: let mnot know |
| 16:04 | <jgraham> | Manishearth: Usually the way these things work is N people express an interest in editing. Then between N and N-1 of them find out that they don't have the time or the inclination, so 0 or 1 people do 100% of the writing |
| 16:04 | <Manishearth> | I don't have the time, but I ought to be able to make time. |
| 16:04 | <jgraham> | (other people still contribute feedback ofc) |
| 16:04 | <astearns> | shh, jgraham - don't scare him off |
| 16:04 | <Manishearth> | haha |
| 16:05 | <Manishearth> | I have a tendency of overloading myself. Already overloaded, and today I decided to TA a course. Blah. |
| 16:26 | <Hixie> | what would a "Sync" worker be? |
| 16:26 | <Manishearth> | Hixie: THat exists? |
| 16:27 | <Hixie> | i dunno, some people were talking about it earlier |
| 16:27 | <Hixie> | i didn't follow the conversation |
| 16:27 | <Ms2ger> | Hixie, dedicated worker |
| 16:27 | <Hixie> | how is a dedicated worker "sync"? |
| 16:27 | <Manishearth> | a sync worker makes no sense |
| 16:27 | <Manishearth> | ah |
| 16:27 | <Hixie> | and how is a shared worker any less "sync"? |
| 16:27 | <Ms2ger> | Hixie, in the sense that it gets access to FooSync APIs |
| 16:27 | <Ms2ger> | Shared too |
| 16:27 | <Ms2ger> | But not ServiceWorker |
| 16:27 | <Manishearth> | ah |
| 16:27 | <Hixie> | o_O |
| 16:27 | <Hixie> | why would service worker not get the same apis? |
| 16:28 | <Manishearth> | hooray for nomenclature |
| 16:28 | <Ms2ger> | Because it's not supposed to block |
| 16:28 | <Hixie> | why would it matter if it blocks? and how would you stop it from blocking? |
| 16:28 | <Hixie> | are service workers going to have script timeouts like main thread scripts? |
| 16:28 | <Ms2ger> | annevk, ^ |
| 16:29 | <annevk> | not sure, they might die at any point |
| 16:29 | <annevk> | but that seems like a good question to ask in that thread |
| 16:44 | <Hixie> | annevk: so are we going to give up on killing mutation events? or what? |
| 16:50 | <annevk> | Hixie: smaug____ still has hope, so I haven't given up just yet |
| 16:52 | <Ms2ger> | I'd certainly like to not implement them in Servo |
| 16:53 | <Ms2ger> | Hixie, er... *goes off to check the spec* |
| 16:54 | <Ms2ger> | Hixie, no, I think I'm right |
| 16:54 | <Hixie> | The :disabled pseudo-class must match any element that is actually disabled. |
| 16:54 | <Hixie> | An element is said to be actually disabled if it falls into one of the following categories: |
| 16:55 | <Hixie> | button elements that are disabled |
| 16:55 | <Hixie> | A form control is disabled if its disabled attribute is set, or if it is a descendant of a fieldset element whose disabled attribute is set and is not a descendant of that fieldset element's first legend element child, if any. |
| 16:55 | <Ms2ger> | Stop |
| 16:55 | <Ms2ger> | I'm talking about fieldsets |
| 16:55 | <Hixie> | what about them? |
| 16:55 | <Hixie> | oh nested ones? |
| 16:55 | <Ms2ger> | Yes |
| 16:55 | <Hixie> | ohhh |
| 16:55 | <Hixie> | iteresting |
| 16:55 | <Hixie> | int... |
| 16:55 | <Ms2ger> | "fieldset descendant of a disabled fieldset" |
| 16:56 | <Hixie> | i interpreted "fieldset descendant" in the same sense as "italian descendant", as in, a descendant of a fieldset |
| 16:56 | <Hixie> | my bad |
| 16:56 | <Ms2ger> | Fair :) |
| 16:59 | <Hixie> | man, i'm so bad at being a human. i came into this room an hour ago to get a drink. then i sat down just to see what was going on online, and an hour later, i still haven't gotten a drink. |
| 17:00 | <smaug____> | Mutation events sure are in my list to kill |
| 17:00 | <Hixie> | seems like if we manage to kill showModalDialog() before mutation events, mutation events are a bit too hardy to kill. |
| 17:02 | <Domenic> | I think MutationEvents will die slowly over the next few years, event-by-event |
| 17:02 | <Hixie> | we don't have much history of usage of a feature going down over time. |
| 17:03 | <Domenic> | Hmm I thought I recalled some chromestatus graphs indicating otherwise |
| 17:03 | <Domenic> | I think loud deprecation warnings help actually |
| 17:03 | <Hixie> | having those is relatively new, so yeah, maybe they have an effect |
| 17:03 | <Hixie> | though honestly i'd be surprised |
| 17:04 | <Ms2ger> | One can hope ;) |
| 17:08 | <Hixie> | MikeSmith: for validator reasons, be aware of https://www.w3.org/Bugs/Public/show_bug.cgi?id=25572 |
| 17:17 | <Domenic> | JakeA: yaaaay for removing the * |
| 17:19 | <annevk> | jamesr__: that email was somewhat depressing |
| 17:20 | <annevk> | jamesr__: I believe roc still holds hope for the storage mutex in Servo |
| 17:23 | <jamesr__> | annevk: the status quo is a bit depressing, but once you accept it the possibilities are much freer |
| 17:31 | <annevk> | jamesr__: and the apps harder to debug? |
| 17:32 | <jamesr__> | theoretically, yes, in practice, it doesn't seem so |
| 17:34 | <annevk> | jamesr__: also, my problem in that thread is mostly what state the browser will end up in, not so much the page's app |
| 17:39 | <jamesr__> | the page can't tell about any of this for the most part. if a page calls requestFullscreen(), the UA is allowed to do any number of async steps before deciding to accept or reject the promise |
| 17:39 | <jamesr__> | so from the page's POV it just gets an accepted or rejected promise at some point later |
| 17:49 | <annevk> | jamesr__: if the updating of document state races can't the page get in a state where when it's first notified it's fullscreen it's for a different element from the one it requested? |
| 17:51 | <jamesr__> | can't that happen without races? |
| 17:51 | <jamesr__> | i.e. i ask for fullscreen on X, the ua pops an infobar asking the user if they want to allow X, then somebody request fullscreen on Y, the ua pops an infobar asking for permission, the user allows Y ? |
| 18:09 | <annevk> | I thought we had no infobars. Hmm |
| 18:21 | <JakeA> | Domenic: yeah, it's late in the day to be removing that, but needed to go |
| 18:23 | <zewt> | surely every ua would have a "yes always stop bothering me every time" button |
| 18:23 | <zewt> | though browsers today are pretty bad about fullscreen, iirc no way to stop the obnoxious "you're fullscreen now" thing every single time |
| 18:55 | <Ms2ger> | What do people use for http fetching in python nowadays? |
| 18:58 | <jgraham> | requests |
| 18:59 | Ms2ger | tries that |
| 19:11 | <Ms2ger> | jgraham, shouldn't root.find("span[@id='summary']") work? |
| 19:12 | <jgraham> | Which treebuilder? If it's ElementTree it only supports a bastardised subset of XPath |
| 19:13 | <Ms2ger> | "the default" |
| 19:13 | <jgraham> | Oh and .find only seems to look at children |
| 19:14 | <Ms2ger> | Doh |
| 19:14 | <jgraham> | Oh wait I lied |
| 19:15 | <jgraham> | The documentation is self-contradictory |
| 19:15 | <jgraham> | You porbably want a // though |
| 19:15 | <jgraham> | "//span[@id='summary']" |
| 19:15 | <Ms2ger> | SyntaxError: cannot use absolute path on element |
| 19:15 | <jgraham> | Add a . then |
| 19:16 | <jgraham> | .// |
| 19:16 | <Ms2ger> | Then it doesn't find anything :/ |
| 19:16 | <jgraham> | Does it find anything without the attribute selector? |
| 19:16 | <Ms2ger> | With ".//[@id='summary']" it manages to raise SyntaxError("invalid descendant") |
| 19:17 | <Ms2ger> | Aha |
| 19:17 | <jgraham> | Yeah, that's not valid XPath |
| 19:17 | <Ms2ger> | ".//*[@id='summary']" seems to find something |
| 19:17 | <Ms2ger> | Looks like perl to me, but oh well |
| 19:18 | <jgraham> | To be fair CSS Selectors look even more like Perl for non-trivial cases |
| 19:18 | <jgraham> | XPath is mostly consistent, it's just complex for any case |
| 19:19 | <Ms2ger> | Had I just used regexps rather than html5lib, I'd probably have cursed less now |
| 19:19 | <Ms2ger> | (And more later, of course) |
| 19:57 | <Ms2ger> | MikeSmith, there's no API to get at the summary of w3.org bugs, right? |
| 20:03 | <Hixie> | Ms2ger: bugzilla has an api |
| 20:03 | <Ms2ger> | Does it work on the w3.org installation? |
| 20:04 | <Hixie> | yeah, it's what i use to graph total bugs |
| 20:05 | <Ms2ger> | Pointer? |
| 20:06 | <Hixie> | uh |
| 20:07 | <Hixie> | dunno |
| 20:07 | <Hixie> | can't see any comments in my code pointing to anything useful :-) |
| 20:08 | <Hixie> | try putting ctype=xml on the query string for a bug |
| 20:10 | <Ms2ger> | Aha |
| 20:29 | <Ms2ger> | Hixie, this seems to be reacting terrible slowly |
| 20:29 | <Hixie> | yeah i noticed that too |
| 20:29 | <Hixie> | dunno if it's always that slow |
| 20:48 | <Hixie> | MikeSmith: you around? |
| 20:49 | <Hixie> | MikeSmith: i was wondering how easy it would be to instrument the validator, or have something on the validator that would catch certain specific errors and encourage users to comment on the relevant bug |
| 20:49 | <Hixie> | MikeSmith: e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=12990 is asking for us to allow nested <footer>. Would we be able to detect this case and ask people to comment on that bug about why they need it, possibly linking to their page? |
| 20:53 | <Ms2ger> | Hixie, thanks for the pointer :) |
| 20:54 | <Hixie> | there's something you can do for queries too, iirc |
| 20:58 | <Ms2ger> | This was sufficient :) |
| 21:21 | <Hixie> | foolip: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=25573 |
| 22:01 | <SamB> | ... hmm, is it possible to scale an image to fit in a given box, keeping the aspect ratio, without knowing the dimensions of the image? |
| 22:09 | <Hixie> | SamB: from JS, or in general? |
| 22:09 | <Hixie> | or in CSS? |
| 22:09 | <SamB> | CSS |
| 22:09 | <Hixie> | yeah, there's some property for that |
| 22:09 | <Hixie> | background-cover or something |
| 22:09 | <SamB> | with JS, you could of course cheat and wait for the image to load |
| 22:11 | <SamB> | well, HTML + CSS; it's not an issue if it needs an extra box inside the main box |
| 22:12 | <SamB> | Hixie: background-size comes up when I search for that, and looks relevant |
| 22:16 | <SamB> | Hixie: hmm, looks like that has values "cover", which will avoid any blank parts at the expense of chopping off other bits, and "contain", which avoids cutting anything off at the expense of having blank spaces? |
| 22:17 | SamB | wonders how it is possible to have one intrinsic dimension AND an intrinsic proportion |
| 23:00 | <Hixie> | SamB: sounds about right |
| 23:28 | <Hixie> | zcorpan: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=25555 |