| 01:11 | <caitp> | nah, you're an ideographic or phonetic language, where you don't need two+ characters for every consonant and vowel, even with utf8 where your average cjk character is 3 bytes, it still doesnt make utf16 massive savings |
| 01:12 | <caitp> | whether it's used or not is besides the point, it's still not heavily used for interchange |
| 01:12 | <caitp> | we use it internally because it's slightly easier to work with, but for interchange it doesn't make a whole lot of sense |
| 01:13 | <caitp> | slightly bigger characters, but fewer characters used |
| 01:15 | <caitp> | i'd attribute the fact that actual documents use it more to the nature of tools than anything else |
| 01:21 | <caitp> | but it's not really a storage size win, it's not a network traffic performance win |
| 01:21 | <caitp> | not that any of it really matters a whole lot |
| 01:50 | <MikeSmith> | caitp: so I've been wondering how things will end up evolving with the big js mvc frameworks once web components actually becomes a cross-browser-implemented part of the platform |
| 01:50 | <MikeSmith> | if it ever does |
| 01:51 | <caitp> | well, we're hoping it does, but these frameworks aren't just about drawing pretty widgets |
| 01:51 | <caitp> | they're about application structure, right |
| 01:51 | <MikeSmith> | sure yeah I realize that |
| 01:52 | <caitp> | so I guess the thing that happens is, ideally, web components and other parts of the framework are easy to test, and it makes it nice and easy for us to help people structure applications, large and small |
| 01:52 | <MikeSmith> | it's not clear to me how much of, e.g., angular is handling the bits that web components does natively |
| 01:52 | <MikeSmith> | ok |
| 01:52 | <caitp> | s/framework/platform/ |
| 01:55 | <caitp> | well, a good answer to that question is "look at the angular 2.0 prototype stuff", a big issue that they're dealing with is fitting the web component model into an application framework, IE fitting them into the dependency injection model, and making them aware of their surrounding DOM nodes |
| 01:55 | <caitp> | it's pretty interesting, and it's not a super easy problem to solve as web components exists currently |
| 01:56 | <MikeSmith> | so that's another question I had |
| 01:56 | <MikeSmith> | which is, what's lacking in web components as it exists currently |
| 01:57 | <MikeSmith> | I mean, what have you seen that angular could use that web components should ideally provide but doesn't yet |
| 01:58 | <MikeSmith> | I was thinking about this today after seeing abarth's message about his <marquee>-in-js implementation |
| 01:58 | <MikeSmith> | in particular https://groups.google.com/a/chromium.org/d/msg/blink-dev/sQndrT36l1A/b9fJoUK3RAUJ |
| 01:59 | <MikeSmith> | "There were a couple things that I couldn't implement correctly because they're magic pieces of the platform we haven't explained yet..." |
| 02:02 | <caitp> | I've been following that thread a bit, but I'm not sure of the magic necessary for marquee --- but I guess what we're dealing with is, custom elements are always instantiated asynchronously (as far as I'm aware), and you can't really do any magic like inject some parameters into their "constructors", if such a thing were to exist. the hack around it is to do the dependency injection logic in the attach callback |
| 02:03 | <caitp> | so in other words the platform doesn't enable that natively, and that's our mechanism for making controls aware of their relationship to the application |
| 02:03 | <caitp> | and the whole asynchronous "upgrading" of elements has other issues WRT testability, which I think have been raised with the test-the-web-forward people |
| 02:06 | <MikeSmith> | as far as the testing issue goes, the subset of the test-the-web-forward people working on writing tests for web components and reviewing those tests are actually the same people from Google who implemented web components in blink |
| 02:07 | <MikeSmith> | so I think we're planning on them to also come up with some solution to any special testing issues it creates |
| 02:07 | <caitp> | i expect so |
| 02:09 | <caitp> | there are some other things that are sort of frustrating, but I only really hear about it during meetings, since I'm working on other areas at the moment. might be some of it available in the meeting notes |
| 02:12 | <caitp> | yeah, looks like a lot of the discussion is recorded |
| 02:16 | <MikeSmith> | caitp: I guess I'll trust that that folks from angular are getting the feedback to dglazkov and hayato and others working on the web-components implementations and specs |
| 02:17 | <caitp> | i've suggested it, but I don't know if it's getting there. have to ask dglazkov if he's heard anything |
| 02:56 | <abarth> | MikeSmith: that's one of the reasons to use web components internally in the engine: you discover what's missing |
| 02:56 | <abarth> | MikeSmith: One thing I didn't mention on the list is I haven't figured out how to do inline event handlers properly |
| 02:57 | <abarth> | <marquee onbounce="...">Foo</marquee> |
| 02:57 | <abarth> | setting up the right JS environment for the ... is a bit subtle |
| 02:57 | <MikeSmith> | oh |
| 02:57 | <abarth> | the engine does that all the time, but it's not clear how to authors can do precisely the same thing |
| 02:57 | <abarth> | I think I've got the script version working right |
| 02:57 | <abarth> | foo.onbounce = ... |
| 02:58 | <abarth> | but the attribute version is subtly different |
| 02:58 | <MikeSmith> | it's cool to see these gaps getting exposed |
| 02:59 | <MikeSmith> | though I guess in the short term you'd just like to have a way to make it work |
| 03:01 | <MikeSmith> | also incidentally I guess this could be added to the list of reasons why inlining event handlers is not a best practice |
| 03:02 | <abarth> | I'm not really injecting much opinion |
| 03:02 | <abarth> | just trying to make thing A work the same way as thing B |
| 06:10 | <annevk> | krit: ah okay, guess I have some time to read up on SVG then :-) |
| 06:12 | <annevk> | gsnedders: utf-16 is the only encoding that's not ASCII-compatible |
| 06:38 | <MikeSmith> | hsivonen: about https://bugzilla.mozilla.org/show_bug.cgi?id=1024447#c12 I don't think the EME spec specifies the "keysystem" content attribute for the source element sufficiently, and it would be better to have it defined properly in the HTML spec -- provided that the attribute is actually suppored in UAs. |
| 06:38 | <MikeSmith> | hsivonen: I mean, for one thing, the relevant text in the EME spec reads in whole just, "The keysystem content attribute is added to HTMLSourceElement." |
| 06:39 | <annevk> | MikeSmith: did you file a bug on that? |
| 06:40 | <annevk> | MikeSmith: you should really file bugs :-) |
| 06:40 | <SamB> | MikeSmith: what, no "TODO: flesh out"? |
| 06:55 | <annevk> | JakeA: Headers is now defined in more detail |
| 07:00 | <JakeA> | annevk: cool. Will review in detail tomorrow. Stupid I/O deadline today. |
| 07:01 | <annevk> | JakeA: I'll mostly be working on SVG this week so that seems fine |
| 07:01 | <annevk> | JakeA: you already in SF? |
| 07:06 | <JakeA> | annevk: nah, heading out on Friday |
| 07:33 | annevk | finds out jungkees has been busy |
| 07:51 | <mathiasbynens> | zcorpan: you called it! (re: DnD/picture) |
| 08:10 | <zcorpan> | mathiasbynens: what do you mean? |
| 08:14 | <jungkees> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/235 |
| 08:15 | <jungkees> | annevk: with this particular thread, what should be fixed more? |
| 08:17 | <annevk> | jungkees: looking at https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#default-method |
| 08:17 | <annevk> | jungkees: step 3.2 needs to be removed |
| 08:18 | <annevk> | jungkees: if response is a network error you need to reject with a TypeError |
| 08:18 | <annevk> | jungkees: and you need to explain how this relates to the overall lifecycle |
| 08:23 | <jungkees> | annevk: alright |
| 08:31 | <annevk> | jungkees: I think the spec still does not do a great job of explaining the overall model and how all the various pieces interact with it |
| 08:32 | <annevk> | jungkees: e.g. what is .default() plugging into that makes "handle a fetch" return the correct thing? |
| 08:32 | <jungkees> | annevk: will add them after sorting out the hooks to Fetch this week |
| 08:34 | <annevk> | jungkees: ah yeah, Nikhil opened an issue for that |
| 08:37 | <jungkees> | annevk: I'll add informal sections to explain the overall hook model and the use of fetch API in SW context xref to Fetch esp. Request/Response/Fetch part |
| 08:38 | <annevk> | jungkees: I'm not talking non-normative |
| 08:38 | <annevk> | jungkees: my concern is with the normative model |
| 08:38 | <annevk> | jungkees: the current setup is not sufficient |
| 08:38 | <mathiasbynens> | zcorpan: i assumed it would be simple & a no-brainer but you realized logic doesn’t necessarily apply in the world of Web Standards |
| 08:38 | <jungkees> | annevk: as I'll remove the Request/Response interfaces from SW |
| 08:39 | <zcorpan> | mathiasbynens: ah. yeah |
| 09:22 | <krit> | annevk: am back… back online |
| 09:24 | <krit> | zcorpan: hi. I uploaded a couple of DOMRect,DOMPoint and DOMQuad tests. If you have time, please review them. https://github.com/w3c/csswg-test/pulls #551-#553 |
| 09:24 | <zcorpan> | krit: ok nice |
| 09:26 | <annevk> | krit: okay, how to best do this? |
| 09:26 | <smaug____> | heycam: would you need some ["foo", "bar"] defaults values for the dictionary/eventinit ? |
| 09:26 | <annevk> | krit: it seems your best bet is assuming the model HTML has outlined |
| 09:26 | <krit> | annevk: we could switch to #svg on w3c irc server… it is recorded as well IIRC |
| 09:27 | <krit> | annevk: we can discuss it here. Just not sure if we produce to much noise |
| 09:27 | <annevk> | krit: here is fine, this channel is known to be noisy |
| 09:27 | <krit> | annevk: ok |
| 09:27 | <krit> | annevk: agree that we should start from the HTML model |
| 09:28 | <krit> | annevk: For standalone SVG’s the model should be identical |
| 09:28 | <krit> | annevk: not much different to inline SVG |
| 09:28 | <annevk> | krit: given that, it's not clear why https://svgwg.org/specs/integration/ is needed, it seems the text should just be in https://svgwg.org/svg2-draft/ |
| 09:28 | <krit> | annevk: Problem comes with fetching further resources… more specifically, SVG as fetch resource |
| 09:29 | <krit> | annevk: I think the SVG WG wanted to produce an anchor for specs using SVG |
| 09:29 | <krit> | annevk: something light weighted that provides all reference modes |
| 09:30 | <krit> | annevk: also, it would apply to all SVG specs, regardless of the version W3C status as REC and so on |
| 09:30 | <annevk> | krit: I think that's the wrong way to think about SVG. The way I see it is that we have some new elements (elements in the SVG namespace) and a special processing mode for XML with an "image/svg+xml" MIME type loaded as image |
| 09:31 | <krit> | annevk: I think for the security model, the WG would be open to put it back to SVG2. |
| 09:31 | <krit> | annevk: that doesn’t seem to be the biggest issue :) |
| 09:32 | <annevk> | krit: so you'd need to define the processing model for these new elements and you need to define a special algorithm for the "image" case that disables scripting and such |
| 09:32 | <krit> | annevk: there might be more modes…. SVG OpenType fonts could have a different set |
| 09:33 | <annevk> | krit: fair, that might be a third |
| 09:33 | <annevk> | krit: although I think fonts and images have roughly similar security characteristics |
| 09:33 | <krit> | annevk: At least for SVG images and SVG external resources (<pattern>, <filter>) we already agreed on the same policy |
| 09:33 | <krit> | annevk: agree, just that SVG as font gets context information to color the font |
| 09:34 | <krit> | annevk: but I am fine with keeping SVG as font as a special case that we handle later. |
| 09:35 | <krit> | annevk: so far there is just one implementer willing to implement SVG OpenType fonts |
| 09:35 | <krit> | annevk: back to SVG as document and SVG as image/svg+xml |
| 09:35 | <annevk> | krit: https://etherpad.mozilla.org/fixing-svg-processing |
| 09:39 | <annevk> | krit: so <svg:image> is like <img> these days? |
| 09:39 | <krit> | annevk: it ought to be |
| 09:39 | <annevk> | krit: if it loads SVG that SVG cannot execute script? |
| 09:39 | <annevk> | krit: sounds good |
| 09:39 | <krit> | annevk: still need to add cross origin attribute |
| 09:39 | <krit> | annevk: yes, same model as <img> |
| 09:39 | <annevk> | krit: that's fine, as long as the security model is equivalent |
| 09:40 | <annevk> | krit: do you know why CSS was seen as a risk? is it the fetching? |
| 09:41 | <krit> | annevk: the WebAppsSec WG wanted to disable styling in general… they feared that some data could be used to trick the user |
| 09:41 | <krit> | annevk: example is coloring the image dependent on viewport size |
| 09:42 | <krit> | annevk: by using media queries and selectors |
| 09:42 | <annevk> | krit: ah okay, so the attack vector would be anything that can read from the environment |
| 09:42 | <krit> | annevk: that was the strongest argument, yes |
| 09:43 | <krit> | annevk: while “read” does not mean that the attacker can read |
| 09:43 | <annevk> | hmm yeah, need better word |
| 09:43 | <krit> | annevk: just a different display behavior dependent on context |
| 09:44 | <annevk> | krit: so https://svgwg.org/svg2-draft/linking.html#processingIRI has a long list of things that can fetch |
| 09:45 | <krit> | annevk: let me check if it is accurate |
| 09:45 | <annevk> | krit: for each of those we need to figure out what happens with the resources retrieved |
| 09:45 | <krit> | annevk: a view elements can’t anymore: mask, filter.. otherwise correct |
| 09:46 | <annevk> | few? |
| 09:46 | <krit> | annevk: yes :) |
| 09:47 | <krit> | annevk: I think with the exception of script, a, (cursor?) the policy can be the same for all elements |
| 09:47 | <annevk> | krit: can they all reference externally too? |
| 09:47 | <krit> | annevk: yes |
| 09:47 | <annevk> | krit: but they're a bit different from the SVG as image case right? |
| 09:47 | <krit> | annevk: I don’t think so... |
| 09:47 | <krit> | annevk: actually they can'y |
| 09:47 | <krit> | t |
| 09:48 | <annevk> | krit: you basically extract some elements to act as a paint server or some such? |
| 09:48 | <krit> | annevk: they must be treated the same |
| 09:48 | <krit> | annevk: <use>, <text> and a couple of other elements reference elements for drawing, other elements are pain sources…. to differ here is not necessary |
| 09:49 | <krit> | s/pain/paint/ |
| 09:49 | <annevk> | well it seems good to make a difference since you'd invoke different algorithms |
| 09:49 | <krit> | annevk: in this case there are 4: |
| 09:50 | <annevk> | one is draw an image given a response object and some height/width criterea |
| 09:50 | <annevk> | the others would be not that :) |
| 09:50 | <krit> | annevk: image, as paint source(gradients patterns), as operator (mask, clipPath, filter) |
| 09:50 | <krit> | annevk: and referenced (external) elements that are drawn in the context of the current document |
| 09:51 | <krit> | annevk: example for the last: <use xlink:href=“other.svg#path/> |
| 09:51 | <krit> | annevk: A <path> element is “copied” from the document other.svg and added in the place of <use> |
| 09:52 | <annevk> | krit: but you don't actually change the DOM, correct? |
| 09:52 | <annevk> | krit: this is some kind of shadow DOM thingy? |
| 09:52 | <krit> | annevk: no, it is implemented with shadow DOM |
| 09:52 | <krit> | annevk: right |
| 09:52 | <annevk> | same-origin restriction? |
| 09:52 | <krit> | annevk: none defined yet |
| 09:53 | <krit> | annevk: part of the new security model :) |
| 09:53 | <annevk> | do scripts execute? |
| 09:53 | <annevk> | I see |
| 09:53 | <annevk> | please start calling it processing model ;) |
| 09:53 | <annevk> | security is just one aspect of the many things that are not defined here :) |
| 09:53 | <krit> | annevk: that was brought up recently : <use xlink:href=“other.svg#g”/> that references <g><script></script></g> |
| 09:53 | <krit> | annevk: and it is not executed |
| 09:54 | <annevk> | okay, so potentially less volatile than HTML imports |
| 09:54 | <krit> | annevk: if implemented correctly :) |
| 09:56 | <annevk> | krit: does <use> have an object model? |
| 09:56 | <krit> | annevk: it was removed |
| 09:56 | <annevk> | krit: what about hit testing on <use> does that return the <use> element? |
| 09:57 | <krit> | annevk: so hit testing applies in general to <use>… do you mean event handlers? |
| 09:57 | <annevk> | krit: what would elementFromPoint() return? |
| 09:57 | <krit> | annevk: something like onmouseover may apply… need to check |
| 09:57 | <annevk> | krit: but yes, event handlers, :hover, etc. |
| 09:58 | <annevk> | krit: note that hit testing can return different things depending on who is asking |
| 09:58 | <krit> | annevk: elementFromPoint would not go into the <use> tree |
| 09:58 | <annevk> | krit: hit testing not being defined is of course problematic for that... |
| 09:59 | <krit> | annevk: there are no restrictions to hit testing for <use>… think that is defined |
| 10:00 | <krit> | annevk: “The event handling for the non-exposed tree works as if the referenced element had been textually included as a deeply cloned child of the ‘use’ element, and events are dispatched according to the shadow tree event dispatching algorithm [SHADOWDOM]." |
| 10:01 | <annevk> | krit: so basically this is defined in terms of shadow DOM, except shadow DOM does not actually provide encapsulation at the moment |
| 10:02 | <annevk> | krit: only Chrome has such a thing |
| 10:02 | <krit> | annevk: yes |
| 10:03 | <annevk> | mkay, I guess you guys can clean that up at some point, hit testing should prolly follow from that |
| 10:03 | <krit> | annevk: is there an example in HTML? |
| 10:03 | <krit> | annevk: how HTML defines hit testing? |
| 10:03 | <annevk> | krit: nobody defines hit testing |
| 10:04 | <annevk> | krit: it's a big problem |
| 10:04 | <krit> | annevk: that sounds like a meme |
| 10:04 | <annevk> | might be something about anne and being a broken record on hit testing |
| 10:08 | <annevk> | krit: so is <use> non-isolated or isolated? |
| 10:09 | <krit> | annevk: not isolated for styling, isolated for DOM |
| 10:09 | <annevk> | hmm |
| 10:09 | <krit> | annevk: hooking up <use> on shadow DOM is new… there might potentially be changes |
| 10:10 | <annevk> | krit: so <use> fetches a resources, parses it as XML, then locates node by ID and deepclones it into the shadow tree? |
| 10:10 | <annevk> | krit: and when it parsers it does so with scripting disabled |
| 10:11 | <krit> | annevk: so, what happens in implementations is that we fetch the document and run it though the parser… then we look for the id and deep clone it (some implementations just create the render tree) |
| 10:12 | <krit> | if you just create the render tree, you exclude Scripting already |
| 10:12 | <annevk> | well the render tree is created from the shadow tree |
| 10:13 | <annevk> | and the parser is what executes script |
| 10:15 | <krit> | annevk: animations can not be disables=d by author ATM. This is one problem with Canvas’s drawImage() “first frame” doesn’t really apply for SVG… in this case the UA indeed disables the animation |
| 10:17 | <annevk> | okay |
| 10:18 | <annevk> | krit: "(result of rendering to a bitmap or something else?)" is about how we'd define it; how it's implemented is immaterial |
| 10:18 | <krit> | annevk: ok, defining it by bitmap is the easiest |
| 10:19 | <krit> | annevk: (resolution depends on the device of course) |
| 10:23 | <krit> | annevk: xref == xlink:href ? |
| 10:23 | <annevk> | krit: cross-reference |
| 10:23 | <krit> | annevk: makes sense :P |
| 10:25 | <krit> | annevk: beside elementFromPoint() we have CSSOM calls like getClientsRect() and so on… which of course don’t look into the shadow tree |
| 10:25 | <krit> | annevk: not sure if there is a common expression for these kind of interfaces |
| 10:25 | <annevk> | krit: layout APIs? |
| 10:26 | <krit> | annevk: maybe |
| 10:26 | <annevk> | krit: render tree APIs I suppose, as they operate on that |
| 10:26 | <krit> | annevk: basically all APIs in http://dev.w3.org/csswg/cssom-view/ :P |
| 10:28 | <krit> | annevk: CSS WG refuses to deifne render tree. so layout actually sounds good |
| 10:28 | <annevk> | krit: is there anything in particular with getClientsRect()? |
| 10:29 | <annevk> | krit: it seems if you use it on <use> it would reveal the render size of the shadow tree? |
| 10:30 | <krit> | annevk: <use> it would |
| 10:31 | <krit> | annevk: *it would |
| 10:31 | <annevk> | krit: seems like <use> should be same-origin / CORS |
| 10:31 | <krit> | annevk: yes… it is in Firefox |
| 10:32 | <krit> | annevk: In FF the same for paint sources and operators |
| 10:33 | <krit> | annevk: And it shouldn’t be a problem to add this requirement in the spec. External references are just implemented in Firefox so far. |
| 10:33 | <krit> | annevk: and Opera <= 12 |
| 10:33 | <annevk> | krit: I remember there was a problem with CSS and SVG together? |
| 10:34 | <annevk> | krit: where for CSS we did not want to have that restriction and so we ended up making the distinction through fragment identifiers? |
| 10:34 | <krit> | annevk: you probably mean the mask-image: url() problem, where url() can reference an image or an SVG resource? |
| 10:34 | <krit> | annevk: well, we went away from present fragment switching and required the same policies for both |
| 10:35 | <krit> | annevk: this indeed seems critical with same origin requirement for SVG resources :/ |
| 10:36 | <annevk> | krit: okay, so if that's always same-origin that's great |
| 10:36 | <krit> | annevk: hm… need to think about it |
| 10:36 | <krit> | annevk: well, for use definitely |
| 10:36 | <krit> | annevk: for paint sources/operators maybe not so much because if the url() CSS function issue |
| 10:36 | <krit> | s/if/of/ |
| 10:37 | <annevk> | I think I remember what I proposed to roc |
| 10:37 | <krit> | annevk: Ah! FF added the restriction because the resource was allowed to fetch more data |
| 10:37 | <krit> | annevk: IIRC |
| 10:38 | <krit> | annevk: and with the new model, operators and paint sources are not allowed to fetch anything no matter what |
| 10:38 | <annevk> | That we would make the cross-origin fetch, but if the resulting document was SVG, we would treat it as an error |
| 10:38 | <annevk> | krit: I thought you could still do some amount of discovery based on what gets masked on the page |
| 10:39 | <krit> | annevk: for clipPath yes, it affects hit testing |
| 10:39 | <krit> | annevk: that wasn’t seen as issue by the CSS WG when I brought it up |
| 10:39 | <annevk> | krit: yeah, so I'm thinking that blocking tainted SVG is probably the way to go (while allowing tainted images) |
| 10:40 | <annevk> | I'm not sure the CSS WG is the best place for security issues |
| 10:40 | <annevk> | It's not like CSS' processing model is very clear |
| 10:40 | <krit> | annevk: well, atm implementations fetch resources with certain policies… there is no checking for further policies after fetching |
| 10:41 | <annevk> | I'm not sure what that means |
| 10:41 | <krit> | annevk: you fetch a resource with same origin requirement, or you fetch it without any requirements… (to make it simple just the two cases) |
| 10:42 | <annevk> | sure |
| 10:42 | <krit> | annevk: once the implementation has the resource, it is assumed that everything is ok IIRC |
| 10:42 | <annevk> | but you can make a check once you get something back to see whether you want it |
| 10:42 | <annevk> | similarly to doing a content-type check as we sometimes do |
| 10:42 | <krit> | annevk: so if we fetch SVG without policies… then we do not check it a second time |
| 10:42 | <annevk> | yes, but we could, to make this work |
| 10:42 | <krit> | annevk: but do we do that today? |
| 10:42 | <annevk> | without the ridiculous check the url's fragment nonsense |
| 10:43 | <krit> | annevk: I mean somewhere? |
| 10:43 | <annevk> | well, SVG introduced this image or SVG problem |
| 10:43 | <krit> | annevk: true |
| 10:44 | <annevk> | and the way it was initially solved was by trying to distinguish them upfront by checking if the url had a fragment |
| 10:44 | <annevk> | which is broken |
| 10:44 | <krit> | annevk: yes |
| 10:44 | <annevk> | so either we create separate properties for the two cases or we distinguish after the fetch |
| 10:44 | <annevk> | and if you distinguish after the fetch between image and SVG, you can still discard one or the other if there's a problem |
| 10:45 | <annevk> | such as the response being tainted and being SVG |
| 10:45 | <krit> | annevk: to step back… masking does affect the visual output but does not contribute to hit testing |
| 10:45 | <krit> | annevk: it is just clip-path which does it |
| 10:45 | <krit> | annevk: so maybe we can limit it to clip-path only? |
| 10:45 | <krit> | annevk: clip-path property does not fetch images |
| 10:46 | <annevk> | my memory of the public-fx thread was that this was bigger |
| 10:46 | <krit> | annevk: bigger? |
| 10:48 | <annevk> | krit: http://lists.w3.org/Archives/Public/public-fx/2013AprJun/0046.html |
| 10:48 | <krit> | annevk: there is just one thing that could be exposed: rendering time… it take more time to render a mask than no mask |
| 10:48 | <krit> | annevk: so it could have affect on rAF |
| 10:48 | <annevk> | was about mask |
| 10:49 | <annevk> | http://lists.w3.org/Archives/Public/public-fx/2013AprJun/0021.html |
| 10:50 | <krit> | annevk: the first link still assumes that the document with the <mask> element can reference images from the same origin… which we don’t allow anymroe |
| 10:51 | <krit> | annevk: it must be in the document itself… no fetching |
| 10:52 | <annevk> | krit: so if you put a data URL there it'll always fail? |
| 10:53 | <krit> | annevk: dataURLs do not fetch by default, do they? they could have elements within that would try to fetch… which always fails. |
| 10:55 | <annevk> | krit: okay, I guess I see what you meant with respect to <mask>, you guys changed the model to be as "SVG as image" since that email exchange and now you think you can allow tainted responses |
| 10:55 | <annevk> | krit: does Firefox no longer do special casing for fragments then? |
| 10:55 | <krit> | annevk: hehe, right |
| 10:55 | <krit> | annevk: I don’t think it ever did? |
| 10:55 | <krit> | annevk: mask still just allows SVG resource in Gecko |
| 10:56 | <annevk> | okay, so it might be same-origin restricted at the moment? |
| 10:56 | <krit> | annevk: I think it is ATM |
| 10:58 | <annevk> | krit: okay, I want to take a break for a bit; I guess when we come back we should enumerate all the places that fetch |
| 10:58 | <krit> | annevk: ok, will be here |
| 10:59 | <annevk> | krit: prolly hour and a bit |
| 11:00 | <krit> | annevk: ok, thanks for looking into this! |
| 12:25 | <annevk> | krit: https://svgwg.org/ Streaming Draft link is broken |
| 12:26 | <krit> | annevk: doesn’t work for me too |
| 12:28 | <krit> | annevk: very strange, it is in the repository |
| 12:30 | <krit> | annevk: reported it to heycam, all I can do at the moment |
| 12:30 | <annevk> | krit: k |
| 12:30 | <annevk> | krit: https://etherpad.mozilla.org/fixing-svg-processing |
| 12:30 | <annevk> | krit: trying to complete the list of elements that fetch |
| 12:31 | <annevk> | krit: then I guess we can collect them into buckets somehow |
| 12:40 | <annevk> | krit: <style> does external references right? |
| 12:40 | <krit> | annevk: yes |
| 12:41 | <krit> | oh |
| 12:41 | <krit> | mistaken |
| 12:41 | <annevk> | krit: so can <cursor> be defined in terms of 'cursor'? |
| 12:41 | <annevk> | krit: as in, it might be good to remove the elements that can be described in terms of CSS |
| 12:42 | <krit> | annevk: old content might use it, but let me bring it up to SVG WG conf |
| 12:42 | <annevk> | krit: I mean spec-wise |
| 12:42 | <annevk> | krit: e.g. HTML defines <font> in terms of CSS |
| 12:43 | <krit> | annevk: needed to check, but yes |
| 12:43 | <krit> | annevk: cursor property might even be more powerful |
| 12:45 | <annevk> | krit: is the same true for other elements? |
| 12:45 | <krit> | annevk: looks like SVG has <cursor> to get the cursor position |
| 12:45 | <annevk> | o_O |
| 12:45 | <krit> | annevk: we have <font> in SVG which is the treated the same as in HTML |
| 12:46 | <annevk> | krit: <cursor> does not seem to be about getting the cursor position |
| 12:46 | <krit> | annevk: the x and y attributes are described about that + cursor image of course |
| 12:46 | <annevk> | yes |
| 12:46 | <krit> | http://www.w3.org/TR/SVG/interact.html#CursorElement |
| 12:47 | <annevk> | no, x and y are about where the image is to be placed relative to the mouse pointer |
| 12:47 | <annevk> | krit: see http://dev.w3.org/csswg/css-ui/#cursor |
| 12:49 | <krit> | annevk: for the property yes, but the SVG text implies otherwise |
| 12:49 | <annevk> | krit: that seems like one of the SVG's many bugs |
| 12:50 | <hsivonen> | MikeSmith: moving the keysystem attribute from EME to the HTML spec is a whole can of worms politically |
| 12:50 | <annevk> | because it doesn't actually make sense |
| 12:51 | <krit> | annevk: not even sure if we implement it in WebKit/Blink |
| 12:51 | <hsivonen> | MikeSmith: I'd rather have it better defined in EME itself as a first step |
| 12:51 | <annevk> | krit: can <feImage> be expressed in CSS? |
| 12:53 | <krit> | annevk: it does the same as <image> with the exception that it can reference an element |
| 12:54 | <krit> | annevk: which is than drawn in an offscreen buffer |
| 12:54 | <krit> | annevk: (maybe <image> can do the same? unsure) |
| 12:54 | <annevk> | is that observable somehow? |
| 12:55 | <krit> | annevk: observable how? |
| 12:56 | <krit> | annevk: I mean what do you want to observe? |
| 12:57 | <annevk> | nm |
| 12:58 | <annevk> | krit: do you know for all of these what the default fetching mode is? |
| 12:58 | <annevk> | krit: e.g. which are no CORS, which are CORS, and which are same-origin? |
| 13:00 | <krit> | annevk: again, definition is as <image> in general… added the cross origin attribute even http://dev.w3.org/fxtf/filters/#element-attrdef-crossorigin |
| 13:00 | <krit> | annevk: so it is no CORS by default, but can CORS can be set |
| 13:00 | <annevk> | what's the benefit of CORS in that case? |
| 13:02 | <krit> | annevk: http://dev.w3.org/fxtf/filters/#security |
| 13:02 | <annevk> | :( |
| 13:03 | <krit> | annevk: hehe, I guess I will never see a smile :) |
| 13:03 | <annevk> | heh |
| 13:04 | <annevk> | Okay, so feImage is tainted if the response's type is opaque |
| 13:05 | <annevk> | krit: I guess what I'm really interested in is whether the elements and properties we listed are same-origin or no-CORS by default |
| 13:05 | <MikeSmith> | hsivonen: ok I guess I'll do as annevk suggested and raise a bug against the EME spec |
| 13:06 | <annevk> | MikeSmith: please copy Chris Pearce and maybe me |
| 13:06 | <MikeSmith> | k |
| 13:06 | <krit> | annevk: all no-CORS since CORS didn’t existed when SVG 1.1 was speced |
| 13:07 | <krit> | annevk: (specification wise of course) |
| 13:07 | <annevk> | krit: nothing was same-origin restricted? |
| 13:07 | <krit> | annevk: and CSS doesn’t handle CORS yet either |
| 13:07 | <krit> | annevk: no |
| 13:07 | <krit> | annevk: nothing |
| 13:07 | <annevk> | can we talk implementation-wise now? |
| 13:08 | <krit> | annevk: CSS is still no-CORS |
| 13:08 | <krit> | annevk: same as in HTML |
| 13:08 | <annevk> | even clip-path? |
| 13:08 | <krit> | annevk: clip-path, mask, fill, stroke are same origin in Firefox |
| 13:09 | <krit> | annevk: they don’t fetch in WebKit and Blink yet |
| 13:09 | <annevk> | mask is mask-image? |
| 13:09 | <krit> | annevk: with the exception of -webkit-mask and -webkit-filter and -webkit-clip-path |
| 13:09 | <krit> | annevk: yes |
| 13:09 | <annevk> | ah, and -webkit- properties load images, not SVG, and do so no-CORS? |
| 13:09 | <krit> | annevk: remove -webkit-mask from the list |
| 13:10 | <krit> | annevk: -webkit-filter and -webkit-clip-path do load external resources as well. IIRC no self origin at the moment |
| 13:11 | <krit> | annevk: talking for general documents of course… not for SVG images |
| 13:11 | <annevk> | yeah |
| 13:11 | <krit> | annevk: the SVG elements do not fetch in Blink at all |
| 13:12 | <annevk> | krit: no SVG element? |
| 13:12 | <krit> | annevk: in WebKit we have the <use> element that did fetch. Think it is broken again |
| 13:12 | <krit> | annevk: In Firefox elements fetch same origin |
| 13:12 | <annevk> | krit: as in <svg><image xlink:href=...></svg> is broken? |
| 13:12 | <krit> | annevk: Opera <=12 fetches for CSS and elements without any restrictions |
| 13:13 | <krit> | annevk: I am unspecific |
| 13:13 | <krit> | annevk: operators and paint source elements don’t fetch |
| 13:13 | <krit> | in Blink and WebKit |
| 13:13 | <annevk> | in no context? |
| 13:13 | <krit> | annevk: right |
| 13:13 | <annevk> | but they support inline references? |
| 13:14 | <krit> | annevk: yes |
| 13:14 | <annevk> | okay, so lets figure out the algorithm to get to an SVG element |
| 13:14 | <annevk> | how is it established that you have an inline reference? |
| 13:14 | <krit> | annevk: I am not aware of restrictions for <script>, <?…stylesheet…?>, <image>, <feImage> specification wise |
| 13:15 | <krit> | annevk: we parse URL but just use the fragment identifier and search in the same document |
| 13:16 | <krit> | annevk: This caused a bug where the URL is a different document but we still search for the fragment ID in the same document |
| 13:16 | <krit> | annevk: might still be broken |
| 13:17 | <annevk> | given a document /doc and a base URL /a/ and a fragment in /doc that reads #text where should we look? |
| 13:17 | <annevk> | what if the fragment/reference reads /a/#text |
| 13:18 | <krit> | annevk: exclusively speaking for WebKit/Blink: we do not resolve the URL… we just take the string specified by the user and use the fragment identifier of it…. no resolving of URL yet |
| 13:18 | <annevk> | krit: what if the string does not start with a #? |
| 13:19 | <krit> | annevk: well, the parsing process looks for the fragment identifier exclusively… example: “other.svg#test”… we do not resolve the base address of other.svg |
| 13:20 | <annevk> | krit: what is this "parsing process"? |
| 13:20 | <annevk> | krit: you just try to find a #? |
| 13:20 | <krit> | annevk: let me check, but that is what I remember |
| 13:22 | <krit> | annevk: the parsing algorithm is 350 loc |
| 13:23 | <krit> | annevk: I can say that we do not “simply” search for #… the algorithm does a lot more… just say we extract the fragment identifier from the string |
| 13:23 | <krit> | let me find the link |
| 13:24 | <krit> | annevk: http://trac.webkit.org/browser/trunk/Source/WebCore/platform/URL.cpp#L1088 |
| 13:27 | <annevk> | krit: oh okay, so it seems to properly parse a URL, but then ignore all the good bits |
| 13:28 | <annevk> | seems to warrant a :( |
| 13:29 | <krit> | annevk: actually, it was a security pro caution and is limited to SVG |
| 13:30 | <annevk> | if you ignore the path and such that's not a security procaution, that's a bug |
| 13:31 | <krit> | annevk: this way we didn’t need to look into when we allow external resources. In the first days of SVG integration in WebKit this seemed wise. And then we never actually came to implement it correctly and there wasn’t a huge demand either |
| 13:31 | <annevk> | sure, I'm not advocating that we support Fetch |
| 13:31 | <krit> | annevk: it is a bug, true |
| 13:31 | <annevk> | but not properly parsing the URL and making sure it actually is relative to the document before proceeding is a huge forward compat issue |
| 13:31 | <krit> | annevk: I know, but implementations are ramping up and now it gets important |
| 13:32 | <krit> | annevk: agree, that was a bug we didn’t thought about at the time |
| 13:32 | <annevk> | o_O |
| 13:32 | <annevk> | okay, lets move on, I started drafting an algorithm |
| 13:37 | <gsnedders> | Hixie: ping; can you give me both your code, how to build it, and how to run it, then I'll try? |
| 13:39 | <annevk> | krit: data URLs and blob URLs will work due to the fetching algorithm |
| 13:39 | <annevk> | krit: though for data URLs we'd need explicit opt in |
| 13:39 | <krit> | annevk: which section is that in URL spec? |
| 13:39 | <annevk> | krit: it's in the fetch spec |
| 13:40 | <krit> | annevk: looking |
| 13:43 | <krit> | annevk: still, your algorithm compares document URL with parsed URL… if they are equal and the URL has a frag id, then we search for an element in the same document OTHERWISE: 1)return network error if fetch is disabled… |
| 13:43 | <krit> | annevk: or do we not quit at 1)? |
| 13:44 | <annevk> | krit: ah |
| 13:45 | <annevk> | krit: no, blob and data URLs would just proceed to step 3 |
| 13:45 | <krit> | annevk: right. Just mean that 3.1) says return on fetching disabled |
| 13:46 | <krit> | annevk: so dataURL and blob would return with negative result at 3.1 |
| 13:46 | <annevk> | yes |
| 13:46 | <annevk> | if fetching is disabled |
| 13:46 | <krit> | annevk: for SVG image it is… and we should still allow blob and dataURL |
| 13:46 | <annevk> | how can an "SVG image" contain a blob URL? |
| 13:47 | <krit> | annevk: dholbert had a weird example |
| 13:47 | <krit> | annevk: I’ll ask him about the example again |
| 13:48 | <krit> | annevk: Asked him. He is in PSD timezone and should be awake in a couple of hours |
| 13:49 | <krit> | s/awake/online/ |
| 13:49 | <annevk> | krit: okay, we could maybe make it a flag on Fetch |
| 13:49 | <annevk> | krit: "no networking flag" or some such |
| 13:50 | <krit> | annevk: ok, what about dataURLs and base64? |
| 13:50 | <annevk> | krit: I guess it might be okay to allow those yes |
| 13:50 | <krit> | annevk: it is important! :) People embed there PNGs in SVG files today |
| 13:51 | <krit> | annevk: External fonts seems to be the biggest problem for SVG Images… not sure how Firefox handles that today… not even sure how webkit does |
| 13:52 | <krit> | annevk: think WebKit doesn’t fetch web fonts today |
| 13:52 | <krit> | annevk: for SVG images |
| 13:52 | <annevk> | krit: "SVG images" is ambiguous |
| 13:53 | <krit> | annevk: indeed. In SVG WG we refer to image/svg+xml usually |
| 13:53 | <annevk> | krit: what is important for now is to define a model that's somewhat realistic, once we have that we can address various features |
| 13:55 | <krit> | annevk: yes |
| 13:56 | <annevk> | krit: so no scripting seems reasonably solid |
| 13:56 | <krit> | annevk: you refer to blobs? |
| 13:56 | <annevk> | krit: no, lets leave blob/data URLs alone for now, not important |
| 13:57 | <annevk> | krit: not doing scripting for an external resource is straightforward |
| 13:57 | <annevk> | krit: you simply don't invoke the parser with scripting enabled |
| 13:57 | <annevk> | krit: not doing fetching however, is processing layer |
| 13:58 | <annevk> | krit: so somewhere there's an algorithm that takes an SVG element and does something with it; use it as a mask/image/paint server/clip |
| 13:58 | <annevk> | krit: might be various such algorithms |
| 13:58 | <annevk> | krit: those need to be allowed to process elements, but also need to ensure no fetching is done |
| 13:59 | <annevk> | krit: for the CSS part of that CSS will need to gain a flag of "no fetching" |
| 13:59 | <annevk> | krit: which suggests maybe that flag should be passed all the way down to the fetching layer |
| 13:59 | <annevk> | krit: which then can decide whether to allow certain URLs, such as data URLs |
| 13:59 | <annevk> | in that mode |
| 14:00 | <krit> | annevk: another idea was to flag document |
| 14:00 | <krit> | annevk: and look at the status of document. So in general yes, fetching must pass the mode |
| 14:00 | <annevk> | yeah that seems equivalent |
| 14:00 | <krit> | annevk: fetchingEnables |
| 14:00 | <krit> | d |
| 14:02 | <annevk> | so for HTML most fetching is disabled if there's no browsing context |
| 14:02 | <annevk> | but it seems that wouldn't work here |
| 14:05 | <krit> | annevk: right |
| 14:05 | <krit> | annevk: sorry, need to take care of kids… slow in responce |
| 14:05 | <krit> | se |
| 14:09 | <krit> | annevk: could we continue tomorrow morning? |
| 14:09 | <annevk> | yeah sure, thanks for the help |
| 14:09 | <krit> | annevk: wrong way around ;) |
| 14:09 | <annevk> | need to think a bit how to proceed here |
| 14:10 | <annevk> | I'll let some Gecko people know we're trying to lock these things down |
| 14:14 | <krit> | annevk: cool! roc , bz and dholbert might be the right ppl to talk too |
| 14:51 | <jgraham> | annevk: I might just be very stupid, but your response about why .to() is preferred over .toX() didn't make any sense to me |
| 14:54 | <annevk> | *waves magic wand to make jgraham understand unstated things* |
| 14:56 | <Ms2ger> | The "state them" wand? |
| 14:57 | <annevk> | Ms2ger: unclear |
| 14:57 | <jgraham> | annevk: Erm. You posted the mail, I kind of assumed you already knew what you had stated |
| 14:57 | <annevk> | jgraham: you assumed I would understand what part didn't make sense to you? |
| 14:57 | <annevk> | sorry |
| 14:57 | <jgraham> | All of it didn't |
| 14:57 | <jgraham> | Hence "any sense" |
| 14:57 | <jgraham> | :) |
| 14:58 | <annevk> | seems pretty clear to me |
| 14:58 | <annevk> | anyway, I have to do something else |
| 14:58 | <jgraham> | I don't think it's at all clear conceptually (wihout reading the spec) why you can only call to() once, or why it would be worse with toX() |
| 14:59 | <jgraham> | Neither seems more complicated than the other to implement, really |
| 15:00 | <jgraham> | But the concerns about feature detection seem legitimate |
| 15:04 | <gsnedders> | Does anyone know if Google use Dart for anything significant? |
| 15:04 | <gsnedders> | (presumably in dart2js form) |
| 15:07 | <caitp> | the greentea stuff, at least |
| 15:10 | <caitp> | i guess it depends how you define "significant", though |
| 15:48 | <annevk> | jgraham: yeah, I guess we can look into it again |
| 16:37 | <annevk> | Is anyone trying this? https://loop.services.mozilla.com/calls/kfsTnuhULV9QzkcMbR4Xu1vJVV2hi-lQ4blJD1JVxcVlQ5lmH6isvyOI9iroY09PmTtX8hxuXCdeT-D4dXMwswZRId7DvBBEF728FxUOa0uS80v_TAt-pyak6A_Kubg0HU9qpbeQawu8KlEGuxcXYB9cpUPfAtoTWC6OJTMbx4YzxMnSnR0WfJwGJo41VsAVH_gC5W3lSIxArBE9V2-WG-CJ9fA |
| 18:42 | <estellevw> | The <output>, even those with a name, never have their value sumbitted along with the associated form, right? |
| 18:49 | <zcorpan> | estellevw: right |
| 18:49 | <estellevw> | thanks |
| 18:52 | <Domenic> | annevk: do you have that list of stream concepts that would be nice to define? |
| 18:57 | <Hixie> | gsnedders: ok here now |
| 18:58 | <gsnedders> | Hixie: you could just email me ;P |
| 18:58 | <Hixie> | that sounds like crazy talk |
| 18:58 | <Hixie> | ok |
| 18:58 | <Hixie> | so |
| 18:58 | <Hixie> | tests |
| 18:59 | <Hixie> | let's see |
| 18:59 | <Hixie> | git diff gives me a 1653 line diff |
| 19:00 | <Hixie> | how do you want them, one file at a time? |
| 19:01 | <gsnedders> | Hixie: related changes together |
| 19:01 | <Hixie> | how do i do that? |
| 19:01 | <gsnedders> | Hixie: you can use git add -p to select what to commit at each time |
| 19:01 | <gsnedders> | Google or prod someone else as to how, I need to phone my sister before I go out ;P |
| 19:01 | <Hixie> | k |
| 19:04 | <Hixie> | man git makes no sense to me at all |
| 19:05 | <Hixie> | what's the equivalent of "svn commit", meaning, the thing that sends my change upstream? |
| 19:05 | <Hixie> | everyone on the web is talking about multi-step processes involving web pages |
| 19:06 | <caitp> | `git push`? |
| 19:07 | <Hixie> | and waht does that push? all my commits? |
| 19:07 | <SamB> | hmm, anyone know a reference for the term "tofu"? |
| 19:08 | <Hixie> | SamB: context? |
| 19:09 | <SamB> | that stuff you see when you don't have the right font |
| 19:09 | <SamB> | usually little boxes, sometimes with hex codes in them |
| 19:09 | <Hixie> | oh the little squares? |
| 19:09 | <caitp> | Hixie: it will push the objects needed for the local refs to make sense remotely |
| 19:10 | <Hixie> | caitp: i've no idea what that means |
| 19:10 | <Hixie> | caitp: do i run git add, then git push? or git add, then git commit, then git push? |
| 19:10 | <SamB> | you have to commit before you can push changes |
| 19:10 | <Hixie> | how do i get several patches up to gsnedders? |
| 19:10 | <SamB> | commit each patch |
| 19:11 | <SamB> | then push the lot of them somewhere and inform him of where |
| 19:11 | <Domenic> | branch per patch, if they are independent |
| 19:11 | <caitp> | it's easier to explain with a chalkboard, but for the most part it's not worth worrying about the specifics of what gets pushed --- the simple case is, you have a branch, and you want to update a remote branch to match it |
| 19:11 | <caitp> | so you push your branch to the remote, and if it's a fast-forward commit, it will just work |
| 19:12 | <caitp> | and if it's not a fast-forward commit, then you should think carefully about it :d |
| 19:12 | <Hixie> | ok so with subversion, all i have to do is "svn diff", then i have the patch for review, then "svn commit", then it's upstream. |
| 19:13 | <SamB> | Hixie: in git you can commit first and review second |
| 19:13 | <Hixie> | you can do that in subversion too. svn commit, then svn diff with the revision numbers. |
| 19:13 | <Hixie> | i don't understand why git has to be so much more complicated. |
| 19:13 | <SamB> | yes, but without it being upstream |
| 19:13 | <Hixie> | i want it upstream |
| 19:13 | <Hixie> | what's the point of it not being upstream :-P |
| 19:14 | <caitp> | it's pretty simple, but there's a bit of a learning curve maybe. once you get the hang of it, it is totally natural |
| 19:14 | <SamB> | Hixie: git is used by many who don't have write access to upstream |
| 19:14 | <Hixie> | anyway |
| 19:14 | <Hixie> | so you're saying i should git add, then git commit, then git push, then git add, then git commit, then git push, etc? |
| 19:14 | <Hixie> | until i've got no more local changes? |
| 19:15 | <caitp> | you don't have to commit -> push -> commit -> push |
| 19:15 | <caitp> | you can commit -> commit -> commit -> push |
| 19:15 | <caitp> | if it's easier =) |
| 19:16 | <Hixie> | and that results in multiple patches on gsnedders' side? |
| 19:16 | <Hixie> | separate "pull requests" or whatever they're called? |
| 19:17 | <Domenic> | it results in separate commits, but not separate patches |
| 19:17 | <Domenic> | for separate patches, you should make separate branches |
| 19:17 | <Domenic> | Has anyone gotten Anolis + Travis-CI up and running? |
| 19:17 | <Hixie> | separate _branches_? |
| 19:17 | <Domenic> | Alternately, TabAtkins, how do I switch to Bikeshed? |
| 19:18 | <Hixie> | just to commit two separate files? |
| 19:18 | <Domenic> | branches are basically equivalent to commits in git |
| 19:18 | <Domenic> | they are not heavyweight as in svgn |
| 19:20 | <Hixie> | Domenic: i'm not finding anything online that leads me to that conclusions :-) |
| 19:20 | <Domenic> | Branches are pointers to commits |
| 19:21 | <Domenic> | literally if you look in the .git directory there will be files saying something like "branch_name: deadb33f" |
| 19:22 | <Hixie> | maybe i should just send gsnedders diffs |
| 19:23 | <SamB> | branches are *names* for commits |
| 19:23 | <SamB> | Hixie: you can use "git send-email" for that ;-P |
| 19:23 | <SamB> | after committing everything |
| 19:23 | <SamB> | or get format-patch |
| 19:23 | <Hixie> | is there no real documentation got git? i'm not finding anything sane on the web. |
| 19:23 | <Hixie> | for git |
| 19:23 | <Hixie> | not got git |
| 19:24 | <SamB> | you could try the manpages |
| 19:24 | <TabAtkins> | Domenic: What are you switching from? |
| 19:24 | <TabAtkins> | git manpages are terrible. |
| 19:24 | <Domenic> | TabAtkins: Anolis. Not too much complicated stuff yet. https://github.com/whatwg/streams/blob/master/index.html |
| 19:24 | <Hixie> | the man pages are impenetrable |
| 19:24 | <SamB> | hmm |
| 19:24 | <Domenic> | http://git-man-page-generator.lokaltog.net/ |
| 19:24 | <TabAtkins> | Domenic: That's pretty easy to switch from, since it's similar to the old CSSWG preprocessor, and Bikeshed is a spiritual descendent. |
| 19:25 | <TabAtkins> | I can convert for you, or you can just follow the docs and ask me questions. |
| 19:25 | <Domenic> | Hixie: http://git-scm.com/book is probably the best |
| 19:25 | <SamB> | Hixie: anwyay, the nice thing is that anything you screw up before you push, you can still fix |
| 19:26 | <Hixie> | Domenic: i don't even know where to begin with that |
| 19:26 | <Hixie> | Domenic: (i've been trying to read that for the past half hour) |
| 19:26 | <TabAtkins> | Ugh, there's a super-great visual guide to git I'm trying to find. |
| 19:26 | <Domenic> | TabAtkins: hmm documentation has gotten much better since I last saw. I'll give it a shot and ask questions if I get stuck. Thanks! |
| 19:26 | <TabAtkins> | Domenic: It's been stable for like a year, so you must have looked at it a *long* time ago. ^_^ |
| 19:26 | <TabAtkins> | https://marklodato.github.io/visual-git-guide/index-en.html |
| 19:26 | <SamB> | Hixie: maybe http://eagain.net/articles/git-for-computer-scientists/ will help? |
| 19:27 | <TabAtkins> | Hixie: ^^^ this was super informative to me. |
| 19:27 | <SamB> | Hixie: you aren't scared of DAGs are you? |
| 19:27 | <Hixie> | i'm not _scared_ of them, i just find the idea that i need to know about hashes and branches and DAGs and so forth just to submit some small diffs to be absurd |
| 19:28 | <Hixie> | TabAtkins: thanks, loking |
| 19:28 | <Hixie> | [24~looking |
| 19:28 | <Hixie> | l o o k i n g |
| 19:28 | <TabAtkins> | Hixie: The link I gave gives you a great, easy visual guide to the commands and what effect they have on the working directory, the index, and the history. |
| 19:28 | <TabAtkins> | Hahahaha |
| 19:28 | <SamB> | Hixie: well you don't have to know much about hashes to use it |
| 19:28 | <TabAtkins> | The hardest part of getting into git is (a) learning, intuitiveyl, what the index is for and why it's exposed, and (b) what commands interact with what thing. |
| 19:29 | <SamB> | call it the staging area |
| 19:29 | <TabAtkins> | Hard when you're used to a VCS that doesn't expose an index, at least. |
| 19:29 | <TabAtkins> | Yeah, same deal. |
| 19:29 | <Hixie> | TabAtkins: that explains the local stuff, but my real problem here is i don't care about the local stuff and just want to upload stuff to a remote server |
| 19:29 | <SamB> | the chief virtual of calling it an "index" is that that is less misleading than "cache" |
| 19:29 | <SamB> | er. |
| 19:29 | <Hixie> | i literally have zero use for the fact that git stores anything locally |
| 19:29 | <SamB> | s/virtual/virtue/ |
| 19:30 | <TabAtkins> | Hixie: Pushing to a remote is just (1) get the stuff into your history, then (2) git push. |
| 19:30 | <SamB> | Hixie: you do it locally and then upload when you've got all the things locally that you want remotely |
| 19:30 | <Hixie> | TabAtkins: but what does it push? |
| 19:30 | <SamB> | just pretend you are the server for the moment |
| 19:30 | <TabAtkins> | Your history. |
| 19:30 | <Hixie> | i only want to push one diff |
| 19:30 | <SamB> | Hixie: all it needs to push to keep the dag in one piece |
| 19:30 | <TabAtkins> | (Using the "visual guide" terms.) |
| 19:30 | <SamB> | you can't push a diff |
| 19:30 | <SamB> | git has no diffs |
| 19:30 | <TabAtkins> | Hixie: You're already tracking the server, right? |
| 19:31 | <TabAtkins> | So you pulled from the server, then made changes and committed them, and want to push? |
| 19:31 | <Hixie> | "tracking"? |
| 19:31 | <TabAtkins> | Sorry, I keep using terms of art. ^_^ |
| 19:31 | <SamB> | Hixie: you have it in the output of "git remote -v"? |
| 19:31 | <TabAtkins> | Point is: how did you get the code you were hacking on? |
| 19:31 | <TabAtkins> | With a `git pull`? |
| 19:31 | <Hixie> | i've no idea how i got my working directory, at this point, it's scrolled off the top of my .bash_history :-) |
| 19:31 | <TabAtkins> | Or `git clone`, whatever? |
| 19:32 | <SamB> | Hixie: so what says "git remote -v"? |
| 19:32 | <TabAtkins> | You probably cloned it. There a `.git` folder in the top-level folder? |
| 19:32 | <Hixie> | git remote -v says "origin https://github.com/html5lib/html5lib-tests (fetch)" (and origin) |
| 19:32 | <TabAtkins> | Okay, cool. |
| 19:32 | <Hixie> | er, and push |
| 19:32 | <SamB> | so yeah, you're tracking it |
| 19:32 | <Hixie> | now i have several changes in this direcory, and i'd like to submit them as separate patches. pull requests. whatever. |
| 19:32 | <TabAtkins> | Ah, you wanna do PRs. |
| 19:32 | <SamB> | hmm, separate pull requests means you'll need a branch for each |
| 19:32 | <TabAtkins> | That makes things a touch more complex. |
| 19:33 | <TabAtkins> | Want a walkthrough? |
| 19:33 | <Hixie> | if you're happy to give me one i would be much obliged, but i'd happily settle for documentation :-) |
| 19:33 | <TabAtkins> | Github's docs are okay for this, but it'll be compolicated since you've already made your changes all together. |
| 19:34 | <SamB> | "git gui" is your friend, I think |
| 19:34 | <Hixie> | they're in different files, fwiw |
| 19:34 | <TabAtkins> | Okay, that's easier. |
| 19:34 | <SamB> | oh, then "git add" is all you need |
| 19:34 | <TabAtkins> | Have you committed them yet? "No" is okay. |
| 19:34 | <Hixie> | (if they're not we'll pretend they are and then apologise to gsnedders later) |
| 19:34 | <Hixie> | nope |
| 19:34 | <TabAtkins> | Okay, cool. |
| 19:34 | <TabAtkins> | So you've got a lot of new files added, and none of them have had `git add` or `git commit` run on them yet, right? |
| 19:34 | <SamB> | ("yes" would have been okay too) |
| 19:35 | <Hixie> | no new files iirc, just edits to existing files |
| 19:35 | <Hixie> | (these are changes to the html5lib tests) |
| 19:35 | <TabAtkins> | SamB: (Yeah, but I was trying to head off a "No, but I'm doing it now"). |
| 19:35 | <TabAtkins> | Hixie: Okay. |
| 19:35 | <SamB> | Hixie: "git add" isn't just for new files |
| 19:35 | <TabAtkins> | So for each PR you wanna do, you'll need a fresh branch. |
| 19:35 | <Hixie> | ok |
| 19:35 | Hixie | grabs some wood |
| 19:35 | <TabAtkins> | So run `git checkout -b my-new-branch-name`. |
| 19:35 | <TabAtkins> | That'lll make a new branch and switch you to it. |
| 19:35 | <Hixie> | is that going to create new directories or anything? |
| 19:36 | <TabAtkins> | No. |
| 19:36 | <Hixie> | or just change the local directory to be in a branch? |
| 19:36 | <TabAtkins> | Branches are a magic git concept, not reflected in your directory structure. |
| 19:36 | <TabAtkins> | They're just a way of naming commits. |
| 19:36 | <Hixie> | so this is basically a way of naming the next commit(s)? |
| 19:36 | <TabAtkins> | The Yeah. |
| 19:36 | <SamB> | it switches which branch git considers to be your current branch |
| 19:36 | <TabAtkins> | Once you're in a new branch, `git add` the files you changed that you want to submit in a single PR, and `git commit`. |
| 19:37 | <TabAtkins> | Then make a new branch, and repeat. |
| 19:37 | <Hixie> | are these branch names local only, or should i take care to make them relevant in the future? |
| 19:37 | <TabAtkins> | Your uncommited files will follow you around as yous witch branches. |
| 19:37 | <SamB> | TabAtkins: shouldn't he switch back to "master" or whatever before he makes the next one? |
| 19:37 | <TabAtkins> | They'll go away as soona s the PR is merged. |
| 19:37 | <TabAtkins> | SamB: Oh yeah, right. |
| 19:37 | <Hixie> | ok |
| 19:37 | <SamB> | Hixie: the branch names don't have to last |
| 19:37 | <TabAtkins> | Do `git checkout master` after each commit, or your history'll be weird. |
| 19:37 | <TabAtkins> | And github will be unhappy. |
| 19:38 | <SamB> | I mean, probably the branches will be around forever but nobody will care once they've been merged up |
| 19:38 | <TabAtkins> | SamB: GH's UI lets you delete the branches. |
| 19:38 | <SamB> | well, sure |
| 19:38 | <Hixie> | where do i put the commit message? |
| 19:38 | <TabAtkins> | At least, remotely, and then that'll sync down. |
| 19:38 | <Hixie> | git commit -m"" ? |
| 19:38 | <TabAtkins> | Hixie: `git commit -m ""` |
| 19:38 | <Hixie> | k |
| 19:38 | <SamB> | but most people don't seem to bother to actually delete them ;-) |
| 19:38 | <Hixie> | and that gets sent to gsnedders somehow as part of the pull request? |
| 19:38 | <SamB> | Hixie: yes |
| 19:38 | <TabAtkins> | Not quite. |
| 19:38 | <TabAtkins> | Heh. |
| 19:38 | <TabAtkins> | This is preparing them for that. |
| 19:39 | <TabAtkins> | There are ways to do the PR from teh command-line, but I've never learned them. |
| 19:39 | <TabAtkins> | I do it through github's UI. |
| 19:39 | <zcorpan> | Hixie: you will want to checkout master (or gh-pages or whatever is the default branch) before doing the next git checkout -b foo |
| 19:39 | <Hixie> | TabAtkins: github can see my server? |
| 19:39 | <SamB> | TabAtkins: well, it does get included in the PR more-or-less |
| 19:39 | <TabAtkins> | Hixie: It can after you push. |
| 19:40 | <TabAtkins> | You'll be pushing the branches individually, and then you can tell GH to turn each branch into a PR. |
| 19:40 | <TabAtkins> | Like I said, there are more direct ways to do this last part, but I ahven't learned them yet. |
| 19:40 | <Hixie> | ok, so i've done git checkout -b format-changes; git add README.md; git commit -m"Update README file to include new and recent changes to the format" |
| 19:41 | <TabAtkins> | Now checkout master. |
| 19:41 | <TabAtkins> | Then repeat those steps for each other change. |
| 19:41 | <Hixie> | ok |
| 19:41 | <TabAtkins> | This'll clear out your working directory, which'll make things simpler if you have to resolve conflicts or whatever. |
| 19:41 | <zcorpan> | not push first? |
| 19:41 | <zcorpan> | git push origin -u format-changes |
| 19:42 | <TabAtkins> | zcorpan: Yeah, I'm just worrying about merge conflicts, though I guess that can be handled later. |
| 19:42 | <TabAtkins> | There won't be any conflict with the initial push. |
| 19:42 | <TabAtkins> | So yeah, do what zcorpan says. |
| 19:43 | <Hixie> | k |
| 19:44 | Hixie | wonders what his username is |
| 19:44 | <TabAtkins> | Is it asking for that? |
| 19:44 | <TabAtkins> | It's your github username/pw. |
| 19:44 | <zcorpan> | (if you want to make more commits to the same PR later, you can just checkout that branch and make your change, git add <file>; git commit -m "..."; git push ) |
| 19:45 | <zcorpan> | (to fix review comments or rebase etc) |
| 19:45 | <Hixie> | hm |
| 19:45 | Hixie | tries to log in via the web site |
| 19:45 | <Hixie> | i thought i knew my credentials... |
| 19:46 | <zcorpan> | Hixie: did you clone with https: URL? |
| 19:46 | <Hixie> | "The requested URL returned error: 403 while accessing https://github.com/html5lib/html5lib-tests/info/refs"; |
| 19:46 | <Hixie> | so i guess yes? |
| 19:46 | <Domenic> | if you have two-factor auth on you get screwed and have to generate a new per-machine password |
| 19:47 | <Hixie> | looks like chrome knows my password |
| 19:47 | <Domenic> | good old chrome |
| 19:47 | <Hixie> | now i just need to get chrome to tell it to me :-) |
| 19:47 | <TabAtkins> | That's in your settings page. |
| 19:47 | <Hixie> | yeah, chrome i know how to use. :-P |
| 19:47 | <Hixie> | ok well it's what i thought it was |
| 19:47 | <Hixie> | weird |
| 19:48 | <Hixie> | wtf |
| 19:49 | <Hixie> | no two factor auth... |
| 19:49 | <TabAtkins> | Oooh! |
| 19:49 | <TabAtkins> | You may have used your keys, and it's asking for your key password. |
| 19:49 | <TabAtkins> | Though, if it's asking for username, that's not right. |
| 19:49 | <Hixie> | it's asking for my username first, yeah... |
| 19:50 | <TabAtkins> | Oh wait, that might still be right. |
| 19:50 | <Hixie> | my .gitconfig has different information |
| 19:50 | <Hixie> | i wonder if that's the problem |
| 19:50 | <TabAtkins> | Maybe your key password for whatever key you gave to github? |
| 19:50 | <Hixie> | TabAtkins: i have no ssh keys set up |
| 19:50 | <TabAtkins> | Okay, then never mind that. |
| 19:50 | <Hixie> | though maybe i should just do that |
| 19:51 | <TabAtkins> | It means no un/pw, so that's what I do. |
| 19:52 | <Hixie> | yeah |
| 19:52 | <Hixie> | ok done |
| 19:52 | <Hixie> | let's try git push again |
| 19:52 | <Hixie> | still asking for username |
| 19:52 | <Hixie> | wtf |
| 19:54 | <Hixie> | https://help.github.com/articles/https-cloning-errors is unhelpful... |
| 19:55 | <Hixie> | i've just discovered you can use svn with github |
| 19:55 | <Hixie> | that's rather tempting |
| 19:55 | <TabAtkins> | Haha, you'll have to learn git someday! |
| 19:56 | <caitp> | I think it just uses git-svn behind the scenes, but it's probably not as tempting as you think |
| 19:56 | <TabAtkins> | (Though, learning GitHub is somewhat harder than just learning git.) |
| 19:56 | <Hixie> | ok seriously, why is github not letting me login |
| 19:56 | <Hixie> | i can ssh to github fine |
| 19:57 | <TabAtkins> | annevk: Which spec was it that I offered to Bikeshed for you? Was it DOM? |
| 19:58 | <caitp> | Hixie: which remote url are you using? if its your own repository, and you aren't using the secure url, you should be able to login with your github user/pass |
| 19:58 | <Hixie> | https://help.github.com/articles/why-is-git-always-asking-for-my-password seems likely to be what's going on, but i don't understand the words on that page |
| 19:58 | <caitp> | if it's the secure url, you should associate a key with your account and make sure git knows where to find it |
| 19:58 | <Hixie> | caitp: i'm trying to push to https://github.com/html5lib/html5lib-tests |
| 19:58 | <Hixie> | caitp: and i have the key set up such that ssh -T git⊙gc works fine |
| 19:58 | <caitp> | if it's not an account you have write access to, you're out of luck regardless |
| 19:58 | <jamesr_> | you can push to the ssh url if you want to use ssh key to auth |
| 19:59 | <caitp> | i'm guessing you have write access to html5lib |
| 19:59 | <caitp> | actually, I don't see you in the members list for that org |
| 19:59 | <Hixie> | caitp: i'm just trying to upload a pull request, presumably i don't need any rights to do that |
| 19:59 | <TabAtkins> | Oh yeah, that's probably it. |
| 19:59 | <caitp> | for a pull request, you'd upload to your own account |
| 20:00 | <TabAtkins> | To do a PR without commit right, you need to fork the repo to your own account. |
| 20:00 | <TabAtkins> | Then you push to your fork, and issue a PR from that. |
| 20:00 | <Hixie> | (seriously, what was wrong with the way we did it five years ago) |
| 20:00 | <SamB> | TabAtkins: is there a quick way to delete all the branches then? |
| 20:00 | <TabAtkins> | The main account can then accept the PR to integrate the change into themselves. |
| 20:00 | <caitp> | defunkt's `hub` tool makes this workflow pretty nice |
| 20:00 | <caitp> | so you might want to look into that |
| 20:00 | <Hixie> | so... |
| 20:00 | <TabAtkins> | Hixie: If you have commit rights its easier. |
| 20:00 | <Hixie> | how do i do that |
| 20:00 | <Hixie> | i thought i had already done my own fork |
| 20:00 | <TabAtkins> | Go into GitHub, and click the "fork" button. |
| 20:00 | <Hixie> | isn't that the whole point of git |
| 20:00 | <TabAtkins> | Then we can change your remote. |
| 20:00 | <Domenic> | TabAtkins: what metadata can I use to get something like the headers on http://fetch.spec.whatwg.org/ et al? |
| 20:00 | <TabAtkins> | And push your branches there instead. |
| 20:01 | <caitp> | cloning and forking are distinct |
| 20:01 | <TabAtkins> | Domenic: We don't have WHATWG boilerplate yet, but you can add that yourself really easily. |
| 20:01 | <Domenic> | TabAtkins: sounds good, will do later. |
| 20:01 | <TabAtkins> | Hixie: "forking" is a GH concept, not a git one. |
| 20:01 | <Hixie> | ok https://github.com/Hixie/html5lib-tests exists, whatever that is |
| 20:02 | <TabAtkins> | Hixie: All of these instructions are *way* more complicated than they have to be, because you're working within the GH model, but didn't *start* that way. |
| 20:02 | <Hixie> | TabAtkins: i'd be happy to work in some other model if it's simpler |
| 20:02 | <TabAtkins> | Hixie: Easiest model is to ask gsnedders to give you commit rights, and just push your changes. ^_^& |
| 20:02 | <Hixie> | i just want to have gsnedders review my changes and then have them committed to the repo |
| 20:02 | <TabAtkins> | Then you can set up cleanly with the GH model. |
| 20:03 | <TabAtkins> | In the GH model, you do all your work in your own fork, and throw PRs at the main repo. |
| 20:03 | <caitp> | the GH model is typically, you have your organization with a canonical repository, which is considered upstream, you have your own fork on your own account, and you have your local clones on however many machines |
| 20:04 | <Hixie> | TabAtkins: so in the GH model, you have a local repo, and then you push to a GH repo, and then you push from there to another GH repo? |
| 20:04 | <Hixie> | man |
| 20:04 | <caitp> | so all of your pushes should be against your fork on your github account, and you can submit those pushes for review in the canonical repository, it's pretty elegant |
| 20:04 | <Hixie> | again |
| 20:04 | <TabAtkins> | You push from your local repo to your fork, then PR over to the main fork, yeah. |
| 20:04 | <Hixie> | life was so much easier back in the subversion days |
| 20:04 | <Hixie> | but whatever |
| 20:04 | <TabAtkins> | Hixie: Depends on what you mean by "easier". |
| 20:05 | <Hixie> | is there some way to change my local working copy to point to https://github.com/Hixie/html5lib-tests instead? |
| 20:05 | <TabAtkins> | The GH model is designed for easy collaboration with strangers without allowing them to stomp on everything. |
| 20:05 | <TabAtkins> | And it works, once you know how to use it. |
| 20:05 | <caitp> | this model really grows on you, I am looking forward to chromium fully switching to git so that it's less crazy |
| 20:05 | <TabAtkins> | Yes, `git remote set-url origin <url-here>` |
| 20:05 | <Hixie> | caitp: so far this model has only grown on me like a disgusting fungus :-P |
| 20:06 | <TabAtkins> | You'll have to do this for each branch, I think? I'm not super-sure, haven't done that before. |
| 20:06 | <TabAtkins> | Hixie: You're just experiencing change aversion due to trying to apply your SVG mental model on top of git. |
| 20:06 | <TabAtkins> | They're close, but not exact, so the friction feels like errors. |
| 20:06 | <Hixie> | no, i'm pretty sure it's not change aversion :-) |
| 20:06 | <TabAtkins> | Adn then having to deal with GH's structure on top of it is makign it worse. |
| 20:06 | <TabAtkins> | Having used both SVG and git extensively, I know it's not just "git is fucked up and hard". ^_^ |
| 20:07 | <TabAtkins> | It's a little bit more complex, but most of the time you don't see that, and the complexity is actually quite worthwhile. |
| 20:07 | <TabAtkins> | Hixie: You may be able to make changes directly to .git/config |
| 20:08 | <Hixie> | so .git/config has no mention of the old url at all anymore |
| 20:08 | <caitp> | the basics are super simple, and intermediate stuff like complicated rebasing and refactoring stuff across multiple commits is actually really straight forward, but I guess I should focus on meetings and do less git-evangelism |
| 20:08 | <Hixie> | but i'm still getting prompted for my username |
| 20:08 | <Domenic> | TabAtkins: what if I have <dfn>Chunks</dfn> and want to (auto?) link to it from the word "chunk" |
| 20:09 | <TabAtkins> | Domenic: That happens automatically. |
| 20:09 | <Domenic> | such magic :O |
| 20:09 | <TabAtkins> | When it doesn't, use the title attribute to provide alternate text. |
| 20:09 | <Domenic> | Is there any difference between <a> and '? |
| 20:10 | <jgraham> | Hixie: We can make this easier |
| 20:10 | <TabAtkins> | (Bikeshed automatically accounts for common plurals, possessives, and -ing for both definitions and auotlinks.) |
| 20:10 | <TabAtkins> | Domenic: Big diff. Single quotes are for CSS property autolinks. |
| 20:10 | <jgraham> | Hixie: The GitHub model is broken for cases like this |
| 20:10 | <TabAtkins> | <a> by itself is a dfn autolink. |
| 20:10 | <Domenic> | ah k |
| 20:10 | <TabAtkins> | That is, a definition of type "dfn". |
| 20:10 | <TabAtkins> | A normal term, in other words. |
| 20:10 | <jgraham> | You should push to a branch of the main repo |
| 20:10 | <jgraham> | Then gsnedders or whoever can make pushes to fix your commits if needed |
| 20:11 | <TabAtkins> | jgraham: He just needs commit right for that, which he currently doesn't have. |
| 20:11 | <jgraham> | TabAtkins: That seems like a solvable problem |
| 20:12 | <TabAtkins> | That's what I said. ^_^ |
| 20:12 | <Hixie> | ok, i've changed my password and now it lets me use that to push |
| 20:13 | <jgraham> | TabAtkins, Hixie: OK, now you have push access |
| 20:13 | <Hixie> | still isn't using ssh |
| 20:13 | <Hixie> | but whatever |
| 20:13 | <Hixie> | jgraham: ah |
| 20:13 | <TabAtkins> | Hixie: Okay, so just pushing to the main repo should be good now. |
| 20:13 | <Domenic> | General question (not Bikeshed specific): when should I use a normative vs. informative reference? |
| 20:13 | <Hixie> | does "push" affect my local repo at all? |
| 20:13 | <Hixie> | or can i just change the remote url and push again |
| 20:13 | <TabAtkins> | Domenic: Will a change in the reference cause your spec to need to change? If so, normative. |
| 20:13 | <Domenic> | In this case I am using the reference in an example, so it is presumably informative, but curious what the dividing line is. |
| 20:13 | <TabAtkins> | Hixie: Don't bother with remote urls now. |
| 20:13 | <Domenic> | TabAtkins: nice, that's a pretty clear line. thanks. |
| 20:14 | <Hixie> | Domenic: normative reference means that implementations of your spec need to read and implement the other spec or your spec won't make sense |
| 20:14 | <TabAtkins> | Hixie: But no, a push does nothing to your local repo. It just copies commits from your history to the remote repo's history. |
| 20:15 | <Hixie> | Domenic: non-normative means that the other document could be deleted from the world, and your spec would be unaffected |
| 20:15 | <Hixie> | Domenic: but that readers might still want to see that other spec for context |
| 20:15 | <Hixie> | TabAtkins: k |
| 20:15 | <Domenic> | Thanks Hixie. |
| 20:15 | <TabAtkins> | Hixie: Just like how "add" just copies changes from your working area to your staging area, and "commit" just copies changes from your staging area to your history. ^_^ |
| 20:16 | <Domenic> | TabAtkins: well, that was pretty darn easy; impressive tool. |
| 20:17 | <jgraham> | Hixie: You want to do something like git remote add github git⊙gc:html5lib/html5lib-tests.git; git push --set-upstream github HEAD:hixie/new_tests |
| 20:17 | <TabAtkins> | Starting from Anolis makes some things easy. It's also possible that your dfns aren't typed correctly yet. ^_^ |
| 20:17 | <Domenic> | TabAtkins: what's the best way to get WHATWG boilerplate in? Pull request bikeshed, or can I have it take a boilerplate from external? |
| 20:17 | <TabAtkins> | I'll give it a lookover if you want. |
| 20:17 | <Hixie> | TabAtkins: there sure are a lot of different stages in the git/gh model |
| 20:17 | <Hixie> | what is whatwg boilerplate? |
| 20:17 | <TabAtkins> | Domenic: PR bikeshed - the /include directory has all the boilerplate files. |
| 20:17 | <Hixie> | there shouldn't be any whatwg boilerplate |
| 20:17 | <TabAtkins> | Just make new ones for whatever you need. |
| 20:17 | <TabAtkins> | Hixie: The entire header and footer are boilerplate. |
| 20:17 | <Domenic> | TabAtkins: Eek, that means I have to get it running locally on Windows... wheeee |
| 20:18 | <Hixie> | there's no standard header and footer for whatwg specs |
| 20:18 | <Hixie> | unless you mean the DOCTYPE |
| 20:18 | <TabAtkins> | You should make one. ^_^ |
| 20:18 | <Domenic> | Hixie: "boilerplate" in this case includes <script> and <link> files |
| 20:18 | <TabAtkins> | But also, the Group can be as granular as needed. |
| 20:18 | <Hixie> | TabAtkins: no, i mean, there's no standard. it's whatever the spec writer wants. |
| 20:18 | <Hixie> | e.g. whatwg/html and whatwg/dom are quite different |
| 20:19 | <TabAtkins> | HTML's a special case. Everyone else is mostly different just because of the lack of a standard. |
| 20:19 | <TabAtkins> | Crafting a stadnardized header would be fine for most of them. |
| 20:19 | <Hixie> | noooooo |
| 20:19 | <Hixie> | no bureaucracy |
| 20:19 | <Hixie> | no boilerplate |
| 20:19 | <Hixie> | the spec author should be responsible for all spec content |
| 20:20 | <TabAtkins> | It's nothing to do with "bureacracy". |
| 20:20 | <TabAtkins> | It's just that the header is pretty formulaic. |
| 20:20 | <Hixie> | it shouldn't be |
| 20:20 | <TabAtkins> | And so typing it all out yourself is dumb. |
| 20:20 | <Hixie> | it should be compelling |
| 20:20 | <Hixie> | it should draw the reader in |
| 20:20 | <Hixie> | if it's formulaic then we're doing something wrong |
| 20:20 | <Hixie> | different specs have different needs |
| 20:21 | <TabAtkins> | Those needs are much less unique and special than I think you're indicating. Case in point: most WHATWG specs have nearly identical-looking headers. |
| 20:22 | <Hixie> | and they all suck |
| 20:22 | <TabAtkins> | And I'll bet that whenever Anne makes a new one, he copy/pastes from an old one. |
| 20:22 | <Hixie> | seriously they're ugly headers right now |
| 20:22 | <Hixie> | we shouldn't create new specs that look like that |
| 20:23 | <TabAtkins> | Then figure out what they *should* look like, and standardize on that. |
| 20:23 | <Hixie> | it will surely change regularly |
| 20:23 | <Hixie> | as different spec authors experiment |
| 20:23 | <TabAtkins> | Then change it regularly. |
| 20:23 | <Hixie> | there shouldn't be an "it" |
| 20:23 | <TabAtkins> | This is far easier to do when it's generated by the tool. |
| 20:24 | <Hixie> | it should just be part of the spec source |
| 20:24 | <Hixie> | there's nothing to generate |
| 20:25 | <TabAtkins> | Welp, most of it is repetitive garbage no matter what you do, so I guess I totally disagree. |
| 20:26 | <Hixie> | there shouldn't be anything repetitive about it |
| 20:26 | <Hixie> | if it's repetitive it shouldn't be in the spec |
| 20:27 | <Domenic> | I *would* be happier right now if I could just port over the existing parts of the spec source, and have Bikeshed only touch the main body of the spec... there's like 15 lines that I'm going to spend the next few hours duplicating |
| 20:28 | <TabAtkins> | Domenic: If you do that, you'll lose the auto-genned index, refs, issues index, etc. |
| 20:28 | <TabAtkins> | But you can trick Bikeshed into not doing the header generation by including a doctype. |
| 20:28 | <TabAtkins> | If the first line is the html doctype, Bikeshed assumes you're providing your own header. |
| 20:28 | <TabAtkins> | Hm, I can't remember if it still includes the footer in that case. Lemme see... |
| 20:29 | <Hixie> | um, so i broke something with this git stuff i'm doing |
| 20:29 | <TabAtkins> | Ah, it does not. |
| 20:29 | <Hixie> | i tried to be clever and use git add -p to add just one part of a change |
| 20:29 | <Hixie> | and now it's saying "error: You have local changes to 'tree-construction/template.dat'; cannot switch branches" when i try to checkout master |
| 20:30 | <SamB> | Hixie: "git stash" now |
| 20:30 | <TabAtkins> | Hixie: You need to commit them first. |
| 20:30 | <SamB> | then "git stash pop" after you switch back |
| 20:30 | <Hixie> | i did commit them |
| 20:30 | <Hixie> | i'm following the same steps you gave before :-) |
| 20:30 | <TabAtkins> | Oh, but they're to the file that's also commited. |
| 20:30 | <Hixie> | git checkout -b BRANCHNAME; git add FILES; git commit -m"MESSAGE"; git push origin -u BRANCHNAME; git checkout master |
| 20:30 | <TabAtkins> | Okay, yeah, stash. |
| 20:30 | <Hixie> | what does git stash pop do? |
| 20:30 | <TabAtkins> | `git stash` now will save and undo all the remaining uncommitted local changes. |
| 20:30 | <TabAtkins> | pop throws them away, don't do that. |
| 20:31 | <Hixie> | it says "nothing to apply" |
| 20:31 | <SamB> | hmm |
| 20:31 | <SamB> | I thought pop applied them first, THEN threw them away if that worked |
| 20:31 | <Hixie> | how do i see my "local changes"? |
| 20:31 | <Hixie> | and what are they local to? |
| 20:32 | <TabAtkins> | So, back to the visual guide. ^_^ |
| 20:32 | <Hixie> | since there's three levels just in my own repo... |
| 20:32 | <TabAtkins> | working directory is the current state of your files. |
| 20:32 | <TabAtkins> | What you actually see. |
| 20:32 | <SamB> | Hixie: once committed, they don't count as "local" according to git |
| 20:32 | <TabAtkins> | staging area is what's getting ready for a commit. |
| 20:32 | <Hixie> | so which are the local changes? staged or working? |
| 20:32 | <TabAtkins> | (This exists for a few reasons, one of which is so that `git add -p` can exist and make sense) |
| 20:33 | <TabAtkins> | It usually means "not committed". |
| 20:33 | <Hixie> | git diff looks at working vs current comitted state of the branch? |
| 20:33 | <jgraham> | Hixie: git status shows the files with changes |
| 20:33 | <TabAtkins> | git diff looks at lots of things depending on the args. |
| 20:33 | <TabAtkins> | Visual guide explains that. |
| 20:33 | <jgraham> | Split into staged / unstaged / untracked |
| 20:33 | <TabAtkins> | Better than I'd be able to. |
| 20:33 | <jgraham> | git diff shows the unstaged changes |
| 20:33 | <jgraham> | git diff --staged shows the staged changes |
| 20:33 | <Hixie> | git diff --staged is empty |
| 20:34 | <Hixie> | git status shows everything under "On branch newtemplatetest" "Changed but not updated" |
| 20:34 | <Hixie> | presumably this is because i commited just one bit of one of these changed files |
| 20:34 | <Hixie> | and it doesn't know how to throw just that change away when going back to the earlier branch |
| 20:34 | <Hixie> | while keeping my other changes |
| 20:35 | <Hixie> | so i guess i do git diff > foo.patch; git reset; patch < foo.patch ? |
| 20:35 | <jgraham> | Hixie: Can you pastebin the output somewehre |
| 20:35 | <Hixie> | output of what? |
| 20:35 | <jgraham> | No, if you're using patch files you're doing it wrong |
| 20:35 | <jgraham> | Hixie: git status |
| 20:36 | <Hixie> | damowmow.com/temp/git-output |
| 20:36 | <Hixie> | http://damowmow.com/temp/git-output |
| 20:36 | <Hixie> | $ git checkout master |
| 20:36 | <Hixie> | error: You have local changes to 'tree-construction/template.dat'; cannot switch branches. |
| 20:36 | <Hixie> | template.dat is the file for which i commited just one chunk |
| 20:36 | <Hixie> | on the current branch |
| 20:36 | <jgraham> | Hixie: Just to make sure I know, what are you trying to achieve |
| 20:37 | <jgraham> | The scrollback was quite hard to follow |
| 20:37 | <Hixie> | trying to get gsnedders a bunch of patches |
| 20:37 | <Hixie> | one for each related change |
| 20:37 | <Hixie> | (brb getting food, back in 5 min) |
| 20:37 | <jgraham> | OK, and you have committed one patch and want to make more |
| 20:39 | <TabAtkins> | jgraham: And specifically, he's commited part of a changed file with add -p, and wants the rest of the file's changes in another branch. |
| 20:39 | <jgraham> | OK |
| 20:40 | <jgraham> | Hixie: So the advice from everyone about git stash was correct |
| 20:41 | <jgraham> | git stash basically commits all the changes in your working directory to a temporary branch |
| 20:42 | <jgraham> | These temporary areas are notionally arranged as a stack |
| 20:42 | <jgraham> | so git stash; git checkout master; git stash pop |
| 20:42 | <annevk> | TabAtkins: yeah, DOM I think |
| 20:42 | <Hixie> | back |
| 20:43 | <Hixie> | jgraham: ok cool, thanks |
| 20:43 | <Hixie> | jgraham: that's basically the same as what i said about with diff and patch |
| 20:43 | <annevk> | Domenic: hmm "tee", push x to stream, read from stream (and read until empty or read current buffer) |
| 20:45 | <annevk> | Domenic: if stream is closed/open I guess |
| 20:45 | <annevk> | (I currently use "is fully read" for closed) |
| 20:47 | <Hixie> | if i added something to my staging area in error, how do i remove it? |
| 20:48 | <Hixie> | git reset? |
| 20:49 | <Hixie> | yeah that seems to be it |
| 20:49 | <Hixie> | how about a way to diff the working directory against the staged stuff? |
| 20:49 | <Hixie> | so i can tell what i haven't staged? |
| 20:49 | <TabAtkins> | Hixie: VISUAL GUIDE |
| 20:49 | <TabAtkins> | It has all of these questions in beautiful diagram form. |
| 20:50 | <Hixie> | it claims "git diff" does what i want |
| 20:50 | <Hixie> | but it's not clear that that is true |
| 20:50 | <TabAtkins> | It hasn't lied to me yet, so shrug. |
| 20:51 | <Hixie> | k |
| 20:51 | <Hixie> | part of the problem is that things that seem symmetric have entirely different names |
| 20:51 | <Hixie> | e.g. look at the diff diagram on that page |
| 20:51 | <TabAtkins> | Yes. |
| 20:51 | <Hixie> | diff maint, diff HEAD, diff, diff --cached, wtf |
| 20:51 | <Hixie> | it's all over the place |
| 20:52 | <TabAtkins> | Note that "maint" is just a branch name there, not a command. |
| 20:52 | <TabAtkins> | And HEAD is a magic commit name that always refers to the tip of your branch. |
| 20:53 | <Hixie> | yeah |
| 20:53 | <TabAtkins> | So `diff` is WD against SA, `diff <commit/branch/etc>` is WD against history, `diff <commit/etc> <commit/etc>` is commit against commit. |
| 20:53 | <TabAtkins> | The --cached one is weird, but it's also rare to have to diff staging area against history. |
| 20:53 | <Hixie> | basically i think git suffers from two fundamental problems (both made orders of magnitude worse by github): it's over-engineered, and it has a horrible inconsistent ui |
| 20:54 | <TabAtkins> | Ignore the GH parts right now. They have a simple and consistent model that is terribly confusing if you come at it piecemeal and trying to slowly adapt your working process to it. |
| 20:54 | <TabAtkins> | Once you actually learn it and use it proper, it's fairly easy and simple. |
| 20:55 | Hixie | accidentally types git checkout -p foo instead of -b foo and hopes that didn't break anything |
| 20:55 | <TabAtkins> | I can't make the same argument as strongly for git itself, because it does have some weird edges, but its core is pretty simple and elegant. |
| 20:56 | <TabAtkins> | Though again, piecemeal changing your process from SVG to git is confusing, and it burned me too. |
| 20:56 | <TabAtkins> | Once I found the visual guide everything made way more sense. |
| 20:56 | <Hixie> | i'm not trying to change my process at all |
| 20:56 | <Hixie> | i'm just trying to commit this one set of changes |
| 20:56 | <Hixie> | :-) |
| 20:56 | <TabAtkins> | Your process being "make changes, commit them". ^_^ |
| 20:57 | <TabAtkins> | Domenic: Point me to a spec that you want to use the heading portion of, and I'll make boilerplates for you to use. |
| 20:57 | <TabAtkins> | Domenic: If you and annevk can agree on what heading stuff to use, all the better. |
| 20:58 | <TabAtkins> | Domenic: Also, I'm happy to review your bikeshedded file, to make sure you're using the right dfn types (so Shepherd will be happy when it starts parsing your spec). |
| 20:59 | <Hixie> | jgraham: (btw, thanks for setting me up with access) |
| 20:59 | <Domenic> | TabAtkins: excellent. i am very close to being done with a bikeshed draft that repros my current stuff, will ping you in 10 minutes probably |
| 20:59 | <TabAtkins> | kk |
| 21:01 | <TabAtkins> | annevk: Is "dom-core.html" an important filename to maintain for the generated file? |
| 21:01 | <TabAtkins> | Totally fine if it is, just making sure what you want. |
| 21:02 | <Hixie> | TabAtkins: ok i've committed everything |
| 21:02 | <Hixie> | TabAtkins: is there somewhere i can review these changes? |
| 21:02 | <Hixie> | pushed everything ,rather |
| 21:02 | <TabAtkins> | In the github UI, you can change what branch you're looking at. |
| 21:03 | <TabAtkins> | And if you need to make changes, `git checkout my-branch-name`, make changes, commit, push. |
| 21:04 | <Hixie> | then i hit "create pull request"? |
| 21:05 | <TabAtkins> | PRing from a branch to another branch in the same repo is fiddly. |
| 21:05 | <TabAtkins> | Better to just ping gsnedders about it and let him deal with it. |
| 21:05 | <TabAtkins> | He can pull the branch and merge it himself. |
| 21:06 | <Hixie> | ah ok these are all publicly viewable already? good |
| 21:06 | <Hixie> | https://github.com/html5lib/html5lib-tests/branches |
| 21:06 | <TabAtkins> | Yeah. |
| 21:06 | <Hixie> | gsnedders: ok dude, https://github.com/html5lib/html5lib-tests/branches |
| 21:06 | <Hixie> | TabAtkins: thanks so much for the help |
| 21:06 | <Hixie> | and to everyone else also |
| 21:06 | <Hixie> | but mainly tab :-) |
| 21:06 | <TabAtkins> | Now in the *future*, this can be much easier. |
| 21:07 | <TabAtkins> | Because you can do it right from the start. |
| 21:07 | <TabAtkins> | Clone your fork instead. |
| 21:07 | <Domenic> | heh, Python doesn't like Unicode |
| 21:07 | <TabAtkins> | Then make branches whenever you want to submit something. |
| 21:07 | <TabAtkins> | *Then* the "create PR" button in GitHub is easy and does the right thing. |
| 21:07 | <TabAtkins> | Domenic: Bikeshed errors? Plz let me know, everything should be clean by now. |
| 21:11 | <TabAtkins> | annevk: Would it annoy you if I converted your indentation to tabs? |
| 21:11 | <jgraham> | TabAtkins: No it isn't |
| 21:12 | <TabAtkins> | jgraham: What isn't? |
| 21:12 | <jgraham> | Fiddly to create PRs from branches in the same repo |
| 21:12 | <jgraham> | There is like a big green button for that |
| 21:13 | <jgraham> | Working from a fork is *much* harder |
| 21:13 | <jgraham> | Because there are 3 repos to worry about rather than two |
| 21:13 | <jgraham> | and it's much harder for anyone else to help you out |
| 21:13 | <jgraham> | because they can't push commits |
| 21:13 | <TabAtkins> | jgraham: In my experience with picture-element, it was really annoying. |
| 21:14 | <TabAtkins> | But maybe that was because we used a non-master main branch. |
| 21:14 | <jgraham> | Perhaps |
| 21:14 | <TabAtkins> | The GH UI was just super-unfriendly for this. |
| 21:14 | <TabAtkins> | And defaulted to doing some crazy shit when trying to specify what branch you were PRing against. |
| 21:14 | <jgraham> | In all the situations where I use GH I vastly prefer working with one upstream rather than a fork and a master |
| 21:14 | <jgraham> | s/master/origin/ |
| 21:15 | <Hixie> | i have no experience of this, so my opinion is worthless, but what jgraham is saying makes more sense to me. :-) |
| 21:15 | <jgraham> | TabAtkins: For example https://github.com/html5lib/html5lib-tests/tree/newtemplatetest seems to be one of Hixie's branches |
| 21:15 | <jgraham> | and the green button to the left of the branch name creates a PR from that branch against master |
| 21:16 | <TabAtkins> | I've worked with several repos in the "fork and PR" model, and it's always worked well for me. |
| 21:16 | <TabAtkins> | jgraham: Okay, so my difficulty may have mainly been from the non-master main branch. |
| 21:16 | <TabAtkins> | Stupid gh-pages bullshit. |
| 21:16 | <TabAtkins> | In Anolis, does <span> by itself do anything? |
| 21:17 | <jgraham> | If you then want to make a PR against another branch, you can do it using the "pick a branch |
| 21:17 | <jgraham> | " UI after you select "create pull request" |
| 21:17 | jgraham | wished he knew that a few hours ago |
| 21:17 | <TabAtkins> | jgraham: Yeah, that UI *completely bugged out* when I last used it in the picture-element repo. |
| 21:18 | <Domenic> | TabAtkins: https://github.com/whatwg/streams/tree/bikeshed |
| 21:18 | <Domenic> | index.html is the old Anolis source; output.html is the bikeshed output. |
| 21:18 | <Domenic> | In the future will have Travis run bikeshed on gh-pages branch and not commit the output at all. |
| 21:18 | <TabAtkins> | Okay. |
| 21:19 | <Domenic> | Haven't started using implicit paragraphs yet but I think I got most other things like references and definitions updated. |
| 21:19 | <Domenic> | https://rawgit.com/whatwg/streams/bikeshed/output.html is the rendered output |
| 21:20 | <TabAtkins> | Domenic: OH man, use them. They're so good! |
| 21:20 | <TabAtkins> | Also: Markdown headings should work now. |
| 21:20 | <Domenic> | Ooooh |
| 21:20 | <TabAtkins> | But they're still technically experimental. |
| 21:20 | <TabAtkins> | Have I updated the docs yet? Hm... |
| 21:20 | <Domenic> | Can I use them for no-num no-toc or similar? |
| 21:20 | <Hixie> | <span> is just a cross-ref source (<a>) |
| 21:20 | <Hixie> | in anolis |
| 21:20 | <TabAtkins> | I have not. |
| 21:21 | <TabAtkins> | Domenic: Not quite yet. |
| 21:21 | <TabAtkins> | Domenic: I have a shorthand for adding an id, but not for marking them no-num or no-toc. |
| 21:21 | <TabAtkins> | Hixie: Thanks. |
| 21:22 | <Domenic> | TabAtkins: any other markdown features to know about? E.g. links? |
| 21:22 | <TabAtkins> | Domenic: No inline markdown yet. |
| 21:23 | <TabAtkins> | Still slightly unsure if I want to do them or not. |
| 21:23 | <Domenic> | ya |
| 21:23 | <TabAtkins> | But code blocks work. |
| 21:23 | <TabAtkins> | And I'm working on lists. |
| 21:23 | <Domenic> | oooh |
| 21:23 | <Domenic> | fenced code blocks? dare i ask, with syntax highlighting?? |
| 21:23 | <TabAtkins> | Plan to add syntax highlighting to code blocks a la gfm |
| 21:24 | <Domenic> | yessss will make these examples so much better |
| 21:24 | <TabAtkins> | Oh, I haven't added the code block support quite yet! |
| 21:24 | <TabAtkins> | I'll do that today, it's easy. |
| 21:25 | <Hixie> | ok so now that i have an html parser i need to figure out what features i need in my pipeline |
| 21:26 | <Hixie> | TabAtkins: what does bikeshed do that's critical? |
| 21:26 | <TabAtkins> | Hixie: Biggest one is cross-spec cross-references. |
| 21:26 | <Hixie> | ok, got that one |
| 21:26 | <Hixie> | outline, also |
| 21:26 | <TabAtkins> | Totally automagic unless there's a conflict. |
| 21:26 | <Hixie> | not so worried about the magic aspect, i like being explicit |
| 21:26 | <TabAtkins> | Bleh, okay. |
| 21:27 | <TabAtkins> | Railroad diagrams seem to be a lot of people's favorite feature. ^_^ |
| 21:27 | <Hixie> | i also need spec splitting, and back-references from <dfn> |
| 21:27 | <TabAtkins> | IDL auto-markup, too. |
| 21:27 | <TabAtkins> | (That is, inserting <dfn> or <a>, as appropriate, on all the things in an IDL block.) |
| 21:28 | <Hixie> | interesting |
| 21:28 | <Hixie> | i'll just stick to using <span>s for now |
| 21:28 | <Hixie> | i need to get this up and running before i start making it clever :-) |
| 21:28 | <TabAtkins> | Yeah, those were all nice-to-haves that I added later. |
| 21:29 | <TabAtkins> | cross-spec refs were the actual reason I started Bikeshed. |
| 21:29 | Hixie | adds that to the "v2" list |
| 21:44 | <Domenic> | TabAtkins: When I do "<dfn>Some term</dfn> means ..." at the start of a paragraph, it gets capitalized in the index, which seems silly. |
| 21:45 | <TabAtkins> | Domenic: You can manually specify the linking test with title='', just like Anolis. |
| 21:45 | <TabAtkins> | I don't want to tweak any capitalization normally, as that will often be wrong. |
| 21:46 | <Domenic> | niiice |
| 21:51 | <TabAtkins> | annevk: Is your definition of "throw" supposed to be the same as WebIDL's, or something different? |
| 21:56 | <TabAtkins> | annevk: Hmmmm, the version of DOM on GitHub is different from the version on whatwg.org. Where's the canonical source? |
| 21:56 | TabAtkins | is going to stop working on Bikeshedding this until figuring this out, in case he has to redo anything. |
| 22:09 | <TabAtkins> | Domenic: So it sounds like you were encountering unicode errors in Bikeshed? |
| 22:09 | <TabAtkins> | That's very strange, because unicode *definitely* works when run on linux and mac. |
| 22:10 | <TabAtkins> | So there's something wrong with your setup on Windows that is screwing things up. |
| 22:11 | <Domenic> | TabAtkins: I was actually using just the curl version |
| 22:11 | <Domenic> | albeit, via Windows curl... |
| 22:11 | <TabAtkins> | There's something getting fucked up in the middle, then. |
| 22:11 | <TabAtkins> | Hmmmm |
| 22:12 | <TabAtkins> | (The apostrophe thing is because Bikeshed automagically converts apostrophes to curly aposes when it can.) |
| 22:12 | <Domenic> | Totally willing to believe it's Windows' fault |
| 22:12 | <Domenic> | well, it shouldn't do that inside comments ;) |
| 22:13 | <TabAtkins> | Possibly, but it's done as a source-level hack, before parsing occurs. |
| 22:13 | <TabAtkins> | And comments are stripped out, too, so shrug. |
| 22:38 | <zewt> | close-quote-as-apostrophe is terrible |
| 22:38 | <TabAtkins> | Tell that to people who care about typography. |
| 22:39 | <zewt> | quotes are quotes, apostrophes are apostrophes, and ' is apostrophe |
| 22:39 | <TabAtkins> | Or a quote. |
| 22:39 | <TabAtkins> | You know, depending. |
| 22:39 | <zewt> | close-single-quote is a quote; using it as an apostrophe is just making *it* ambiguous too |
| 22:41 | <zewt> | it's absurd that unicode introduced a set of characters that are unambiguously quotes, then proceeded to recommend that everyone use them as ... apostrophes |
| 22:42 | <TabAtkins> | Unicode defines it as the preferred form. |
| 22:42 | <TabAtkins> | So shrug. |
| 22:46 | <Domenic> | Hixie: bad security cert on https://resources.whatwg.org/logo-streams.svg ? |
| 22:47 | <TabAtkins> | If you follow the link, there's a server error anyway. |
| 22:47 | <Domenic> | i was too scared of the hax0rs |
| 22:48 | <Domenic> | My Travis auto-build is working pretty awesomely though |
| 22:48 | <Hixie> | Domenic: there's no cert at all, is there? |
| 22:49 | <Domenic> | Hixie: it says there's one issued to sni.dreamhost.com |
| 22:49 | <Hixie> | odd |
| 22:49 | <Hixie> | i'm surprised there's even an https server at that domain |
| 22:49 | <Domenic> | I kind of thought we fixed this somewhat recently and got resources working over https |
| 22:49 | <Hixie> | oh |
| 22:49 | <Hixie> | of course there is |
| 22:49 | <Hixie> | it's the same IP as whatwg.org |
| 22:49 | <Hixie> | we got a cert for www.whatwg.org for one year |
| 22:49 | <Domenic> | gtg grab food before kitchen closes, bbiab |
| 22:49 | <zewt> | missing intermediate CAs? |
| 22:49 | <Hixie> | but didn't get any other certs |
| 22:50 | <Hixie> | and i don't expect to renew the one in one year, either, given how much of a pain that was |
| 22:50 | <Hixie> | if anyone wants to take charge on this, be my guest :-) |
| 22:50 | <zewt> | it's pretty simple, but it's definitely lame to have to pay the SSL Tax, heh |
| 22:51 | <Hixie> | i found some free provider |
| 22:52 | <zewt> | the only free certificate providers i tried were a huge pain in the ass |
| 22:52 | <Hixie> | see above. :-) |
| 22:52 | <zewt> | but that's the fault of the shtity provider |
| 22:52 | <zewt> | also shitty |
| 22:53 | <zewt> | i think the one I tried wanted users to create client certificates to log in and didn't have passwords at all, which is a nice option but given the actual level of security certs provide, absurd to require |
| 22:54 | <Hixie> | yep, that's the one |
| 22:54 | <zewt> | yeah. better off just paying the $20 or whatever on a real provider |
| 22:55 | <Hixie> | send me the $20 and i'll get right on that :-) |
| 22:55 | <Hixie> | i'm already paying plenty to actually host the server |
| 22:55 | <Hixie> | that seems to me to have a higher benefit-per-dollar ratio |
| 22:56 | <zewt> | my SSL cert off of godaddy was $13/year for a 5-year |
| 22:56 | <zewt> | (single domain, not wildcard; those are the ones they want stupid money for) |
| 22:56 | Hixie | mumbles something about "." and ".." messing up his "is this directory empty" logic |
| 22:56 | <Hixie> | given how many domains whatwg.org has, it might be best to go wildcard |
| 22:57 | <zewt> | of course, the "xhr.spec.whatwg.org" hostname layout will screw you there, too |
| 22:57 | <zewt> | never use hostnames more than one deep |
| 22:58 | <Hixie> | it's not really clear to me why we care about encryption here anyway |
| 22:58 | <Hixie> | they're specs |
| 22:58 | <Hixie> | we _want_ people to read them |
| 22:58 | <Hixie> | and it's not like some encryption is going to stop people from inserting random crap into them |
| 22:58 | <Hixie> | the w3c already does that in broad daylight |
| 22:58 | <zewt> | heh godaddy wants $300/year for wildcard |
| 22:59 | <zewt> | (but they also want $70/year for regular--you have to search out coupon codes to get the real prices, I guess there's no avoiding some form of stupid crap) |
| 23:00 | <zewt> | which is probably why I renewed for 5 years, I probably found a good coupon (also it means I don't have to screw with it for a long time) |
| 23:00 | <zewt> | i suppose it's unlikely that somebody would bother initiating an MITM attack on whatwg.org that randomly changes the word "must" to "should" |
| 23:01 | <Hixie> | not only is it unlikely, it'd be pretty hilarious |
| 23:13 | <Hixie> | hm |
| 23:13 | <Hixie> | doing those commits and stuff seems to have removed some of the changes from my local copy |
| 23:13 | <Hixie> | TabAtkins: is there some way to fetch all the changes back somehow? |
| 23:14 | <Hixie> | i'm not sure i even know what question i should be asking |
| 23:14 | <TabAtkins> | Hixie: You probably ruined everything at some point, so... no. |
| 23:14 | <TabAtkins> | But... maybe. |
| 23:14 | <TabAtkins> | Probably no. |
| 23:14 | <Hixie> | it ssays i'm "ahead by two commits" |
| 23:15 | <Hixie> | is there some way to see what those are? |
| 23:15 | <Hixie> | ("it" being sgit status) |
| 23:15 | <Hixie> | git |
| 23:15 | <TabAtkins> | That means you've got two commits more than your remote repo. |
| 23:15 | <jgraham> | git log @{u}.. |
| 23:15 | <TabAtkins> | I have no idea what that means. |
| 23:15 | <jgraham> | @{u} is short for @{upstream} |
| 23:16 | <jgraham> | Which is the upstream branch that the current branch is tracking |
| 23:16 | <Hixie> | how do i get a diff though? |
| 23:16 | <jgraham> | git dif @{u}.. |
| 23:16 | <jgraham> | *diff |
| 23:16 | <Hixie> | that didn't show me anything |
| 23:16 | <Hixie> | (i tried that) |
| 23:17 | <Hixie> | the log gives two checkins from march |
| 23:17 | <Hixie> | which seems unlikely? |
| 23:17 | <jgraham> | Well what does git show HEAD show? |
| 23:17 | <Hixie> | it gives a commit id |
| 23:17 | <Hixie> | and a couple of merge ids |
| 23:17 | <Hixie> | and then says me, and march |
| 23:17 | <Hixie> | no idea what to do with that |
| 23:18 | <jgraham> | You have a merge in your history? That sounds pretty odd |
| 23:19 | <Hixie> | it's the way that git diff gives no content that baffles me |
| 23:19 | <caitp> | what is the git diff command you're using? |
| 23:19 | <caitp> | just git diff BASE HEAD? |
| 23:20 | <Hixie> | git diff <blabla> where blabla is the id of any of the last three checkins in git log |
| 23:20 | <Hixie> | git diff BASE HEAD says "fatal: ambiguous argument 'BASE': unknown revision or path not in the working tree" |
| 23:20 | <caitp> | I should have said <BASE> |
| 23:21 | <caitp> | and <HEAD>, like, the base revision and the head revision you want to check against it |
| 23:23 | <Hixie> | assuming these commits were just me messing about, and are in fact empty |
| 23:23 | <jgraham> | Hixie: If it's a merge commit and there are no conflicts there wouldn't be any |
| 23:23 | <Hixie> | how do i throw them away and just be at tip of tree? |
| 23:23 | <Hixie> | i just want to be at whatever html5lib is, then i want to pull in all my changes i uploaded earlier |
| 23:23 | <Domenic> | <Hixie> the w3c already does that in broad daylight // literal lol'ing happened |
| 23:26 | <jgraham> | Hixie: You have just seperated out all your changes into seperate branches |
| 23:26 | <Hixie> | yes |
| 23:26 | <jgraham> | It's not terribly easy to get into a state where you have the changes from all of those branches at the same time |
| 23:27 | <jgraham> | I mean you can |
| 23:27 | <jgraham> | But you probably don't want to |
| 23:27 | <Hixie> | my code won't compile until i do... |
| 23:27 | <Hixie> | well, it'll compile, but it won't pass its tests |
| 23:27 | <TabAtkins> | You really want to wait until they're accepted, then just pull the main repo again. |
| 23:28 | <TabAtkins> | That'll have everything in it at that point. |
| 23:28 | <Hixie> | i really want to run my code right now :-) |
| 23:28 | <Hixie> | i presumably have these branches locally |
| 23:28 | <Hixie> | i wonder if i can stash each one and pop it on my main branch |
| 23:28 | <TabAtkins> | Nothing to stash, as they're all committed up. |
| 23:29 | <TabAtkins> | You can make a separate branch, rebase all the other branches over it. That might work? |
| 23:29 | <TabAtkins> | Or just merge them all, possibly simpler. |
| 23:29 | <TabAtkins> | (Merge on a separate branch.) |
| 23:29 | <jgraham> | You can make a branch and cherry-pick all the changes onto it |
| 23:29 | <Hixie> | no idea what "rebase" means, but ok? |
| 23:29 | <caitp> | rebase is fun, you'll love it |
| 23:29 | <jgraham> | Don't try to use rebase |
| 23:29 | <caitp> | haha |
| 23:29 | <caitp> | aw. |
| 23:30 | <jgraham> | It's an awesome tool, but not what you want in this case |
| 23:30 | <Hixie> | how do i find a list of all my branches? |
| 23:30 | <jgraham> | git branch |
| 23:30 | <jgraham> | then create a new branch |
| 23:30 | <caitp> | git branch -a or -v, to list branches |
| 23:30 | <jgraham> | git checkout -b all_hixie_changes origin/master |
| 23:30 | <jgraham> | Just git branch in this case |
| 23:31 | <caitp> | ah I guess branch on its own does list them, without remotes |
| 23:31 | <jgraham> | (the second argument to git checkout means that the branch starts off at origin/master) |
| 23:31 | <jgraham> | And then for each branch that you have created |
| 23:31 | <jgraham> | git cherry-pick my_other_branch_name |
| 23:32 | <jgraham> | Which will take the topmost commit from the other branch and put it onto your combined branch |
| 23:32 | <Hixie> | cool, thanks |
| 23:32 | <jgraham> | I am assuming that there is only one commit on each of the other branches |
| 23:32 | <Hixie> | let's assume that for now |
| 23:32 | jgraham | -> slep |
| 23:32 | <jgraham> | *sleep |
| 23:33 | <Hixie> | nn! |
| 23:33 | <jgraham> | Hixie: I strongly recommend reading something that explains the git data model |
| 23:33 | <Hixie> | and thanks for the help |
| 23:33 | <Hixie> | the data model isn't really the source of my confusion |
| 23:33 | <jgraham> | Once you basically understand that everything becomes much simpler |
| 23:33 | <caitp> | the workflow? |
| 23:33 | <Hixie> | i mean, i get the model, it's the just UI for manipulating the model makes no sense to me |
| 23:33 | <caitp> | yeah |
| 23:34 | <jgraham> | My experience is once you understand the data model the manipulation of it makes a lot more sense |
| 23:34 | <Hixie> | you use IDs here, branches there, weird punctuation in the other place, or arguments, all depending on... some black magic logic |
| 23:34 | <Hixie> | i mean why "origin" but "@{u}" ? |
| 23:34 | <jgraham> | http://wildlyinaccurate.com/a-hackers-guide-to-git |
| 23:34 | <Hixie> | instead of @{o} and @{u} or origin and upstream? |
| 23:34 | <jgraham> | Probably not the best guide, but I saw it recently and it |
| 23:35 | <jgraham> | 's not inaccurate |
| 23:35 | <Hixie> | and fundamentally imho it's just over-engineered. but then i don't want distributed version control... |
| 23:36 | <zewt> | i have no idea what @{u} is and i've used git for a couple years now |
| 23:36 | <caitp> | i'm not sure what "@{u}" is supposed to be either, and I'm pretty good with git |
| 23:36 | <zewt> | there are tons of things you just don't need to know in git |
| 23:36 | <Hixie> | that's pretty much the problem |
| 23:36 | <Hixie> | and a pretty clear sign of something being over-engineered |
| 23:37 | <Hixie> | personally i think _svn_ is too complicated |
| 23:37 | <jgraham> | It's really not over-engineered |
| 23:37 | <jgraham> | If anything it's too simple |
| 23:37 | <gsnedders> | Hixie: you can use names of branches as aliases for the commit at the top of the branch |
| 23:37 | <gsnedders> | Hixie: likewise tags |
| 23:37 | <jgraham> | Most of the things that confuse people are because the data model is poking through |
| 23:37 | <zewt> | there are definitely things which are weird and unobvious which suggests questionable design to me |
| 23:37 | <gsnedders> | git's data model is /really, really, really/ simple. And arguably the problems are lack of absractions on it. |
| 23:38 | <caitp> | add, rm, commit, rebase, push, pull, checkout, remote cherry-pick, format-patch, am, log, and maybe rev-parse for scripting, and not necessarily in that order |
| 23:38 | <caitp> | most of those commands are simple and self-explanatory |
| 23:38 | <jgraham> | e.g. origin/master is literally the path .git/refs/origin/master |
| 23:38 | <jgraham> | Which is a file containing a SHA1 |
| 23:38 | <jgraham> | Which points to the head of the origin/master branch |
| 23:39 | <jgraham> | caitp: ref-log is also useful |
| 23:39 | <Hixie> | i just want a remote file system that's versioned |
| 23:39 | <Hixie> | no branches, tags, local repos, etc |
| 23:39 | <zewt> | different workflows need different thing |
| 23:39 | <Hixie> | just a way to commit, a way to diff, a way to revert |
| 23:39 | <jgraham> | Yeah, but that's not what we want in order to share work with you |
| 23:40 | <zewt> | i've never once needed format-patch |
| 23:40 | <Hixie> | i'm not really looking to share work with anyone :-P |
| 23:40 | <jgraham> | Well here you are |
| 23:40 | <jgraham> | But your needs are strange because you usually work alone |
| 23:40 | <caitp> | format-patch made working on mozilla-central from git a lot easier |
| 23:40 | <jgraham> | That is very much the 0.1% case |
| 23:40 | <jgraham> | caitp: moz-git-tools |
| 23:40 | <caitp> | this was from a while back |
| 23:40 | <zewt> | the whole "patch sets to mailing lists" workflow seems pretty terrible to me, heh |
| 23:41 | <jgraham> | Yeah, it is |
| 23:41 | <jgraham> | The whole patches attached to bugzilla workflow is also terrible |
| 23:41 | <zewt> | the #1 biggest thing open source has gained from git is being able to send patches *without* having to send patches |
| 23:41 | <Hixie> | i think people working alone is more like the 99.999% case, but sure |
| 23:41 | <Hixie> | i agree that other people have other needs |
| 23:41 | <caitp> | in some ways, I think bugzilla's model kind of beats rietveld. _. |
| 23:42 | <zewt> | fork github project, make changes in a branch, send a PR, and the whole "sending a patch" thing is invisible--which has lowered the bar for sending patches massively |
| 23:42 | <Hixie> | alright, my tests pass again |
| 23:42 | <Hixie> | excellent |
| 23:42 | <caitp> | horray |
| 23:42 | <Hixie> | jgraham: thanks again, btw, especially for putting up with my whining |
| 23:42 | <jgraham> | zewt: Yeah, it's pretty amazing that forms the central value proposition of github |
| 23:43 | <jgraham> | Especially when their implementation is so halfassed |
| 23:43 | <gsnedders> | jgraham: thanks for putting up with Hixie's whining so I could go and drink cider |
| 23:43 | <jgraham> | Hixie: np |
| 23:43 | <zewt> | oddly i tend to make a comparison between git and twitter--twitter has essentially zeroed the cost for sending a message to someone else (even if those messages are excessively limited) |
| 23:43 | <Hixie> | gsnedders: https://github.com/html5lib/html5lib-tests/branches |
| 23:44 | <gsnedders> | Hixie: aye, I saw in the backlog |
| 23:44 | <gsnedders> | tomorrow's problem, assuming I don't kill someone and end up in jail during driving lesson :) |
| 23:44 | <jgraham> | gsnedders: I doubt the cider will help</protip> |
| 23:44 | jgraham | really is going to sleep now |
| 23:45 | <Hixie> | gsnedders: roger, good luck |
| 23:45 | <TabAtkins> | Ooh, yeah, "Hacker's Guide to Git" works quite well as an explanation of the data model. |
| 23:45 | <gsnedders> | jgraham: I'm pretty sure I can cope with one bottle ten hours before. |
| 23:46 | <zewt> | git is one of those things that you sort of have to both 1: read a bunch and then 2: suck up and use it for a couple months to get past the curve |
| 23:46 | <zewt> | which isn't an indicator of great design, but worth it in its case |
| 23:48 | <TabAtkins> | I think it's easier if you didn't learn a previous VCS. |
| 23:49 | <TabAtkins> | But yeah, intuitively getting what commits/tags/branches represent, and how they're different from files and folders, is a little hard. |
| 23:49 | <zewt> | rebasing can be a bit tricky too |
| 23:49 | <gsnedders> | most of git makes sense if you understand the underlying model |
| 23:49 | <TabAtkins> | Super-easy once you understand cherrypicking. |
| 23:49 | <gsnedders> | but only if you understand the underlying model |
| 23:49 | <TabAtkins> | Because rebase is just "automatically cherry-pick everything from the common ancestor to here for me". |
| 23:49 | <zewt> | what helped me a lot was to peek into .git while it was rebasing; once you see a directory with a couple dozen numbered patch files, it's pretty clear what it's doing |
| 23:51 | <zewt> | i guess one of the weaker points is force pushing |
| 23:51 | <zewt> | because explaining it goes like this: "you should never ever ever do this, except when you should" |
| 23:52 | <zewt> | that might be more due to the github pull request model that was layered on top (where you have to force push over the PR branch to update it); in the original linux kernel model maybe there was no normal workflow reason to ever do it |
| 23:53 | <gsnedders> | you should always assume others have cloned your repo and have things based on that branch |
| 23:53 | <gsnedders> | hence getting rid of that is bad |
| 23:55 | <TabAtkins> | What *&is* a good reason to force push? |
| 23:55 | <TabAtkins> | I've never had to do so. |
| 23:56 | <gsnedders> | A good reason? You committed your password to the repo and want to entirely remove it from history. |
| 23:56 | <gsnedders> | However, note anyone who already has a clone still has it |
| 23:57 | <TabAtkins> | Right, you can't amend othe rpeople's histories. |
| 23:57 | <gsnedders> | The typical case in the GitHub case is when rebasing a PR |
