| 00:16 | <Domenic> | TabAtkins: what is <css> |
| 00:20 | <TabAtkins> | Domenic: A shorthand for <span class="css">, for when we want to mark up something to look like a keyword but not actually link to anything (because there's no such definition, or too many, or what have you). |
| 00:47 | <wanderview> | annevk: JakeA: if a controlled document is in the bfcache, do we need to fire fetch events for it when the user hits the back button to return to the page? or basically not because network is not normally done there |
| 00:48 | <wanderview> | just a random thought I had this evening (I need a hobby) |
| 00:58 | <danbeam> | TabAtkins: well, I'd expect it to find the first element in the DocumentFragment |
| 00:58 | <danbeam> | TabAtkins: not the fragment itself |
| 01:00 | <TabAtkins> | danbeam: Those aren't document roots. But I defined a :top-level pseudo to do what you're thinking |
| 01:03 | <danbeam> | TabAtkins: the only reason I need :root or :top-level or whatever is that I'm trying to do piercing from a root to find everything with a certain attribute name (across shadow DOMs) |
| 01:03 | <danbeam> | currently that entails .querySelector(':root /deep/ [attr]') |
| 01:04 | <danbeam> | i'd prefer just... /deep/ [attr] |
| 01:04 | <danbeam> | but that throws |
| 01:04 | <danbeam> | is there a better way to accomplish a query through all shadow roots? |
| 01:04 | <danbeam> | that includes top-level elements? |
| 01:11 | <danbeam> | fwiw: [attr], ::shadow [attr] might work |
| 05:28 | <MikeSmith> | annevk: the test deployment of the TLS-enabled www.w3.org site is already helping to catch some bugs in the gecko CSP upgrade-insecure-requests implementation https://bugzilla.mozilla.org/show_bug.cgi?id=1183563#c7 |
| 05:38 | <annevk> | MikeSmith++ |
| 05:39 | <annevk> | MikeSmith: oh my god, our redirect code is sooo bad |
| 05:40 | <annevk> | wanderview: bfcache is not specified to that level of detail (and e.g. Chrome doesn't implement it) |
| 05:40 | <annevk> | danbeam: /deep/ is dead |
| 05:43 | <kochi> | annevk: /deep/ and ::shadow are still allowed for querySelector. |
| 05:43 | <annevk> | ah true |
| 05:43 | <annevk> | well, I'm not sure if everyone agreed to that, but yeah |
| 05:43 | <kochi> | I easily forget which one is static profile and which is dynamic profile |
| 05:46 | <kochi> | Hmm, http://dev.w3.org/csswg/selectors/ , selectors you can write in CSS stylesheets are 'dynamic' profile, while what you can write for querySelector() is 'static' profile. |
| 05:46 | <kochi> | So /deep/ and ::shadow are likely to remain in 'static' profile. |
| 05:46 | <annevk> | They should've just called "dynamic" "live", which is what the rest of the world calls it |
| 05:46 | <annevk> | Perhaps it didn't go to Last Call yet... |
| 05:48 | <kochi> | Maybe I'm the only one, but I feel calling selectors in CSS stylesheet file 'dynamic' quite weird, because such CSS stylesheet file is quite static :) |
| 05:49 | <kochi> | They are just matched against dynamic things (DOM). |
| 05:51 | <MikeSmith> | annevk: yeah I guess that gecko bug exposes an underlying problem that's not specific just to upgrade-insecure-requests |
| 05:51 | <annevk> | kochi: well, they're continuously matched, whereas querySelector() is matched once |
| 05:52 | <annevk> | MikeSmith: yeah, flawed architecture |
| 05:52 | <annevk> | MikeSmith: seems Tanvi is aware of it though so maybe it'll get fixed some day |
| 05:53 | <MikeSmith> | annevk: cool, they should give me a bonus in my bug-reporting royalty check for that |
| 05:55 | <kochi> | annevk: that exlanation is very understandable |
| 06:02 | <TabAtkins> | annevk: Mind switching Compat over to gh-pages? http://www.xanthir.com/b4Zz0 for an easy guide. |
| 06:02 | <JakeA> | wanderview: annevk: if the bfcache impl is effectively keeping the page in memory, I wouldn't expect it to fire a fetch event on back/forward |
| 06:02 | <TabAtkins> | That way we can look at the spec from github too. |
| 06:02 | <annevk> | TabAtkins: it should sync automatically to https://compat.spec.whatwg.org/ |
| 06:02 | <annevk> | automatically* |
| 06:03 | <TabAtkins> | danbeam: You want "[attr], * /deep/ [attr]". |
| 06:03 | <TabAtkins> | annevk: Okay, then please link that from the readme. ^_^ |
| 06:04 | <annevk> | TabAtkins: you can't look at the link at the top of the repo? :p |
| 06:05 | <TabAtkins> | Who looks there? |
| 06:05 | <annevk> | I hope you're happy |
| 06:08 | <TabAtkins> | Thank you :-* |
| 06:24 | <annevk> | TabAtkins: at some point we need to work this through too: https://github.com/w3c/resource-timing/issues/27#issuecomment-122189039 |
| 06:24 | <annevk> | TabAtkins: but I guess HTML first... |
| 06:24 | <annevk> | CSS and SVG have some tricky corner cases when it comes to Fetch, though I think most of the infrastructure is in place |
| 07:13 | <MikeSmith> | TabAtkins: (if you're still awake & around) I've been asked to do a 30-minute presentation about CSS for a webdev/designer audience, on any specific topic I'd like. At a CSS conference where all ~6-8 or so other speakers are actual web devs/designers who unlike me actually do a lot of day-to-day work using CSS. So if I have to do it I'd like to talk something no other speakers are likely to be covering a |
| 07:14 | <MikeSmith> | nd that will be new to the audience. |
| 07:14 | <MikeSmith> | TabAtkins: so, given all that, any suggestions? |
| 07:14 | <MikeSmith> | "The Dark Side of CSS" |
| 07:18 | <MikeSmith> | one thing more near and dear for me is that I think we need to make a new CSS Checker (aka validator) to replace the current Java-based bailing-wire-and-duct-tape one |
| 07:18 | <MikeSmith> | and write it in Javascript, using your parser/tokenizer as a start, to run under node.js |
| 07:19 | <MikeSmith> | so maybe I could use the opportunity to see if I can get anybody else interested in collaborating on that |
| 07:20 | <Ms2ger> | Ew, js |
| 07:21 | <Ms2ger> | There's a good Rust CSS parser ;) |
| 07:29 | <MikeSmith> | oh hey |
| 07:29 | <MikeSmith> | that would be more fun actually |
| 07:31 | <MikeSmith> | Ms2ger: did SimonSapin write that? |
| 07:31 | <Ms2ger> | Yup |
| 07:31 | <MikeSmith> | yeah |
| 07:31 | <MikeSmith> | perusing https://github.com/servo/rust-cssparser/commits/master |
| 07:33 | <MikeSmith> | this would be a great way for me to learn rust and make something actually useful when doing it |
| 07:33 | <SimonSapin> | MikeSmith: feel free to file issues or ping me about this |
| 07:33 | <MikeSmith> | SimonSapin: will do |
| 07:34 | <MikeSmith> | (btw y'all really want to have a TR link in the description of that repo? "Rust implementation of CSS Syntax Level 3 http://www.w3.org/TR/css-syntax-3/"; |
| 07:35 | <SimonSapin> | good point |
| 07:35 | <MikeSmith> | http://drafts.csswg.org/css-syntax/ I guess |
| 07:36 | <MikeSmith> | SimonSapin and TabAtkins btw please consider to stop using http://dev.w3.org/ URLs in CSS drafts |
| 07:36 | <MikeSmith> | and just use http://drafts.csswg.org/ URLs instead |
| 07:37 | <SimonSapin> | I was gonna say I wish we could pick one. Could it be a redirect? |
| 07:37 | <MikeSmith> | SimonSapin: redirect? why not just use http://drafts.csswg.org/css-syntax/ ? |
| 07:38 | <SimonSapin> | MikeSmith: I mean, could http://dev.w3.org/csswg/ redirect to https://drafts.csswg.org/ rather than proxy? |
| 07:38 | <MikeSmith> | all http://dev.w3.org/csswg URLs are rewrites; reverse-proxying or whatever Apache calls it |
| 07:38 | <SimonSapin> | make it HTTP 301’s |
| 07:38 | <MikeSmith> | SimonSapin: it could yeah |
| 07:38 | <MikeSmith> | I should make it do that |
| 07:39 | <SimonSapin> | that will make people use the new URL |
| 07:39 | <MikeSmith> | yeah |
| 07:39 | <SimonSapin> | I tend to navigate to whatever is in my browser history, and copy/paste whatever is in the URL bar |
| 07:39 | <MikeSmith> | yup |
| 07:39 | <MikeSmith> | I will tell plinss I'm going to change it to a 301 |
| 07:40 | <SimonSapin> | make it HTTPS, while you’re at it :) |
| 07:40 | <MikeSmith> | at this point it's just an additional point of possible failure that adds nothing except having w3.org in the URL |
| 07:41 | <MikeSmith> | I think that dev.w3.org server isn't on the list of servers that the W3C systems team is working on moving to https |
| 07:41 | <SimonSapin> | I mean redirect to https:// |
| 07:42 | <MikeSmith> | ah yeah |
| 07:42 | <MikeSmith> | sure |
| 07:43 | <MikeSmith> | SimonSapin: so the servo rust parser fully conforms to the current CSS syntax spec? |
| 07:43 | <SimonSapin> | it might not be completely up to date |
| 07:44 | <Ms2ger> | Variables? |
| 07:44 | <MikeSmith> | Ms2ger: you mean it doesn't support CSS Variables yet? |
| 07:45 | <Ms2ger> | I don't know |
| 07:45 | MikeSmith | tries to remember if/where CSS Variables have been implemented |
| 07:45 | <Ms2ger> | Is there any parser work required for them? |
| 07:46 | <MikeSmith> | good question |
| 07:46 | MikeSmith | looks around for a CSS-parser implementor to ask |
| 07:47 | <MikeSmith> | y'all know of any other rust-based tools anybody's made for providing the server-side backend of Web app? |
| 07:48 | <MikeSmith> | or some kind of existing rust-based http server |
| 07:49 | <SimonSapin> | MikeSmith: rust-cssparser is property agnostic, you need to write parsing code for every property you want to support. It implements the Syntax spec and nothing else. |
| 07:49 | <Ms2ger> | hyper/iron |
| 07:49 | MikeSmith | finds https://github.com/chris-morgan/rust-http |
| 07:49 | <Ms2ger> | rust-http is abandoned |
| 07:49 | <MikeSmith> | ah OK |
| 07:49 | <SimonSapin> | MikeSmith: try https://github.com/iron/iron |
| 07:49 | MikeSmith | looks |
| 07:50 | <MikeSmith> | SimonSapin: ok (about "property agnostic, you need to write parsing code for every property you want to support" |
| 08:07 | <kochi> | Is "CSS Custom Properties" a new name for "CSS Variables"? |
| 08:18 | <MikeSmith> | kochi: /me doesn't know |
| 08:20 | <MikeSmith> | SimonSapin: can rust-cssparser in its current form be feasibly made error-reporting? |
| 08:20 | <SimonSapin> | kochi: yes |
| 08:20 | <kochi> | SimonSapin: thx, I thought it was once abondoned ;) |
| 08:55 | <MikeSmith> | SimonSapin: you saw my question earlier? |
| 08:55 | <MikeSmith> | about error reporting? |
| 09:25 | <annevk> | MikeSmith++ for redirecting dev.w3.org |
| 09:54 | <annevk> | miketaylr: https://twitter.com/compatstandard should perhaps link to the spec? |
| 09:54 | <annevk> | miketaylr: although I guess there isn't much of a spec yet |
| 10:28 | smaug____ | wonders if dglazkov ended up with the current Custom elements design because running ctors sync was just too hard |
| 10:28 | <annevk> | smaug____: part of the problem was that constructors were not a thing |
| 10:29 | <annevk> | smaug____: but yes, I think the "invoke callbacks a little later" stems from the invariants breaking trouble |
| 10:48 | <annevk> | JakeA: you around? |
| 10:48 | <JakeA> | annevk: yep! |
| 10:48 | <annevk> | JakeA: in step 2.2 of https://fetch.spec.whatwg.org/#http-fetch why do we disallow a CORS response to a client request? |
| 10:50 | <JakeA> | annevk: wanderview asked me this recently & I couldn't remember. It may have been a precaution, but I don't see what it prevents as you could just make a manual response with the same content |
| 10:52 | <annevk> | JakeA: I want to change that line to 'if request is a navigation request and response is "opaque"' |
| 10:52 | <annevk> | JakeA: although I think that might be covered already by 'request's mode is not "no-cors" and response's type is "opaque".' I'm not entirely sure, since HTML hasn't been updated yet |
| 10:53 | <annevk> | (I think a navigation request, by definition, is always with mode "same-origin") |
| 10:54 | <JakeA> | agreed. I don't think we'd need to single out 'navigation', even if we did we'd want to ensure other client requests don't get opaque content |
| 10:56 | <annevk> | JakeA: well I know for a fact that workers are always "same-origin" |
| 10:56 | <annevk> | JakeA: and client is navigation + workers |
| 10:57 | <JakeA> | annevk: could it be an "assert" in the spec? (until HTML specifies same-origin for navigations) |
| 10:58 | <annevk> | JakeA: I could make it a note for now, I don't really have formal asserts anywhere |
| 10:59 | <JakeA> | A note would be good enough |
| 11:04 | <annevk> | JakeA: ta |
| 11:10 | <annevk> | JakeA: wanderview: https://github.com/whatwg/fetch/commit/1612905aae06fdb912779b308d71bfc13422833f |
| 11:11 | <JakeA> | annevk: lgtm |
| 11:12 | <annevk> | JakeA: how is cancelation going? |
| 11:13 | <annevk> | JakeA: the only new tricky thing I can think of there is being able to cancel "no-cors" stuff and thereby perhaps being able to extract data somehow |
| 11:14 | <JakeA> | annevk: Haven't looked at it for a couple of weeks (holiday, then this week), but I was approaching a prototype. Going to stab at it on the flight |
| 11:14 | <JakeA> | The plan is to make Promise cancelable, but only by the creator |
| 11:14 | <JakeA> | and have CancelablePromise which is cancelable by outsiders |
| 11:14 | <annevk> | And you're refcounting? |
| 11:15 | <JakeA> | CancelablePromise would have the refcounting |
| 11:15 | <annevk> | What would fetch() use? |
| 11:15 | <JakeA> | the tough bit, which is still todo, is how to handle promises resolved with promises |
| 11:15 | <JakeA> | fetch() would use CancelablePromise |
| 11:15 | <JakeA> | (or you could opt into it) |
| 11:16 | <JakeA> | fetch(url, {cancelable: true}) perhaps - although I'd rather it was default |
| 11:16 | <annevk> | I see, perhaps the solution for "no-cors" is simply that you can't cancel it |
| 11:16 | <annevk> | That would certainly be the least leaky |
| 11:18 | <annevk> | Although even for CORS that'd mean you could only cancel it once you have seen the headers and followed the redirects... |
| 11:18 | <JakeA> | annevk: I was talking to David Benjamin & Ryan Sleevi about it briefly yesterday, they weren't too bothered about it. |
| 11:18 | <annevk> | Hmm okay |
| 11:19 | <JakeA> | It's not the final say, but we couldn't think of something that'd leak with a partial body |
| 11:20 | <annevk> | I'm mostly worried about stuff like `p { content: "Secrets!" } p { content: "no secrets" }` |
| 11:20 | <annevk> | and similar things in script |
| 11:21 | <JakeA> | Script is running in the context of the page, so you're only shooting yourself in the foot |
| 11:22 | <annevk> | Yeah, seems hard to extract data from a script, though we do make exceptions opaque and don't expose comments and such |
| 11:22 | <annevk> | Attackers are pretty clever and manage to exploit all kinds of things nobody thought of |
| 11:23 | <JakeA> | I didn't know about the exception thing. Are you saying if a no-cors script throws, window.onerror doesn't get a full picture of it? |
| 11:23 | <annevk> | correct |
| 11:23 | <JakeA> | TIL |
| 11:23 | <annevk> | <script> does not check MIME types, so you'd be able to load all kinds of resources and extract data from the exception that way |
| 11:24 | <JakeA> | True, certainly for parse errors |
| 11:24 | <annevk> | JakeA: if you have time: https://github.com/whatwg/fetch/issues/67 |
| 11:47 | <SimonSapin> | MikeSmith: at the moment rust-cssparser ignore what the Syntax spec calls "parse errors". But with some work that could be added |
| 11:58 | <MikeSmith> | SimonSapin: ok |
| 12:00 | <MikeSmith> | SimonSapin: I see the code for BadURL etc, and it wouldn't be much work to add some error-reporting for those which could optionally be switched on by consuming apps that want error reporting |
| 12:02 | <SimonSapin> | MikeSmith: Yes, each of Bad*, and after the parser Close* tokens is a parse error, but they don’t represent all parse errors |
| 12:03 | <SimonSapin> | I have to double check if the spec ever emits more than one parse error per token. If not, the tokenizer could yield something like (Token, Option<ParseError>) rather than just Token |
| 12:07 | <MikeSmith> | SimonSapin: OK |
| 12:09 | <MikeSmith> | annevk: square brackets in URL query part or path must be percent-encoded, right? |
| 12:27 | <Ms2ger> | TabAtkins, hey, could you have a look at https://github.com/Reviewable/Reviewable/issues/127 ? |
| 12:45 | <annevk> | MikeSmith: something around that changed recently |
| 12:46 | <annevk> | MikeSmith: I think they must be encoded, but are not by the parser if they aren't |
| 12:47 | <MikeSmith> | annevk: ok |
| 13:47 | <TabAtkins> | MikeSmith: Variables are impl'd in Firefox and about to be turned on in Chrome. An earlier (and prefixed >_<) syntax of them is in WebKit. |
| 13:47 | <annevk> | MikeSmith: spam https://www.w3.org/Bugs/Public/show_bug.cgi?id=27162#c2 |
| 13:50 | <TabAtkins> | Ms2ger or MikeSmith: A Syntax-supporting browser doesn't need to do anything special to support Custom Properties. The actual style system implementation generally does, because it's not used to storing raw tokens or pasting them into other properties at computed-value-time, but at the parsing level they're nothing special. |
| 14:00 | <miketaylr> | annevk: cool, will add the link |
| 14:00 | <miketaylr> | (and fix the commit thing today hopefully) |
| 14:01 | <MikeSmith> | TabAtkins: ok, thanks |
| 14:02 | <miketaylr> | oh wait, it looks like it already tweeted. |
| 14:05 | <Ms2ger> | "Google is not affiliated with the contents of Chromium Code Reviews or its owners." |
| 14:05 | <MikeSmith> | annevk: somebody else already disabled that bug-spammer's account |
| 14:07 | <TabAtkins> | Ms2ger: Correct, we're not, Chromium is an open-source project that happens to be mostly worked on by Googlers. |
| 14:12 | <MikeSmith> | everybody wants to be like, "Hey *I'm* not the one who made this code-review tool with a really bad UI and user experience." |
| 14:12 | <TabAtkins> | It really is the worst. |
| 14:13 | <MikeSmith> | yeah I feel genuinely sorry for people who have to use it every day |
| 14:14 | <MikeSmith> | but then pretty much all code-review tools that browser projects use are pretty bad as far as the UI and UX |
| 14:15 | <MikeSmith> | but that one looks like to was designed by somebody at Oracle, or SAP |
| 14:24 | <Domenic> | You can switch to the new UI, it feels less horrible |
| 14:25 | <TabAtkins> | Domenic: How?!? |
| 14:26 | <Domenic> | TabAtkins: settings, uncheck use legacy UI |
| 14:26 | <annevk> | miketaylr: I didn't touch anything related to Twitter, but when I changed the README it did tweet indeed |
| 14:36 | <Domenic> | yesss it's coming full circle https://twitter.com/feross/status/621960735401193472 |
| 14:37 | <Ms2ger> | So the not "deprecated ui" is just "wait forever until everything's loaded client-side"? |
| 14:38 | <Domenic> | I think there's a reason it's not on by default. |
| 14:39 | <MikeSmith> | choose your poison |
| 14:42 | <MikeSmith> | I think tools that people in product-development orgs develop and foist on one another are subconsciously some form of complex passive-aggressive way to try to punish each other |
| 14:49 | <jgraham> | MikeSmith: It's not like there are all these great commercial review tool products available |
| 14:49 | <jgraham> | The actual state of the nation seems to be "everything sucks in different ways" |
| 14:50 | <MikeSmith> | jgraham: true, I guess there's not a big market out there for it with people who have lots of high expectations for it in terms of usability |
| 14:51 | <TabAtkins> | It's Better Than Command Line® |
| 14:51 | <jgraham> | Well, I think to a certain extent that's untrue |
| 14:53 | <jgraham> | People want a specific kind of usability which isn't necessarily the same as for some random content consuming app |
| 14:53 | <wanderview> | annevk: is this something that will be fixed in the fetch spec or does it need to go in the other specs? "The underlying assumption here is that all client requests use mode "same-origin", which is currently not explicitly stated for navigation requests." |
| 14:53 | <jgraham> | It has to have all the reequired features to make them productive and not get in the way of their prefered workflow |
| 14:53 | <annevk> | wanderview: needs to be fixed in HTML |
| 14:53 | <annevk> | wanderview: specifically its navigate algorithm |
| 14:54 | wanderview | doubts we set event.request.type correctly |
| 14:54 | <annevk> | wanderview: you mean context? |
| 14:55 | <wanderview> | annevk: sorry... RequestMode |
| 14:55 | <wanderview> | I'll have to look at what we do... we seem to set no-cors correctly for cross origin stuff... just wondering if we set same-origin in the right places |
| 14:58 | <smaug____> | MikeSmith: designing a good code review tool seems to be very very hard, because people have their own habits for reviewing code |
| 14:58 | <smaug____> | one tool may not fit to all |
| 15:20 | <wanderview> | annevk: do you really think get-with-bodies is worth it if you're never going to get the right caching semantics anyway? might as well just require post to be used |
| 15:21 | <annevk> | wanderview: it didn't seem to be about caching so much |
| 15:21 | <wanderview> | annevk: one of the whole complaints about post was that it broke caching, though |
| 15:22 | <wanderview> | the other complaint about post is that "its not theoretically pure to the REST concept"... which I don't really rate as a concern |
| 15:24 | <annevk> | wanderview: I think the main point is that HTTP allows it while we don't |
| 15:24 | <annevk> | wanderview: at least for me |
| 15:25 | <annevk> | wanderview: that seems worth sorting out a definitive answer to at some point, but likely not this year |
| 15:25 | <annevk> | (but others are welcome to prioritize differently of course and sort it out) |
| 15:26 | <wanderview> | annevk: does it really allow GET bodies? the spec he linked to says "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." |
| 15:27 | <annevk> | wanderview: none of that says it's disallowed |
| 15:27 | <annevk> | wanderview: would have to be a quite literal statement or grammar production |
| 15:28 | <annevk> | "no defined semantics" means nothing, since some protocol on top of HTTP might give it semantics |
| 15:28 | <wanderview> | ok... I just don't see the advantage of using GET over POST if you're not getting caching semantics anyway |
| 15:29 | <wanderview> | anyway, I have to run to meet someone for lunch... later |
| 19:18 | <danbeam> | TabAtkins: * /deep/ [attr] doesn't work if the first level of elements has [attr] |
| 20:19 | <TabAtkins> | danbeam: That's why I said `[attr], * /deep/ [attr]`. (It's unfortunate we don't have the ability to do "self and combinator".) |