06:27
<annevk>
It's a little unclear to me whether https://github.com/whatwg/html/pull/1492 needs further review
06:27
<annevk>
I guess/hope Domenic is asleep already
06:51
<MikeSmith>
annevk: seems like you probably want to wait til Domenic is around
06:59
<MikeSmith>
botie, inform zcorpan rather than adding space around text only from the elements listed in https://github.com/validator/validator/issues/315#user-content-space-before-after why don’t I instead just always put space around it from any element regardless (with the exceptions for script, style, math, svg, template
06:59
<botie>
will do
07:16
<botie>
zcorpan, at 2016-07-05 06:59 UTC, MikeSmith said: rather than adding space around text only from the elements listed in https://github.com/validator/validator/issues/315#user-content-space-before-after why don’t I instead just always put space around it from any element regardless (with the exceptions for
07:16
<botie>
script, style, math, svg, template
07:20
<zcorpan>
MikeSmith: i figured sometimes the inlines are used without intending to break up words (like <a>, <wbr>, <em>...)
07:21
<MikeSmith>
zcorpan: ah true
07:44
<zcorpan>
MikeSmith: looking at httparchive it seems to be a mixed bag of expectations; sometimes separate words appear across a tag boundary and sometimes a single word spans the tag boundary
07:45
<zcorpan>
probably more common with separate words
07:51
<MikeSmith>
OK
10:07
<hsivonen>
annevk: why does the "encode" spec concept start by asserting the _encoding_ isn't replacement, UTF-16BE or UTF-16LE instead of starting by setting _encoding_ to its _output encoding_?
10:13
<annevk>
hsivonen: probably because you need to do that ahead of time
10:14
<annevk>
hsivonen: otherwise metadata elsewhere would get faulty
10:14
<hsivonen>
annevk: good point. thanks.
10:15
<hsivonen>
encoding-rs now has "decode" and "decode_with_replacement" and similarly "encode" and "encode_with_replacement"
10:15
<hsivonen>
I wonder if I should have "decode_without_replacement" and "decode" and "encode_without_replacement" and "encode" instead...
10:17
<hsivonen>
BOM handling works the other way round
10:17
<hsivonen>
the short name gives you bom sniffirng and there are longer names to opt out
10:22
<hsivonen>
hmm. I suppose I should make the ones that can fail *_without_replacement and drop _with_replacement from the names
10:22
<hsivonen>
annoying
10:22
<hsivonen>
that'll affect a lot of code
10:23
<hsivonen>
But that's the logical conclusion if I want to make the short obvious names both obvious spec-wise and want to make the short names to steer the user to do what's most likely the right thing
10:24
<hsivonen>
*sigh*
11:46
<zcorpan>
alwu: did you want to take a stab at fixing cue identifier in the spec, or should i?
12:11
<zcorpan>
annevk: re https://github.com/whatwg/html/pull/1500 what kinds of navigations are being excluded with the new text?
12:12
<annevk>
zcorpan: setting <object>.data to "sameurl#test"
12:27
<zcorpan>
annevk: like this? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4300
12:28
<wanderview>
JakeA: is there a header for <link rel="preload">?
12:28
<wanderview>
JakeA: or maybe thats just http2 push
12:28
<annevk>
zcorpan: yeah, though I'm not sure what's going on there
12:28
<zcorpan>
annevk: me either :-)
12:29
<annevk>
zcorpan: the main thing with <object>.data and also embed is that they first fetch, and then navigate to the response of that fetch
12:29
<annevk>
zcorpan: rather than navigating a request
12:30
<zcorpan>
wanderview: it might be implemented, but preload is a bit different from http2 push. see https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/
12:32
<wanderview>
zcorpan: I was asking specifically in the context of https://github.com/slightlyoff/ServiceWorker/issues/920
14:01
<Alv-c>
hey there!
14:04
<Alv-c>
may I ask a little thing about URL standard design?
14:05
<annevk>
Alv-c: sure
14:10
<Alv-c>
I'm actually working on a C++ URL parser following the whatwg URL standards, and I noticed that url `query` is not `UTF-8 percent encode`d. But if I create a new URL instance in javascript it does. Is it related to `x-www-form-urlencoded`? Should I encode url `query` in my implementation
14:11
<Alv-c>
Sorry if it's inappropiate to ask questions here :P. This is my first time using irc
14:13
<annevk>
Alv-c: per https://url.spec.whatwg.org/#query-state the default is certainly UTF-8
14:13
<annevk>
Alv-c: but the encoding can also be coming from the document for certain APIs defined in HTML, such as <a>
14:14
<annevk>
Alv-c: since that's legacy it's a feature exposed through the URL API
14:14
<annevk>
Alv-c: it's *not* a feature exposed through the URL API, doh
14:15
<annevk>
(And IRC is a fine place to ask questions.)
14:15
<MikeSmith>
zcorpan: FYI https://github.com/validator/validator/commit/5ff6fe8331fff08bdb98301a360543e5149fdb43
14:16
<MikeSmith>
zcorpan: will only emit a warning if it ia 90% confident it found the right match
14:19
<Alv-c>
Oh! I see. Thank you annevk
14:21
<Alv-c>
I hope it's not too bad to only support UTF-8 d:
14:21
<annevk>
Alv-c: really depends on your goals, probably mostly fine
14:25
<Alv-c>
I'm ashamed now, btw, because the reason why my implementation wasn't percent-encoding query parameters was because I misunderstood "If byte is less than 0x21, greater than 0x7E, or (...)" with "if byte is less than 0x21 AND greater than 0x7E". Like saying "if is less than 2 and greater than 10". Thanks god I didn't push to github yet
14:25
<Alv-c>
Again, thank you annevk.
14:35
<zcorpan>
MikeSmith: nice
14:41
<zcorpan>
MikeSmith: it seems xml:lang in the code is xml:lang in no namespace. it should be lang in the XML namespace instead
14:44
<zcorpan>
MikeSmith: https://github.com/validator/validator/blob/5ff6fe8331fff08bdb98301a360543e5149fdb43/src/nu/validator/servlet/LanguageDetectingXMLReaderWrapper.java#L157 - similarly this should also check if namespace is ""
14:48
<MikeSmith>
zcorpan: actually there is another part of the validator code that seems to always put that lang into the http://www.w3.org/XML/1998/namespace namespace
14:49
<MikeSmith>
that caused me a lot of confusion when I was writing and testing that code
14:49
<zcorpan>
ah, yeah, i remember something about that
14:50
<MikeSmith>
yeah the current logic there matches what the rest of the validator backend actually exposes to that code at that point
15:16
<JakeA>
wanderview: yeah, see example 2 at http://w3c.github.io/preload/#h-introduction
15:17
<wanderview>
JakeA: ah, cool... seems PlzNavigate could boost the preload priority for things it sees during its own "preflight"
15:18
<zcorpan>
correct answer posted for https://twitter.com/zcorpan/status/749976380247605248
15:19
<JakeA>
wanderview: makes sense. Still trying to fit all the use-cases in my head
15:19
<JakeA>
But still not convinced on Alex's proposal. Seems to narrow and hacky.
15:20
<wanderview>
JakeA: but it seems like maybe some of this is doable as H2 push? although I guess this POST might not end up in http cache?
15:20
<wanderview>
JakeA: there is something to be said for a narrow API change now that allows us to do a general purpose API change later when we have more data
15:21
<JakeA>
wanderview: how H2 push interacts with the cache are grossly underspeced as far as I know
17:40
<annevk>
H2 push doesn't put SW in control of networking
17:57
<wanderview>
annevk: why not? if its in the http cache you can access it via fetch(sameOriginURL, { cache: 'only-in-cache' }), no?
18:16
<annevk>
wanderview: it means a connection was established somehow without SW being in control
18:25
<wanderview>
annevk: isn't that exactly what is being requested in this use case...
18:31
<annevk>
wanderview: yes, and without opt-in it's bad
19:28
<wanderview>
Domenic: how does GetV(O, P) ever return with an abrupt completion in PromiseInvokeOrNoop() step 3?
19:32
<annevk>
wanderview: FWIW, he might be away today, apparently a Google US holiday
19:32
<wanderview>
thanks... I'll write an issue
19:35
<wanderview>
I guess if the O is null or undefined
19:35
<Domenic>
wanderview: PromiseInvokeOrNoop({ get foo() { throw new Error("boo"); } }, "foo")?
19:36
<wanderview>
ah, a throwing getter
19:36
<wanderview>
ok
19:39
<wanderview>
Domenic: why does ValidateAndNormalizeHighWaterMark() throw a TypeError for NaN? seems like elsewhere we use RangeError for this
19:39
<Domenic>
wanderview: for NaN in particular? hmm.
19:39
<wanderview>
Domenic: step 2 here https://streams.spec.whatwg.org/#validate-and-normalize-high-water-mark
19:39
<Domenic>
yeah
19:40
<Domenic>
It does seem like it would be cleaner to just use IsFiniteNonNegativeNumber everywhere and throw RangeErrors if not
19:40
<wanderview>
Domenic: seems like it should just use IsFiniteNonNegativeNumber() to me
19:40
<wanderview>
yea
19:40
<Domenic>
File an issue?
19:41
<wanderview>
Domenic: added a comment here: https://github.com/whatwg/streams/issues/475#issuecomment-230581097
19:46
<wanderview>
Domenic: finally made finished my first pass through the js for the refactored ReadableStream spec!
19:46
<wanderview>
now to make it actually work
19:46
<Domenic>
\o/!!
19:49
<wanderview>
Domenic: have you guys done any work to figure out how streams should work across compartments? like `new frame.contentWindow.ReadableStream({ start: frame2.contentWindow.streamStart })
19:50
<wanderview>
added points for one or the other globals being privileged
19:50
<Domenic>
wanderview: nothing special. I think it just falls out of JS semantics? :-/
19:50
<wanderview>
Domenic: maybe its a spidermonkey issue... but I will probably have to write tests to exercise all these combinations
19:51
<wanderview>
since we might need special unwrapping to see object types
20:58
<zcorpan>
hmm, dead pixel :-(
21:07
<miketaylr>
rip