| 05:08 | <domfarolino> | Is there a benefit of using multiple link tags w/ media attributes as opposed to stuffing ALL styles into one file and using @media throughout? My guess is there will be less render blocking CSS since the parser doesn't have to actually parse ALL styles up front (and of course wait for that larger file to download) to display page...is this accurate? |
| 06:43 | <zcorpan> | MikeSmith: hmmm. the script is loading cross-references when selecting some text. is that intentional? |
| 06:44 | <MikeSmith> | zcorpan: nope |
| 06:44 | <MikeSmith> | dunno why it would do that.. |
| 06:45 | <MikeSmith> | but will investigate and fix it |
| 06:45 | <MikeSmith> | but I guess it’s just the event listener |
| 06:46 | <MikeSmith> | I mean, it’s probably not the select but just the click event? |
| 06:46 | <MikeSmith> | which is ignore if you’re clicking on a hyperlink |
| 06:46 | <MikeSmith> | but otherwise do not ignore it seems |
| 06:47 | <MikeSmith> | so I think it will happen every time you click anywhere in a page other than a hyperlink |
| 06:48 | <zcorpan> | MikeSmith: right |
| 06:49 | <MikeSmith> | OK I’ll figure out how to make it not do that and write a patch and PR it |
| 06:54 | <zcorpan> | MikeSmith: i guess the listener should check if e.target or e.target.parentNode or e.target.parentNode.parentNode is a dfn, and none of those are <a> |
| 06:55 | <zcorpan> | (or walk up to <body> maybe) |
| 06:55 | <MikeSmith> | zcorpan: yeah was trying to think of a more elegant way but I guress that will do |
| 06:57 | <zcorpan> | matchesSelector could work but is likely more expensive. but maybe that doesn't matter if it happens on each click |
| 06:59 | <MikeSmith> | well I guess just iterating up to body is simple and fast |
| 07:21 | <nox> | TabAtkins: So regarding our discussion about computed values and serialisation, |
| 07:22 | <nox> | TabAtkins: Does that mean that https://drafts.csswg.org/css-shapes/#basic-shape-computed-values doesn't matter when it comes to serialising these computed values, and that parts that can be omitted should be? |
| 09:23 | <zcorpan> | MikeSmith: i'm looking at html-dfn now |
| 09:24 | <MikeSmith> | ok thanks |
| 09:25 | <MikeSmith> | (sorry I didn’t get teh PR raised earlier; needed to pick up my little one from daycare) |
| 13:36 | <TabAtkins> | nox: Yes |
| 13:37 | <hsivonen> | zcorpan: sorry, I don't know how to fix that with nginx |
| 13:40 | <nox> | TabAtkins: Nice! |
| 15:37 | <astearns> | TabAtkins: is that Shapes section incorrect? |
| 15:38 | <astearns> | or is it just that it's not applicable to serialization? |
| 15:41 | <TabAtkins> | astearns: Not applicable to serialization. |
| 15:42 | <TabAtkins> | It's just normalizing the computed value to have all the information readily available. |
| 15:42 | <TabAtkins> | And then serialization outputs the shortest form of it, which will often omit some of that information. |
| 16:28 | <a-ja> | is there work under way getting link preload with integrity|nonce attribs working with fetch and csp sri for script|style ? |
| 16:55 | <nox> | TabAtkins: And OTOH we serialise to the shortest form for specified basic shapes only because of the spec, right? |
| 16:55 | <TabAtkins> | Because of CSSOM |
| 16:55 | <nox> | TabAtkins: Other properties, by default, should serialise to whatever was in the property rule, just normalising whitespace and whatnot, is that correct? |
| 16:57 | <TabAtkins> | This is for computed values. Specified values should match what was input (modulo whitespace/etc) |
| 16:57 | <nox> | TabAtkins: Except in the case of basic shapes and similar cases, where the spec states how they should be serialised, right? |
| 16:58 | <TabAtkins> | No, it shouldn't be. |
| 16:58 | <TabAtkins> | (Our story isn't too straight here.) |
| 16:59 | <nox> | I would love to be able to just serialise shortest forms all the time, but I guess that's wishful thinking. |
| 17:00 | <TabAtkins> | People depend on specified values equaling what they entered, in general. |
| 17:00 | <nox> | TabAtkins: Adding that this part isn't too clear for now makes a lot of sense, I'm ok with that. |
| 17:00 | <nox> | TabAtkins: Sometimes you state things as if they are crystal clear from the prose in the various specs and it confuses the hell out of me hah. |
| 17:00 | <TabAtkins> | This is only observable by looking at a stylesheet directly or reading .style, of course. |
| 17:00 | <TabAtkins> | Hehe, sorry. |
| 17:01 | <TabAtkins> | My specs aren't golden in this regard either. |
| 17:01 | <nox> | Well, I don't blame you, given how implementing that stuff is a huge task, I don't want to even think about how to specify them. |
| 17:02 | <TabAtkins> | One of my tasks for Typed OM is too define the "shortest form serialization" for every single property. |
| 17:02 | <TabAtkins> | Joy. |
| 17:02 | <nox> | TabAtkins: In Servo we switched a lot of code to use generic types, parameterised for example by a specified or computed length, |
| 17:02 | <nox> | so simpler properties share the same code for serialisation, |
| 17:03 | <nox> | that's why I would like both of them to just serialise the same, but I guess real world won't let me have that. :) |
| 17:03 | <TabAtkins> | Understandable. |
| 17:03 | <TabAtkins> | I'd do it if I could! |
| 17:03 | <nox> | TabAtkins: And the cherry on the cake, |
| 17:04 | <nox> | TabAtkins: I recently implemented #[derive(ToCss)], so we don't even have to write serialisation code anymore for many properties. |
| 17:05 | <nox> | Rust's #[derive(...)] has been damn useful to implement many aspects of the CSS properties, whether a value contains viewport percentages, how to compute values, and serialisation. |
| 17:06 | <TabAtkins> | Interesting! |