| 13:31 | <MikeSmith> | zcorpan: Domenic TabAtkins https://gist.githubusercontent.com/sideshowbarker/8284404/raw/c9157d8f597c3b91f7df23e07197c9627e7c4c66/wpt-anno.png |
| 13:32 | <MikeSmith> | <wpt> output displayed as annotation in the margin |
| 13:32 | <MikeSmith> | like the canisue annotations |
| 13:32 | <MikeSmith> | styles are https://github.com/whatwg/wattsi/blob/014ab4dc3bb6ffc53d8e69887fd27cae7db354be/src/wattsi.pas#L2068 |
| 13:33 | <MikeSmith> | the test filenames have text-overflow: ellipsis, and a title attribute with the testname |
| 13:34 | <MikeSmith> | so if the full filename is truncated/elided in the output, you can hover the text to see the title with the full filename |
| 13:44 | <zcorpan> | MikeSmith: that looks good |
| 13:48 | <MikeSmith> | zcorpan: ok cool |
| 14:26 | <Domenic> | MikeSmith: +1, that looks great and fits well with existing margin stuff we have |
| 14:26 | <MikeSmith> | good good |
| 14:26 | <MikeSmith> | thanks |
| 14:29 | <fserb> | annevk, Domenic, you around? |
| 14:29 | Domenic | waves |
| 14:29 | <fserb> | maybe we could try a quick chat around https://github.com/whatwg/html/pull/3931 ? |
| 14:30 | <fserb> | I feel like we could split the conversation of making the baselines more standard with the current PR. |
| 14:30 | <fserb> | To answer anne's question on how we can solve this in the future. |
| 14:30 | <fserb> | I feel like we'd have to: 1. come up with some definition of what a hanging/ideo baseline look like when the font file doesn't specify it. |
| 14:31 | <fserb> | 2. that definition needs to either point to or match a CSS equivalent definition |
| 14:31 | <fserb> | I've tried doing this in the past, but it's very complicated topic. |
| 14:32 | <fserb> | so basically the current PR could just be self-referential as it is now, and once we fix the bigger issue of spec'ing the baselines, refer to it as: "if the UA returns a hanging baseline, it must follow X" |
| 14:33 | <fserb> | one option to address this in the future is have a fallback system: |
| 14:33 | <fserb> | 1. hanging baseline is the hanging baseline that is provided by the font file |
| 14:33 | <fserb> | 2. if that is not available and a hanging baseline is needed, run the following algorithm: |
| 14:34 | <fserb> | 2a. if the current font contains one of the following characters ...(is IRC unicode friendly?) क.... then the hanging baseline is the smallest ascent of those characters. |
| 14:35 | <fserb> | *ascent = ascend |
| 14:35 | <fserb> | 2b. the hanging baseline is 80% of the em ascend. |
| 14:36 | <fserb> | but again, something like that would make more sense if CSS is also agreeing with it. (They have tried in the past, afaik, to come up with definitions for those baselines but failed to agree) |
| 15:57 | <devsnek> | so for @@asyncIterator on ReadableStream |
| 15:58 | <devsnek> | that last comment in the PR seems to suggest that BYOB streams will also be using DefaultReader |
| 15:58 | <devsnek> | but then why does BYOBReader exist |
| 15:58 | <TimothyGu> | iirc there's no such thing as a "BYOB stream" |
| 15:59 | <devsnek> | there are streams with mode: byob which use ReadableStreamBYOBReader |
| 15:59 | <TimothyGu> | ah |
| 15:59 | <devsnek> | i think |
| 15:59 | <devsnek> | oh no mode is on getReader |
| 16:00 | <devsnek> | ok yeah that makes @@asyncIterator even more annoying |
| 16:12 | <Domenic> | I can't think of any way to use @@asyncIterator for BYOB-reading |
| 16:12 | <Domenic> | It just doesn't really make sense |
| 16:13 | <Domenic> | It's intentional that byte streams can be read either in BYOB mode or default mode |
| 16:13 | <Domenic> | I.e. efficient-but-hard-to-code, vs. not-as-efficient easymode |
| 16:13 | <Domenic> | Saying that for-await-of always does easymode seems fine |
| 16:13 | <Domenic> | If we come up with some magical way to make for-await-of work with BYOB mode that's what we can use .iterator() for. |
| 16:14 | <Domenic> | Let me do a more thorough review now; I've been leaning on ricea and TimothyGu too much. |
| 16:21 | <annevk> | fserb: hey! |
| 16:21 | annevk | reads |
| 16:23 | <annevk> | fserb: that makes sense, but it doesn't resolve textBaseline having seemingly non-baseline values, right? |
| 16:23 | <annevk> | fserb: and we'd probably cannot get rid of those? |
| 16:23 | <annevk> | fserb: I guess if everyone is okay with that seeming mismatch I'm fine; I wish we got a little more input from other implementers at times |
| 16:24 | <annevk> | (other implementers that also have detailed knowledge about these issues, that is) |
| 16:25 | <annevk> | fserb: also, I'm very much in favor of trying to find shared primitives between CSS, <canvas>, and SVG |
| 16:25 | <annevk> | fserb: I kinda wish we also had one definition for paths, gradients, etc. |
| 16:33 | <fserb> | yeah, I agree. |
| 16:33 | <fserb> | what do you mean by textBaseline having non-baseline values? |
| 16:34 | <annevk> | fserb: top/middle/bottom are based on the em-stuff you said were not baselines |
| 16:36 | <fserb> | well, but that's fine. |
| 16:36 | <fserb> | ok, let me recap that. |
| 16:37 | <fserb> | emAscend emDescent are not baseline, they are just font measurements. |
| 16:37 | <fserb> | textBaseline defined top/middle/bottom based on them, which is totally ok. |
| 16:38 | <fserb> | There's no explicit need for "getBaseline()" to return top/middle/bottom because they are not usually special properties of a font, and are ALWAYS defined in terms of the em. |
| 16:38 | <fserb> | (i.e., one can always calculate what top/middle/bottom is given the info on TextMetric) |
| 16:39 | <fserb> | the reason for getBaselines() to exist, is because there are font SPECIFIC baselines, that can't be constructed out of the other metrics. |
| 16:39 | <fserb> | which is the case of hanging/ideographic baselines. |
| 16:39 | <annevk> | fserb: if it's about fonts, shouldn't it be some other API, since multiple fonts could be used here? |
| 16:40 | <fserb> | for the baselines, you mean? Well, in theory yeah. In practice, the fallback font system of the browsers (that defines which font to use for each glyph) behaves like it's a single font. |
| 16:41 | <fserb> | so it is useful for the UA to say "if I'm rendering those two characters, in the font that you asked, I'm actually using different fonts but deciding on a common baseline for both of them" |
| 16:41 | <fserb> | so yeah, it could be thought as a property of the font itself. |
| 16:41 | <fserb> | but in practice, there's value in asking "for this sequence of glyphs, what's the baseline that you used" |
| 16:42 | <fserb> | bc the UA can be smart about it and return a meaningful value for multiple fonts together |
| 16:42 | <annevk> | ok |
| 16:42 | <annevk> | and is the only reason we're turning this into a method because they are optional? |
| 16:43 | <annevk> | it seems we could also make them return -1 / null / undefined or some such |
| 16:43 | <annevk> | oh wait, I guess that was to match the API style |
| 16:43 | <annevk> | ok |
| 16:44 | <annevk> | fserb: I'll push some style nits to the PR |
| 16:44 | <fserb> | awesome! :) |
| 16:44 | <annevk> | fserb: thanks for taking the time to discuss this, I feel a bit more reassured |
| 16:45 | <fserb> | no stress. If there are more questions, I'd gladly answer :) |
| 16:55 | <devsnek> | Domenic: you gotta tell people before you're gonna push :( |
| 16:55 | <devsnek> | merge conflicts aaa |
| 16:55 | <Domenic> | I did! |
| 16:55 | <Domenic> | " I'll upload a patch fixing all of these as I go, as penance for the long turnaround times so far." |
| 16:56 | <devsnek> | oh |
| 16:56 | <devsnek> | my bad :P |
| 16:56 | <devsnek> | lol did you just fix all of them |
| 16:56 | <Domenic> | Yeah the little ones |
| 16:56 | <Domenic> | Writing up a comment on what the big things left are |
| 16:57 | <annevk> | Fixing nits is Domenic and I's day job now |
| 16:58 | <devsnek> | Domenic: the whole point of the AsyncIteratorPrototype inheritance is the @@asyncIterator return this property lol |
| 16:58 | <Domenic> | devsnek: ahhh right OK, nice |
| 16:58 | <devsnek> | thats actually the only thing it provides |
| 17:00 | <devsnek> | Domenic: also was gonna comment about the ObjectCreate thing, we don't do ! anywhere else when we call it |
| 17:01 | <Domenic> | Oh hrm |
| 17:01 | <Domenic> | We should.. |
| 17:01 | <devsnek> | 262 doesn't prefix it with anything either |
| 17:01 | <devsnek> | i don't think there's any situation where it can fail |
| 17:02 | <devsnek> | (and while i disagree with the idea that doesn't fail means no prefix, i think consistency wins here) |
| 17:02 | <Domenic> | Yeah, I prefer prefixing things like that, and thought we'd done that so far in streams |
| 17:22 | <Domenic> | TabAtkins: can you help me figure out why https://github.com/whatwg/streams/blob/5d9498e7526d2f50618432e7aada8582d08745c0/index.bs#L521 works but if I add `attribute` to https://github.com/whatwg/streams/blob/5d9498e7526d2f50618432e7aada8582d08745c0/index.bs#L540 it fails? |
| 17:27 | <Domenic> | I guess it has to do with `fillAttributeInfoSpans` in Bikeshed but I can't see what that's useful for |
| 17:29 | <annevk> | FYI: I won't be working tomorrow |
| 17:29 | <Domenic> | I'll file a bug I guess |
| 17:29 | <annevk> | And I guess next week things might be a bit slower than usual as well, but anything urgent can be done |
| 18:13 | <TabAtkins> | Domenic: As you probably saw in GH email just now, I opened up https://github.com/tabatkins/bikeshed/issues/1346 to figure out what exactly raw-JS needs for Bikeshed dfn types. Trying to shoehorn raw JS into the IDL types is not going to work (and it's already causing problems even in the limited sense you're currently using it, with two specs both plausibly claiming to be the definition of Stream). |
| 18:19 | <Domenic> | TabAtkins: thanks, that'll be good. I think the attribute vs method thing is more limited though... |
| 18:20 | <Domenic> | TabAtkins in particular why does method work but attribute fail. |
| 18:21 | <Domenic> | TabAtkins in particular why does method work but attribute fail. |
| 18:30 | <TabAtkins> | The attribute fails because I'm looking for information that the IDL block would contain. I don't have the same feature for methods. |
| 18:31 | <TabAtkins> | So it happens that a JS class and its methods look sufficiently close to IDL interfaces and methods that you can use those types and be mostly okay. |
| 18:31 | <TabAtkins> | Until you get to Symbol-named properties, etc., as you found. ^_^ |
| 18:31 | <Domenic> | Hmm what feature is this for IDL attributes? |
| 18:39 | <TabAtkins> | Try it and see. ^_^ It fills in information about the attribute's type, its default value, and whether its' readonly or nullable. |
| 18:39 | <TabAtkins> | Does the same for dict-member definitions. |
| 18:39 | <Domenic> | Yeah I tried to find a spec that uses it but couldn't |
| 18:40 | <TabAtkins> | https://drafts.csswg.org/css-font-loading/#dom-fontface-status |
| 18:40 | <TabAtkins> | That's probably because it's, uh, not documented. |
| 18:40 | <TabAtkins> | Which I should fix. |
