05:48
<yhirano_>
hi, does any one know how we should handle a "retry" field without value, in EventSource?
05:48
<yhirano_>
WebKit and Blink restores their default retry value, but it is not written in the spec.
05:49
<yhirano_>
Is it simply wrong, or is there any historical context?
08:51
<annevk>
Hmm, I wonder why the HTML standard claims it was updated today, while in fact it was last updated on Friday
09:40
<nox>
annevk: So is DOMTokenList.replace something Servo should implement?
09:41
<nox>
annevk: I tried to specify [Alias=…] btw, couldn't write a sentence that made sense.
09:41
<annevk>
nox: I don't see why Servo shouldn't implement stuff
09:42
<ondras>
guys, not escaping ampersands in html attribute values, is this a recent stuff?
09:43
<nox>
annevk: "00:05 <Domenic> nox: well, it doesn't have to be; nobody implements it 00:05 <Domenic> and i don't think there was any implementer interest"
09:43
<ondras>
or has this been around from the very beginning ?
09:44
<nox>
annevk: That was prompted by the following question: 21:48 <nox> Given that now classList.add() and and classList.remove("unexisting-class") both set the 'class' attribute to the empty string if it was missing, 21:49 <nox> shouldn't classList.replace("unexisting-class", "foo") create it too?
09:44
<nox>
ondras: Always been around.
09:44
<nox>
ondras: SGML and XML both allow that.
09:44
<nox>
ondras: Same for '<'.
09:44
<ondras>
interesting
09:45
<ondras>
so perhaps the validator was previously marking "?a=b&c=d" as an error?
09:45
<ondras>
(incorrectly)
09:46
<ondras>
nox: because my firefox, if I am not mistaken, highlights these & in a red color in the "view source" mode
09:48
<Ms2ger>
That's not as easy a question as it sounds :)
09:48
<nox>
Ms2ger: Which one?
09:48
<Ms2ger>
In general, &amp; is safer
09:48
<nox>
Yeah, that the spec allows it doesn't mean all UAs can cope with it.
09:48
<Ms2ger>
UAs cope, that's not an issue
09:48
<annevk>
nox: I guess we could change replace()'s behavior slightly, don't care much about that
09:48
<nox>
I'm suddenly not sure anymore whether & is in the set of allowed characters.
09:49
<nox>
I know < is, but I think I'm wrong about &.
09:49
<ondras>
well if it is allowed for the time being (including sgml and xml), one would expect it works the same way in all parsers...
09:49
<annevk>
nox: replace() was requested by Ember.js, so tokens wouldn't get reordered in templates
09:49
<ondras>
nox: I am pretty sure "&" is allowed when it does not resemble an entity reference
09:49
<nox>
ondras: Yeah I said crap.
09:49
<Ms2ger>
ondras, just don't do it :)
09:49
<nox>
ondras: It isn't.
09:49
<ondras>
nox: i.e. the [a-z]+ after it does not end with ";"
09:49
<nox>
Cf. "additional allowed character" in https://html.spec.whatwg.org/multipage/syntax.html#attribute-value-(double-quoted)-state
09:50
<nox>
and https://html.spec.whatwg.org/multipage/syntax.html#attribute-value-(single-quoted)-state.
09:50
<ondras>
well
09:50
<ondras>
https://html.spec.whatwg.org/multipage/syntax.html#character-reference-in-attribute-value-state
09:50
<ondras>
Attempt to consume a character reference.
09:50
<ondras>
If nothing is returned, append a U+0026 AMPERSAND character (&) to the current attribute's value.
09:51
<ondras>
sounds like there is a well-defined scenario for the unescaped amp
09:51
<nox>
ondras: Read how one should consume a character reference.
09:52
<nox>
ondras: "If the last character matched is not a U+003B SEMICOLON character (;), there is a parse error."
09:52
<nox>
annevk: Ok.
09:52
<nox>
annevk: But do implementors plan to support it?
09:53
<annevk>
nox: I hope so
09:53
<nox>
annevk: Ember should have asked for a toggle method with two arguments IMO.
09:53
<ondras>
hmmh
09:53
<ondras>
If the character reference is being consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON character (;), and the next character is either a U+003D EQUALS SIGN character (=) or an alphanumeric ASCII character, then, for historical reasons, all the characters that were matched after the U+0026 AMPERSAND character (&) must be unconsumed, and nothing is returned.
09:53
<annevk>
nox: toggle already has two arguments
09:54
<nox>
annevk: Ok, I need more sleep. :)
09:54
<nox>
annevk: Two DOMString arguments, I meant.
09:54
<ondras>
nox: honestly, I am not sure I understand the sentence I posted last
09:54
<ondras>
nox: but the current validator allows ?a=b&c=d
09:55
<nox>
ondras: Doesn't matter, the sentence I pasted still apply.
09:57
<annevk>
nox: overloading toggle seems worse than just having a distinct method that is clear
09:57
<nox>
annevk: Oh it wouldn't do the same thing as replace.
09:57
<nox>
I'm pretty sure Ember toggles two classes, and that require two different replace calls, doesn't it?
09:58
<annevk>
nox: hmm no, they have something like _templateValue_ and need to replace that, without it changing location
09:58
<nox>
Ok.
09:59
<ondras>
nox: I understand that the spec it more important that the validator's behavior. But, still: 1) what is the *real* meaning of that paragraph I posted? 2) does this mean the validator does not follow the spec?
09:59
<MikeSmith>
ondras: yes the validator was previously marking "?a=b&c=d" as an error
10:00
<MikeSmith>
until very recently the validator had always reported an error for that caseーbecause originally the HTML spec in fact did define it as an error
10:00
<ondras>
MikeSmith: according to what nox wrote, it is still an error
10:00
<nox>
MikeSmith: "If the last character matched is not a U+003B SEMICOLON character (;), there is a parse error."
10:01
<ondras>
but I find it hard to understand this part of the spec
10:01
<MikeSmith>
nox: I think that requirement doesn't apply to all cases
10:02
<MikeSmith>
I am pretty sure the current spec does make the "?a=b&c=d" case a non-error
10:02
<nox>
I'm pretty sure that's not the case.
10:02
<nox>
I interpret ondras' citation as "?a=b&c" not being an error,
10:03
<nox>
but "?a=b&c=d" being one.
10:03
<MikeSmith>
zcorpan: ⬆
10:03
ondras
likes the arrow glyph.
10:04
<MikeSmith>
nox: I'll look back at the (several) bug reports from users that I got about this after the spec changed
10:04
<MikeSmith>
which it did
10:04
<MikeSmith>
it may be that it's now changed back, I dunno
10:04
<ondras>
(both posted variants are considered valid by the validator, for the record)
10:05
<nox>
It seems the spec contradicts itself.
10:05
<MikeSmith>
yeah at this poine I'm very unlikely regardless to revert the validator change I recently made with regard to this
10:05
<nox>
"… and the next character is either a U+003D EQUALS SIGN character (=) …"
10:05
<nox>
"… However, if this next character is in fact a U+003D EQUALS SIGN character (=), …"
10:06
<nox>
Ah no, it just says after the fact that in this case, it's a parse error.
10:06
<zcorpan>
"If the last character matched is not a U+003B SEMICOLON character (;), there is a parse error." only applies if an entity was actually matched
10:06
<MikeSmith>
ok yaeh that's what I had thought
10:07
<nox>
zcorpan: Ok, but it is still a parse error even if no entity is matched.
10:07
<ondras>
zcorpan: interesting, but I do not see how to infer this fact from the spec
10:07
<zcorpan>
nox: what is? (and is it in-attribute-value or not?)
10:09
<MikeSmith>
for anybody curious, the change I landed that affects the validator behavior around this was actually a change to the htmlparser the validator relies on, and I landed the change about a month ago https://github.com/validator/htmlparser/commit/4e5446644c3a0d0faad76f2650ba6ca453196a48 (and pushed it to the W3C validator then)
10:09
<nox>
zcorpan: "If the character reference is being consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON character (;), and the next character is either a U+003D EQUALS SIGN character (=) or an alphanumeric ASCII character, then, for historical reasons, all the characters that were matched after the U+0026 AMPERSAND character
10:09
<nox>
(&) must be unconsumed, and nothing is returned. However, if this next character is in fact a U+003D EQUALS SIGN character (=), then this is a parse error, because some legacy user agents will misinterpret the markup in those cases."
10:09
<nox>
zcorpan: Last sentence.
10:10
<MikeSmith>
also I think the change hasn't been pushed to validator.nu so it's likely that validator.nu still reports an error for this, but I've not checked
10:11
<zcorpan>
nox: i think that is only intended to apply if something was consumed, e.g. <p title="&amp=">
10:12
<zcorpan>
nox: granted it's not super-clear
10:13
<MikeSmith>
yeah it seems clear that it's not super-clear 😀
10:14
<nox>
That's the paragraph about it not being consumed.
10:14
<zcorpan>
nox: yeah sorry i was confused myself
10:15
<zcorpan>
nox: i mean the paragraph above, i read "no characters are consumed, and nothing is returned" as "return and abort here"
10:15
ondras
imagining how the parser vomits (un-consumes) data after reaching an EQUALS SIGN
10:15
<zcorpan>
and in &c= no match can be made.
10:16
<zcorpan>
and so &c= is not a parse error but &amp= is (in attribute value)
10:17
<nox>
Where does it distinguish c from amp?
10:19
<zcorpan>
"If no match can be made, then no characters are consumed, and nothing is returned."
10:50
<deltab>
hmm, in data state, U+0000 is emitted as a character token; elsewhere it's replaced with U+FFFD or ignored
10:53
<nox>
deltab: Yes.
10:53
<deltab>
is that intentional?
10:53
<nox>
Yes.
10:54
<nox>
deltab: Cf. that note in the spec: "The handling of U+0000 NULL characters varies based on where the characters are found. In general, they are ignored except where doing so could plausibly introduce an attack vector. This handling is, by necessity, spread across both the tokenization stage and the tree construction stage."
10:54
<deltab>
the character token part, I mean
10:54
<deltab>
why's it not replaced or ignored?
10:55
<Ms2ger>
"legacy"
10:56
<deltab>
I guess the note under "12.2.5.4.8 The "text" insertion mode" doesn't apply to that
10:58
<MikeSmith>
zcorpan: about "&c= is not a parse error but &amp= is", I believe what I implemented in the htmlparser/validator matches thatーand overall is now in conformance with the current spec. At least that's what I intend. So if you try it and find any cases where the validator should per-spec be emitting an error but isn't, please let me know.
10:59
<zcorpan>
MikeSmith: ok i can have a look
11:00
<MikeSmith>
thanks
11:07
<ritsyy>
annevk: as you specified data-x should be kept right? https://github.com/whatwg/html/pull/499/files
11:15
<zcorpan>
MikeSmith: seems to work as it should... but now i wonder why we're anal about the semicolon for numbered charrefs but so lax for named refs
11:16
<zcorpan>
e.g. &#x40
11:33
<MikeSmith>
zcorpan: yeah true
11:34
<MikeSmith>
and thanks for checking
11:43
<annevk>
ritsyy: you should probably remove it for consistency
11:43
<annevk>
ritsyy: not needed for flags
11:52
<ritsyy>
annevk: okay
12:38
<annevk>
MikeSmith: note that if an attribute value contains a space, you can break there too
12:38
<annevk>
MikeSmith: didn't notice the attribute values had spaces in them initially, sorry
12:39
<MikeSmith>
annevk: no worries
12:39
<MikeSmith>
so should I leave it as it is, or re-break it on the spaces?
12:40
<MikeSmith>
I thought we had problems with refs with embedded line breaks
12:40
<annevk>
MikeSmith: probably break on the spaces if that gets us longer lines
12:40
<annevk>
MikeSmith: hmm, I don't think so, but now I'm not sure anymore
12:41
<MikeSmith>
heh
12:41
<MikeSmith>
well I'll try and see if anything breaks
12:46
<MikeSmith>
annevk: any objection to breaking before the ">" in start tags?
12:46
<MikeSmith>
e.g.:
12:46
<MikeSmith>
The <span>Content Security Policy</span> given in the <code data-x="attr-meta-content"
12:46
<MikeSmith>
>content</code> attribute will be <span data-x="enforce the policy">enforced</span> upon the
12:46
<MikeSmith>
>current document. <ref spec="CSP"></p>
12:47
<annevk>
MikeSmith: we haven't done it thus far
12:47
<ondras>
please, can anyone provide rationale for the uri stripping in CSP reports?
12:47
<MikeSmith>
annevk: yeah I know. I'm wondering if there's any reason not to start now. Other than greater consistency
12:47
<annevk>
ondras: leaking of redirects, iirc
12:48
<MikeSmith>
yaeh
12:48
<ondras>
annevk: can you elaborate please? I do not follow what is the problem.
12:48
<annevk>
MikeSmith: it looks a little ugly, I'll defer to Domenic
12:48
<annevk>
ondras: https://fetch.spec.whatwg.org/#atomic-http-redirect-handling
12:48
<ritsyy>
annevk: i didn't understand removing the images at the same time https://github.com/whatwg/html/pull/526#issuecomment-172517560
12:48
<MikeSmith>
ondras: I think that's actually mentioned somewhere, the rationale
12:48
<ondras>
MikeSmith: I would be happy to read about it somewhere. My google-fu is apparently low.
12:49
<annevk>
ritsyy: the HTML repository hosts images used by examples, if we remove an example that uses those images, we should remove the images too (if it's the only example that uses them, which I think is the case here)
12:49
<MikeSmith>
ondras: the CSP spec and/or commit logs for it
12:50
<ondras>
the CSP spec only explains that stripping takes place
12:50
<ondras>
no rationale afaik
12:50
<ritsyy>
annevk: yeah i should remove them from the images too, ok ok
12:55
<ondras>
annevk: I am thoroughly puzzled by this. The CSP report is not supposed to make any (potentially redirecting) requests; I just want to see what was requested. Would you please somehow outline how an attack vector would look like here?
12:55
<ondras>
annevk: ah, I got it!
12:56
<ondras>
an attacker with a rogue CSP logger
12:59
<annevk>
bingo
13:02
<ondras>
:-)
13:04
<ritsyy>
annevk: in one of the example of the data element, table sorting model is used in which is to replaced with a script then, can we point through javascript library like sortable.js , i was not sure
13:08
<annevk>
ritsyy: yeah, referencing a library in the example seems okay
13:08
<annevk>
ritsyy: but don't include the library inline of course
13:09
<ritsyy>
annevk: yeah, okay i will take care of that thanks!
14:51
<ritsyy>
annevk: could you see this once https://paste.kde.org/pfyjmvkdd
14:55
<annevk>
ritsyy: yeah, I guess that's fine, although it's not ideal to include the script synchronously
14:56
<annevk>
ritsyy: the language could also use some improvement, e.g., it's JavaScript
14:56
<annevk>
ritsyy: and you probably want to say "the data element" rather than just data
14:59
<ritsyy>
annevk: oh then if it's not that much suitable should i change it?
15:01
<ritsyy>
annevk: i would do these changes
15:01
<ritsyy>
will*
17:33
<smaug____>
annevk: ok, not going to write to the bug, but "doing bad thing is fine because they are already doing it"?
17:34
<annevk>
smaug____: it isn't clear to me that what they're doing is bad, presumably they need those computations before next render
17:34
<smaug____>
I do expect that we'll add enqueueMicrotask API, but I hope people first think a bit what it means
17:34
<smaug____>
I hope people try to improve the platform by making it easier to write web pages which are responsive from user point of view
17:34
<annevk>
smaug____: and for all intents and purposes we already have that API, it's just not as efficient as it could be
17:35
<smaug____>
we're missing an API which tries to do stuff before rAF, but do it async
17:35
<smaug____>
setTimeout(, 0) is too unreliable
17:35
<annevk>
setTimeout queues tasks, so layout will have happened
17:35
smaug____
starts to feel inventing microtasks may have been a bad thing :/
17:36
<annevk>
Having said that, I'm not really sure what you mean with "async"
17:36
<smaug____>
that event loop spins
17:36
<annevk>
But that means layout happens
17:36
<smaug____>
microtask is totally synchronous from browser point of view
17:37
<smaug____>
layout happens at rAF
17:37
<smaug____>
not at random times
17:37
<smaug____>
(layout may of course happen also sync when .offsetLeft or such is accessed )
17:38
<annevk>
Okay, so you want an API that queues tasks that need to happen just before rAF?
17:38
<smaug____>
that is rAF
17:39
<smaug____>
I'm thinking, whether we need setTimeout(, 0) like API, which guarantees that the callback is called at latest at rAF
17:39
<smaug____>
but sooner if possible
17:40
<smaug____>
something like setImmediate + rAF
17:41
<smaug____>
that way UA could still process other stuff between the callbacks
17:41
<Domenic>
smaug____: the alternative here is for frameworks to keep an array of functions they want to execute after all their work is done
17:41
<Domenic>
smaug____: the alternative is not to use some new scheduling API
17:42
<Domenic>
smaug____: that is what frameworks do today, they just use MutationObserver with an empty text node to detect "their work is done"
17:42
<smaug____>
Domenic: I guess I'm saying that frameworks are doing it wrong atm
17:42
<Domenic>
smaug____: well, good luck with that. A lot of thought has gone into these frameworks over a lot of years.
17:42
<smaug____>
I was horrified about that 100s of microtasks comments
17:42
<smaug____>
sure. though microtasks aren't that old thing
17:42
<Domenic>
yes, you really should not be. are you horrified by 100s of lines of normal code?
17:43
<smaug____>
and some of those frameworks still fallback to setTimeout
17:43
<Domenic>
for IE8 yeah
17:43
<Domenic>
and websites built in those frameworks are a shitty UX on IE8
17:43
<smaug____>
right
17:44
<smaug____>
I am horrified doing any major js execution synchronously in the main thread. In workers it is fine. The more we add microtask callback usage, the more we end up doing sync stuff
17:45
<smaug____>
(and I need to say again: "I do expect that we'll add enqueueMicrotask API")
17:45
<Domenic>
This is really just about preventing people from having to require a library that twiddles an empty text node
17:46
<Domenic>
I don't think microtask usage is going to be any less just because people have to require a library. Making the concept harder to use doesn't prevent people from using it, in a world with abstractions and function calls.
17:46
<annevk>
"or just Gecko" is a bit inflammatory, the concern of blocking the processing user input should really concern everyone
17:46
<smaug____>
and to me the question is not about that, but to try to convince people to use programming models which aren't synchronous
17:48
<smaug____>
we're trying to do that with sync XHR
17:48
<smaug____>
sure, that is way worse case
17:55
<smaug____>
btw, I'm pretty sure I've seen long Promise chains showing up in Firefox startup profiles. Like, we end up painting browser UI later than we should because we end up processing microtask/promise queue.
18:03
<smaug____>
Domenic: do you happen to know what frameworks did before MutationObserver?
18:04
<Domenic>
smaug____: oh yes. They used various tricks to get tasks that are faster than setTImeout(,0). MessageChannel, postMessage-to-yourself were popular.
18:05
<smaug____>
ok, those are async
18:05
<Domenic>
yep. but they would only post one task then inside that task loop over all accumulated framework-microtasks
18:10
<annevk>
It does seem like they want "do this before render, in order" more than "do this at end-of-task"
18:11
<Domenic>
annevk: talking to Misko what they really want is "do this before any new tasks get posted"
18:11
<annevk>
although maybe not, since "do this before render, in order" can be polyfilled using rAF and nobody is doing that...
18:11
<annevk>
k
18:11
<Domenic>
it's used for e.g. synchronizing data models. all future tasks should get a consistent view of the world with the data synced, after the current task + microtasks have settled down.
18:12
<Domenic>
that is a larger problem though, and much harder to solve. along the way we encountered the fact that one building block of it was hidden behind MutationObserver, so proposed unlocking it.
18:13
<smaug____>
annevk: well, polyfilling using rAF would put too much pressure to rAF which would make rendering to be postponed
20:21
<smaug____>
Domenic: you might know. Has anyone written some blog post when to use or more importantly when to not use Promises
20:22
<smaug____>
(I'm just reviewing some tests and feels like overuse of Promises without no reason)
20:22
<smaug____>
(could link to some documentation when to not use Promises)
20:22
<Domenic>
smaug____: https://www.w3.org/2001/tag/doc/promises-guide#when-to-use + https://www.w3.org/2001/tag/doc/promises-guide#when-not-to-use is the general guidance
20:22
<smaug____>
thanks
23:06
<TabAtkins>
annevk: It looks like the term "scheme data" no longer exists in the URL standard (despite HTML referring to it). What's the correct thing to refer to now - the "scheme" definition?
23:08
<TabAtkins>
Domenic: In the Promises guide, a note about not rejecting for a missing key in an AsyncMap could probably use a note to the effect that, while some languages *do* consider a missing key to be an exception-worthy event (Python), JS does not.
23:11
<TabAtkins>
Domenic: And I'm still bothered by the suggested "in parallel" language. ^_^ Every single time, it reads to me that you should execute the substeps in parallel with each other (and implicitly, in series with the wider algorithm), instead of the intended meaning of running the substeps in series, but the subalgo as a whole is done in parallel with the wider
23:11
<TabAtkins>
algo.
23:13
<TabAtkins>
(I know it links, and it's a term of art that can just be learned. It just rubs me the wrong way initially every time I see it.)
23:16
<TabAtkins>
annevk: Looking more into it, it seems like "scheme data" was probably a term for the stuff after the scheme in non-hierarchical URLs, and now something like blob: just has a host and a single path entry.