| 00:46 | <KiChjang> | if i have a Document object (as defined in the HTML spec), can we assume that its associated URL is immutable and never changes? |
| 00:48 | <KiChjang> | in other words, is there a one-to-one relationship between a URL and a Document? |
| 01:12 | <MikeSmit1> | annevk: http://stackoverflow.com/questions/39725955/why-is-there-no-preflight-in-cors-for-post-requests-with-standard-content-type |
| 01:58 | <rniwa> | annevk: yt? |
| 01:58 | <rniwa> | hayato: yt? |
| 03:19 | <fantasai> | So.. if the validator is complaining about <details role="note"> is it an error in the document, the validator, or the spec? |
| 03:25 | fantasai | keeps running into this when trying to publish specs |
| 03:43 | <kochi> | rniwa: looking #3835, fyi hayato is ooo this week |
| 05:18 | <MikeSmith> | fantasai: error in the document because per http://w3c.github.io/html-aria/#details <details> is not allowed to have any role attribute at all |
| 05:19 | <MikeSmith> | it’s implicit role=group |
| 05:20 | <MikeSmith> | if there’s a reason why it should allow role=note file an issue at https://github.com/w3c/html-aria/issues |
| 05:32 | <Domenic> | KiChjang: definitely not 1:1; you can have many documents with the same URL |
| 05:32 | <KiChjang> | Domenic, is it due to fragments and queries? |
| 05:32 | <Domenic> | KiChjang: no, I can just open two documents, both to http://example.com/ |
| 05:33 | <Domenic> | or, within the same window, every call to document.implementation.createDocument() creates a new document with URL about:blank. Many documents -> one URL |
| 05:34 | <Domenic> | KiChjang: for one document -> many URL, use pushState or replaceState |
| 05:34 | <Domenic> | KiChjang: or, indeed, just navigate to a fragment |
| 05:34 | <KiChjang> | but once a document is opened, does the URL change at all? |
| 05:34 | <Domenic> | so it's many to many, not 1:1 |
| 05:34 | <Domenic> | the URL changes with pushState, replaceState, fragment navigation so far... probably a few more |
| 05:35 | <KiChjang> | oh, so it's not immutable |
| 05:35 | <KiChjang> | pushState? |
| 05:35 | <KiChjang> | lemme check its definition |
| 05:35 | <Domenic> | https://html.spec.whatwg.org/#dom-history-pushstate |
| 05:35 | <Domenic> | step 10 |
| 05:36 | <Domenic> | document.open() too it looks like |
| 05:36 | <Domenic> | based on multi-global weirdness |
| 05:36 | <Domenic> | e.g. it looks like otherWindow.document.open() will change otherWindow.document's URL to window.document's URL |
| 05:37 | <Domenic> | i wonder if that's actually interoperable though; would be good to get rid of it if not |
| 06:34 | <annevk> | MikeSmith: you gave the correct answer |
| 06:34 | <annevk> | MikeSmith: added a brief comment though |
| 06:34 | <MikeSmith> | thanks |
| 06:35 | <MikeSmith> | I actually pinged you about it before I posted that answer, because I initially thought the OP was asking a more interesting question |
| 06:39 | <annevk> | ah |
| 06:44 | <annevk> | https://lists.w3.org/Archives/Public/public-webappsec/2016Sep/0118.html |
| 06:44 | <annevk> | "I am describing an idealized world. I thought that’s what Standards are for, and we then work towards them? Conversely, it seems like it would be bad to standardize on “good enough for now” and then need to change it." |
| 06:45 | <MikeSmith> | oh man |
| 06:45 | <MikeSmith> | “Edge can’t do an effective job of CORS Preflight right now due to architectural issues which we hope to address in the future.”... |
| 06:46 | <annevk> | I have no idea what that means either |
| 06:46 | <annevk> | I wonder if mkwst is planning on pointing out what's what? |
| 07:43 | <mkwst> | I don't understand Crispin's arguments, and I'm not sure it would be productive to argue with him. So, I'm not planning on pointing out anything, but just responding to the "I have no complaint at all if Chrome chooses to block loopback access from HTTP sites" with something like "Good. Done. And also, why did we have this entire thread if you don't actually |
| 07:43 | <mkwst> | object?" |
| 07:44 | <mkwst> | MikeSmith: Chrome can't do an effective job of it either because I don't understand our network stack (and it's completely divorced from CORS, which lives in Blink). |
| 07:44 | <mkwst> | Everyone has lots of work to do. *shrug* |
| 07:57 | <annevk> | mkwst: I guess I might reply then to at least point out his notion of standards is wrong |
| 07:58 | <annevk> | mkwst: at least as it pertains to the web |
| 07:58 | <mkwst> | annevk: Sounds like a reasonable thing to do. Though I'm not sure he's the right guy at Microsoft to spend time on. *shrug* |
| 07:58 | <annevk> | mkwst: he's not with Edge? |
| 07:58 | <mkwst> | (I'll look at the CSP node cloning thing today; I don't remember any of the context behind that spec text.) |
| 07:59 | <mkwst> | annevk: He is. |
| 07:59 | <mkwst> | brb |
| 08:18 | <annevk> | mkwst: he sends emojis through Wingdings. K |
| 13:22 | <mkwst> | annevk: What's the origin of the document navigated to as a result of clicking on the link in `<a href="javascript:'boo'">yay</a>`? |
| 13:22 | <mkwst> | The origin of the URL from which the navigation occurred? |
| 13:23 | <annevk> | mkwst: I think so |
| 13:24 | <annevk> | mkwst: I think the origin of the active document of the browsing context, but there's some dispute over whether override URL should be a thing, so it might be wrong still |
| 13:24 | <mkwst> | soooo... can we stop doing that? it's crazy. |
| 13:31 | <annevk> | mkwst: I guess, see the "override URL" issue |
| 13:31 | <mkwst> | Well, I'd prefer to just stop navigating to a random string. :) |
| 13:36 | <mkwst> | Nevermind. This happens on 2% of page loads. |
| 16:44 | <annevk> | https://github.com/w3c/input-events/issues/9 o_O |
| 17:09 | <Domenic> | Yeah that thread has me just flabbergasted |
| 17:10 | <annevk> | I really dislike the "please propose text because I don't understand the problem" replies |
| 17:11 | <annevk> | If you don't understand a problem with something you work on, you should really seek to understand it |
| 17:11 | <annevk> | That kind of response is not limited to that thread or specification, by the way |
| 17:13 | <nox> | annevk: Please explain better because I don't understand the problem with such replies. |
| 17:13 | nox | runs away. |
| 17:31 | <astearns> | annevk: conversely, "this is wrong, and I can't tell you how to fix it" is equally frustrating |
| 17:31 | <Domenic> | All we're asking for is to leave the issue open |
| 17:32 | <annevk> | astearns: fair |
| 17:32 | <annevk> | astearns: I don't think that's the situation here |
| 17:33 | <annevk> | astearns: whenever I get those I still consider it somewhat interesting though and would see it more as a challenge than a problem with the reporter |
| 17:35 | <annevk> | astearns: basically, it's indicative of you as an author not fully grasping the domain you're operating in and having to do some more research |
| 17:35 | <annevk> | astearns: and that can be kinda fun |
| 17:38 | <astearns> | giving a little direction on the required research would probably help (going from my own experience trying to dig in to Fetch for the first time) |
| 17:38 | <annevk> | astearns: yeah, for input events I actually gave a quite detailed description of what needs to be done several times |
| 17:39 | <annevk> | astearns: actually, for UI events in general |
| 17:40 | <annevk> | astearns: https://w3c.github.io/clipboard-apis/ has adopted this advice to some extent |
| 17:40 | <annevk> | astearns: the TL;DR is that we need to define "OS UX input actions" (or whatever you wanna call it), not events |
| 17:41 | <annevk> | astearns: events are just a thing that such actions end up generating at one point or another |
| 17:41 | <astearns> | is that detailed description something that would help with this particular issue? (I don't see a detailed description in that thread) |
| 17:41 | <annevk> | astearns: this particular issue is about it not being defined how the extensions affect that model |
| 17:42 | <annevk> | astearns: if you add an attribute to an event, you actually need to define how it's initialized prior to dispatch, probably based on input from the OS |
| 17:43 | <annevk> | astearns: I mentioned that a few times there and at the F2F I explained the whole thing in person too, so I'm not sure why the editor is now not understanding |
| 17:43 | <annevk> | astearns: to be clear, this has been going on for years |
| 17:44 | <astearns> | fair - I'm just trying to see if there's a way to get past this particular bit of miscommunication |
| 17:45 | <annevk> | astearns: e.g., https://lists.w3.org/Archives/Public/www-dom/2014JanMar/0064.html is an early email on the matter |
| 17:46 | <annevk> | astearns: I also found https://lists.w3.org/Archives/Public/www-dom/2013JanMar/0128.html which still isn't addressed yet (has some overlap with CSS stuff) |
| 17:47 | <annevk> | astearns: as for CSS and Fetch, the main thing there is that you need to define a model around stylesheets |
| 17:47 | <annevk> | astearns: a concept of a stylesheet, it's associated URL, referrer policy, etc. |
| 17:48 | <astearns> | linking to those (and other previous discussions) may help - it looks to me (from just skimming this one issue now) that Johannes is missing connections (that I'm also missing) |
| 17:48 | <annevk> | astearns: you need some kind of fetch queue I suppose for values that require a particular resource |
| 17:48 | <annevk> | astearns: and then just start calling the fetch operation somewhere passing along the right bits |
| 17:48 | <annevk> | astearns: the main problem with CSS is that you don't really define a model (yet are now exposing all kinds of stuff through Houdini, which seems like the wrong way around to be addressing this) |
| 17:50 | <annevk> | astearns: okay, I'll point out the email |
| 17:50 | <astearns> | please open Houdini issues if they need to be thinking through this |
| 17:51 | <astearns> | you're likely to get more engagement on fetch concerns from the Houdini group than the CSSWG as a whole |
| 17:51 | <annevk> | CSS needs to be thinking through this |
| 17:51 | <astearns> | and then we can bring that back to CSS :) |
| 17:52 | <annevk> | I have little faith, been trying since I worked on CSSOM however many years ago |
| 17:52 | <annevk> | Glenn Adams took over and would fix it all, not much happened |
| 17:52 | <astearns> | fair point |
| 17:54 | <annevk> | I told the Houdini folks from Google in person too and they didn't really see it either |
| 17:55 | <annevk> | But meanwhile there's nothing in CSS that actually allocates the objects defined in the object model or ties the whole thing together |
| 17:58 | <annevk> | astearns: anyway, I suppose I should try harder, just hard to balance with everything else that's going on |
| 17:59 | <astearns> | yeah, completely understandable |
| 18:03 | <TabAtkins> | Glenn's contribution was zero or negative literally the entire time. He blessedly faded away. Basing any conclusions on your interactions with him would be... incorrect. zcorpan runs CSSOM now, and I'm going to spend time this week or next writing the stuff to nail down the url() fetch model, and hopefully @import too. |
| 18:04 | <TabAtkins> | Houdini has little to nothing to do with the CSSOM, btw. I don't think there's anything tying the two together. |
| 18:05 | <annevk> | TabAtkins: I'm not really basing it off him, just on where we are today |
| 18:06 | <annevk> | TabAtkins: although I do hold some grudge about how I was treated back then |
| 18:06 | <TabAtkins> | Yeah, sure, I've certainly put off some of the relevant work for, um, years. |
| 18:07 | <gsnedders> | To be fair, CSS inherently doesn't expose as much implementation detail through unspecificed gaps compared with most other bits of the platform which are more directly introspectable |
| 18:08 | <TabAtkins> | The fetch model is one of the exceptions to that. |
| 18:08 | <TabAtkins> | Which is a big failing on our part to spec. |
| 18:08 | <annevk> | Values leak all over too in various forms |
| 18:08 | <annevk> | And various things leak through APIs such as offsetWidth |
| 18:10 | <annevk> | TabAtkins: I think the way Houdini ties in is that it exposes many similar things (perhaps more limited at the start) |
| 18:11 | <gsnedders> | that mostly shows itself only insofar as what unit you get the result in, though |
| 18:11 | <TabAtkins> | Insofar as we start exposing more things, we're (I think) doing a lot better with defining them properly. |
| 18:12 | <annevk> | TabAtkins: mkay, I'm fairly skeptical still given that values and their object model representation are in different specifications |
| 18:12 | <annevk> | TabAtkins: but we'll see how it goes |
| 18:13 | <annevk> | TabAtkins: I mean, we learned a lot with HTML as to how to define syntax/model/API and get implementations better at the edge cases |
| 18:13 | <TabAtkins> | Yup. |
| 18:13 | <annevk> | TabAtkins: I haven't really seen CSS take notice much, but if you think it's improving, sounds good I suppose |
| 18:14 | <TabAtkins> | I mean, feel free to continue yelling at us in the future as we keep fucking it up. ^_^ |
| 18:14 | <annevk> | TabAtkins: heh, I wish I had more time, would be fun to work on CSS |
| 18:15 | <TabAtkins> | Meh, you're already on the "basically work on everything" train. |
| 18:15 | <TabAtkins> | I wish I could work more on SVG. |
| 18:15 | <annevk> | TabAtkins: yeah, that one too, heh |
| 18:16 | <annevk> | TabAtkins: I might try to write a somewhat more cogent piece at some point |
| 18:17 | <annevk> | gotta go, good day! |
| 18:29 | <smaug> | whatwg.org has been slow recently |
| 18:35 | <duper> | smaug: dreamhost, heh. |
| 18:47 | <jsbell> | Given that TC39ers are currently TC39ing, I'll probably have to wait for an answer, but... |
| 18:48 | <jsbell> | Anyone know what became of the TextSegmenter proposal for ECMA-402 (i.e. ECMAScript Intl stuff) ? |
| 18:48 | <jsbell> | Old proposal: http://wiki.ecmascript.org/doku.php?id=globalization:text_segmentation |
| 18:48 | <jsbell> | never made it to https://github.com/tc39/ecma402 so far as I can tell, but I swear it was progressing. :( |
| 18:50 | <Domenic> | jsbell: littledan__ is presenting it at this very TC39! |
| 18:50 | <jsbell> | Domenic: w00t! |
| 18:50 | <Domenic> | https://github.com/littledan/Segmenter https://docs.google.com/presentation/d/1X2zBU3bZ4ergVMWfubCsdnHFzeaDgqiTRJVgvNGjQBs/edit#slide=id.p |
| 18:50 | <littledan__> | I haven't presented it yet; happy to take feedback |
| 18:50 | <littledan__> | did we get a Font Metrics API at TPAC? |
| 18:51 | <littledan__> | some committee members are interested in hyphenation as well; not sure how that should fit into all this |
| 18:51 | <jsbell> | littledan__: I'll review. segmentation is key for building fulltext search on top of IndexedDB. I'll try and rope in some library authors for additional feedback. |
| 18:54 | <littledan__> | jsbell: I know eae is also looking into related issues |
| 18:54 | <littledan__> | but from the web side |
| 18:54 | <littledan__> | jsbell: Unfortunately, segmentation is locale-dependent, as you might notice from the API |
| 18:55 | <jsbell> | littledan__: re: font metrics - not sure. It was planned to be discussed but I was far away from those mtgs. I'd ping eae@ who would have been in the right room |
| 19:01 | <astearns> | littledan__: eae and I did a bit of work on font metrics at TPAC - he'll be adding a wicg repo for it soon (this week or next) |
| 19:21 | <gsnedders> | astearns: yay! |
| 19:37 | <rniwa> | annevk: yt? |
| 20:13 | <annevk> | rniwa: about to get some sleep, will reply to issues tomorrow |
| 20:13 | <rniwa> | annevk: okay |
| 20:48 | <smaug> | anyone recall who patches UIEvents to have composed stuff? |
| 20:48 | <smaug> | annevk: you might recall? |
| 20:50 | <smaug> | oh, maybe hayato did that |
| 20:52 | <smaug> | hmm, I could be wrong |
| 20:53 | <smaug> | we rely on related target in this case |
| 20:57 | <smaug> | how is this spec'ed... |
| 20:57 | <smaug> | is mouseenter happens in shadow dom |
| 20:57 | <smaug> | mouseenter is per specs composed |
| 21:02 | <smaug> | ah, there it is, in DOM spec |
| 21:33 | <smaug> | there isn't load event for <video>'s poster image. Should there be? |
| 21:34 | <smaug> | zcorpan: you might have some opinion |
| 21:36 | <zcorpan> | smaug: what's the use case? :-) |
| 21:37 | <smaug> | zcorpan: I could imagine one might want to for example hide the whole <video> if loading doesn't succeed. ok, that would be error event |
| 21:37 | <smaug> | or hide the <video> until load event for poster fires? |
| 21:40 | <zcorpan> | it seems more common to want the <video> to take up the right amount of space (by using width and height attributes) before anything has loaded |
| 21:41 | <zcorpan> | anyway i think poster is a simple convenience feature, if you need something more then use <img> and flip to a <video> with script or so |
| 21:41 | <smaug> | true |
| 21:41 | <smaug> | fine |
| 21:42 | zcorpan | sleep |
| 21:52 | <MikeSmith> | smaug: about whatwg.org you might want to check and make sure you’re not trying to get to it through ipv6 |
| 21:54 | <MikeSmith> | because if you try to reach it through ipv6 it basically behaves as if it’s tarpitting you |
| 23:45 | <Domenic> | rniwa_: I just realized that littledan__'s https://github.com/littledan/Segmenter proposal for JS is solving the issue we discussed about finding the grapheme length of something |
| 23:46 | <rniwa_> | Domenic: oh nice |
| 23:46 | <rniwa_> | Domenic: not sure if I want to tie it with word, sentence, & line stuff though... |
| 23:47 | <Domenic> | rniwa_: apparently ICU does |
| 23:47 | <rniwa_> | Domenic: although... if we did add that feature, we could probably spec selection API using this API |
| 23:47 | <rniwa_> | Domenic: I know ICU does but not sure if it makes sense for JS |
| 23:47 | <rniwa_> | API |
| 23:47 | <Domenic> | rniwa_: just filed https://github.com/littledan/Segmenter/issues/2 to suggest more convenience |
| 23:48 | <rniwa_> | there's a lot of things ICU does for historical reasons. Not sure if this one is intentional and makes sense |
| 23:50 | <jyasskin> | rniwa_: We could ask the ICU authors if they'd still do it this way given a chance to break compatibility. Want to write up an issue in the Segmenter repo that we could point them to? |
| 23:51 | <rniwa_> | jyasskin: that would be useful. |
| 23:51 | <rniwa_> | jyasskin, Domenic: I'd imagine that having one API that counts or iterates characters based on code points and grapheme clusters |
| 23:52 | <rniwa_> | jyasskin, Domenic: then another one that goes over word, sentence, line, etc... |
| 23:52 | <Domenic> | I mean I think we want to expose all (grapheme, word, etc.) of these to the web. So it's a question of whether the spec contains multiple objects or one. One seems to work pretty well. |
| 23:52 | <rniwa_> | jyasskin: Domenic: since I feel like going over each character and going over a word is very different kind of actions |
| 23:53 | <rniwa_> | Domenic: we probably want to but there's no chance of interoperability there because of the way Chinese & Japanese use dictionary based heuristics to define word boundaries |
| 23:53 | <rniwa_> | Domenic: although such is true already for many Intl features so that may not be an issue |
| 23:53 | <Domenic> | rniwa_: interop would be based on ICU dictionaries, wouldn't it? |
| 23:53 | <rniwa_> | Domenic: well, ICU dictionary can be of a different size |
| 23:53 | <rniwa_> | Domenic: also, not all browsers ship with ICU |
| 23:53 | <Domenic> | which ones don't? |
| 23:54 | <rniwa_> | Domenic: or rather not all browsers use ICU as their underlying intl system |
| 23:54 | <jyasskin> | Edge, right? |
| 23:54 | <rniwa_> | Domenic: and even if the browser DID use ICU, there will be differences between ICU versions and of different dictionary size |
| 23:54 | <rniwa_> | Domenic: because of the binary size, I believe, Chrome uses a small dictionary size for ICU |
| 23:54 | <Domenic> | Sure, if you're not using the latest version, you won't be interoperable with the latest version, that's true. |
| 23:54 | <rniwa_> | I believe Chrome* |
| 23:55 | <rniwa_> | Domenic: well, what I'm saying is that even within the same version, you can choose a different size of ICU dictionary |
| 23:55 | <rniwa_> | Domenic: regardless, ICU isn't a thing the spec can refer to so it's kind of irrelevant |
| 23:55 | <Domenic> | Yeah. I guess this just falls into the same pattern as all other Intl features as you said |
| 23:55 | <jyasskin> | Yeah, shipping subsets of ICU is a thing. It seems worth sacrificing that level of interoperability so that not every website needs to ship its own subset of ICU. |
| 23:56 | <Domenic> | Which are in general interoperable if everyone uses ICU, and otherwise, not so much. |
| 23:56 | <rniwa_> | Domenic: well, things are clearly not interoperable between browsers with regards to Chinese & Japanese |
| 23:56 | <jyasskin> | On the question of whether grapheme iteration is a different sort of thing from word iteration, I'd rather defer to the experts than try to figure it out ourselves. |
| 23:57 | <rniwa_> | jyasskin: so my point was more that Grapheme clusters is more of a Unicode concept that doesn't depend on ICU |
| 23:57 | <rniwa_> | even though some browsers may depend on ICU to do it for them |
| 23:57 | <rniwa_> | jyasskin: so I felt like maybe having a separate API for things that are clearly interopeable given a specific version of Unicode might make sense |
| 23:57 | <rniwa_> | but I don't really have a strong opinion nor have I consulted with my colleagues so it's hard to tell |