05:13
<MikeSmith>
TabAtkins: didn’t know you’re an iTerm2 user
07:05
<yoav>
jgraham: Hey! WPT doesn't expose ways to run something like Blink/WebKit's internals in a cross-browser way, right? The subject has come up in https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/j04BdFMfYxg
07:22
<MikeSmith>
yoav: what does “run something like Blink/WebKit's internals in a cross-browser way” mean?
07:25
<yoav>
MikeSmith: Have a non-Web-exposed API that enables you things like changing the screen density, etc
07:26
<yoav>
e.g. Some of srcset's tests in Blink/WebKit cannot be easily migrated elsewhere because of lack of control on these conditions
07:26
<yoav>
And the related blink-dev discussion was related to adding such an API for network state
07:27
<jgraham>
yoav: No, there is no attempt to provide a standardised api for that because it's very unclear that it's possible without agreement on the semantics of the backing api (in which case why not use that directly)
07:27
<yoav>
jgraham: OK, thanks
07:28
<jgraham>
I think there is likely to be some demand for a standardised test-only api fwiw
07:30
<yoav>
personally, I'd love to see something like that
09:52
<nox>
Is it me or https://dom.spec.whatwg.org/#concept-getelementsbytagname doesn't actually describe UAs?
09:54
<nox>
I see, Safari and Firefox disagrees on "Element in non-HTML namespace, prefix, non-ascii characters in name".
10:16
<nox>
annevk: Following https://github.com/whatwg/dom/issues/143, I think getElementsByTagName still contradicts UAs, or at least Firefox.
11:50
<Ms2ger>
annevk, you know if there's a reason BeforeUnloadEvent doesn't have a constructor?
11:56
<MikeSmith>
bravo wanderview
11:58
<annevk>
Ms2ger: I don't
12:04
<nox>
annevk: Any idea about my own question? Maybe there is an open issue I missed?
12:09
<annevk>
nox: what in particular doesn't match?
12:09
<nox>
annevk: http://w3c-test.org/dom/nodes/Element-getElementsByTagName.html
12:10
<nox>
annevk: "Element in non-HTML namespace, prefix, non-ascii characters in name"
12:10
<nox>
This pass on Safari and Chrome but not Firefox,
12:10
<nox>
and the spec seems to agree with Firefox.
12:11
<annevk>
nox: above you said the spec contradicts Firefox?
12:12
<annevk>
nox: the spec is intended to match Firefox, per that issue bz raised
12:12
<nox>
annevk: Sorry, confused myself.
12:12
<nox>
annevk: So the test didn't get updated per spec, is that all?
12:12
<annevk>
nox: I guess so
12:12
<nox>
Ok great.
12:12
<Ms2ger>
Though Aryeh tried
12:21
<hallvors>
This IDL array vs frozenarray thing -> https://github.com/whatwg/html/issues/11 - is there some context here, like a bug arguing for removing array? zcorpan seems to want me to understand it :)
12:22
<nox>
hallvors: Following links leads me here: https://github.com/heycam/webidl/pull/52 and here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682
12:22
<zcorpan>
hallvors: the T[] thing was removed from WebIDL, so any spec still using it is broken
12:23
<hallvors>
ah, thanks. Didn't see the link to 23682
12:25
<nox>
hallvors: No problem.
13:31
<nox>
Spec and tests for insertAdjacentHTML don't seem to agree either.
13:32
<annevk>
I wonder if the insertAdjancentHTML spec is correct
13:33
<annevk>
I looked at it briefly when working on insertAdjacentOtherThings and I remember thinking it had some bugs
13:33
<nox>
annevk: I don't think so.
13:33
<nox>
annevk: But the tests don't look correct either. :)
13:33
<nox>
annevk: https://github.com/servo/servo/blob/master/tests/wpt/web-platform-tests/domparsing/insert_adjacent_html.html#L59-L72
13:34
<nox>
annevk: Am I blind, or child doesn't actually get a parent ever?
13:38
<annevk>
nox: parentElement.appendChild(child);
13:39
<nox>
annevk: Oh missed it.
13:39
<nox>
annevk: Ain't it bad style that it is itself in a test btw?
13:40
<Ms2ger>
That's kinda weird
13:40
<annevk>
nox: it's a little wonky for sure
13:40
<nox>
annevk: Well, someone implemented that method,
13:40
<nox>
and we have failing tests,
13:40
<nox>
so if tests or spec are wrong (or I think they are), I'll ping you.
13:41
<annevk>
it's really the responsibility of Travis Leithead
13:42
<annevk>
since it's part of DOM Parsing & Serialization
13:42
<nox>
Right.
13:42
<annevk>
I sorta think we need to put that in DOM at some point, or at least all the methods and such, but there's also only so many people to do editing work
13:43
<nox>
annevk: You'll forever be my go-to spec guy though. ;)
14:15
<wanderview>
MikeSmith: I should probably avoid twitter before coffee
14:16
<caitp>
the people really want xml https://github.com/angular/angular/issues/673
14:16
<gsnedders>
nox: Travis has been working on bringing the tests in line with the spe AFAIK
14:17
<MikeSmith>
wanderview: nope, you should keep calling out BS and speaking truth to power
14:28
<wanderview>
MikeSmith: ironically they are about to roll out the removal of the UA check and redirect to play store
14:32
<jgraham>
wanderview: It seems entirely reaonable to me. You shouldn't get lots of free marketing for being at the forefront of web design if you are blocking browsers. But ofc when the people making the favoured browsers are the ones handing out the free publicity, it's easy to see why they don't give a fuck
14:36
<annevk>
I'd hope all this renewed interest in the web results in some more people being allocated to making the foundations more interoperable
14:36
<annevk>
Be it through tests or standards
14:37
<caitp>
there's renewed interest in the web?
14:40
<annevk>
caitp: I've no idea, I just want more resources to work on infrastructure
14:42
<caitp>
it only gets harder to keep interest in any of this stuff
14:42
<caitp>
that's the sad truth :(
14:43
<annevk>
Not for me
14:44
<jgraham>
annevk: Not really clear that foudational stuff is the reason that flipkart or whoever are producing single-browser sites
14:45
<jgraham>
(which doesn't mean that it's not important ofc, but it's unclear to me if it's the problem in this case)
14:45
<caitp>
maybe it's because making good experiences on multiple software platforms (and they're all different platforms, they're not a single coherent platform) takes too much time and resources
14:45
<annevk>
Yeah, flipkart seems mostly a case of new technology not having settled
14:46
<annevk>
There's always going to be some brokenness at the forefront
14:46
<annevk>
But that our building blocks are not entirely stable either, I mean, that can't go well forever
14:46
<caitp>
there's unfixable brokenness in the back too
14:47
<annevk>
I wouldn't say it's unfixble really
14:47
<annevk>
We've fixed tons of stuff
14:48
<annevk>
That's the core of what the WHATWG's been doing for a decade and a bit
14:53
<caitp>
I'd write about my perspective on how the web is really playing a key part in the ruining of the world, but it's not an audience that would hear it
14:54
<nox>
WHATWG reconciled me with the Web kinda.
14:54
<caitp>
but the way it speeds the delivery and increases the demand for cheapened crap, while reducing the value of people building that cheapened crap, is not a good thing
14:54
<nox>
caitp: The Web is improving, not regressing, IMO.
14:55
<caitp>
from whose perspective?
14:55
<nox>
Everyone's.
14:55
<caitp>
all week they've been playing on the radio news about a town experiencing like a 10 fold increase in teen suicides, and largely blaming the web, and they're at least partly correct in blaming the web
14:55
<caitp>
it's really a big part of the problem
14:55
<nox>
What.
14:56
<caitp>
it reduces the value of humans, reduces privacy of humans, reduces the value of human works
14:56
<caitp>
actually increases the cost of living
14:57
<caitp>
it's horrific
14:57
<nox>
I don't get your point, nor how it is related with what WHATWG is doing.
14:57
<caitp>
it has nothing to do with the WHATWG, it's just the web, as a technology, is really hurting the world
14:58
<nox>
Abuse and harassment are humans' problems, not the Web's.
14:58
<caitp>
it's not just abuse and harassment
14:58
<caitp>
that's only one side of it
14:58
<nox>
What's hurting the world is the feeling of impunity of some, and parents being completely lost about their youth's virtual lifes.
14:58
<jgraham>
It is unclear to me that The Web is important here in a way that is distinguishable from modern technology in general
14:58
<nox>
jgraham: Thanks, I wish I had said that.
14:58
<caitp>
well, the web is probably the most ubiquitous delivery method for that modern technology
14:59
<nox>
Seems like the Web you talk of is mostly social networks btw.
15:00
<caitp>
it's not, but they're also terribl
15:01
<jgraham>
I think a lot of the bad stuff now happens in ways that are not specifically The Web e.g. via apps. It seems like the general idea of a ubiquitous computer network has a number of unforeseen downsides
15:01
<caitp>
anyways, #whatwg isn't really an audience that is going to see that the web is part of the problem, I drank the same koolaid you all did
15:01
<caitp>
the web is the platform, it helps people communicate and find information, it's important, it changes lives for the better
15:01
<caitp>
but that's not what's happening :(
15:02
<nox>
I didn't drink that koolaid.
15:02
<nox>
I see the Web as the best way to procrastinate, mostly.
15:02
<jgraham>
caitp: I, at least, am receptive to the idea that a problem exists. But I think that pinning it on a specific implementation of the general abstract technology is perhaps naive
15:02
<jgraham>
And there are already multiple implementations of the technology, so it's not like turning off the web tomorrow would make a huge difference
15:03
<caitp>
I keep doing this because it pays for me to keep living, but it's going to result in me drinking a litre of whiskey every week, I'm sure ofi t
15:03
<jgraham>
Pre-emtively give up drinking?
15:03
<caitp>
I need a new job that doesn't involve computers :(
15:05
<nox>
caitp: What about working for IoT then?
15:05
nox
runs away.
15:05
<caitp>
even worse ;-;
15:19
<MikeSmith>
nothing wrong with drinking a liter of whiskey every week
15:19
<MikeSmith>
or even every day
15:22
<MikeSmith>
and it’s an interesting phenomenon when after somebody realizes they had a naive understanding of something they’ve put time into, they assume that others putting time into it have the same naive understanding of it, or ever did
15:51
<smaug____>
annevk: thanks. That was my first pr ever on github :)
15:51
<smaug____>
did I do something wrong
15:52
<smaug____>
(locally I probably did)
15:53
<smaug____>
(I need to figure out how to get my local fork synced. I'm totally no-ob in this stuff)
15:53
<smaug____>
I guess I can always delete the fork
16:05
<mathiasbynens>
zcorpan: have you found the Firefox bug # yet?
16:05
<zcorpan>
mathiasbynens: no, but haven't searched
16:07
<mathiasbynens>
zcorpan: https://bugzilla.mozilla.org/show_bug.cgi?id=1094995 apparently
16:08
<mathiasbynens>
(I wasn’t aware of this bug)
16:11
<mathiasbynens>
https://bugzilla.mozilla.org/show_bug.cgi?id=449811
16:29
<zcorpan>
MikeSmith: https://www.smashingmagazine.com/2016/06/battling-bem-extended-edition-common-problems-and-how-to-avoid-them/?utm_source=html5weekly&utm_medium=email about this BEM thing
16:31
<zcorpan>
(from the comments it appears it's a love or hate kind of thing)
16:31
<annevk>
smaug____: I don't think you did anything wrong
16:32
<annevk>
smaug____: I couldn't merge it as-is because I needed to make some other changes and the final commit needs to contain the generated HTML
16:32
<gsnedders>
zcorpan: I'm getting bad gateway from that URL
16:32
<zcorpan>
huh. try https://www.smashingmagazine.com/2016/06/battling-bem-extended-edition-common-problems-and-how-to-avoid-them/
16:33
<gsnedders>
wtf
16:33
<gsnedders>
works
16:34
<MikeSmith>
zcorpan: thanks
16:34
MikeSmith
looks
16:34
<MikeSmith>
hmm 502 Bad Gateway atm
16:34
<zcorpan>
MikeSmith: try the other link
16:55
<MikeSmith>
zcorpan: thanks
16:55
<MikeSmith>
seems .. complicated
16:57
<zcorpan>
MikeSmith: i guess it avoids thinking of other complicated things like cascade and specificity
16:57
<zcorpan>
gotta go
17:25
<smaug____>
annevk: is there some documentation about best practices how to create prs for specs? /me is obviously looking for some "contributing fixes to specs for dummies"
17:26
<annevk>
smaug____: the README of whatwg/html has some info
17:26
<annevk>
smaug____: README for most specs should have info
17:26
<annevk>
smaug____: if you lack some info, file an issue
17:27
<annevk>
smaug____: because that really should be there in some form
17:27
<smaug____>
well, I was hoping even more precise, like what kind branches one might want to use locally and such
17:27
<smaug____>
github has rather weak documentation itself
17:28
<annevk>
smaug____: oh, if you have write access to a standard always create a branch there with a reasonable unique name
17:28
<annevk>
smaug____: if you don't have write access, you need to create a branch on your fork and what you call that doesn't really matter
17:30
<smaug____>
github documentation just says one may want to use named branches, but isn't too clear about the reasons or whether it is actually required etc
17:39
<annevk>
smaug____: I think it's mostly so you know what the branch is about when selecting one
17:39
annevk
wonders if mven is mvano
17:40
<annevk>
Domenic: another idea I had with the whole icon thing is to have some kind of API that tells you what icon the browser would select, given some inputs
17:40
<Domenic>
annevk: that does seem really nice
17:41
<annevk>
Domenic: and then not alter the end points and just keep those as a single URL that you get out of the API
17:41
<Domenic>
annevk: I don't understand that latter part
17:41
<annevk>
Domenic: instead of making the Notification object more complicated to support multiple icons, just solve the icon selection thing in this new API and then feed the Notification object the result
17:42
<Domenic>
annevk: so what complexity would you remove from the Notification object?
17:42
<annevk>
Domenic: nothing compared to the current state, but we wouldn't add the PR that adds support for multiple icons
17:43
<Domenic>
annevk: we would still accept them as input, just not reflect them in the API, I guess?
17:44
<annevk>
That would be another way to go; I was thinking the Image Selection API would return the URL of the chosen image and you'd pass that along
17:45
<Domenic>
oh i see
17:46
<annevk>
I'm guessing <picture> and friends were before extensible web thingie happened? Anyway, while walking around with O today I figured there is some kind of API there that we don't expose
17:46
<annevk>
And because of that we keep copying the high-level pattern around
17:47
<annevk>
Which just creates a ton of API surface with not so much value
17:53
<Domenic>
Yeah that seems very true to me
17:53
<Domenic>
<picture> is a bit unique because it needs to be in markup for the preload scanner
17:55
<annevk>
Anyway, really time to make dinner, guess I'll post tomorrow unless someone wants to do it for me
17:56
<TabAtkins>
MikeSmith: I'm not, that's just a good feature that's worth telling others about.
18:06
<mven>
annevk: hmm. nope.
18:06
<mven>
who's mvano?
18:17
<jyasskin>
mven: Michael van Ouwerkerk
18:23
<TabAtkins>
smaug____: I've been meaning to write up some stuff on that topic for myself anyway, so I went ahead and did it: http://www.xanthir.com/b4hf0
18:23
<TabAtkins>
smaug____: My guidelines for how to easily work with forks on GitHub.
18:24
<smaug____>
I need to see what git does when there are merge conflicts
18:24
<smaug____>
TabAtkins: thanks
18:39
<annevk>
TabAtkins: five is no longer needed thanks to squash and merge
18:39
<annevk>
TabAtkins: actually prefer fixup commits to more easily review them
18:40
<TabAtkins>
annevk: Yeah, that's probably true.
19:46
<coppro>
there is no way to use HTTP content negotiation to negotiate image size, is there?
20:00
<TabAtkins>
coppro: No.
20:17
<coppro>
:(
20:48
<coppro>
also is there a more recent spec for CORS than the W3C recommendation? By my reading of fetch(), it doesn't implement that recommendation.
20:48
<coppro>
(in particular, it requires the server to explicitly allow Authorization)
20:50
<TabAtkins>
It looks like Fetch defines CORS on its own? https://fetch.spec.whatwg.org/#http-cors-protocol
20:50
<TabAtkins>
but annevk ^^^
21:14
<Domenic>
coppro: TabAtkins: yes, CORS spec is obsoleted by Fetch
21:16
<coppro>
cool, thanks!