freenode :: #whatwg

15 May 2017
07:53zcorpanMikeSmith: I suppose template should have been parsed like foreignObject
07:54annevkI think all that was considered at the time
07:54annevkBut too long ago to remember the specifics :/
07:54zcorpanOr like foreignObject doesn't solve that, hmm
07:56MikeSmithwell if we dont want to change the parsing at this point, or cant, then I guess we should at least change the document-conformance requirements as far as the end-tag omission rules
07:57MikeSmithI mean specifically to say that the </td> and </tr> end tags cant be omitted if for a td or tr element thats a child of a template element
08:15MikeSmithwill raise a PR for that then
08:49* hsivonen is currently very annoyed by
08:49hsivonenI wonder how to formulate polite and well-reasoned feedback
08:49hsivonenI don&#39;t feel polite at all about that at the moment
08:51hsivonenI guess I&#39;m going to argue that we know UTF-16 is bad, so we should optimize UTF-8 decode to software that uses UTF-8 internally and, therefore, we should optimize for UTF-8 *validation*
08:55annevkhsivonen: can&#39;t we just argue on the basis that changing something widely deployed is bad if there&#39;s no concrete benefit?
08:55annevkhsivonen: I guess I&#39;m glad you know where to even go raise this, Unicode is rather opaque to me
08:58hsivonenannevk: arguing from deployment isn&#39;t a great point when the argument for change involves standardizing ICU&#39;s spec violation
08:58hsivonenI want to argue though that Unicode now owning ICU is hazardous to the credibility of spec text if ICU bugs, not spec text, rules
08:59annevkI had forgotten the bit about ICU, sigh
09:00annevkJavaScript folks building APIs directly on top of ICU is also rather worrisome
09:00annevkBut I haven&#39;t been able to convince littledan and others of that I think
09:02littledanhey, now&#39;s a great time to have this conversation; Mozilla just started contracting with Igalia to work on Intl features (Zibi&#39;s been my contact), so I&#39;ll have more time to take things in whatever direction is appropriate
09:02littledanquestion 1: Do you think a normative reference to, not ICU but CLDR would be bad?
09:03annevkCLDR dependency seems more okay, there&#39;s some precedent for that I think
09:04annevkThat&#39;s standardized data, basically, not a standardized implementation
09:04littledanquestion 2: If new APIs should differ from ICU, how should they? Obviously we won&#39;t replicate warts like calling something Normalizer2, but there are some basic patterns that have been copied so far, like using using a factory that holds locale data, and keeping the names when they seem reasonable
09:04littledanare these bad ideas?
09:05littledanquestion 3: How should we deal with OS default settings--should it somehow be serialized in a locale object (similar to current patterns), or should it just be threaded through as a complicated default, possibly in conjunction with new options that explicitly opt into it (Zibi&#39;s been suggesting this; apparently the suggestion came from MS)
09:07annevkI think in terms of API design it&#39;s always good to check how various systems solve it, but ultimately you want something that looks familiar to JavaScript developers; if what ICU does matches that it doesn&#39;t necessarily seem problematic to copy patterns
09:08annevkAs for that last question, OS defaults are typically exposed on the Navigator object somehow
09:08littledanquestion 4: Should we add CLDR pattern strings for datetime and number formatting? Should we add parsing? We&#39;ve been leaving these out so far, in order to avoid being too ICU-like
09:09littledanthe claim is that, without pattern strings, there&#39;s no realistic way to expose the OS defaults on the navigator
09:11annevklittledan: does Microsoft participate actively?
09:11littledannot at the moment; they&#39;re too tied up in investigating switching to ICU
09:11annevklittledan: so far they have the only non-ICU implementation that&#39;s somewhat competitive in terms of features
09:11annevkoh my
09:12littledanOTOH we have community members who are building various polyfills based on CLDR and not ICU
09:12annevkI wish Mozilla had more resources so we could write an impl in Rust
09:12littledanlike Mathias Bynens and the Intl.js folks
09:13littledanwell, I was just invited to the Mozilla all-hands for this Intl work, and then un-invited since it&#39;s not Quantum; maybe if a Rust rewrite were added into the picture, Intl would suddenly be Quantum and everyone would get resources...
09:14littledancurrently Zibi&#39;s working on using ICU *more* rather than Mozilla&#39;s legacy stuff for things were functionality overlaps; Jungshik Shin is doing the same within V8
09:14littledansince the non-ICU stuff tends to be a worse implementation
09:15annevkWell, hsivonen just wrote a new encoding library in Rust that seems to be better than what ICU offers, which is what prompted my thing above
09:15littledananyway, FWIW V8 doesn&#39;t use ICU&#39;s UTF-8 decoder and isn&#39;t looking at switching
09:16annevkBut we didn&#39;t use ICU before, we used iconv
09:16annevkWell, plus patches
09:16littledananyway, that thread is sad
09:17annevklittledan: anyway, I guess we are mostly on the same page, I just hope that everyone using ICU underneath won&#39;t make future refactorings extremely hard
09:18littledanI hope so too. The Intl spec tries to be sufficiently detailed so it should be possible. Do you think it meets that goal?
09:18littledan(actually, IMO the Intl spec is too detailed now, tying down some things to a wrong default that implementations should be allowed to get right)
09:26annevklittledan: I haven&#39;t reviewed it in enough detail to say, I probably should one day
10:25hsivonenhmm. my email doesn&#39;t show up at
10:26hsivonenmaybe stuck in human moderation or achive view slow to update
10:26hsivonenannevk: argument from deployment works, actually, since Blink and WebKit don&#39;t use the ICU UTF-8 decoder
10:28hsivonenannevk: uconv isn&#39;t iconv plus patches
10:29hsivonenannevk: we use iconv only for non-Android, non-Mac *nix filenames
10:30MikeSmithJakeA: when you have time, please see and consider posting an answer
10:32MikeSmithI tried myself but thats basically just repeating whats already explained at MDN and the OP seems to indicate theyre seeing some behavior that doesnt conform to the requirements
10:32MikeSmithbut theyre seeing it in both Firefox and Chrome so maybe theres something Im misunderstanding
10:47annevkhsivonen: oh, uconv is its own thing, ta
10:49annevkMikeSmith: added an answer
10:49MikeSmithannevk: thanks
10:49* MikeSmith takes a look
10:50MikeSmithah, d&#39;oh navigations
10:50MikeSmithannevk: thanks
10:52annevkmkwst: potentially with Origin policy we could do the &quot;request with me without credentials always&quot; thing, but bleh
10:52mkwstannevk: *shrug* It would be nice if the problem statement was a bit crisper. It&#39;s not clear what folks want.
10:53annevkmkwst: timbl doesn&#39;t like varying on credentials; he thinks the input should be just a URL, nothing else
10:54hsivonenI now I got notification that my email got stuck in moderation
10:54annevkmkwst: and the TAG apparently doesn&#39;t just tell me no so now there&#39;s this debate-by-proxy
10:54annevks/me/him/ oops
10:56mkwstannevk: *shrug* Like I said on the bug, I don&#39;t think something like `Access-Control-Allow-Origin: omg-its-totally-public-did-you-make-sure-this-is-sane?` is out of the question.
10:56mkwstBut I&#39;m reluctant to add it without something more compelling than &quot;Tim doesn&#39;t want to add options to `fetch()`.&quot;
10:58annevkmkwst: I&#39;d actually like that implementers pick up on existing extensions first
10:59mkwstBy &quot;extension&quot; do you mean &quot;redirect behavior&quot;?
10:59annevkmkwst: that and also allowing * for more headers
10:59mkwstI know some folks on our loading team wanted to look at that.
11:00mkwstHrm. Which headers? That should be a small change.
11:00annevkmkwst: Expose-Headers, Allow-Headers, Allow-Methods (as long as no credentials are in play and with the exception of Authorization)
11:01annevkmkwst: I filed bugs and there&#39;s tests too
11:01mkwstI see. I&#39;ll follow up.
11:16mkwstannevk: Does Gecko support these wildcards? I&#39;m trying to run the tests you added from ``, but it&#39;s too slow to execute.
11:16annevkmkwst: I don&#39;t think it does yet
11:17annevkmkwst: using https:// sometimes ends up being faster on
11:17annevkmkwst: not sure what is going on with that server, it&#39;s rather useless
11:17mkwstHuh. HTTPS is faster.
11:18mkwstOk. I&#39;ll poke our loading folks to see if they can get this on a roadmap.
11:33hsivonenI take it that moderation of the unicode list doesn&#39;t happen at European business hours
12:05annevkhsivonen: Mark Davis lives in Europe, but I suppose he wouldn&#39;t do the moderation
12:06annevk(I tried to find if he has a GitHub ID so I could copy him on that issue, but no luck.)
12:53zcorpanMDN and caniuse claim IE10/11 support WebKitCSSMatrix. Per browserstack testing that seems false... Anyone know which version (of Edge) it was added?
14:30smaugvar l = document.createElement(&quot;label&quot;); l.innerHTML = &quot;<input>&quot;; l.firstChild.labels.length
14:30smaugwhy would that be 0?
14:32annevksmaug: sounds like a bug
14:35smaugthat is what I think too
14:36noxWhat kind of music would the band &quot;Pseudo-classing Pseudo-elements&quot; play?
16:15jyasskinhsivonen: Markus works for Google, so if a direct line would help, I can help set one up.
16:23jyasskinhsivonen: Your message didn&#39;t really make clear to me what operation the new spec would make difficult. Is it ingesting external &quot;claimed-UTF-8&quot; into internal &quot;definitely-UTF-8&quot;? Markus&#39;s team has written that operation, so he&#39;ll have some context for it.
17:18annevkjyasskin: yes, when you need to U+FFFD input
18:21hsivonenjyasskin: the proposed spec change requires not just an UTF-8 validation state machine but also the states for skipping over the original UTF-8 forms that were made illegal for UTF-16 compat
18:22hsivonenjyasskin: so it requires a larger state machine and the rationale is really flimsy: &quot;feels right&quot; in the context of an UTF-16-oriented implementation
18:23hsivonenjyasskin: currently, you only need the validation state machine states, since you fall out of the state machine to output U+FFFD as soon as invalidity is detected
18:28jyasskinhsivonen: Mhmm. FWIW, even ignoring UTF-16, transforming up to 6 bytes of data matching the &quot;n 1&#39;s followed by n-1 bytes&quot; form into a single U+FFFD seems reasonable. But if it makes the optimal UTF-8 validator larger, that seems like a good argument against it.
18:30jyasskinIt&#39;s the sort of thing that might convince Markus, especially if you have code size or speed measurements to explain the impact.
18:36hsivonenjyasskin: I think the current spec text is technically better due to the state machine size issue, but procedurally, I think a proposal to change something like this should be argued way better than &quot;feels right&quot;
18:37jugglinmikeJakeA: I&#39;ve been trying to verify the validity of a service workers test in WPT. I could use your help, though. Would you mind weighing in on ?
18:39jyasskinhsivonen: The choice of how many U+FFFDs to include initially seemed like a matter of taste to me, in which case &quot;feels right&quot; is perhaps the only way to decide. However, you&#39;ve introduced a technical reason that one of the options is easier to implement, which starts meaning the technical reason should win.
18:57JakeAjugglinmike: looking into it now
19:06JakeAjugglinmike: I agree with your analysis. That condition shouldn&#39;t happen. I&#39;m not sure why the test is broken down into wait_for_install and wait_for_activate isn&#39;t wait_for_activate enough?
19:09jugglinmikeJakeA: Seems that way
19:11jugglinmikeJakeA: I was going to say that, from the perspective of the person who thought these extra conditions were necessary, the split would also be necessary
19:12jugglinmikebut knowing the history of the test (specifically the commit that Matt found ), this was originally written in such a way as to not need that
19:12jugglinmikeI&#39;m glad to get your confirmation here. I&#39;ve spent the better part of today going back and forth between the spec, the test, and your post
19:44annevkjyasskin: maybe initially a matter of taste, but a decade in it should not be a matter of taste to change it
19:45jyasskinannevk: Fair enough.
19:52jugglinmikeJakeA: Would you mind taking a look at another one?
20:03JakeAjugglinmike: glad the event loop post was useful. Looking at that other issue now
20:05JakeAjugglinmike: is it specifically line 61+ that you&#39;re wanting me to look at, or the test as a whole?
20:09jugglinmikeJakeA: actually, it&#39;s falken&#39;s request and my response to his request
20:09JakeAAhh the equality thing. Gotcha
22:26tobieWhat does setting [SecureContext] on a partial interface actually do?
22:31Domenictobie: not really sure, but maybe nothing, since the main interface already has it...
22:31tobieDomenic: seems like we should disallow them altogether, if that&#39;s the case.
22:33DomenicWell, or that issue is suggesting mandating them, but yeah....
22:33tobieWell, the mandate is decorative.
22:34tobieyou can&#39;t have a constructor on a partial interface. You shouldn&#39;t have [SC] either.
22:36jyasskintobie: Is it a shorthand for putting [SecureContext] on all the bits added by that partial part of the interface?
22:37tobiejyasskin: I don&#39;t think so. But I might be wrong.
22:37tobiejyasskin: I&#39;m having a hard time parsing sentences like &quot;The interface or namespace is not available only in secure contexts.&quot; tbh
22:38jyasskinI interpret &quot;The interface member is available only in secure contexts if and only if the interface or partial interface the member is declared on is.&quot; to say that methods within a [SecureContext] partial interface are themselves [SecureContext].
22:38jyasskinI wouldn&#39;t object to saying that you should just say [SecureContext] on all the members you intend it for.
22:41jyasskintobie: I think [SecureContext] on a partial interface does nothing to the actual interface object, since doesn&#39;t care whether *partial* interfaces are available only in secure contexts.
22:42jyasskins/wouldn&#39;t object to/would support/
22:42tobiejyasskin: so [SecureContext] on a partial interface whose&#39;s non partial interface doesn&#39;t have [SecureContext] is shorthand for marking each members of that partial interface with [SecureContext]?
22:43jyasskinThat&#39;s how I read the current wording, yes.
22:44tobieWhereas [SecureContext] on a non partial interface makes the whole interface unavailable, not just its members right?
22:45tobieI think it would be a lot simpler to spec, and a lot clearer to read and understand if that was simplified.
22:46jyasskinI agree. :)
22:57jyasskintobie: Oh great, you&#39;re citing me as if I actually know things instead of just guessing them based on some words in a spec. ;-)
23:01tobiejyasskin: As far as I&#39;m concerned, anybody willing to comment here understands this better than I do at present. :D
23:18tobieSo predictably bz has a point
23:25Domenictobie: I don&#39;t understand the question about &#39;How would you handle the &quot;on |O| if |O| is not null&quot; part keeping it in WebIDL, though?&#39;
23:25DomenicWhy not just put &quot;on |O| if |O| is not null&quot; into those steps?
23:26DomenicLike you did?
23:26tobieI guess it&#39;s the &quot;on&quot; part that bothers me.
23:27DomenicHmm, seems fine to me...
23:30tobieDomenic: OK, I was thinking about putting that right after the were is defined.
23:32Domenictobie: seems good. I edited my most recent comment as I realized I forgot the &quot;O&quot; bits.
23:32tobieI was about to ask. :)
23:33tobieAlright I&#39;ll fix that tomorrow
16 May 2017
No messages
Last message: 12 days and 2 hours ago