| 00:48 | <annevk> | Hmm, GitHub is down |
| 00:49 | <annevk> | Fortunately Git is decentralized harhar |
| 00:52 | <MikeSmith> | heh |
| 00:55 | <MikeSmith> | the graphs at https://status.github.com/ provide some entertainment value as we wait for life to begin again |
| 00:58 | <MikeSmith> | I like how the Server Availability one shows a 95% average for the day, since it was 100% all day til now that it's 0% |
| 00:59 | <MikeSmith> | anyway I guess I'll use the opportunity to stare out the window for a while |
| 06:24 | <Domenic> | philipj is on an editing blitz while annevk and I are stuck in meetings this week :D |
| 06:26 | <philipj> | Domenic: just doing some easy stuff to avoid the hard stuff (play() promises) :) |
| 06:34 | <MikeSmith> | heh |
| 06:51 | <botie> | zcorpan, at 2016-01-27 23:24 UTC, MikeSmith said: about <template><source src="" srcset=""></template> checking, if you mean the errors for the empty values, suppressing those is doable though somewhat significantly more work to implement in the checker than the attribute-is-just-missing case and at |
| 06:51 | <botie> | 2016-01-27 23:31 UTC, MikeSmith said: abou 「the spec has requirements forelements that are not in a document」I'm not sure what you mean, so please enlighten me further |
| 06:52 | <zcorpan> | MikeSmith: i meant that both src and srcset attributes were present |
| 06:53 | <zcorpan> | MikeSmith: for the other, consider e.g. <script>var img = document.createElement('img');</script> - now that img element is not conforming because it lacks a src attribute |
| 06:54 | <ritsyy> | philipj: for these urls https://w3c.github.io/webappsec-csp/#initialise-global-object-csp (line 2661) https://w3c.github.io/webappsec-csp/#initialise-document-csp (lines 2661, 58669) , http should be done right? |
| 06:55 | <zcorpan> | MikeSmith: i think we need to allow arbitrary values for all attributes, so you can do <img src="{{url}}"> etc |
| 06:56 | <philipj> | ritsyy: I'm not sure what you mean, but see https://github.com/whatwg/html/pull/574 and the other PRs linked from https://github.com/whatwg/html/issues/573 |
| 06:57 | <zcorpan> | MikeSmith: so what i wondered was if we should check presence of attributes based on other attributes, e.g. <template><input type=submit alt></template>, or don't bother |
| 06:58 | <philipj> | ritsyy: I actually think I've taken care of most issues, so it may be best to wait until they've been merged to see what remains |
| 06:58 | <ritsyy> | philipj: i was seeing the "broken URI fragments" of the link checker results |
| 06:58 | <ritsyy> | philipj: oh okay |
| 06:58 | <philipj> | ritsyy: the CSP one was because of en-US vs. en-GB |
| 06:58 | <philipj> | initialize vs initialise |
| 07:00 | <ritsyy> | philipj: okay yes i see that, okay will wait until the PRs merge |
| 08:04 | <MikeSmith> | zcorpan: so it seems like one way to consider the document-conformance requirements is that they can only apply to a specific state of a document, and certainly it's only possible to HTML-check a particular state |
| 08:04 | <MikeSmith> | so to me, the <script>var img = document.createElement('img');</script> case is sorta irrelevant |
| 08:06 | <MikeSmith> | because when you check the document in the state of the source prior to the JS executing, the contents of that script element are just an opaque string, text |
| 08:07 | <MikeSmith> | or when you consider it terms of the document-conformance requirements for the spec |
| 08:08 | <MikeSmith> | of course if we're considering (or checking) the resulting DOM, that's a different case (state) |
| 08:09 | <MikeSmith> | but I guess your point is that the <template> contents are similar to unexecuted JS in that regard |
| 08:11 | <MikeSmith> | to me I think the big difference is that we have no way to evaluate any part of arbitrary unexecuted JS in terms of the document-conformance requirements for the DOM it would produce |
| 08:11 | <MikeSmith> | since it could be doing anything in any number of ways |
| 08:12 | <MikeSmith> | but in constrast we do have a way to evaluate (static) <template> contents prior to JS execution |
| 08:13 | <MikeSmith> | we just clearly need to be more liberal about the requirements |
| 08:16 | <zcorpan> | MikeSmith: agreed on everything you just said, BUT it's not unreasonable to validate DOM at any point in time during a document's lifetime using a browser's devtools |
| 08:16 | <zcorpan> | MikeSmith: which could validate out-of-document trees just as easily as in-document trees, i would think |
| 08:17 | <MikeSmith> | yeah true |
| 08:17 | <MikeSmith> | incidentally I want to write devtools integration to actually do that |
| 08:17 | <MikeSmith> | though would be glad if somebody else beat me to it |
| 08:18 | <MikeSmith> | I can imagine that browser project could run their own vnu somewhere and their devtools could call that through its HTTP API and show the results |
| 08:19 | <MikeSmith> | sending the serialized DOM |
| 08:19 | <MikeSmith> | so yeah it's not actually so hypothetical a case |
| 08:19 | <MikeSmith> | I |
| 08:19 | <MikeSmith> | I am certain we will have it eventually |
| 08:21 | <MikeSmith> | but since for now the majority case is still people just checking their actual source, I guess I tend to think about the spec doc-conformance requirements more in terms of that, along with the checker behavior |
| 08:22 | <zcorpan> | MikeSmith: what do you think about skipping validation for <template> children altogether, and effectively only report parse errors? that seems like it would be simple to implement and solve the issue, but we'd miss typoed attribute names and content model violations |
| 08:23 | <MikeSmith> | zcorpan: that would be easier as far as the checker goes, but I think it would be less helpful to authors |
| 08:23 | <MikeSmith> | for the reasons you mentioned |
| 08:24 | <MikeSmith> | they can't catch typos |
| 08:25 | <MikeSmith> | and they may break the content-model rules in ways that, e.g., are going to result in a non-intuitive DOM |
| 08:25 | <zcorpan> | my thinking was that it could be more useful to validate the template's output, after transformation |
| 08:25 | <zcorpan> | aren't those parse errors anyway? |
| 08:26 | <MikeSmith> | yeah I guess they are more parse errors than validation |
| 08:26 | <zcorpan> | if someone does <template><ul> {{ if foo }} <li> bar </li> {{ /if }} </ul></template>, is it helpful to report the content model violation? |
| 08:28 | <MikeSmith> | and yeah it would be more useufl to validate the template's output and authors can actually do that now if they use something like the bookmarklets at https://validator.w3.org/nu/about.html#extras to send a DOM to the checker |
| 08:28 | <MikeSmith> | in teh case of <template><ul> {{ if foo }} <li> bar </li> {{ /if }} </ul></template>, no it's clearly not helpful to report errors there |
| 08:29 | <MikeSmith> | but I get your point |
| 08:29 | <MikeSmith> | in that it would be very hard to have the validator not report an error for that case |
| 08:29 | <MikeSmith> | and the only way to avoid it would just be to not check the subtree at all |
| 08:30 | <zcorpan> | given that we want to allow things like duplicate IDs, empty table rows, etc, i'm leaning more towards skipping validation altogether and focus our work on the more useful validate the output in a good way |
| 08:31 | <MikeSmith> | yeah I agree, given cases like <template><ul> {{ if foo }} <li> bar </li> {{ /if }} </ul></template> and the duplicate-ID case |
| 08:32 | <zcorpan> | really the content model for <template> should be "empty", since that's what it ends up being (unless you appendChild() to it) |
| 08:34 | <MikeSmith> | yeah, in terms of the behavior/function of it |
| 08:36 | <MikeSmith> | it's somewaht sad if we end up not being able to provide mistake-catching help for <template> contents in source, but I guess that gives me that much more motivation to make the devtools HTML checker integration happen, so that we can provide checking where it really should be in this regard |
| 09:25 | <zcorpan> | philipj is now officially the space-slash hitler :-D |
| 09:34 | <philipj> | zcorpan: it's a shit job, but someone has to do it |
| 09:35 | <philipj> | MikeSmith: there? I'm puzzled by [[ ! $QUIET = "true" || ! "$WATTSI_RESULT" = "0" ]] in build.sh |
| 09:37 | <philipj> | MikeSmith: trying to make wattsi run only once if there are no errors, which saves a few seconds every build |
| 10:01 | zcorpan | -> Arlanda |
| 11:31 | <ondras> | so, service worker push messages |
| 11:31 | <ondras> | the docs are so confusing |
| 11:31 | <ondras> | with respect to the "push service" |
| 11:31 | <ondras> | can *I* implement the push service on my server infrastructure? |
| 11:32 | <ondras> | or are my servers supposed to deliver push notifications by pushing them to {mozilla,google} ifrastructure? |
| 11:32 | <ondras> | can someone please provide some more insight -- or better, link to docs -- for this? |
| 12:16 | <JeanCarloMachado> | exit |
| 12:31 | <ondras> | JakeA: ^^ |
| 12:44 | <MikeSmith> | philipj: here now. did you get it worked out? |
| 12:44 | <MikeSmith> | I have some wattsi and html-build PRs pending to fix that |
| 12:45 | <MikeSmith> | in the mean time you'll need to edit the build script locally |
| 12:45 | <MikeSmith> | ondras: I believe you cannot implement the push service on your own server yet |
| 12:47 | <MikeSmith> | I think google's implementation currently only works with gcm and they haven't yet implemented support for the IETF Web Push protocol spec |
| 12:48 | <MikeSmith> | I think Mozilla has some support for them protocol already but not sure it's enough that you could implement a server yourself and have it work with Firefox |
| 12:51 | <JeanCarloMachado> | unbanme <channel> |
| 12:52 | <ondras> | MikeSmith: now I am puzzled. So to support all browsers, my servers would push to every vendor's push endpoint? |
| 12:52 | <ondras> | MikeSmith: sounds weird. Why no provide my own push enpoint as a parametrization to the service worker? |
| 12:53 | <ondras> | *not |
| 13:12 | <MikeSmith> | because there's no standard protocol that's been implemented in browsers yet |
| 13:13 | <MikeSmith> | well at least not in Chrome yet as far as I understand |
| 13:27 | <beverloo> | ondras, MikeSmith: there will be some turbulence in both implementations in the next few months |
| 13:27 | <beverloo> | encryption will slightly change, Chrome will switch to the Web Push protocol |
| 13:28 | <beverloo> | but we have slightly different requirements and will use server authentication, whereas Mozilla allows "anonymous" pushes |
| 13:28 | <beverloo> | happy to detail more if you're interested :) |
| 13:28 | <ondras> | well |
| 13:29 | <ondras> | I am interested in having a browser impl that allows me to specify my own endpoint |
| 13:29 | <beverloo> | Ah, right. No, we're very unlikely to allow that |
| 13:29 | <ondras> | beverloo: any particular reasons? |
| 13:29 | <beverloo> | the reason of the push API is exactly to avoid needing multiple persistent connections |
| 13:30 | <ondras> | beverloo: I mean, am I ultimately supposed to push data from my server to vendor{1..X}.pushservices.com ? |
| 13:30 | <beverloo> | which costs a fair amount of resources for the user (i.e. power usage) and causes network noise |
| 13:30 | <beverloo> | Yes |
| 13:30 | <ondras> | ah |
| 13:30 | <ondras> | :/ |
| 13:30 | <beverloo> | The goal of the standardization process is that you don't have to care how it gets to the user (whilst the user is protected by you not having their identity, only a key that may allow you to reach them) |
| 13:30 | <MikeSmith> | oh, all good to hear |
| 13:31 | <beverloo> | tickles are easy, but if you have payloads they must be encrypted because you don't know who the man in the middle is |
| 13:31 | <ondras> | beverloo: my priority here would be to have a guarantee of my own infrastructure for the delivery |
| 13:32 | <ondras> | but I guess this is an unreal request |
| 13:32 | <beverloo> | you could achieve that while the user is on the page, e.g. using web sockets, but for mobile devices it's much too expensive to keep a page (or even a Service Worker) running continuously |
| 13:32 | <ondras> | right |
| 14:24 | <philipj> | MikeSmith: I got distracted with other things |
| 14:25 | <philipj> | MikeSmith: like the html-build PR I just created, because it was on the same lines |
| 15:44 | <jgraham> | smaug____: I got 48, but maybe that changes if I turn off the Fx tracking protection thing |
| 15:45 | <jgraham> | Yup 624 in Chromew |
| 15:47 | <jgraham> | In case people were wondering: *that* is the biggest threat to the web. Not "mobile has more APIs" |
| 15:48 | <jgraham> | It's "native apps aren't 90% ad delivery to 10% content" |
| 15:49 | <smaug____> | ( I consider Facebook as the biggest threat to the web. ) |
| 15:54 | <Hory_> | only indirectly by being the biggest threat to humanity |
| 15:56 | <jgraham> | smaug____: It's part of the same problem |
| 15:57 | <tobie> | Hey, annevk, dom standard asks to ping WHATWG when wanting to create new Event interface. I'm not sure that's what I need to do for the sensor spec, though. |
| 15:57 | <jgraham> | If most websites are slow and messy it's not a surprise if people chose to use walled gardens, which then makes those walled gardens more attractive places to publish content |
| 15:58 | <annevk> | tobie: heh, me neither |
| 15:58 | <annevk> | tobie: I wonder if Streams can be reused in some way and/or what Domenic's thoughts are |
| 15:59 | <tobie> | So we discussed that already and agreed that no. |
| 16:00 | <tobie> | (reasoning, streams are for when you want to handle/buffer back-pressure, which isn't the case with sensors--mostly) |
| 16:01 | <annevk> | Okay, would that not be a way to slow down the rate of signals from the sensor? |
| 16:01 | <tobie> | annevk: (for ref: https://github.com/w3c/sensors/issues/70) |
| 16:01 | <annevk> | Anyway, if you want to use events, it's mostly suggesting to talk to us to see if your new Event subclass makes sense |
| 16:02 | <annevk> | Which I think shouldn't be a problem for you, but who knows 😛 |
| 16:03 | <tobie> | yeah--who knows. |
| 16:03 | <annevk> | So do all sensors really work identically enough that a single pattern makes sense? |
| 16:04 | <tobie> | So basically, there are two broad categories of sensors. Those that are polled at regular intervals (e.g. gyroscopes, etc.) |
| 16:05 | <tobie> | ... and those that are a bit smarter and sort of emit an event when they change beyond a certain threshold. |
| 16:06 | <tobie> | In practice, though, this distinction can be a bit muddied, as the latter type can actually be implemented in terms of the former. |
| 16:06 | <tobie> | I'm still struggling to find the right way to represent these two types on the platform. |
| 16:06 | <tobie> | See https://github.com/w3c/sensors/issues/75 for details. |
| 16:07 | <annevk> | I guess for polling perhaps just a method that returns a promise |
| 16:07 | <annevk> | And the treshold ones seems like an event |
| 16:08 | <tobie> | the polling is done at the hardware abstraction layer. |
| 16:08 | <tobie> | so the implementation basically sets a frequency and listens to the ouput. |
| 16:09 | <tobie> | So basically both categories are event targets. |
| 16:10 | <tobie> | One gets an event a regular intervals. The other on configurable changes. |
| 16:10 | <tobie> | What I had in mind for the Event interface was something like: |
| 16:11 | <tobie> | SensorReadingEvent : Event { readonly attribute SensorReading reading } |
| 16:12 | <tobie> | SensorReading basically contains a High resolution timestamp, an identifier to the sensor and sensor values (e.g. temperature, longitude, etc.) |
| 16:22 | <jochen__> | annevk: i think the idl level thing is a different thing |
| 16:22 | <jochen__> | annevk: that's about who may access that API at all |
| 16:22 | <jochen__> | while the in code check is about the origin, not the effective origin |
| 16:22 | <annevk> | ah |
| 16:23 | <jochen__> | MDN also mentions this |
| 16:23 | <jochen__> | https://developer.mozilla.org/en-US/docs/Web/API/Document/open#Gecko-specific_notes |
| 16:25 | <annevk> | thanks |
| 16:28 | <annevk> | jochen__: so do you want to make the style edits or shall I do that? |
| 16:49 | <jochen__> | I thought I already did? |
| 16:49 | <jochen__> | Maybe I forgot to push |
| 16:51 | <jochen__> | Apparently, I didn't :-( |
| 16:51 | <jochen__> | On the subway right now, will push later |
| 16:56 | <annevk> | ta |
| 17:15 | <Domenic> | tobie: is there a reason SensorReading is a separate interface instead of just properties on the event? |
| 17:16 | <tobie> | Domenic: https://github.com/w3c/sensors/issues/82 |
| 17:17 | <Domenic> | Hmm the overwriting timestamp question is tricky |
| 17:17 | <Domenic> | I think last we checked event timestamps cannot be changed as it breaks the web :( |
| 17:17 | <Domenic> | so dom needs high res timestamps as a separate property |
| 17:17 | <Domenic> | annevk should just add that |
| 17:18 | <tobie> | Domenic: there's also the oneshot, promise-returning method which needs to return a Reading object, not an event. |
| 17:18 | <annevk> | I thought that was still ongoing |
| 17:18 | <Domenic> | tobie: ah if that's the case then just a property makes sense to me |
| 17:19 | <annevk> | rbyers should know |
| 17:19 | <Domenic> | I think it broke Angular according to bz, which was game over |
| 17:20 | <tobie> | Could also do `SensorReadingEvent implement SensorReading` or something of the like. |
| 17:20 | <annevk> | I see |
| 17:21 | <annevk> | tobie: I was thinking that, little tricky with the initdict, but doable |
| 17:23 | <tobie> | At which point I could also do: `Sensor implement SensorReading` |
| 17:24 | <tobie> | So instead of doing: sensor.reading.temperature or event.reading.temperature you'd do sensor.temperature and event temperature in both cases. |
| 17:26 | <tobie> | I'm not sure if this isn't trading looks against cognitive load, though. E.g. what does sensor.timestamp mean? (Compared to sensor.reading.timestamp) |
| 17:28 | <Domenic> | Yeah I prefer separate object |
| 17:29 | <Domenic> | If SensorReading is going to be a first-class thing in other parts of the API it should be that here too |
| 17:29 | <Domenic> | Ideally sensor.hrTimestamp or whatever we end up with is === sensor.reading.timestamp |
| 17:29 | <Domenic> | (Hmm I think we spell it timeStamp) |
| 17:29 | <tobie> | well, that's a hard one, though. |
| 17:30 | <tobie> | is it event timestamp or sensor reading timestamp? |
| 17:30 | <Domenic> | sorry s/sensor.hrTimestamp/event.hrTimestamp |
| 17:30 | <Domenic> | ah i see |
| 17:30 | <Domenic> | so maybe not === |
| 17:30 | <Domenic> | that seems reasonable too |
| 17:30 | <Domenic> | i think people probably prefer the reading timestamp |
| 17:30 | <tobie> | yup |
| 17:31 | <tobie> | ideally latency = event.hrtimestamp - reading.timestamp |
| 17:31 | <tobie> | which screams for using hrtimestamp on the SensorReading too (or whatever it is going to be). |
| 17:32 | <tobie> | Thanks both of you (annevk + Domenic ). This is super helpful feedback. |
| 17:33 | <Domenic> | we should dig up those bugs and come to a conclusion and put it in the dom spec |
| 17:33 | <tobie> | <3 |
| 18:01 | <jochen__> | annevk: pushed the formating changes |
| 18:32 | <Domenic> | yay, jochen__'s first HTML spec patch! \o/ |
| 22:32 | <annevk> | I have another yay, we resolved the outstanding questions for HTML cross-origin objects, so once I integrate the answers, we can figure out how to merge the whole thing into the HTML standard |