02:29
<rniwa>
kochi: yt?
03:12
<TabAtkins>
miketaylr: Currently I have a manual default setting <color> to css-color-3
03:12
<TabAtkins>
You can override it, but it's a "type" type, not a "value" type.
05:11
<rniwa>
hayato: yt?
05:17
<rniwa>
Domenic: yt?
07:20
<Ms2ger>
Huh: https://lists.w3.org/Archives/Public/public-webapps/2016AprJun/0068.html
07:29
<annevk>
Ms2ger: I don't even think Domenic really knows what that entails since de-upstreaming is obviously not a thing that's going to happen
08:35
<annevk>
Should we revisit <cite>'s bit about not being able to be used for persons? I saw some chatter on Twitter and it seems nobody really cares for that restriction
08:36
<annevk>
The only shame there would be losing the rather fun remark surrounding it
08:39
hsivonen
still thinks the aliases of <i> just fuel arguments, but if we are arguing, <cite> should map to the "title of work" concept in the Chicago Manual of Style
08:43
<annevk>
Yeah, I guess I don't care strongly enough to take action here, it's all rather arbitrary anyway
09:42
<smaug____>
annevk: remind me, why do URLs use USVStrings?
09:43
<annevk>
smaug____: so that the URL parser can operate on scalar values rather than code points
09:45
<smaug____>
ehsan: ^
09:45
<nox>
annevk: You sure the things in DOMString are called code points, btw?
09:45
<annevk>
smaug____: this is interesting when writing new subsystems in languages that are build around the scalar value notion, such as Rust
09:45
<nox>
Because scalar values are code points, and other 16-bits values that aren't scalar values are UTF-16 code units. Not code points.
09:46
<ehsan>
annevk: so I guess you can't have non-plane-1 characters in URLs?
09:46
<annevk>
ehsan: yes you can
09:46
<ehsan>
annevk: and those can be encoded in USVStrings?
09:46
<annevk>
ehsan: yes
09:47
<ehsan>
huh
09:47
<nox>
ehsan: USVString == Unicode string, conceptually.
09:47
<nox>
ehsan: DOMString is more than Unicode.
09:47
<ehsan>
so I guess I don't understand USVStrings after all
09:47
<annevk>
nox: non-scalar values are code points, e.g., surrogate values
09:47
<ehsan>
nox: what's the difference in plain english? :)
09:47
<nox>
ehsan: DOMString can contain lone surrogates.
09:47
<ehsan>
oh
09:47
<ehsan>
I had it backwards!
09:47
<nox>
annevk: I think you got that wrong but I wouldn't bet.
09:47
<annevk>
nox: I would
09:48
<annevk>
nox: though it's true that a DOMString isn't normally described as having code points
09:48
<nox>
annevk: And you would have won money indeed.
09:49
<nox>
annevk: So confusing. :)
09:49
<annevk>
quite
09:49
<annevk>
ehsan: so yeah, USVString is DOMString without lone surrogates
09:49
<ehsan>
glad I'm not the only one totally confused by this
09:49
<ehsan>
annevk: yeah everything makes sense now
09:50
<annevk>
ehsan: bit early no for such a topic? :-p
09:51
<ehsan>
annevk: I'm in Taipei, so just about the right time :P
09:51
<annevk>
aaah
09:51
<ehsan>
only thing missing from the scene is a glass of scotch ;)
13:36
<annevk>
The problem with refactoring HTML to account for shadow trees is that you then feel like you have to fix all the issues you notice along the way too
13:37
<annevk>
It's a positive, I suppose, but it's also a lot of work
13:56
<smaug____>
there is really no needinfo? or similar in github?
13:57
<smaug____>
I'm sure I'm not answering to many questions because I just forget them as soon as I've read the email github sends
13:58
<smaug____>
(in other words, could we move back to using w3c bugzilla ;) )
14:01
<annevk>
smaug____: there's not, you can use https://github.com/notifications
14:01
<annevk>
smaug____: there's also https://github.com/issues/mentioned
14:03
<smaug____>
but those contain too many bugs
14:04
<smaug____>
would need to go through them all and see if there is something to comment
14:18
<annevk>
I do see how needinfo can be useful, if I really need to get someone's feedback I just ping them a few times in different places...
14:18
<annevk>
Not ideal
14:54
<miketaylr>
TabAtkins: ah cool, wrong type thx
16:11
annevk
stumbles upon https://github.com/testomato/minicrawler
16:11
<annevk>
"single-threaded multi-socket web client and WHATWG URL compliant library written in C"
16:12
<miketaylr>
that's cool.
16:13
<annevk>
smaug____: created several more shadow tree PRs btw: https://github.com/whatwg/html/pulls (not all of them have issues)
16:28
<Domenic>
so many PRs to review
16:30
<JoWie>
mine is simplest :p
16:34
<annevk>
JoWie: false, but I'll allow it
17:17
<JoWie>
hehe
21:06
<TabAtkins>
Domenic: Rereading Streams, I get the feeling that it's specialized heavily on binary data, and wouldn't be the best fit for the "promise, but the value can be updated" or "ping whenever an event happens" use-cases. Am I wrong?
21:07
<Domenic>
TabAtkins: I would say it's specialized for I/O, but not necessarily binary I/O. But yes, probably not the best fit for those use cases, unless e.g. the event is a flood of new data from the webcam or something.
21:09
<TabAtkins>
Right. I'm thinking about cases like piping a mousemove event into an Observable, so you have a constant "current mouse position" object that you can listen to updates on.
21:09
<TabAtkins>
(Context is Alex wondering if Streams and Observables have a sub/superset relationship that needs to be reflected in their design.)
21:11
<Domenic>
No, this is covered in the streams FAQ....
21:11
<Domenic>
https://github.com/whatwg/streams/blob/master/FAQ.md#how-do-readable-streams-relate-to-observables-or-eventtarget
21:15
<TabAtkins>
That's not in the spec, and is thus invisible. ^_^