05:46
<sangwhan>
I'm not entirely sure which parts of Servo made it into Gecko, so asking here.. Is this https://dxr.mozilla.org/mozilla-central/source/servo/components/script/dom/htmllinkelement.rs used by Gecko?
07:04
<annevk>
sangwhan: seems highly unlikely
07:04
<annevk>
sangwhan: for now it's text encodings and part of the style system
07:08
<sangwhan>
annevk: Thanks, was just checking if apple-touch-icon is whitelisted in link rel within Gecko, seems like it's dealt with on the Android platform side?
07:25
<TimothyGu>
annevk: we could cite https://tc39.github.io/ecma262/#sec-ecmascript-language-types-string-type for a definition of UTF-16
07:26
<TimothyGu>
esp. when one of the refs to UTF-16 is DOMstring conversion to ES String
07:26
<TimothyGu>
*USVString
07:35
<annevk>
TimothyGu: as I said, once the real fix is in all those UTF-16 references go away
07:35
<annevk>
TimothyGu: so I don't think we should worry too much about it
07:35
<TimothyGu>
ok
07:36
<annevk>
sangwhan: I don't really know anything about that
07:37
<annevk>
sangwhan: I've at various times suggested we create some kind of icon finder algorithm in HTML that deals with all this crap once and for all, but nobody picked up on it and I haven't made the time
07:40
<sangwhan>
I could sit down with wireshark and see what implementations do and document that in the form of a PR if anyone has time to review it..
07:41
<sangwhan>
TIL: ids in implementations are weird, and also zcorpan is living proof that I can't read English
07:44
<zcorpan>
sangwhan: hehe. ids used to be weirder I believe
07:45
<sangwhan>
None of the implementations I checked seem to acknowledge or enforce the uniqueness though, and also let whitespaces through. This probably is worth fixing, but not sure at which layer
07:46
<annevk>
Whoa, this latest thread on whatwg@ is rather surprising to me
07:46
<annevk>
Third email is from someone I think I haven't seen before, but basically spot on with advice
07:46
<annevk>
That doesn't happen a lot
08:07
<annevk>
hayato: https://github.com/w3c/web-platform-tests/pull/4541#issuecomment-328285388
08:13
<hayato>
annevk: thanks. That looks good to me.
09:56
<smaug____>
Which spec might define that modifying .style modifies style attribute too...perhaps HTML
10:00
<smaug____>
hmm, no
10:00
<smaug____>
foolip: perhaps you know
10:01
<smaug____>
I guess https://drafts.csswg.org/cssom/#the-elementcssinlinestyle-interface
10:02
<foolip>
smaug____: looks like it, yeah
10:04
<smaug____>
foolip: I wonder if DOM attribute should be set, when one sets a declaration to its current value
10:05
<smaug____>
That seems to cause https://bugzilla.mozilla.org/show_bug.cgi?id=1395767
10:14
<nox>
"Mutating the declarations must set the style content attribute on the context object to the serialization of the declarations."
10:15
<smaug____>
nox: exactly
10:15
<smaug____>
that is vague
10:15
<nox>
I don't see how.
10:16
<smaug____>
does setting declaration to its current value mutate it?
10:16
<nox>
If I don't see wording that special cases that, I take it as always doing the thing.
10:18
<smaug____>
it is not really a special case, I think. It is more about what the word "mutate" means
10:19
<nox>
Setting = mutating to me.
10:20
<nox>
And AFAIK there would be no precedent for such a behaviour.
10:21
<nox>
Replacing an element by itself queues a mutation record, etc.
10:54
<annevk>
That sentence could be clarified, but I agree with nox's sense of what should happen
10:55
<annevk>
In particular it would be better if declaration mutation was a defined algorithm that ended up invoking something that updates the style content attribute
12:18
<gsnedders>
bah, no hsivonen
12:26
<jgraham>
He sent dev.platform an email not long ago, so you could try email?
12:26
<jgraham>
In unrelated questions
12:27
<jgraham>
Does a websocket connection really not make a page unsalvagable?
12:27
<jgraham>
How are you supposed to keep that alive in the bfcache?
12:27
<jgraham>
What am I missing?
12:27
<jgraham>
gsnedders: Oh I see.
14:27
<gsnedders>
jgraham: yeah, I went for #content instead
14:38
<gsnedders>
jgraham: and now replied to his email. was just trying to be fast before I ran out.
19:37
<czm>
With respect to Fetch, is the following statement from RFC 7231 Section 7.1.1.1 germane?
19:37
<czm>
"When a sender generates a header field that contains one or more timestamps defined as HTTP-date, the sender MUST generate those timestamps in the IMF-fixdate format."