00:07
<rniwa>
Domenic: okay
00:07
<rniwa>
Domenic: let me know how that goes
08:30
<annevk>
TabAtkins: is it bikeshed or specref that causes {{DOMString}} to link to http:// rather than https://?
08:49
<Ms2ger>
annevk, https://github.com/w3c/web-platform-tests/pull/2667 really is unspecified?
08:52
<annevk>
Ms2ger: there's a number of mistakes there
08:53
<annevk>
Ms2ger: status should be 200 for a data URL, statusText "OK"
08:53
<annevk>
Ms2ger: ooh wait, non-GET
08:58
<annevk>
Ms2ger: commented
08:58
<Ms2ger>
Thanks
08:58
<annevk>
Ms2ger: but yes, we need a data URL spec
09:04
<Ms2ger>
Added it to https://wiki.whatwg.org/wiki/Specs/todo
09:06
<annevk>
https://twitter.com/mrphs/status/708548201800982528 is neat
09:06
<annevk>
I wonder if that should be in Fetch
09:32
<tobie>
annevk: which spec are you having the DOMstring issue in?
09:32
<annevk>
tobie: DOM
09:33
<annevk>
tobie: https://dom.spec.whatwg.org/#dom-core-changes
09:34
<tobie>
annevk: seems to be a bikeshed issue: http://www.specref.org/?q=webidl
09:40
<tobie>
annevk: afaik, bikeshed doesn't use Specref for x-spec references.
09:40
<annevk>
tobie: yeah, it uses Shepherd, sorry
09:40
annevk
is always a little confused about the whole setup
09:40
<tobie>
annevk: np
09:41
<tobie>
annevk: yeah, it's complicated is an understatement.
09:41
<tobie>
annevk: that's what you get when you have crappy data sources.
09:44
<AutomatedTester>
Hi all, I was wondering where I can see what the state of innerText is in terms of standardization
09:55
<annevk>
AutomatedTester: https://github.com/whatwg/html/issues/465
09:56
<AutomatedTester>
annevk: what does it need to get incorporated into a spec?
09:57
<tobie>
Bikeshed's unhappy with the following WebIDL: Promise<void> start();
09:57
<tobie>
Any idea why?
09:57
<tobie>
(it spits out: FATAL ERROR: IDL SYNTAX ERROR LINE: 5 - skipped: "Promise start()")
09:58
<annevk>
tobie: perhaps it needs to be &lt;void>?
09:58
<AutomatedTester>
tobie: do the <> need escaping?
09:58
<annevk>
AutomatedTester: someone needs to write formal prose
09:58
<annevk>
AutomatedTester: I suspect another hurdle might be lack of agreement between implementations
09:58
<annevk>
AutomatedTester: but I'm not sure if that should block having any spec at all
09:59
<AutomatedTester>
annevk: ok cool
10:00
<tobie>
annevk, AutomatedTester: tried that but forgot to save before running bikeshed. #facepalm
10:00
<AutomatedTester>
tobie: :D
10:01
<tobie>
ty
10:01
<AutomatedTester>
annevk: roc's spec describes the end state that I want, and I want to reference it in WebDriver
10:01
<AutomatedTester>
well... it's the closest thing to what I want
10:01
<AutomatedTester>
whats the best way to reference it?
10:02
<AutomatedTester>
direct to Roc's version? To the html issue?
10:09
<annevk>
AutomatedTester: both, I guess
10:10
<AutomatedTester>
awesome, thanks
10:43
<tobie>
Is there a standard way to define enum members? annevk, you seem to just do: <code>"foo"</code>, I'm seeing slightlyoff do <em>foo</em> instead, etc.
10:46
<annevk>
tobie: I use "<code>foo</code>" in prose
10:46
<annevk>
tobie: I don't see why <em> makes sense to denote a string
10:46
<tobie>
I think slightlyoff uses it to denote the concept behind the string.
10:47
<annevk>
Example?
10:47
<tobie>
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#service-worker-state-attribute
10:47
<annevk>
That spec is written by JakeA and jungkees
10:48
<tobie>
and https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#dfn-state
10:48
<tobie>
yeah, sorry, the original editor was slightlyoff
10:48
<annevk>
That looks loosely copied from what I used to, see e.g., https://xhr.spec.whatwg.org/#dom-xmlhttprequest-readystate
10:48
<annevk>
I no longer think that's useful
10:49
<JakeA>
Cargo-culted I guess
10:49
<tobie>
ok, so you just do <code>"foo"</code>
10:49
<annevk>
Fetch also used to format enums as <i>value</i>
10:49
<annevk>
I recently decided on "<code>value</code>"
10:49
<annevk>
tobie: quotes are not part of the value
10:50
<tobie>
oh. interesting.
10:50
<annevk>
tobie: they only illustrate it's a string, and not a byte sequence
10:50
<annevk>
(or something else altogether, although I'm not sure what that would be)
10:50
<annevk>
e.g. `<code>value</code>` is what I use for HTTP header values
10:51
<tobie>
Not sure such typographical nuance is the clearest way to convey that, but I don't think it matters either.
10:51
<annevk>
since those cannot be represented by strings, but it's still nice to represent them as strings...
10:51
<annevk>
well, there's an explainer of sorts upfront
10:51
<Ms2ger>
Should we document that on the wiki?
10:52
<annevk>
I hope to at some point document the styles in IDL and basically mandate them
10:52
<annevk>
Ms2ger: that might be useful
10:52
<tobie>
I was working off of those so far: https://github.com/tabatkins/bikeshed/blob/master/docs/markup.md#autolink-shortcuts
10:53
<tobie>
+ using <var> for variables.
10:53
<annevk>
There's need to be some spec at the top of the chain that defines these low-level things in excruciating detail
10:53
<annevk>
I think IDL is likely the best fit, but it could be separate I suppose
10:54
<tobie>
Yeah, having consistency across specs for those would be amazing (and actually allows to do a bunch of cool things on top of specs).
10:55
<tobie>
It would be interesting to have some of the HTML infrastructure stuff (like "in parallel") there too.
10:55
<annevk>
Yeah, and the math operators from Encoding (and a bunch of other things from Encoding)
10:56
<annevk>
And things like "ASCII case-insensitive"
10:56
<annevk>
It's a long list
11:01
<tobie>
annevk: Going back to those enums, you don't make each member linkable, do you?
11:03
<annevk>
tobie: no, though in the HTML standard that's sometimes done
11:04
<tobie>
Right, because why should things be consistant.
11:04
<tobie>
:D
11:04
<annevk>
tobie: there's not often a clear place where you define enums, so I think stylistically it's better to not do it
11:05
<annevk>
tobie: I guess you could make IDL the source... dunno
11:05
<annevk>
tobie: IDL wouldn't work well for Fetch, which sometimes has values outside of the range defined by IDL
11:05
<tobie>
annevk: I'm often struggling with which one should be the source.
11:06
<annevk>
Yeah, I think that's why I haven't bothered to make it work
11:06
<tobie>
heh
11:26
<mounir>
annevk: I would like to allow fullscreen to be requested on orientation change (screen orientation api), would you take a pull request that adds this to the spec?
11:27
<annevk>
mounir: if that's what needs to be implemented, yes
11:28
<annevk>
mounir: though a proper fix might be a change to the "user gesture" concept, no?
11:29
<mounir>
annevk: user gesture would still make sense for stuff like autoplay, or starting a WebRTC session, etc.
11:30
<mounir>
annevk: basically, Chrome Security approved going fullscreen on orientation change but they want orientation to be a signal for some stuff, not everything
11:30
<annevk>
I see
11:30
<annevk>
Yeah, please provide a PR, I guess we'll want to ask at least one other implementer to chime in, but sounds reasonable
11:51
<JakeA>
Touch events have made the "user gesture" thing a bit of a nonsense
11:52
<annevk>
JakeA: oh, why?
11:52
<mounir>
JakeA: yes, but that's only on mobile and that's something we are looking into fixing
11:53
<JakeA>
annevk: touch counts as a gesture, so you can do what you want as soon as scroll happens
11:53
<annevk>
Oh, that's not distinguished? Hmm
11:53
<JakeA>
I'm not sure how it can be
11:53
<JakeA>
mounir: ohh, what are the plans?
11:53
<annevk>
Is that why Apple had touch delay?
11:54
<JakeA>
annevk: nah, that was for double-tap-to-zoom
11:54
<JakeA>
touchstart was still instantly a user gesture
11:55
<JakeA>
I've used touchstart to make videos autoplay on mobile, which is annoying as it adds jank to the initial scroll. But it was either that or replace a 400k video with a 5mb gif
11:56
<JakeA>
But I believe both Chrome & WebKit are going to fix this and just allow videos to autoplay
11:56
<annevk>
<video autoplay> does not work?
11:56
<annevk>
I guess I knew that
11:56
<JakeA>
Not on mobile
11:57
<mounir>
JakeA: this isn't really an issue for autoplay, never heard of websites using it on the wild but it's certainly something we should fix before it becomes a problem
11:58
<annevk>
Quite interesting how standards sort of theorized about an eventual smaller screen and different input handlers, but didn't address it sufficiently that it actually ended up being the model when mobile became a thing
11:58
<JakeA>
mounir: true, the preferred solution is h264 decoders written in JS :(
11:58
<mounir>
JakeA: we have plans for that
11:58
<annevk>
And now it's nine years or so since the first iPhone and it's still a mess
11:58
<annevk>
Not super impressive
12:31
<zcorpan>
JakeA: does it work (on mobile) to use an animated gif in <video poster>? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4000
12:32
<JakeA>
zcorpan: I hadn't considered that, but what does it buy you?
12:32
<JakeA>
Works on Chrome android fwiw
12:32
<zcorpan>
seems like a possible workaround to use a reasonably small subset of the video as a poster animated gif on an autoplaying video, to have it start the gif before the user scrolls
12:33
<zcorpan>
and touchstart autostarts the actual video
13:38
<tobie>
JakeA: looking at https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#service-worker-registration-update
13:39
<tobie>
JakeA: doesn't step 4 effectively prevent the promise from being returned?
13:39
<JakeA>
zcorpan: maybe, but autoplay would still be better
13:39
<zcorpan>
JakeA: yes for sure
13:39
<JakeA>
tobie: haha, yes I think you're right
13:40
<JakeA>
tobie: if memory serves, I think IDL does the right thing and converts throws to promise rejections, we should be doing that
13:41
<tobie>
JakeA: oh, you would just throw and not care about returning anything in that case?
13:41
<tobie>
Sounds harder for an implementor to get right, no?
13:42
<JakeA>
tobie: maybe I just made that up https://www.w3.org/2001/tag/doc/promises-guide#example-validated-delay
13:42
<tobie>
Asking because I'm in the middle of writing a similar algorithm.
13:43
<JakeA>
tobie: oh wait, I'm right https://www.w3.org/2001/tag/doc/promises-guide#always-return-promises
13:43
<tobie>
"If ms is less than zero, return a promise rejected with a RangeError."
13:43
<JakeA>
first time in 2016
13:45
<JakeA>
https://heycam.github.io/webidl/#es-operations "f the operation has a return type that is a promise type, thenโ€ฆ"
13:45
<tobie>
Well, checking that would involve reading some of the prose that's in WebIDL, which my doctor strictly forbids, so no luck.
13:46
<JakeA>
tobie: in short, if your algo throws and your return type is a promise, it auto-wraps the error in Promise.reject(err) and returns that
13:46
<annevk>
If as an implementer you do not read IDL you are also out of luck though
13:46
<tobie>
ok, I'll just throw stuff around.
13:46
<tobie>
:)
13:47
<annevk>
We should have made IDL establish some kind of convention though since I think specifications now do both
13:47
<annevk>
Some reject the promise, otherwise happily throw
13:47
<annevk>
others*
13:49
<tobie>
That seems like a recurring theme.
13:53
<annevk>
Someone needs to find some time
13:57
<tobie>
annevk: I've been trying to sell documenting these things to a bunch of clients in the past. Have been unsuccessful so far.
13:57
<annevk>
tobie: bah
14:03
Ms2ger
wonders if https://drafts.csswg.org/cssom-view/#the-html-body-element should consider frameset
14:06
<annevk>
Trying to define "shadow-host-including tree order" is no fun
14:12
<annevk>
shadow-root-including, even
14:18
<smaug____>
anyone recall where rniwa's tests for rootNode are
14:18
<smaug____>
some pr in github I think
14:19
<annevk>
smaug____: obvious place would be web-platform-tests, and indeed, https://github.com/w3c/web-platform-tests/pull/2665
14:19
<smaug____>
thanks
14:21
<jgraham>
smaug____: Oops, didn't see that rniwa had updated that.
14:22
<jgraham>
Would be nice to get it squashed before merging
15:03
<Domenic>
botie where are you
15:03
<tobie>
When do you decide to name an algorithm and reference it from a method? All the time, or just when you call said algorithm all the time?
15:03
<Domenic>
MikeSmith ^
15:04
<annevk>
Domenic: I guess I'll wait until we have [[PlatformBrand]] and then fix that issue
15:04
<Domenic>
annevk: sounds good
15:04
<tobie>
Hey Domenic -- tried to fix your Specref woes to no avail.
15:04
<Domenic>
tobie: when it has more than one caller, including in other specs, generally.
15:04
<Domenic>
tobie: yeah, I saw :(
15:04
<tobie>
yeah, the codebase is dreadful.
15:05
<tobie>
which I'm to blame for.
15:06
<tobie>
Domenic: ty, had forgotten about the "other specs" aspect which is critical for the sensor work.
15:08
<Ms2ger>
annevk, you know if there's a reason for language to be nullable at https://html.spec.whatwg.org/multipage/#navigatorlanguage ?
15:09
<Domenic>
Ms2ger: fascinating...
15:09
Domenic
remembers how Web IDL return values are useless and redundant
15:10
<annevk>
Ms2ger: no
15:10
<Ms2ger>
They're pretty damn useful
15:10
<Ms2ger>
annevk, want an issue?
15:11
<annevk>
Ms2ger: I guess, would be nice if we could change that
15:11
<Ms2ger>
https://github.com/whatwg/html/issues/881
15:13
<Domenic>
"These interfaces are defined separately so that other specifications can re-use parts of the Navigator interface."
15:13
<Domenic>
like what?
15:13
<Domenic>
Probably WorkerNavigator
15:14
<Domenic>
But that's the same specification
15:15
<Ms2ger>
Used not to be
15:15
<annevk>
Domenic: maybe a leftover from when Hixie_ used to split workers out
15:16
<annevk>
Domenic: I would somewhat prefer a single Navigator interface with better use of [Exposed] for individual members
15:16
<Ms2ger>
But self.WorkerNavigator
15:16
<annevk>
Yeah, that kinda kills it
15:17
<annevk>
I guess we could just do interface WorkerNavigator {}; WorkerNavigator implements Navigator; and not expose Navigator in Worker, just its members...
15:18
<Domenic>
meh
15:19
<Ms2ger>
Interfaces on the rhs of implements? Meh
15:19
<annevk>
I guess I'll stop caring
15:22
<tobie>
So I have a dfn of sensor which is the underlying sensor (https://w3c.github.io/sensors/#sensor) and I have a WebIDL Sensor Interface. Now when I have an algorithm that talks about an instance of Sensor, it seems natural to use <var>sensor</var> for it which is confusing. How should I go about that?
15:23
<tobie>
s/for it which/for it, which/
15:24
<Domenic>
tobie: I ran into this yesterday and decided to merge the concepts so that I can just talk about the Sensor object.
15:24
<tobie>
Commas are kind of useful.
15:24
<Domenic>
(In my case it was CustomElementsRegistry objects. HTML also does this for Window and Document objects.)
15:24
<Ms2ger>
Alternatively, concept-sensor
15:24
<Domenic>
On the other hand annevk does things like URL objects having a url, which is fine.
15:25
<tobie>
The problem is I have one underlying sensor which can have many associated sensor objects
15:25
<Domenic>
In my case I just found that I was constantly doing "the CustomElementRegistry's custom element registry"
15:25
<Domenic>
Sounds like a useful distinction then yeah
15:25
<annevk>
tobie: I'd only disambiguate the variable name if it was important
15:26
<annevk>
tobie: e.g., actualSensor and sensorInstance
15:26
<tobie>
so like "s"?
15:26
<tobie>
oh, better. :)
15:27
<tobie>
Thanks folks, that's super helpful.
15:27
<annevk>
tobie: often though in an algorithm you would just reference "this" (aka context object until we rename that)
15:27
<tobie>
oh
15:27
<tobie>
do you have examples of that handy?
15:27
<annevk>
tobie: and then context object's sensor would be unambiguous, since context object is the instance, and sensor is the shared sensor
15:28
<annevk>
tobie: https://dom.spec.whatwg.org/#dom-element-shadowroot
15:28
<annevk>
tobie: (lots of specifications reuse the "context object" concept from DOM)
15:31
<tobie>
I think using sensorInstance or the like will make the whole thing more readable. Anyway, easy to change later on as long as I'm using two distinct words.
15:32
<Domenic>
We've been using "this `Sensor` object" in new specs
15:33
<annevk>
True, I don't really like that either since it's too long
15:34
<annevk>
We should just be able to use this or a variable that we get to name since IDL invokes the specification-defined algorithm directly with this as the first argument (this is what I really want)
15:38
gsnedders
wonders if anyone knows much about BitTorrent here
15:41
<gsnedders>
Does the DHT contain everything that the torrent metadata file does?
15:45
<annevk>
Doing Fullscreen's shadow DOM integration today is too much... but I'll drop utf-16's encoders, much more satisfying way to end the day too
16:06
<zcorpan>
anyone who likes security and privacy sections pls see https://www.w3.org/Bugs/Public/show_bug.cgi?id=29533 (for cssom-view)
16:06
zcorpan
*poff*
16:20
<TabAtkins>
annevk: It was bikeshed. SpecRef is only for biblio references, not autolinks. Fixed it for you.
16:21
<TabAtkins>
annevk: enum values are now dfn'd by Bikeshed too, so they can be autolinked.
16:21
<TabAtkins>
Style is like <a enum-value>"foo"</a>.
17:02
<annevk>
https://twitter.com/FirefoxNightly/status/709760092648841216 Fetch is still very misunderstood by some ๐Ÿ˜Ÿ
17:02
<annevk>
(In this case the writer of that tweet.)
17:07
<caitp>
maybe you should tweet about it to market it better
17:08
<caitp>
with gretchen from Mean Girls as the mascot
17:08
<annevk>
fair
17:08
<caitp>
catch phrase "That's so fetch!"
17:17
<wanderview>
annevk: wow
17:18
<annevk>
wanderview: yeah, I replied per caitp's advice
17:19
<caitp>
the only thing missing is a lacey chabert gif with a silly caption
17:45
<annevk>
smaug____: have you reviewed https://w3c.github.io/webcomponents/spec/shadow/#extensions-to-event-interface?
17:45
<annevk>
smaug____: I was wondering whether putting those flags on event objects was the way to go, or whether they should be parameters for the dispatch algorithm
17:46
<annevk>
smaug____: I guess putting them on event objects is more consistent with how event objects work today
17:47
<smaug____>
I haven't reviewed that
17:47
<smaug____>
those flags feel a bit odd
17:47
<smaug____>
why would JS need to know about them
17:48
<annevk>
I think when I proposed this to hayato I suggested flags that the dispatcher would pass to dispatch
17:48
<annevk>
But it seems he went with a different design
17:51
<smaug____>
I wonder why
17:52
<smaug____>
is there some use case where those flags are needed in JS
17:52
<smaug____>
so far I haven't heard of anyone needing them with XBL stuff
17:53
<annevk>
smaug____: does Gecko store them on the event object or pass them as part of dispatch?
17:54
<smaug____>
annevk: so this scoped is for example for mouseout/over events?
17:55
<annevk>
smaug____: it's not defined very well at the moment, but see https://w3c.github.io/webcomponents/spec/shadow/#event-paths
17:55
<annevk>
I sorta thought everything Shadow DOM was reviewed at this point
17:56
<smaug____>
really?
17:56
<Ms2ger>
Ha
17:56
<smaug____>
"abort, error, select, change, load, loadedmetadata, reset, resize, scroll and selectstart."
17:57
<annevk>
smaug____: well yeah, guess I'm glad I haven't landed the event stuff in DOM yet
17:57
<smaug____>
so that is missing stuff like mouseover/out within shadow DOM. or perhaps that happens in dispatch.
17:57
<smaug____>
looking
17:57
<annevk>
They don't define dispatch, nobody does
17:58
<annevk>
๐Ÿ˜Ÿ
17:58
<smaug____>
hmm, meeting
17:58
<smaug____>
anyhow, in XBL mouseover/out are handled during event path creation
17:59
<annevk>
smaug____: interesting...
17:59
<smaug____>
and some other stuff use very internal flags so that the event is still dispatched to chrome
17:59
<smaug____>
but nothing of that is exposed to JS
17:59
<annevk>
smaug____: file github.com/w3c/webcomponents/issues/new maybe on exposing these properties and such?
17:59
<smaug____>
yeah
17:59
<annevk>
I'll triage tomorrow / maybe figure something out
18:19
<tobie>
TabAtkins: thanks.
18:20
<tobie>
TabAtkins: for the enum values.
18:52
<smaug____>
annevk: filed. silly bug title. oh well
23:10
<MikeSmith>
Domenic: botie is back
23:34
<gsnedders>
WebIDL help: given the OrderedMap example in it, how would map.apple ever return undefined? shouldn't it just return null? where does the null from the get() become an undefined?