| 00:00 | <roc> | doesn't it? |
| 00:00 | <rniwa> | roc: because it doesn’t prevent component users intruding into its implementaion |
| 00:00 | <roc> | "2) no API is provided which lets code outside the component poke at the shadow DOM. Only internals that the component chooses to expose are exposed." |
| 00:00 | <rniwa> | roc: oh sorry, I misunderstood. |
| 00:01 | <TabAtkins> | rubys: I can't comment on that thread anymore; don't know what's up. |
| 00:01 | <TabAtkins> | rubys: Anyway, linking issues are fixed. Thanks for pointing them out. |
| 00:02 | <TabAtkins> | rubys: The constructor and stringifier not linking is a known issue. Hopefully it's okay to leave them unlinked for now. I'll work on that next week with some other WebIDL fixes I've been putting off. |
| 00:03 | <rniwa> | roc: right, we want to support 2 & 4. |
| 00:03 | <rniwa> | roc: because for things like “like button” we need at least 3 if not 4. |
| 00:03 | <rniwa> | roc: and for regular reusable components, we want 2. |
| 00:04 | <roc> | seems to me that an opt-in attribute that blocks the shadow-piercing CSS combinator, and blocks the use of the shadowRoot getter on Element, would go a long way towards type 2 encapsulation. |
| 00:04 | <rniwa> | roc: indeed. |
| 00:04 | <othermaciej> | roc: that would probably be sufficient for type 2 |
| 00:04 | <othermaciej> | roc: I think for type 4, you need that plus script isolation |
| 00:04 | <TabAtkins> | + a way to name internal pieces that *can* be styled. You really need that for it to be useful. |
| 00:05 | <othermaciej> | roc: part of the right reason I care about type 2 is that I think it’s a good building block for type 4 |
| 00:05 | TabAtkins | is gone for the day and can't follow up; is busy being on vacation. |
| 00:05 | <othermaciej> | TabAtkins: yes, controlled styling access is obviously useful (arguably useful even if you also have unconstrained internals styling access) |
| 00:05 | <rniwa> | othermaciej, roc: yeah, scripts fiddling with prototype probably belongs to 4 |
| 00:05 | <roc> | I need to think about it more, but currently I'm not enthusiastic about providing 4 in Web Components. |
| 00:06 | <rniwa> | roc: because it’s a different way of writing iframe? |
| 00:06 | <roc> | I hope that the Like-button example can be satisfied with a Web Component hosting a cross-origin IFRAME. |
| 00:06 | <roc> | rniwa: because I suspect it would add a ton of complexity to the platform. |
| 00:06 | <rniwa> | roc: the problem is that like button may need to show a pop over to type in comments |
| 00:06 | <rniwa> | roc: i think script isolation already exists in the form of browser extensions |
| 00:07 | <roc> | I don't think so |
| 00:07 | <rniwa> | roc: but I have no doubt it introduces some complexity to the platform. |
| 00:07 | <rniwa> | roc: !? Firefox extensions run in the browser’s main world/isolate? |
| 00:07 | <roc> | e.g. our XBL <video controls> and <marquee> are not trusted. |
| 00:08 | <rniwa> | roc: interesting. but how about browser extensions injected scripts? |
| 00:08 | <smaugB2g> | not trusted, but have non-web view of things |
| 00:08 | <roc> | rniwa: some do, some don't. We do support isolated script worlds. But multiple isolated script worlds living in the same page ... we don't really support that. |
| 00:08 | <rniwa> | roc: oh I see. |
| 00:09 | <rniwa> | roc: okay, so there could be some challege there. |
| 00:09 | <rniwa> | roc: I think combining iframe + dialog element may work |
| 00:09 | <smaugB2g> | yes we do, via wrappers |
| 00:09 | <rniwa> | roc: we just need to sort out use cases and figure out what’s needed for those social media buttons |
| 00:09 | <rniwa> | roc: as well as DISQUS and other cross-origin widgets |
| 00:10 | <rniwa> | social button case is particularly interesting because the button itself is super tiny and yet the comment form needs to be much larger than the button |
| 00:10 | <smaugB2g> | /me suggests asking bholley about Gecko's wrappers |
| 00:11 | <roc> | smaugB2g: we support isolated script worlds manipulating objects from other pages. But you can't, for example, add a DOM node with a different principal to the rest of the page. Without that, I'm not comfortable claiming we have isolated worlds inthe same page. |
| 00:12 | <rniwa> | roc: oh I see. |
| 00:12 | <rniwa> | roc: but I don’t think we need to support something that complicate |
| 00:12 | <rniwa> | roc: we can solve that in DOM API instead |
| 00:12 | <rniwa> | roc: e.g. we can treat shadow root like iframe’s document element |
| 00:12 | <roc> | rniwa: I just don't want to spec and expose an entirely new kind of isolation in the Web. |
| 00:13 | <rniwa> | roc: I used to think like that. |
| 00:13 | <rniwa> | roc: but I think we want the same components model work both same-origin and cross-origin |
| 00:13 | <rniwa> | roc: and we might be able to use iframe’s machinary |
| 00:13 | <rniwa> | roc: instead of inventing its own |
| 00:14 | <rniwa> | roc: ideally, we’ll be just re-using some code we have for iframe already in terms of implementation |
| 00:14 | <roc> | if we can do that by actually using an iframe, that's so much better. |
| 00:14 | <rniwa> | roc: i agree we defintely don’t want to introduce a new security model, etc... |
| 00:14 | <rniwa> | roc: indeed. |
| 00:14 | <rniwa> | roc: at some point, I had an iframe to suguar-coat iframe and provide some nice components API instead |
| 00:14 | <rniwa> | roc: so something like that might work |
| 00:14 | <rniwa> | roc: but this is precisely why we should talk about these stuff :) |
| 00:14 | <rniwa> | roc: and would love to have it spec'ed |
| 00:15 | <rniwa> | roc: perhaps we can have an in-person meeting some time? it’s hard to talk about this without a white board. |
| 00:15 | <roc> | sure |
| 00:15 | <roc> | this is a great time to visit New Zealand |
| 00:16 | <roc> | :-) |
| 00:16 | <rniwa> | roc: oh, you’re in New Zealand? |
| 00:16 | <roc> | yeah |
| 00:16 | <rniwa> | roc: coming to the bay area anytime? |
| 00:16 | <roc> | no doubt, but not for a few months at least |
| 00:16 | <rniwa> | roc: or WebApps F2F in the spring (presumably in paris)? |
| 00:17 | <roc> | probably not |
| 00:17 | <rniwa> | roc: Okay. Please let me know when you do because I don’t think I’m in a hurry to talk about it at the moment. |
| 00:17 | <roc> | this isn't really my bailiwick |
| 00:17 | <rniwa> | roc: so the next few months will probably work for me. |
| 00:17 | <rniwa> | roc: okay. |
| 00:18 | <rniwa> | roc: I think wil chen & sicking are both SF? so it might make sense to meet there. |
| 00:18 | <roc> | yeah |
| 00:19 | <roc> | personally, given the market realities, I think it's a mistake to try to block Web Components on cross-origin stuff. I think we should get the simple type 2 encapsulation added, opt-in, and move forward. |
| 00:19 | <smaugB2g> | you want bholley for any encapsulation discussions |
| 00:20 | <smaugB2g> | for the technical part at least |
| 00:27 | <rniwa> | roc: I agree although I want to make sure we have a rough sketch on how to approach type 4 as well |
| 00:27 | <rniwa> | roc: so that our design for type 2 encapsulation isn’t entirely inconsistent with what we’re going to add later on |
| 00:29 | <rniwa> | roc: may I have your email? |
| 00:29 | <rniwa> | smaugB2g: who is bholley? |
| 00:29 | <rniwa> | roc: mine is nick at apple.com |
| 00:29 | <rniwa> | (as in <my IRC nick> at apple.com) |
| 00:30 | <roc> | robert⊙oo |
| 00:31 | <roc> | rniwa: have you got a thorough list of use-cases? |
| 00:31 | <rniwa> | roc: yeah, we have a list of use cases |
| 00:31 | <smaugB2g> | rniwa: search for bholley+mozilla |
| 00:31 | <roc> | rniwa: can you point me at them? |
| 00:32 | <rniwa> | roc: we have an internal list |
| 00:33 | <rniwa> | roc: it’s kind of messy at the moment with all the notes mangled up |
| 00:33 | <rniwa> | roc: so let me clean that up and send it to you |
| 00:33 | <smaugB2g> | rniwa: naturally you'll want also bz' comments |
| 00:34 | <rniwa> | smaugB2g: most definitely. |
| 00:34 | <rniwa> | smaugB2g: is bz in MV or SF? |
| 00:34 | <smaugB2g> | east coast |
| 00:34 | <rniwa> | oh I see. |
| 00:35 | <rniwa> | perhaps I need to stop by when I go to WebApps F2F in Paris in spring |
| 00:36 | <roc> | rniwa: if you could send it to a mailing list, webapps probably, and let me know, that'd be great |
| 00:37 | <rniwa> | roc: okay, I can do that. |
| 00:37 | <roc> | ta |
| 01:19 | <jwalden> | anyone who works on HTML validators: why exactly would a validator emit a "Text run is not in Unicode Normalization Form C." warning? it seemed like the point of composed/non-composed was to permit exactly that flexibility, so I don't see why warning is reasonable for this, on first pale |
| 01:20 | <MikeSmith> | hi jwalden |
| 01:20 | <MikeSmith> | I work on the validator code |
| 01:20 | <MikeSmith> | I think we have an open bug about this |
| 01:20 | <jwalden> | I will grant that my use case is a rather esoteric one, to be sure :-) |
| 01:21 | <MikeSmith> | what's your use case? |
| 01:21 | <jwalden> | I'm doing a blog post about the JS Intl API, and some of my examples include deliberately non-composed text, to demonstrate collation examples work regardless of composition or not |
| 01:21 | <jwalden> | var decoratedBrowsers = ["A\u0362maya", "CH\u035Brôme", "FirefÓx", "sAfàri", "o\u0323pERA", "I\u0352E"]; |
| 01:21 | <jwalden> | :-) |
| 01:21 | <MikeSmith> | ah |
| 01:21 | <MikeSmith> | yup |
| 01:22 | <MikeSmith> | so yeah that is a bit esoteric, but still |
| 01:22 | <MikeSmith> | anyays, that message is a warning, not an error, right? |
| 01:22 | <jwalden> | MikeSmith: yeah, just a warning |
| 01:23 | <jwalden> | MikeSmith: just seemed a little strange to be anything, because of composition being optional being a feature and all |
| 01:23 | <MikeSmith> | yeah |
| 01:23 | <MikeSmith> | maybe we should just drop it at this point |
| 01:23 | <MikeSmith> | jwalden: we'd need to get some attention from hsivonen |
| 01:23 | <jwalden> | MikeSmith: or at least have it not as part of the default warnings, perhaps |
| 01:24 | <jwalden> | it's not an unreasonable thing to want to know about, potentially |
| 01:24 | <MikeSmith> | jwalden: fwiw for now, if you go to http://validator.w3.org/nu/ and check your doc and then push the "Message filtering" button, you can uncheck that message and you will never see it again (it persists the filtering) |
| 01:25 | <jwalden> | MikeSmith: interesting; that's a next-gen unstable validator or so? |
| 01:26 | <MikeSmith> | Hixie and I have been talking about appending a "Do you think this message is not helpful. If so, please post a comment to _this bug_." (or something) thing to particular error messages, to collect feedback from authors/devs |
| 01:27 | <MikeSmith> | jwalden: that is an alternative UI. hsivonen and I should maybe merge that and the html5.validator.nu UI at some point. |
| 01:28 | <jwalden> | seems reasonable |
| 01:28 | <MikeSmith> | jgraham: but that UI is for the same backend instance that the main (legacy) http://validator.w3.org/ validator uses for checking HTML5 docs |
| 01:29 | <MikeSmith> | it will probably become the UI for http://validator.w3.org/ itself eventually (after retiring the old perl+SGML w3c validator to http://validator.w3.org/old or some such) |
| 01:29 | <jwalden> | mm, Perl, SGML |
| 01:29 | <MikeSmith> | s/jgraham/jwalden |
| 01:29 | <MikeSmith> | heh |
| 01:30 | <MikeSmith> | yup and DTDs too |
| 01:30 | <jwalden> | tasty |
| 01:31 | <MikeSmith> | :) |
| 01:31 | <MikeSmith> | anyway I'll bug hsivonen about the Unicode normalization thing |
| 01:37 | <MikeSmith> | jwalden: we don't yet have any way to opt-in to stricter warnings. I'm pretty sure we wouldn't want to add one, since the trend over the years has been been make the user-facing behavior of validator.nu simpler, with fewer knobs to turn |
| 01:37 | <jwalden> | fair enough |
| 01:38 | <jwalden> | I guess it depends what you want to lint for, really |
| 01:38 | <MikeSmith> | true |
| 01:38 | <MikeSmith> | that's why I added the message-filtering thing |
| 01:38 | <MikeSmith> | that gives the user the choice about what to see and not see |
| 01:39 | <MikeSmith> | and philosophically, this tool really is more like a linter than it is like the old w3c validator. It's just that the linting rules are formally defined in a spec (the HTML spec) |
| 01:40 | <MikeSmith> | it's really mostly meant just to help people catch unintended mistakes -- not to give a pass/fail certification or something |
| 01:41 | <MikeSmith> | and that's also the philosophy that I think Hixie has moslty always taken when adding document (authoring) conformance requirements to the HTML spec |
| 01:56 | <MikeSmith> | jwalden: fyi I just raised a new bug for this http://bugzilla.validator.nu/show_bug.cgi?id=1009 Feel free to comment there if you have more to say |
| 01:56 | <jwalden> | wilco |
| 01:58 | <MikeSmith> | thanks for taking time to ask about it |
| 01:59 | <MikeSmith> | it's always nice to know that people actually working on Web platform stuff actually do use the validator sometimes |
| 02:10 | <MikeSmith> | hsivonen: I know you may not care about this so much but if/when you have a few minutes, it would be great if you could go into https://github.com/settings/emails and add your @iki.fi address and also add the hsivonen@c6dcca6c-c432-0410-a79e-3fbb6554aff1 and hsivonen@e7398766-c432-0410-9565-638d39ca0058 and hsivonen@cc716562-c432-0410-be78-79d2286756cb and hsivonen@5bfc576b-c432-0410-be1c-015b6bc4b1a2 pseudo-addresses (and probably a few others) |
| 02:11 | <MikeSmith> | hsivonen: otherwise, when somebody view https://github.com/validator/validator/graphs/contributors it looks like you've only made 64 commits to the validator sources, which obviously is pretty misleading |
| 02:12 | <MikeSmith> | hsivonen: do to the degree it matters we have a somewhat more accurate record available from the github Web UI it would be nice |
| 02:47 | <tantek> | rniwa - isn't that the point of the Extensible Web Summits? |
| 02:47 | <tantek> | re: in-person meeting on Web Components |
| 02:49 | <rniwa> | tantek: I don’t think Extensible Web Summits are necessarily for Web components |
| 02:49 | <rniwa> | tantek: they talk about a lot of other new Web technologies |
| 02:49 | <tantek> | it would seem the Extensible Web Summits would attract the same people you would want in the room to discuss Web Componenets |
| 02:50 | <rniwa> | tantek: I guess so at least for Web developers |
| 02:51 | <tantek> | rniwa - I see that as a feature - if you're "fixing" web components, you likely need web developer perspective in the room to be sure you're "fixing" them the right (read: practical/relevant for webdevs) way. |
| 02:51 | <tantek> | too many times I feel I've seen browser-dev-only minutia discussions go off into the weeds and end up with weird edge case conclusions that are nothing but super confusing for webdevs. |
| 02:52 | <tantek> | having webdevs in the room is an excellent reality check for that kind of thing - certainly has been in the CSSWG. |
| 02:52 | <caitp> | > every mailing list thread ever |
| 02:52 | <tantek> | (not always effective, but often) |
| 02:52 | <tantek> | caitp - hah, yeah. the "useful" mailing list threads anyway that aren't just support forum q&a. |
| 02:54 | <rniwa> | tantek: oh sure |
| 02:54 | <rniwa> | tantek: but I think I’ve done that part already. |
| 02:55 | <rniwa> | tantek: what I really need is coming up with some strawman proposal I can tell developer |
| 02:55 | <tantek> | rniwa - then you have all the answers? I was under the impression that you needed to collaborate with others to "fix" web components. |
| 02:55 | <tantek> | the point is to have the webdevs in the room when you come up with the strawman proposals in-person at a f2f meeting |
| 02:55 | <rniwa> | tantek: oh, what I need to do is talking with other browser vendors to come up with a solution that everyone can agree to |
| 02:56 | <tantek> | right, *that* is what I'm talking about needing webdevs in the room for |
| 02:56 | <tantek> | otherwise, "everyone can agree to" == aformentioned "go off into the weeds and end up with weird edge case conclusions that are nothing but super confusing for webdevs" |
| 02:56 | <rniwa> | tantek: well, I don’t think we necesarily need web devs with us all the time |
| 02:57 | <rniwa> | tantek: we just need to get feedback early and often |
| 02:57 | <tantek> | nor should we treat "check with webdevs" as a waterfall step |
| 02:57 | <rniwa> | tantek: but most importantly, we need to understand their use cases |
| 02:57 | <tantek> | yes, agreed on that |
| 02:57 | <caitp> | terrible decisions get made when users aren't around and paying attention |
| 02:57 | <tantek> | ^^^ this |
| 02:57 | <rniwa> | caitp: right |
| 02:58 | <rniwa> | but at the same time, a terrible design will be chosen if we had asked users to come up with a design |
| 02:58 | <rniwa> | so we need to balance the two. |
| 02:58 | <rniwa> | although to be fair, web devs are developers so they aren’t like ordinary notive users |
| 02:58 | <rniwa> | end* users |
| 02:58 | <rniwa> | we have to deal with in other feature development |
| 03:00 | <caitp> | technical constraints can't win over user appeal, it's not worth it |
| 03:00 | <rniwa> | caitp: well, if something is a technical constraint, we can’t just remove it. |
| 03:00 | <rniwa> | caitp: that’s why it’s a “constraight" |
| 03:01 | <rniwa> | what we need to do is to understand use cases web developers care about |
| 03:01 | <rniwa> | and address those pain points by coming up with a solution that works around technical constraints we have |
| 03:01 | <rniwa> | that’s our job |
| 03:02 | <caitp> | it's my job too, and I've found that we usually do a pretty awful job at it |
| 03:02 | <caitp> | we build systems where we're actually unable to make things work better |
| 03:03 | <rniwa> | caitp: examples? |
| 03:03 | <caitp> | maybe that's a case of not getting enough user input to begin with, but I think it's mostly that we're pulling things out of our asses to accomodate internal applications without thinking about the bigger picture |
| 03:04 | <caitp> | you end up with a lot of internal "we need this otherwise corner case X, so build all these walls nobody wants" |
| 03:04 | <caitp> | and then the system becomes unmalleable very quickly |
| 03:05 | <caitp> | and at that point it becomes very depressing to maintain it, whether "it" is a spec or implementation |
| 03:05 | <caitp> | so for real, get user stories, make sure user use cases are covered, and make sure the use cases that you want to cover, are covered __well__ |
| 03:07 | <tantek> | and FFS, please *document* the user stories and use cases somewhere openly like on a wiki |
| 03:10 | <caitp> | sorry, examples --- i'm mainly talking about in framework land, but there are a lot of similarities to the web at large in terms of our complete inability to change things lest we break people :( |
| 03:56 | <rniwa> | caitp, tantek: I agree documenting use cases well and continously evaluating desing against them is critical. |
| 04:01 | <MikeSmith> | amen to what tantek said about "having webdevs in the room is an excellent reality check for that kind of thing" |
| 04:01 | <MikeSmith> | and "too many times I feel I've seen browser-dev-only minutia discussions go off into the weeds and end up with weird edge case conclusions that are nothing but super confusing for webdevs" |
| 04:20 | <rniwa> | MikeSmith: indeed. |
| 05:37 | <JonathanNeal> | Is there a spec for devicePixelRatio? |
| 05:37 | <JonathanNeal> | And by devicePixelRatio I mean the one like window.devicePixelRatio |
| 05:38 | <JonathanNeal> | Whoops, maybe it’s http://dev.w3.org/csswg/cssom-view/#dom-window-devicepixelratio |
| 09:13 | <MikeSmith> | hsivonen: did you see my earlier ping about the github stuff? |
| 09:22 | <annevk> | MikeSmith: please keep the NFC warning |
| 09:22 | <annevk> | MikeSmith: I appreciate someone finding an exception to the rule, but in practice that stuff can end up being very confusing if your code is infected by it |
| 09:36 | <MikeSmith> | annevk: OK |
| 09:37 | <MikeSmith> | I guess then we should add a link in the warning message to some place where authors can find more info on how to fix it |
| 09:37 | <MikeSmith> | also maybe we should consider actually adding it as a document conformance requirement to the HTML spec |
| 09:43 | <annevk> | MikeSmith: could point to http://www.unicode.org/reports/tr15/ I guess |
| 09:54 | <MikeSmith> | annevk: I meant something more user-friendly. Because there are python libraries and such that fuck this stuff up (e.g., like lxml or something causes through the spec-splitter or anolis code when generating the formatted HTML spec) and it's then not obvious to an author how to fix that |
| 09:55 | <MikeSmith> | annevk: example: http://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml%2Fsingle-page.html |
| 09:57 | <MikeSmith> | those problems are in the giant character-references table in the spec, and caused by some python thing in the spec-generation toolchain doing the wrong thing |
| 10:09 | <MikeSmith> | for ⟨ and ⟩ |
| 10:22 | <annevk> | Domenic: what's up with the TAG not responding to the security questionnaire proposal? |
| 10:23 | <annevk> | MikeSmith: ah okay, now you mention this... explaining this to someone that has not taken a deep dive seems hard |
| 10:25 | <MikeSmith> | annevk: Yeah |
| 10:25 | <annevk> | MikeSmith: I sometimes forget I've been doing this for a decade |
| 10:26 | <MikeSmith> | You're getting old, man |
| 10:26 | <annevk> | MikeSmith: now Unicode and encoding discussions feel totally natural, but before e.g. 2008 that was not really the case |
| 10:27 | <MikeSmith> | Yeah this stuff is totally arcane to most web devs |
| 10:27 | <annevk> | MikeSmith: I noticed some thinning hair |
| 10:28 | <annevk> | MikeSmith: and finally it almost can be, since encodings are such a thing from the past |
| 10:28 | <MikeSmith> | Yeah, we're moving to a lot better place |
| 10:29 | <annevk> | Although, iso-2022-jp... I feel like I should really turn some of these quick tests into proper test case, but it's just such a hassle to do that correctly |
| 10:29 | <annevk> | E.g. testharness with its absolute URLs requires a local server running... Although I suppose I could develop them online someplace |
| 10:30 | <MikeSmith> | iso-2022-jp is just an ongoing world of hurt |
| 10:30 | <annevk> | I'm getting there: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27256 |
| 10:31 | <MikeSmith> | annevk: maybeyou could do it with wptserve |
| 10:31 | <annevk> | Although the new design is a tad more complicated. Two state tracking variables. One byte tracking variable. And a flag. (Most likely, not done yet.) |
| 10:32 | <annevk> | MikeSmith: sounds like something I should look into |
| 10:32 | <MikeSmith> | Ohthat's a very recent big |
| 10:32 | <MikeSmith> | bug |
| 10:32 | <MikeSmith> | annevk: talk to jgraham |
| 10:33 | <annevk> | MikeSmith: yeah, though it's based on three older bugs |
| 10:34 | <wilhelm_> | wptserve is your friend. |
| 10:56 | <Ms2ger> | annevk, you can just run `python serve.py` in wpt root, with a little bit of one-time setup |
| 11:01 | <annevk> | Ms2ger: sounds pretty awesome |
| 11:11 | <Ms2ger> | annevk, we (and by that I mean jgraham) have tried to make it as painless as possible :) |
| 11:32 | <annevk> | http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0097.html (feel free to reuse for other groups that get this wrong) |
| 12:23 | <annevk> | Ms2ger: thanks for that, this looks great |
| 12:23 | <annevk> | Ms2ger: wish I had known this earlier |
| 12:24 | <Ms2ger> | Np :) |
| 12:24 | annevk | goes to setup a test for iso-2022-jp to make spec writing easier |
| 12:50 | <hsivonen> | MikeSmith: I already have my @iki.fi address set on github |
| 12:50 | <hsivonen> | MikeSmith: where do the pseudo-addresses come from? |
| 12:52 | <MikeSmith> | hsivonen: from the old cvs-svn-hg commit messages |
| 12:52 | <hsivonen> | MikeSmith: how do I find the full list I need to add including "(and probably a few others)"? |
| 12:54 | <MikeSmith> | hsivonen: by doing git log | grep hsivonen | uniq |
| 12:54 | <MikeSmith> | or some such |
| 12:55 | <hsivonen> | MikeSmith: I added the four pseudoaddresses, but they can't receive email, so they are unverified |
| 12:55 | <hsivonen> | is that enough? |
| 12:56 | <annevk> | decode([0x1b, 0x24, 0x40, 0x50, 0x50], "佩", "Multibyte ESC, character") <3 |
| 12:57 | <annevk> | I feel so stupid now for not having set this up earlier |
| 12:58 | <annevk> | Bah, Safari doesn't support TextDecoder yet |
| 12:58 | <MikeSmith> | hsivonen: yeah that's expected; same case as me for my older commits |
| 12:59 | <hsivonen> | MikeSmith: OK, I've added them all |
| 12:59 | <hsivonen> | MikeSmith: thanks |
| 12:59 | <hsivonen> | MikeSmith: how often does github recrunch the numbers? |
| 13:00 | <MikeSmith> | hsivonen: thanks much. I don't think those ever change, so that should cover it forever |
| 13:00 | <MikeSmith> | Oh rhe data |
| 13:01 | <MikeSmith> | yeah I dunno how often. maybe only once a day or so |
| 13:01 | <hsivonen> | MikeSmith: ok. |
| 13:30 | <annevk> | What are you doing? |
| 14:02 | <mukilan> | Hi! In the fetch spec it says "Let HTTPRequest be a copy of request, except that HTTPRequest's body is a tee of request's body. ". What does "tee" mean? |
| 14:06 | <annevk> | mukilan: pain |
| 14:07 | annevk | was hoping for https://streams.spec.whatwg.org/ to define it, but it seems that's missing |
| 14:07 | <mukilan> | annevk: haha |
| 14:07 | <annevk> | mukilan: http://en.wikipedia.org/wiki/Tee_%28command%29 |
| 14:07 | <annevk> | mukilan: there's a comment in the source that stream-related terminology needs to be grounded at some point |
| 14:08 | <annevk> | mukilan: doesn't help you much of course :-( |
| 14:09 | <mukilan> | annevk: could you please put in layman's terms? why split the source stream? where does the other copy go? |
| 14:10 | <annevk> | mukilan: so one copy goes over the wire |
| 14:10 | <annevk> | mukilan: the other one remains part of request, in case we need it again |
| 14:11 | <annevk> | mukilan: (we need it again if we hit a redirect or authentication) |
| 14:12 | <mukilan> | annevk: and the reason we use "tee" rather than just copy is because the body is like a pipe rather than a block of bytes? |
| 14:12 | <annevk> | mukilan: yeah, you can't copy a stream |
| 14:13 | <annevk> | mukilan: whereas everything else from a request can be copied |
| 14:13 | <mukilan> | annevk: ah! now it makes sense. thank you very much :) |
| 14:14 | <annevk> | happy to help, hopefully in due Domenic will have defined tee |
| 14:17 | <annevk> | due course, even |
| 14:21 | <Ms2ger> | Hi mukilan :) |
| 14:22 | <mukilan> | Ms2ger: Hi!! |
| 16:17 | <TabAtkins> | tantek: Interestingly, it's precisely "having webdevs in the room" that led to the current "minimal encapsulation" WC design. (One particular group of advanced authors, but still, authors doing actual Dev with it.) Every time we tried to have stronger encapsulation, it made their job much harder and they howled over it. So our minimum viable product ended up |
| 16:17 | <TabAtkins> | being "encapsulated unless you choose to pierce it in purpose". |
| 16:19 | <annevk> | TabAtkins: e.path is piercing? |
| 16:23 | <TabAtkins> | No, we clean event paths when the events cross boundaries, unless that's somehow changed in the last few months. |
| 16:27 | <annevk> | I think that changed way earlier |
| 16:27 | <smaug____> | google folks, any chance to get http://updates.html5rocks.com/2012/07/Drag-and-drop-a-folder-onto-Chrome-now-available updated to not use webkit prefixes |
| 16:28 | <smaug____> | oh, hmm |
| 16:28 | <smaug____> | it is using google only file system stuff too, I guess |
| 16:33 | <smaug____> | but that is still wrong |
| 16:33 | <smaug____> | the File system API has been abandoned |
| 16:33 | <smaug____> | TabAtkins: you might know who maintains html5rocks.com |
| 16:42 | <annevk> | jgraham: there's no encoding requirement around web-platform tests, right? |
| 16:45 | <gsnedders> | annevk: everything should be utf-8 except when there's good reason, IMO |
| 16:46 | <annevk> | I don't think you have to tell me that... I want to know if something might break |
| 16:46 | <annevk> | I don't really see another way to test e.g. iso-2022-jp's encoder |
| 16:46 | <gsnedders> | Nothing should break. |
| 16:46 | <gsnedders> | I'm not sure how well tested that is, though :) |
| 16:47 | <annevk> | Well it's happening |
| 16:48 | <mukilan> | annevk: In the HTTP fetch spec, section 4.3 step 11, it says "If HTTPRequest's body is non-null, run these substeps:" this does not apply to GET and HEAD methods right ? |
| 16:50 | <annevk> | mukilan: I don't think we allow the combination of those methods and a body, right |
| 16:52 | <mukilan> | annevk: yes, but is it assumed that the check is performed in HTTP spec? i'm asking because of this test /XMLHttpRequest/send-entity-body-get-head-async.htm |
| 16:53 | <annevk> | mukilan: I think XHR has such a check itself |
| 16:54 | <annevk> | mukilan: https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send "If the request method is GET or HEAD, set body to null." |
| 16:54 | <mukilan> | annevk: ha! i missed that. sorry for the trouble :) |
| 17:03 | <TabAtkins> | smaug____: I'll try to remember to bug them on Monday. On vacation now. (I'm bad at vacation.) |
| 17:05 | <smaug____> | vacation, what is that ;) |
| 17:05 | <smaug____> | TabAtkins: thanks |
| 17:08 | <annevk> | Hmm |
| 17:09 | <annevk> | \u005C\u203E\uFF90 -> \%1B(J~%1B$B%_%1B(B |
| 17:09 | <annevk> | Note how the %1B is sensible, but %_ is not, yet both Firefox and Chrome do the exact same thing |
| 17:28 | <annevk> | Note also how https://url.spec.whatwg.org/#query-state endorses this madness by not escaping % |
| 17:28 | <annevk> | Not sure what to think of this... |
| 17:43 | <Ms2ger> | annevk, is a 404 a "network error"? |
| 17:43 | <annevk> | Ms2ger: no |
| 17:43 | <annevk> | Ms2ger: network error has status 0 |
| 17:44 | <Ms2ger> | Hrm |
| 17:45 | <Ms2ger> | I can't figure out what's expected from importScripts("NonExistentFile.js") |
| 17:47 | <annevk> | Ms2ger: are we talking HTTP 404? |
| 17:47 | <Ms2ger> | Yes |
| 17:47 | <annevk> | Ms2ger: Hixie doesn't really define it |
| 17:48 | <Ms2ger> | Lovely |
| 17:48 | <caitp> | Domenic: is chai-as-promised expected to work with promise APIs that don't try to look like ES6 Promises? |
| 17:48 | <annevk> | Ms2ger: but if we assume <script> processing model, it should just parse and execute |
| 17:48 | <caitp> | (someone filed a bug on us, and I'm not seeing how it would possibly work) |
| 17:48 | <Ms2ger> | I've got tests from MS that expect a NetworkError |
| 17:48 | <Hixie> | Ms2ger: does HTTP define that as a successful load or a failed load? |
| 17:49 | <annevk> | Hixie: it's not defined in terms of HTTP though |
| 17:49 | <Hixie> | annevk: Ms2ger's case was http |
| 17:50 | <Hixie> | annevk: the HTML spec just says "If the fetching attempt failed" |
| 17:50 | <Hixie> | so it depends on the protocol's definition of success |
| 17:50 | <annevk> | Yeah, given <script> and <img> and such I'm inclined to say that this should just work |
| 17:50 | <annevk> | That seems very sketchy |
| 17:51 | <annevk> | We should define things in terms of network errors vs non network errors (what <script> and <img> do) or in terms of status codes |
| 17:51 | <Ms2ger> | Also not quite obvious |
| 17:52 | <Hixie> | file a bug saying what you want it to say (ideally matching implementations) |
| 17:52 | <annevk> | Ms2ger: ^ |
| 17:52 | <Ms2ger> | Filing |
| 17:53 | <Ms2ger> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=27276 |
| 17:58 | <annevk> | I guess I'll finish this iso-2022-jp rewrite this weekend |
| 17:58 | <annevk> | And submit some tests for it |
| 18:02 | <smaug____> | https://wiki.whatwg.org/wiki/DragAndDropEntries might use a comment that the File System API is obsolete |
| 18:02 | smaug____ | wonders if he has account for that wiki |
| 20:38 | <wanderview> | jsbell: can you reopen this issue? https://code.google.com/p/chromium/issues/detail?id=429832 |
| 20:38 | <wanderview> | jsbell: based on this spec issue: https://github.com/slightlyoff/ServiceWorker/issues/551 |
| 20:41 | <jsbell> | wanderview: done |
| 20:42 | <wanderview> | jsbell: thanks! sorry for my initial confusion in that bug |
| 20:46 | <jsbell> | wanderview: re: response bodies... yeah, I was pondering that too. they're more subtle since e.g. text() on a response consumes the body even if it's empty. We don't implement optional bodies on Responses yet either via script ctor |
| 20:49 | <wanderview> | jsbell: aren't Request and Response identical in how they handle empty bodies per the spec? the default is "Let stream be an empty byte stream." ... which I guess could be consumed, but it would be nice to avoid that |
| 20:53 | <jsbell> | hrm, right. |
| 20:53 | <wanderview> | jsbell: I think the fetch spec needs to be clarified: https://github.com/slightlyoff/ServiceWorker/issues/550#issuecomment-62209952 |
| 20:53 | <jsbell> | +1 |
| 20:53 | <jsbell> | Also, bleah, we apparently support new Response(null) but not new Response() |
| 20:54 | <annevk> | jsbell: I hope new Response(null) is equal to new Response("null") |
| 20:55 | <jsbell> | annevk: you may be disappointed. :) crbug.com/412027 |
| 20:55 | <annevk> | Hmm, guess I have to review that issue at some point |
| 20:56 | <jsbell> | (agreed it *should* turn into "null", though) |
| 20:58 | <jsbell> | On a tangent, union support in Blink's IDL compiler is almost usable. Yaaaay! *kermit flail* |
| 20:58 | <annevk> | It's really hard to balance getting work done and answering difficult emails |
| 20:59 | <annevk> | On the upside I'm almost done with iso-2022-jp (again), and on the downside there's a bunch of emails that need looking into plus I don't know what else |
| 21:01 | <wanderview> | jsbell: unrelated question... is there IDB 2.0 spec going on? possibly including the KeyRange.inList() thing I proposed a year or so ago? |
| 21:02 | <jsbell> | wanderview: SW has been eating my time. I've got a team member exploring API changes to improve perf, including the inList thing actually |
| 21:02 | <wanderview> | jsbell: cool... I haven't looked at recently (because SW!), but I didn't want to miss the boat again |
| 21:02 | <jsbell> | wanderview: we need batched fetches of some sort too; the overhead of an event per result is too damn high |
| 21:03 | <jsbell> | wanderview; not missing anything. I'll make noise when there's any attempt at concrete progress |
| 21:03 | <wanderview> | jsbell: awesome, thanks! |
| 21:03 | <jsbell> | wanderview: I've been noodling on IDB+Promises again too.... https://gist.github.com/inexorabletash/8c122c84a65de65c35b3 |
| 21:04 | <jsbell> | not sure that holds together or not yet, or that it's an improvement |
| 21:05 | <wanderview> | seems reasonable |
| 21:08 | wanderview | takes a break to watch http://us.battle.net/overwatch/en/ |