| 03:14 | <hdhoang> | .gwwwwwwwwiiyj .py, |
| 03:15 | <hdhoang> | = |
| 03:15 | <hdhoang> | h |
| 03:17 | <hdhoang> | jyasskin, w89g ku.ekj x bwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwmmmmmmmmmmmmmmmmmmmmmuuuuk6666666666666666666666666666666666bbbbbbbbbbbb |
| 03:17 | <hdhoang> | qbhqoae |
| 03:19 | <hdhoang> | ooooooooooooooooooohhhhhhhhhhhhhhhhh h55cccccccccccuqquuuuuuu |
| 03:19 | <hdhoang> | |
| 03:19 | <hdhoang> | b |
| 03:20 | <hdhoang> | hg77bbbbbb yyyyyyyyyyyyyyjkyyjjjjjjjjjjjjjjjjjjjjjjjq,sorry |
| 06:52 | <shaharmor> | Hey Anne, i see that you are also one of the owners here so i guess there's not point for me asking it here too.. |
| 07:00 | <annevk> | shaharmor: ask what? |
| 07:01 | <annevk> | shaharmor: oh, that ProgressEvent thing? |
| 07:01 | <shaharmor> | Yeah |
| 07:02 | <annevk> | Almost always when the specification says something but all implementations do something else, the specification is wrong |
| 07:02 | <shaharmor> | But in Chrome its not like this |
| 07:02 | <shaharmor> | Its only on Firefox |
| 07:02 | <annevk> | That is interesting |
| 07:03 | <annevk> | shaharmor: that would have been good to mention |
| 07:03 | <annevk> | shaharmor: I support reopening on that basis |
| 07:03 | <shaharmor> | Oh, sorry about that |
| 07:03 | <shaharmor> | Ok i will |
| 07:03 | <shaharmor> | Thanks |
| 07:09 | <shaharmor_> | done |
| 07:12 | <annevk> | shaharmor_: filed https://github.com/whatwg/fetch/issues/284 |
| 07:12 | <annevk> | shaharmor_: and thanks, sorry about causing you some trouble |
| 07:13 | <shaharmor_> | No thank you |
| 07:13 | <shaharmor_> | This will be helpful if it will be fixed :) |
| 07:18 | <shaharmor_> | If this will indeed be fixed, will it only go to Fetch or also to XHR? |
| 07:19 | <annevk> | shaharmor_: mostly Fetch, XHR just reads out the bits that Fetch passes to it at this point |
| 07:20 | <annevk> | shaharmor_: e.g., progress event's total attribute just reflects Fetch's response's body's total bytes's value |
| 07:22 | <shaharmor_> | That means that if it will be fixed in Fetch it will not be reflected in XHR |
| 07:24 | <annevk> | shaharmor_: XHR would automatically pick it up, really |
| 07:25 | <shaharmor_> | Got it, thats great |
| 08:25 | <MikeSmith> | anybody know if Firefox devtools provide a way for me to delete a service worker |
| 08:25 | <MikeSmith> | wanderview: ⬆ |
| 08:30 | <annevk> | MikeSmith: you can use about:serviceworkers to do it |
| 08:33 | <MikeSmith> | annevk: yup, just found that |
| 08:33 | <MikeSmith> | by way of https://wiki.mozilla.org/Service_Workers |
| 08:33 | <MikeSmith> | overholt++ |
| 08:58 | <MikeSmith> | annevk: FYI I’m told about:debugging#workers is the new hotness |
| 08:58 | <MikeSmith> | central place, rather than separate about:serviceworkers etc |
| 09:56 | <annevk> | Is there some programmer's guide to encapsulation? |
| 09:57 | <annevk> | I feel like we keep treading water with Shadow DOM with only smaug---- and rniwa having a set of principles in their head |
| 13:33 | <zcorpan> | https://html.spec.whatwg.org/multipage/browsers.html#nested-browsing-contexts - is there any element that creates a browsing context when it's not in a document? |
| 13:34 | <Ms2ger> | I don't think so |
| 13:39 | <annevk> | zcorpan: shadow trees might |
| 13:39 | <annevk> | zcorpan: unless you meant in a shadow-including document |
| 13:40 | <annevk> | zcorpan: I still need to figure out a sensible model for that though since it seems like nobody else is going to |
| 13:40 | <zcorpan> | annevk: the spec references https://dom.spec.whatwg.org/#in-a-document for "in" currently |
| 13:40 | <annevk> | Hopefully tomorrow I can put some time into shadow trees again, they're kinda fun |
| 13:40 | <annevk> | zcorpan: yeah I know, that will all need to change throughout the entire HTML Standard for shadow trees |
| 13:41 | <annevk> | zcorpan: except of course where we want to keep the existing behavior, good times all around |
| 13:41 | <zcorpan> | :-) |
| 13:44 | <annevk> | zcorpan: so mkwst is touching "update a style block" and I noticed that at no point whatsoever do we pass "style data" to the CSS subsystem |
| 13:45 | <annevk> | zcorpan: is CSS expected to use the element and then extract the style data itself, hopefully using the same algorithm HTML put in place? |
| 13:46 | <zcorpan> | annevk: no, we should pass the style data to CSSOM I think. loading CSS is broken in the spec, i need to fix that |
| 13:47 | <mkwst> | annevk, zcorpan: I didn't see anything that looked like it read style data in CSSOM either, FWIW. |
| 13:47 | <annevk> | Anyway, I think https://github.com/whatwg/html/pull/1051/files looks good. zcorpan, agreed? |
| 13:48 | <annevk> | This is something that's not really mkwst's fault and we need to fix separately |
| 13:48 | <mkwst> | https://drafts.csswg.org/cssom/#create-a-css-style-sheet calls into https://drafts.csswg.org/cssom/#add-a-css-style-sheet, but neither appear to do anything that would gather style data. |
| 13:51 | <zcorpan> | annevk: yep |
| 17:01 | <TabAtkins> | annevk: The paragraph at https://dom.spec.whatwg.org/#concept-shadow-including-tree-order is nonsense English. |
| 17:01 | <TabAtkins> | I understand what it's saying, but it's missing a lot of words. |
| 17:02 | <annevk> | TabAtkins: ah, thanks for verifying |
| 17:03 | <annevk> | TabAtkins: I wasn't too sure how to word that |
| 17:03 | <annevk> | TabAtkins: I'd appreciate suggestions, preferably in an issue, since it's getting rather late |
| 17:03 | <annevk> | TabAtkins: seems I also forgot to uppercase something after a period... |
| 17:04 | <TabAtkins> | kk, will try to remember to PR you later today. |
| 17:04 | <annevk> | TabAtkins: https://dom.spec.whatwg.org/#concept-tree-order is okay with you, right? |
| 17:05 | <TabAtkins> | Not quite. I think it should read: |
| 17:05 | <annevk> | It's deferring a little bit to dictionary/wikipedia land, which I'm not entirely comfortable with, but has worked thus far |
| 17:05 | <TabAtkins> | "In tree order" is preorder, depth-first traversal of a tree. |
| 17:05 | <TabAtkins> | That is, add quotes to clarify what you're defining. Without quotes it feels like an incompletely sentence. |
| 17:06 | <annevk> | That's why it's bold, no? |
| 17:06 | <TabAtkins> | It's still not perfect, but good enough. Doing the same with shadow-including tree order would definitely help. |
| 17:07 | <TabAtkins> | No, you've bolded "tree order", because it's the definition anchor. But for the purposes of constructing the English sentence, "In tree order" is the subject you're defining. |
| 17:07 | <TabAtkins> | Or drop the "In" entirely. |
| 17:08 | <TabAtkins> | That makes sense too. |
| 17:08 | <annevk> | That might be okay |
| 17:08 | <annevk> | Though definitions often have various words leading them in, "When invoked, [x]", "The [x]", etc. |
| 17:10 | <TabAtkins> | Right. But starting a sentence with "In" like that typically means you're providing a context for the following subject. |
| 17:10 | <TabAtkins> | But here "in tree order" *is* the subject. |
| 17:10 | <TabAtkins> | So the mismatch makes it look like bad English. |
| 17:10 | <TabAtkins> | The quotes clarify that "in" is part of the subject, not a grammatical indicator of a clarifying context. |
| 17:11 | <annevk> | I'll take your word for it, but then I think I'd rather omit "in". Adding quotes would make it look very suspect to me |
| 17:11 | <TabAtkins> | Sure. |
| 17:11 | <annevk> | Anyway, thanks for reviewing |
| 17:11 | <annevk> | As a heads up, the slots stuff is not stable |
| 17:11 | <TabAtkins> | As in, the concepts aren't, or the text in DOM isn't? |
| 17:11 | <annevk> | See the end of https://github.com/w3c/webcomponents/issues/288 for the planned changes |
| 17:12 | <annevk> | TabAtkins: some of the slots concepts probably aren't stable |
| 17:12 | <annevk> | TabAtkins: instead of getting slotables, slotables will be assigned |
| 17:13 | <TabAtkins> | Luckily that's exactly the way I'm talking about things. |
| 17:13 | <TabAtkins> | (I don't explicitly ref your algorithms, just the concepts, and allude to slotables being assigned to slots.) |
| 17:13 | <annevk> | Basically when insert/remove run we'll also assign all the slots |
| 17:14 | <annevk> | Assign the slotables, doh |
| 17:14 | <annevk> | Hopefully there's nothing else tomorrow so I can work on that |
| 17:14 | <TabAtkins> | Yup, sounds like those changes won't affect me at all, which is fine. |
| 17:14 | <annevk> | I think in the end I'd like it tightly integrated with CSS, but we can go multiple rounds |
| 17:40 | <laughinghan> | obviously no one here owes me anything, but I'm also going out of my way on this to try to make things better for everyone, my own issue I've already worked-around |
| 17:40 | <laughinghan> | (right now I'm thinking of https://github.com/whatwg/html/issues/639#issuecomment-209189744 ) |
| 17:40 | <annevk> | laughinghan: I would say at least a week, but it depends |
| 17:40 | <laughinghan> | annevk: copy, thanks! |
| 17:42 | <annevk> | laughinghan: could maybe bug smaug____ since he hangs out here |
| 17:43 | <laughinghan> | beep boop smaug____ https://github.com/whatwg/html/issues/639#issuecomment-209189744 |
| 17:43 | <annevk> | laughinghan: also, if you plan on doing more standards work patience helps |
| 17:43 | <laughinghan> | :) |
| 17:44 | <laughinghan> | by the way annevk I've been following your blog on and off for a while, used Opera for a long time, I'm a fan of yorus :) |
| 17:44 | <smaug____> | laughinghan: pong |
| 17:45 | smaug____ | notes that github is totally horrible for any kind of issue tracking, or "needs feedback from person X" tracking |
| 17:46 | <smaug____> | laughinghan: don't know what information you want from me? |
| 17:46 | <laughinghan> | :/ haha maybe I don't know how this works |
| 17:47 | <laughinghan> | I guess feedback? Or you guys don't really care, the browser makers are who I have to convince |
| 17:48 | <smaug____> | I consider myself as a voice from a browser engine vendor ;) |
| 17:48 | <smaug____> | laughinghan: you could ping devs from other vendors too |
| 17:48 | <laughinghan> | okay! so then |
| 17:48 | <laughinghan> | well I commented on all of those tickets |
| 17:48 | <laughinghan> | that were linked |
| 17:48 | <smaug____> | @majido from blink |
| 17:49 | <laughinghan> | so I guess my questions are |
| 17:49 | <laughinghan> | 1. is it out of the question to implement it as a breaking change |
| 17:49 | <smaug____> | laughinghan: well, you want a spec change, and spec changes aren't done in implementation specific bug trackers |
| 17:49 | <laughinghan> | breaking from both spec and how browsers consistently behave |
| 17:49 | <laughinghan> | if I can show at least one of the ways people might rely on it don't happen |
| 17:50 | <laughinghan> | to just try the breaking change in Nightlies to see if people complain |
| 17:51 | <smaug____> | I could say that even tiniest changes to existing history API tend to break pages |
| 17:51 | <smaug____> | and such issues aren't often found during Nightly/Aurora testing |
| 17:51 | <laughinghan> | this is basically just a tweak to the :target selector |
| 17:51 | <smaug____> | but later in beta or even later when the change is actually shipped |
| 17:52 | <laughinghan> | barely affected by the history API |
| 17:52 | <laughinghan> | I see |
| 17:52 | <smaug____> | don't underestimate what breaks the web ;) |
| 17:52 | <laughinghan> | well I guess interaction with the history API. But not really a history API change |
| 17:52 | <smaug____> | sure |
| 17:52 | <laughinghan> | haha very fair |
| 17:53 | <laughinghan> | do you have suggestions of where I could find stylesheets of the top 1000 websites or...something? |
| 17:54 | <smaug____> | philipj might be able to help with that |
| 17:54 | <smaug____> | laughinghan: but ask feedback from @majido too in the bug |
| 17:54 | <laughinghan> | copoy |
| 18:01 | <smaug____> | laughinghan: but how would you deal with :target here? Like, would the implementation need to check if #foo is passed as new url? |
| 18:01 | <smaug____> | but if some other value is passed, then :target isn't changed? |
| 18:01 | <smaug____> | I assume so... |
| 18:02 | <laughinghan> | implementation-wise? |
| 18:02 | <smaug____> | what should passing foo#foo as url do? |
| 18:02 | <laughinghan> | oh like what if we change the path too, not just the fragment? |
| 18:02 | <laughinghan> | hmm, good point |
| 18:06 | <smaug____> | maybe it should work in all the cases, just take the fragment. But what if scrolling is manual, then :target handling may not make so much sense. maybe |
| 18:07 | <laughinghan> | I guess the thing that seems obvious to me is for :target to select for whatever is the current fragment portion of the URL, regardless of what the path is. But suddenly that seems more likely to break real sites |
| 18:07 | <laughinghan> | yeah, exactly for the first sentence you said. I think with manual scrolling it still makes perfect sense |
| 18:08 | <smaug____> | well, if there is manual scrolling, and #target is somewhere outside view port... |
| 18:09 | <smaug____> | might be good to try to find out why the spec ended up not dispatching hashchange event in this case |
| 18:10 | <smaug____> | since if we change :target handling, also hashchange handling should be changed, IMO |
| 18:12 | <laughinghan> | I'm not sure why it matters to manual vs auto scrolling whether #target changes or doesn't styles? |
| 18:12 | <laughinghan> | good point about hashchange though, ugh you're so right |
| 18:14 | <smaug____> | laughinghan: I assume the discussion about hashchange and pushState etc. are in whatwg mailing list archives. |
| 18:15 | <hsivonen> | ouch. I thought the ISO-2022-JP decoder was the worst, but it seems the GB18030 decoder is |
| 18:15 | <laughinghan> | okay, I can try searching for them in a mo, right now I'm checking something about how :target is affected by going Back and Fwd. This might be a really good argument why the breaking change doesn't break anything |
| 18:17 | <smaug____> | The spec has "Since this is neither a navigation of the browsing context nor a history traversal, it does not cause a hashchange event to be fired." mentioned explicitly, so better to know the reasoning for that decision. |
| 18:20 | <laughinghan> | fair point |
| 18:43 | <smaug____> | is w3c irc working normally? |
| 18:44 | <smaug____> | (or do I see a regression in my irc client) |
| 20:16 | <jyasskin> | TabAtkins: Another possible Shepherd problem: https://w3c.github.io/permissions/#permission-store works fine as a definition inside of the spec, but `bikeshed refs --text 'permission store'` doesn't return it from a separate directory. |
| 20:33 | <TabAtkins> | jyasskin: Interesting. Busy right now, but will look into this in the afternoon. |
| 20:33 | <jyasskin> | TabAtkins: Thx |