| 05:18 | <annevk> | hayato: thanks for cleaning up past shadow DOM issues! |
| 08:43 | <tobie> | Hi all--in Bikeshed, does anyone know how I can both use markdown and use "algorithm" attributes on containers? |
| 08:44 | <tobie> | I'm getting: FATAL ERROR: Line 567 isn't indented enough (needs 1 indent) to be valid Markdown |
| 09:24 | <tobie> | Answering my own question: you don't need to indent markdown outside of containers, but you somehow do when it's inside a container. (Also know as: read the error message properly.) |
| 09:46 | <zcorpan> | tobie: i think you can remove indentation in either case if you like |
| 09:47 | <tobie> | zcorpan: oh, through a meta property or something? |
| 09:47 | <tobie> | I'm having the hardest time linking to algorithms. Any pointers? |
| 09:47 | <zcorpan> | tobie: no. i'm guessing you used something like 1 or 2 spaces indentation when you added the container? |
| 09:48 | <zcorpan> | tobie: use <dfn> and <a>? |
| 09:48 | <tobie> | zcorpan: no, there was no spacing at all. |
| 09:48 | <zcorpan> | tobie: huh. ok then i don't know |
| 09:49 | <tobie> | zcorpan: well, I'm using the algorithm attribute on the section title where the attribute is defined. |
| 09:49 | <tobie> | sorry: |
| 09:49 | <tobie> | zcorpan: well, I'm using the algorithm attribute on the section title where the algorithm is defined. |
| 09:50 | <zcorpan> | algorithm="" is to scope <var>s so bikeshed can complain if you use a var only once in an algorithm, it doesn't help with linking |
| 09:51 | <zcorpan> | you can link to sections or <dfn>s |
| 09:51 | <tobie> | mmm. that's unfortunate. |
| 09:52 | <tobie> | Is the sole point of naming the algorithm for error reporting, then? |
| 09:52 | <zcorpan> | yeah |
| 09:52 | <tobie> | gotcha |
| 09:52 | <tobie> | thanks! |
| 09:53 | <zcorpan> | it works about as well to just say <h3 algorithm> if you don't want to spend time naming things |
| 09:54 | <tobie> | right. |
| 09:56 | <zcorpan> | TabAtkins: when should <dfn abstract-op> be used? |
| 09:58 | <tobie> | It's weird though, because that makes things sort of redundant. |
| 09:58 | <tobie> | You have to do something like: |
| 09:59 | <tobie> | <h3 algorithm>Update State</h3>\n<p>The <dfn>Update State</dfn> algorithm… |
| 10:08 | <tobie> | zcorpan: so I'm now referencing the "update state" (https://w3c.github.io/sensors/#update-state) algorithm from within the "update reading" algorithm (https://w3c.github.io/sensors/#update-reading), and of course that creates an extra id (https://w3c.github.io/sensors/#update-state0) that points to the dfn. |
| 10:09 | <tobie> | I'm sure there's a more elegant solution to this issue, but I'm struggling to figure out what it should be. |
| 10:14 | <zcorpan> | tobie: HTML spec sometimes uses dfn in a heading |
| 10:14 | <zcorpan> | maybe try it and see what bikeshed makes of it :-) |
| 10:18 | <tobie> | zcorpan: https://w3c.github.io/sensors/#update-state |
| 10:18 | <tobie> | Updated only the first one so you could compare. |
| 10:19 | <tobie> | I think I'm going to go with that. |
| 11:16 | <mkwst> | tobie: `<h3 algorithm dfn>Update State</h3>` should define the term in the heading. |
| 11:16 | <tobie> | mkwst: oh! Wow. |
| 11:19 | <tobie> | Now _that_ is exactly what I was looking for. |
| 11:20 | <mkwst> | Bikeshed does basically everything. Something those things are less well documented than others, though. :) |
| 12:18 | <tobie> | Pondering whether a sensor event should move to an "idle" state after emitting an error event, have a specific "errored" state, or continue expecting more data from the underlying HW sensor. |
| 12:26 | <annevk> | tobie: depends a bit on the HW I guess |
| 12:27 | <tobie> | annevk: yeah, that what makes me uncomfortable, I guess. |
| 12:28 | <annevk> | tobie: does HW fail sometimes and then goes on or fail more permanently |
| 12:28 | <tobie> | So that would imply having a way to distinguish these failure "types" |
| 12:29 | <annevk> | tobie: I guess if you are considering switching states it's a bit more permanent than just a wrong value/read? |
| 12:30 | <annevk> | tobie: maybe, if we want to expose that amount of detail; also tells a lot about the device |
| 12:30 | annevk | is just brainstorming, fwiw |
| 12:30 | <tobie> | annevk: brainstorming is what I need here, so that's perfect. |
| 12:31 | <tobie> | annevk: so I transition state from "activating" to "active" when the first reading is received. |
| 12:32 | <tobie> | annevk: in the meantime I can get a "permission denied" error, which should clearly shut the sensor off. |
| 12:32 | <annevk> | Well, not the HW per se, some other window might be using it |
| 12:33 | <tobie> | annevk: oh, yeah absolutely. Granted User Agent can't really access the sensors themselves on most devices |
| 12:34 | <annevk> | Hopefully long term the UA is the OS |
| 12:35 | <tobie> | annevk: heh |
| 12:35 | <tobie> | Good point though. |
| 12:36 | <annevk> | But yeah, I guess it depends on what the HW does or what existing OS libs provide, prolly varies per sensor and over time 😊 |
| 12:37 | <tobie> | annevk: ok, so let's admit we can split errors into two categories. Terminal ones and others. |
| 12:38 | <tobie> | Terminal ones imply that sensor access is definitely severed. |
| 12:38 | <tobie> | Others that it might be a temporary glitch. |
| 12:40 | <annevk> | I think state === error is what you want |
| 12:40 | <tobie> | Terminal errors should: emit an error, reject the start() promise if that promise hasn't been resolved already, and change tge state back to "idle" (or "errored") |
| 12:40 | <annevk> | In the "permanent" failure cases |
| 12:40 | <tobie> | annevk: ok so you would add an "error" state for the permanent failure case. |
| 12:41 | <tobie> | Or "errored"? |
| 12:41 | <tobie> | yikes. |
| 12:41 | <annevk> | Yeah, if you dispatch a special event it's generally worth observing |
| 12:42 | <annevk> | On the object too, otherwise you have to keep track yourself |
| 12:42 | <annevk> | Bit ugly eg with XHR |
| 12:42 | <tobie> | Oh, do you mean an "error" attribute? |
| 12:43 | tobie | is confused. |
| 12:43 | <annevk> | I meant in terms of state |
| 12:43 | <tobie> | so: sensor.state === "error" |
| 12:44 | <annevk> | Detailed error info is never v0-1 |
| 12:44 | <annevk> | Yeah |
| 12:44 | <tobie> | yeah, I guess that's another good point. |
| 12:44 | <annevk> | error is easier than errored, but I guess you already noticed 😊 |
| 12:46 | <tobie> | annevk: sure, it's just weird to have a noun in the middle of adjectives and verbal actions. |
| 12:47 | <tobie> | Should that state imply the sensor object is good to throw away? |
| 12:47 | <tobie> | annevk: or would it be roughly the same as "idle" |
| 12:47 | <tobie> | i.e. you can give it another try? |
| 12:48 | <annevk> | I would reject start I guess |
| 12:48 | <annevk> | If HW failure, new thing would fail too |
| 12:49 | <tobie> | right, but permissioning might change |
| 12:50 | <annevk> | Hmm, not sure then |
| 12:50 | <annevk> | Biab |
| 13:11 | <annevk> | tobie: so how do permissions work here? Maybe start() can just return false and you return to idle? |
| 13:11 | <annevk> | tobie: not sure if coupling permission errors and HW errors is best |
| 13:13 | <annevk> | jochen__: if it's not too much trouble, it would be great to have Blink's origin setup as a reply to https://www.w3.org/Bugs/Public/show_bug.cgi?id=27378#c39 |
| 13:13 | <annevk> | jochen__: that and your review on the origin PR, pretty please |
| 13:14 | <tobie> | annevk: well, start's return promise is going to be rejected if the permission is denied |
| 13:15 | <tobie> | annevk: I would imagine other fatal errors to do the same. |
| 13:16 | <annevk> | tobie: so both are exceptional? |
| 13:17 | <annevk> | tobie: as in, if start() were synchronous you'd throw an exception for these cases? |
| 13:17 | <tobie> | yes, I mean if the sensor doesn't work or can't be accessed, it should just throw, |
| 13:21 | <tobie> | I guess I'm going to distinguish between fatal and nonfatal exceptions. |
| 13:24 | <tobie> | annevk: one last thing: what's your take on letting the API consumer control timeouts? Seems fetch doesn't have that ability. |
| 13:25 | <Ms2ger> | XHR does, no? |
| 13:26 | <tobie> | annevk: so basically something like: sensor.start(3000).then(...) or new Sensor({timeout: 3000}).start()... |
| 13:27 | <tobie> | Ms2ger: indeed |
| 13:29 | <annevk> | tobie: I would wait for cancelable promises |
| 13:30 | <annevk> | tobie: until that happens folks can create some kind of wrapper with setTimeout and eat up the extra cost of something being allocated they don't need |
| 13:31 | <annevk> | tobie: sensors needing cancelable promises will only help further them being created |
| 13:32 | <tobie> | annevk: mmm. |
| 13:33 | <tobie> | I'm not too sure what cancellable promises would give me in this case. |
| 13:35 | <annevk> | tobie: the way a timeout works is that it cancels the activity after a period of time |
| 13:36 | <annevk> | tobie: the activity is represented by the promise |
| 13:36 | <annevk> | tobie: we have a timer, what we lack is the cancel primitive |
| 13:36 | <tobie> | annevk: oh, so you're suggesting that this should not be an error. |
| 13:37 | <annevk> | tobie: if you make a timeout cause rejection, your API will likely be out-of-sync with fetch() where it will likely cause cancelation |
| 13:37 | <annevk> | tobie: it's a little unclear, but I wouldn't add the feature until we know |
| 13:37 | <tobie> | annevk: OK, what's the timeline for that? |
| 13:38 | <tobie> | roughly |
| 13:38 | <annevk> | tobie: Domenic gave an ETA of 2 months, but custom elements came in the way, and he's also working on JavaScript Zones, but that seems smallish |
| 13:38 | <annevk> | tobie: so, 6-12 months? :-p |
| 13:38 | <tobie> | :D |
| 13:41 | <tobie> | annevk: what's your plan for distinguishing timeout errors coming from the network layer from consumer timeout-based cancellation? |
| 13:43 | <annevk> | tobie: you mean from the UA? No plan as of yet |
| 13:44 | <annevk> | tobie: is a network error and prolly hard to change |
| 13:45 | <tobie> | annevk: right, so you will have both, then? |
| 13:45 | <tobie> | annevk: currently calling stop() while start's promised is unresolved throws an Abort error, so maybe I should defer that too, no? |
| 13:46 | <tobie> | * promise |
| 13:46 | <tobie> | Whereby "defer" I mean "wait for cancellable promises to be shipped" |
| 13:49 | <annevk> | tobie: yeah, maybe ask JakeA / Domenic |
| 13:50 | <annevk> | tobie: we'll have developer-controlled timeouts at some point |
| 13:50 | <tobie> | Well, you just did for me. :) |
| 13:51 | <annevk> | tobie: I could even imagine cancelablePromise.time(100) or some such, but takes a long time for convenient methods to get added to JavaScript |
| 13:51 | <annevk> | convenience* |
| 14:26 | <wanderview> | annevk: I was just in a meetup this week where a developer said "don't use promises, use observables because they can be canceled" |
| 14:33 | <tobie> | push-api "defines" a PermissionDeniedError DOM Exception. Is that going to make its way into WebIDL or should I use something else? |
| 14:34 | <tobie> | Oh, it actually uses a dfn: https://w3c.github.io/push-api/#dfn-permissiondeniederror |
| 14:34 | <Ms2ger> | You should kick whoever wrote that spec |
| 14:35 | <Ms2ger> | https://heycam.github.io/webidl/#dfn-error-names-table |
| 14:35 | <Ms2ger> | > If an error name is not listed here, please file a bug as indicated at the top of this specification and it will be addressed shortly. Thanks! |
| 14:35 | <Ms2ger> | NotAllowedError seems good enough, though |
| 16:39 | <wanderview> | annevk: the context of the meetup was angular2 which I guess offers observables or promises... you can either effectively |
| 16:43 | <wanderview> | would be nice to get cancelable fetch() though |
| 16:46 | <annevk> | Yeah, path to cancelable seems easier, but we'll find out soon enough |
| 16:51 | <jarek> | Why the spec allow something like "let option = new HTMLOptionElement()" but not "let button = new HTMLButtonElement()"? |
| 16:51 | <jarek> | Is this intentional or just work in progress? |
| 16:51 | <annevk> | yhirano_: I might not get to your XHR patch before Monday |
| 16:51 | <jarek> | s/allow/allows |
| 16:51 | <annevk> | yhirano_: sorry about that |
| 16:51 | <annevk> | jarek: which spec? I don't think either of those work |
| 16:52 | <annevk> | jarek: it only has new Option() |
| 16:52 | <jarek> | annevk: https://html.spec.whatwg.org/multipage/forms.html#the-option-element |
| 16:52 | <annevk> | jarek: note "Named" in "NamedConstructor" |
| 16:52 | <jarek> | annevk: they don't work in any browser afaik, but it should be easy to polyfill with proxies |
| 16:53 | <Domenic> | "easy" ... "proxies" .... O_o |
| 16:53 | <Ms2ger> | new HTMLOptionElement() does not work |
| 16:53 | <jarek> | annevk: I don't know WebIDL very well, what's the difference between NamedConstructor and Constructor? |
| 16:53 | <annevk> | jarek: if you can do that, would love to see it |
| 16:53 | <annevk> | jarek: note https://github.com/w3c/webcomponents/issues/369 for some difficulties with element constructors |
| 16:54 | <annevk> | jarek: NamedConstructor means the constructor name doesn't match the interface name |
| 16:54 | <annevk> | jarek: we also need to give each element a dedicated interface, or use arguments for local name, which gets ugly |
| 16:55 | <Domenic> | NamedConstructor basically creates a factory function that uses UA magic to construct the object |
| 16:55 | <Domenic> | It isn't a constructor at all |
| 16:55 | <jarek> | Domenic: window.HTMLButtonElement = new Proxy(window.HTMLButtonElement, {construct() { return document.createElement("button");}}); |
| 16:56 | <Domenic> | jarek: sure, or just window.HTMLButtonElement = function () { return document.createElement("button"); } |
| 16:56 | <Domenic> | meh I guess that breaks the .prototype link, the proxy is kind of nice |
| 16:59 | <jarek> | Domenic: the spec says "When invoked as a constructor, it must return a new HTMLOptionElement object" |
| 17:00 | <jarek> | the terminology used by Web Components specs is really overwhelming to me |
| 17:02 | <jarek> | so NamedConstructor (unlike Constructor) is defined for the internal purposes? Is that correct? |
| 17:04 | <jarek> | ahh, I get it now, as per spec, you can do "let option = new Option()", but you can't do "let option = new HTMLOptionElement()" |
| 17:10 | <tobie> | Domenic: apologies for: "[URL] is obsoleted by [WHATWG-URL]." I know this needs fixing. |
| 17:18 | <smaug____> | annevk: I still don't understand why you're favoring the 3rd param approach of addEventListener |
| 17:19 | <smaug____> | that is against the basic rule we've been following elsewhere |
| 17:19 | <smaug____> | "spec what browsers do" |
| 17:19 | <Domenic> | tobie: yes, would be great :). But somehow that spec references both so presumably something is going wrong on that end too. |
| 17:20 | <annevk> | smaug____: how? |
| 17:20 | <annevk> | smaug____: but basically, the alternatives are worse |
| 17:20 | <smaug____> | how? |
| 17:21 | <annevk> | smaug____: keeps an awkward boolean argument that was already confusing and makes it mandatory |
| 17:22 | smaug____ | notes that he was against making the boolean argument optional |
| 17:22 | <smaug____> | anyhow, the dictionary is for special cases only |
| 17:23 | <smaug____> | if you're going to use that, you sure should understand what different phases in dispatch mean |
| 17:23 | <annevk> | I don't think that would have worked with WebKit not requiring it, but that's also bad API |
| 17:23 | <annevk> | We might add more features going forward now it is easier to do so |
| 17:24 | <annevk> | This is a perfect way to enable more improvements without a whole redesign |
| 17:24 | <smaug____> | but this is totally not compatible with millions of browsers |
| 17:24 | <smaug____> | which won't be updated any time soon |
| 17:24 | <annevk> | It totally is |
| 17:25 | <annevk> | That is always a hazard with new features |
| 17:25 | <smaug____> | addEventListener is not a new feature |
| 17:27 | smaug____ | so doesn't understand the argument that keeping 3rd param as boolean is that bad. |
| 17:28 | <smaug____> | since the arguments for that have been like "I just don't like it" |
| 17:33 | <annevk> | Overloading of the third arg is the new feature, does not break compat, so seems great |
| 17:34 | <smaug____> | it does break compat. passing { capturing: false} ends up being interpreted as true in older browsers |
| 17:35 | <smaug____> | s/capturing/capture/ |
| 17:35 | <annevk> | Sure, so would most new features |
| 17:35 | <annevk> | That is why devs use libs |
| 17:36 | <annevk> | That feature test |
| 17:36 | <annevk> | And dismissing ergonomics like it is not a thing is unfair |
| 17:36 | <smaug____> | if the argument is now that devs use libs, then we can totally use 4th param approach, since that will be hidden anyway in the libs |
| 17:36 | <annevk> | API design matters |
| 17:37 | <annevk> | Hopefully not long term for all things |
| 17:49 | <annevk> | https://twitter.com/bitsgalore/status/709382042895654912 wow Steven Pemberton hasn't really changed his tune much if anything |
| 17:53 | <jgraham> | Mmm XForms + XSLT |
| 17:54 | <jgraham> | Nice punchline |
| 18:05 | <MikeSmith> | Steven is embarrassing himself with that stuff at this point |
| 18:06 | <MikeSmith> | it used to be kind of amusing but now it’s just sad |
| 18:46 | <MikeSmith> | TabAtkins: I think you may make better use of retweets than anybody else I know |
| 18:47 | <MikeSmith> | case in point your retweet about http://gutenberg-poetry.decontextualize.com/ |
| 18:55 | <Mek> | MikeSmith: I'm the volunteer/victim jsbell found to edit FileAPI... could you give me ('mkruisselbrink') the appropriate powers to be able to do so? |
| 18:55 | <jsbell> | \o/ |
| 19:01 | <MikeSmith> | w00t |
| 19:01 | <MikeSmith> | howdy Mek |
| 19:01 | <MikeSmith> | jsbell++ |
| 19:01 | <MikeSmith> | y’all rock the bells |
| 19:01 | <MikeSmith> | Mek: yup will do right now |
| 19:02 | <MikeSmith> | done |
| 19:02 | <Mek> | MikeSmith: awesome, thanks |
| 19:03 | <MikeSmith> | Mek: very glad this landed on your plate |
| 19:03 | <MikeSmith> | I “know” you from seeing your comments/contributions to other repos |
| 19:41 | <aklein> | Domenic: do you happen to know anything about <script> in SVG? |
| 19:41 | <aklein> | Domenic: Blink's implementation of script handling doesn't do a lot to distinguish between the processing model of HTML and SVG scripts, wondering how hard it would be to spec type=module for SVGScriptElement |
| 19:44 | <aklein> | hmm, the current spec just seems to have placeholders for some of the "new" HTML features anyway |
| 19:44 | <aklein> | https://www.w3.org/TR/SVG2/interact.html#ScriptElement |
| 19:54 | <Domenic> | aklein: yeah I don't know much... I remember an open bug or two |
| 19:55 | <Domenic> | Can we just make SVG2 use HTMLScriptElement? TabAtkins heycam|away |
| 19:56 | <pdr> | Domenic, I don't think we can for namespace reasons |
| 19:56 | <TabAtkins> | Domenic: I'm 100% for it, same with <style>. SVGWG is for it, as long as browsers are okay with compat. Objection is what pdr said. |
| 19:56 | <pdr> | But the spec says ""A ‘script’ element is equivalent to the ‘script’ element in HTML and thus is the place for scripts"" which seems to me to mean that the two are equivalent and module should work for svg too |
| 19:57 | <Domenic> | pdr: I thought the plan was for SVG2 to merge the namespaces or something |
| 19:58 | <Domenic> | pdr: does it also say that SVGScriptElement is "equivalent" to HTMLScriptElement? |
| 19:58 | <TabAtkins> | tobie: Headings can define things, too. <h3 algorithm abstract-op>Update State</h3> works. |
| 19:59 | <Domenic> | I guess not |
| 19:59 | <TabAtkins> | tobie: The markdown rules, generally, are that when you open a container element the contents have to be indented one more level. |
| 19:59 | <Domenic> | TabAtkins: doesn't svg have a version parameter that could help with any compat issues? |
| 19:59 | <tobie> | TabAtkins: yeah, I assumed dfn was a tag and thus… |
| 19:59 | <TabAtkins> | Domenic: No. |
| 19:59 | <TabAtkins> | tobie: I don't understand what you mean. |
| 20:00 | <TabAtkins> | Oh! "dfn" type definitions. |
| 20:00 | <Domenic> | TabAtkins: <svg xmlns="http://www.w3.org/2000/svg"; version="1.1"> |
| 20:00 | <TabAtkins> | Yeah, sorry about that being confusing. Mistake on my part early on in naming, can't be fixed now. |
| 20:00 | <TabAtkins> | Domenic: That has no effect on anything. |
| 20:00 | <Domenic> | I guess you're saying browsers don't want to implement a version switch, which is fair |
| 20:00 | <TabAtkins> | Yeah. |
| 20:01 | <tobie> | TabAtkins: gotcha, np. As most things, obvious once you're aware of it, arcane before then. |
| 20:01 | <Domenic> | This is the bug I remember BTW https://www.w3.org/Bugs/Public/show_bug.cgi?id=28753 |
| 20:03 | <TabAtkins> | Domenic: The *intention* is definitely that <svg:style> and <svg:script> be exactly identical to the HTML versions in every way. Whatever needs to be fixed to make that happen, we're happy to do. |
| 20:03 | <TabAtkins> | If we could make it automatic by merging them, that would be great, but some implementors have an aversion to "chameleon" elements that are identical in multiple namespaces. :/ |
| 20:04 | <Domenic> | TabAtkins: well saying that the element interface for ("http://www.w3.org/2000/svg";, "script") is HTMLSVGElement sounds like the right fix to me |
| 20:04 | <Domenic> | Darn implementers. |
| 20:04 | <Domenic> | *HTMLScriptElement |
| 20:09 | <TabAtkins> | Works for me. Poke at pdr and whoever's doing it in Firefox. ^_^ |
| 21:11 | <zcorpan> | TabAtkins: when should abstract-op be used? |
| 21:12 | <TabAtkins> | when you're defining an abstract operation. Use your best judgement. |
| 21:13 | <TabAtkins> | (I'm gonna add a metacategory for autolinking to dfn/abstract-op/any other English-language definition categories I add in the future, like <a idl> is for all IDL types, so it's easy to link.) |
| 21:13 | <TabAtkins> | Gotta do some more refactoring of the autolinker first to make that possible tho, because "abstract-op" doesn't automatically lowercase the definition, like "dfn" does. |
| 21:14 | <zcorpan> | i'm not familiar with the terminology "abstract operation" to be able to apply judgement. any example or pointer? |
| 21:17 | <TabAtkins> | Any time you're defining something that you'll call like a method, but it's just normal language. |
| 21:17 | <zcorpan> | ok |
| 21:18 | <TabAtkins> | Like https://dom.spec.whatwg.org/#get-the-parent |
| 21:18 | <zcorpan> | and so what does bikeshed do differently from "dfn"? |
| 21:18 | <TabAtkins> | It doesn't assume that it can lowercase it freely. |
| 21:19 | <TabAtkins> | https://github.com/tabatkins/bikeshed/issues/625 is where it was added, with examples asking for it. |