 Hello. Hello, everybody. Welcome. It was explained to me that apparently people are interested in this in development wiki font. So here we are. Basically, to preface this a bit, a few months ago we were working on getting some icons in flow. We were already there, but for the most part we were using SVGs. Now, when I came along, one of the main issues that we were experiencing was a lack of support for Internet Explorer. The older versions, really. And the icons just didn't scale at all. And to implement any sort of scaling for that would have involved having to use PNGs which are converted automatically from the SVGs. But it gets a lot more complex than that and it just basically made it a nightmare and our CSS would have gotten quite bloated from having to load all these different data URIs and remote URLs. So it eventually came to be that we would create an icon set. Basically, glyph icons. And the primary inspiration for this was Twitter's bootstrap which has a pretty good icon set. We even used that for a while while we were developing our new version of flow as an interim solution. So we did that, but then May over the course of one random weekend basically just kind of implemented a bunch of them made a whole glyph icon set and we've been using that since. It's been iterated upon. And the end goal is to make it fairly robust and try to meet as many of the needs as possible for everybody at the foundation and media weekend users in general. So that's where we're at now. It's still a work in progress, so keep that in mind as we do explain this to you. So I mean, what I'd like to go through with you guys is to give you a quick rundown of what it looks like and how you can use it. And we'll also talk about how you guys can get involved in requesting icons that you might need for your project and how you could submit your own icon you need to. And May will be covering those topics. I'll be covering more of the technical aspect of this. So what I'll do with you guys now is I'm going to share my screen. Let's see if I can hold that up for you. Oh, God. No. Let's take a look. So currently WikiFont is up on GitHub at this point in time. Under one May's account, WikiFont, you might be a little confused as to why it's called WikiFont. I was too for a while. Essentially right now what we have is WikiFont glyphs, which is a subset of an eventual WikiFont. I think May's goal at some point is to develop the entire font. But at this point, the beginning part of it is just the glyph icon set. So that's what you'll have access to at this point in time. So this is where you would put any issues that you have with this, pull requests, whatever else you need to do. And it's quite in development. And this is basically the current set of icons. It might be a little bit more expansive than this. I think there's a few more that aren't listed here. But in general, this is what we have so far. And more will be added. You'll see there's even a few icons that can be layered and will cover layering icons in a bit as well. But essentially this is what you have. And if you find, I think this should meet a lot of needs, especially these first few right here. But beyond this, there will definitely be more icons that need to come out. And I know even on Flow, we do have a few more icons in the pipeline that we're going to be needing. Now let's take a look at this CSS. Basically what we do is we determine font face, which is just the glyph icon set. And then we create a base class, which is WikiGlyph. And this just puts on that font and then sets some very basic styles on it, so that it always looks crisp. And then there's a bunch of these individual class names that actually implement the icons themselves. So I mean, the way you would use this, in the instance that you wanted to use a flag, you would create, say, a span, for example, and then name the span's class as WikiGlyph. And then a second class, which is WikiGlyph flag, that would essentially assign the font and all the other styles that goes along with it, and then insert the actual icon itself. Now what this would do is this would work for pretty much most browsers. However, it wouldn't work for IE6 and 7 because they lack support for this selector. However, should we actually need support for IE6 and 7, we could easily drop in a CSS rule that does it with basically CSS JavaScript and only for IE6 and 7. So I mean, it's a small performance hit, but not a huge one, given that it doesn't need to be super dynamic. So if you had a question whether or not to support IE6 and 7, it could and at some point the goal is for it to actually follow. But right now, it's not really concerned for us because we're not really using it anywhere that really mandates IE6 and 7 support in that regard. So this is what it looks like right now in use. We're using a few icons here and that's kind of all over the place. Now, the nice thing about this is you'll notice we actually color our icons. They're all differently colored here. And this is something that, you know, you couldn't easily do with SVGs or PNGs without having to have multiple images. I think this is probably the biggest benefit to it, even that we can actually put context-aware colors that match the text that goes along with it. And in some scenarios, like this icon, we could just invert it and there's even a little drop shadow there. So I mean, this goes a long, long way in our design work because I mean, you literally drop in the font and then you put your icon in and you're done. There's really nothing else to do. It inherits whatever color you need, whatever drop shadows, whatever else it is that you need and it's just there. As opposed to before where we would have had to have multiple variants of an individual icon, drop those into the CSS, you know, it would reduce a lot of flexibility that we had in these scenarios. And here it's just in line. It's already the correct blind height. It just matches. So I mean, there's really not much to say about it. It's really, really straightforward and the usage is incredibly simple. If we take a look at this, that's really all it is for that little edit icon right here. There's your span with the wiki glyph pencil and then edit, that's it. That's really all that we need to do for that. And as far as this goes, you can basically drop this into anywhere you need and start using it. Currently, we are doing so in flow. So if we take a look here, we've dropped this into our CSS for the flow extension. Maybe I'll increase my font size a bit if it wants to. Feel free, I guess not. Well, it doesn't seem to want to increase my font size. Let's pretend it did. So that's basically it. We dropped it into this interactive dotless file that we have in flow, and this gives us our glyphs and we can use it anywhere in our templates. We've modified it slightly on flow because we wanted to have larger icons by default. But other than that, it's really all it is. I don't really have much else to say. Does anybody have any questions about the technical side of this? So one question I got before for some reason here, couldn't be here today, was that they use the current SVGs and sometimes raster images as backgrounds, like they specified as a background with an element, and they were curious to know whether that was going to be possible with the wiki fonts. It's possible. You would have to do it in a strange way where basically the content of the element itself would be the icon, and then you just have to give it, I guess, a large font size. But I mean, it wouldn't work quite as well as an image in that instance. Browser support for that type of sizing of an element that's text like this wouldn't really work so well. I'm not entirely sure how we could go about doing that, and I personally wouldn't recommend it. If you want to use a background, then you should probably just use a background for that. But I'm not entirely sure what the context is, so it varies. If you had, say, a reasonably large version of one of these icons in the side that's just kind of faded out, it's doable. If you wanted a full-size background that scales to the exact size of your element, no, that's a lot more complicated to do and really wouldn't be possible with a font. Does that answer your question? I will get back to them. The question from IRC is, is it possible to show this in quick-fiddle or something? In quick-fiddle? That sounds like two things. I don't know what that is. What is quick-fiddle? I don't know. You're shooting the messenger. I think I'm in the wrong chat room. The person who will listen to the question will know eventually. So the very question, hang on a chat, by the way, about RTL. Yeah. Amir has RTL questions. Sorry? If we can ask questions in the IRC channel just to keep it clean, that would be awesome, but there are questions in the chat too. Those of you in the media... Those of you in the hangout, I'm still free just to ask. Yeah, okay. So what are the questions? What's the channel? I'm not in it. It's your IRN. It's a chat of the hangout. Oh, it's the chat of the hangout. God. Sorry, guys. Take four questions to the side. Okay. Middle East rules. Thanks, Amir. How will RTL work? So RTL is... I haven't really... We haven't implemented anything with regards to RTL. For the most part, the icons should be fine and they will render somewhat fine, but the issue specifically would be that some of the icons actually need to be flipped and that's doable with the CSS. Essentially, all it would be is a separate selector in the scenario where an element or the page or anything is actually RTL. We would use a separate selector that overrides the previous one and uses a flipped icon to that solve your issue. I think there is probably a bit more specific issues in that with regards to RTL. But for most cases, that should solve it. That will probably kind of work. It's a bit of a regression from the way it works now where you can put bash LTR in the file name and CSS Genes will automatically make it bash RTL if you're viewing an RTL language. Yeah. It should be fine, I mean for the most part, because this is all done in CSS as opposed to directly with the files themselves. So the only thing that kind of sucks about that is we would have to create the extra glyph that's flipped. We already have to do that, that's not the concern. Oh, alright then. Then I guess we're good? Wait, so maybe I'm trying to take some notes, but I don't follow. If the whole point is to have a single glyph that's flipped with code, why would we have a second flipped glyph? It's not flipped, he misspoke. You have to have two separate glyphs the CSS selector that chooses what icon is just going to choose one or the other symbol. Oh, I'm saying why wouldn't we flip the character in code? It's not possible. Transport? I think it is possible, actually. I've seen it in use. Yeah, using CSS transforms which aren't going to work. Yeah, CSS transforms won't work in this scenario because the glyph would be more complex than just flipping it. When I say flip, I mean we'll have to create an extra glyph that's visually flipped but the icon could be different in an RTL scenario. There could be even very specific language, specific icon overrides that might need to be made. So do what you will with that information. Any other questions? I see this I mean, you know Github's been doing this for a long time. I think there's a lot of really cool things about the technology but CSS is like a major barrier to contribution because right now we have very, very low cost to sending icons from like a huge number of sources. Extensions, core software, skins and this is sort of making this huge model with or if extensions or skins or core have separate files now we're forced to load them separately which you're adding like a lot of extra requests whereas we used to be able to embed things on the fly into the CSS where we're already loading which is combined with JavaScript so like bare minimum you're adding one request and likely you're adding a lot more but I think more problematically that this is going to require I assume you're probably using like font forge as part of your build process and this is going to require a more complicated build process and it's going to like make it a lot more complex when we're trying to like get contribution from a variety of sources Right What's your what's the plan with that? I mean right now essentially what this is for the most part is one a proof of concept and two a solution for the flow project the long term goal is for this to become a global tool for the entire media wiki usage on whatever projects you need to and we haven't gotten to the point where we need where we need to figure out what the process will be and how we'll kind of automate this I would envision ideally essentially an automated font build whenever we modify the files if we need to but we're not quite at that point and I don't think we will be for a while I think it's small enough that there's still warrants being built by hand and I'm okay with that I yeah wow okay so I just assumed that you were using something like custom font to build it automatically May is currently building them using which tool it's called font prep I found the thing to get a repository it was made open source recently but it's only available on 64 bit osx there's also a custom font which uses font forge which is available on multiple platforms and is that open source yes it is I'm okay with switching this to a more automated process like I said May kind of started whipping this up over the course of a weekend so I haven't had a chance to really kind of look at changing the technical aspect of building the font in a few weeks or a couple of months down the line I'd be happy to do some work in switching that unless anyone else wants to take it over feel free and I mean it should be too much work automating that given that font and all the SPGs are already available two other questions that came in before this one was around accessibility and specifying alt text and how that will differ from using an image or an SPG and then you were also going to actually talk a bit about stacking so as far as the alt text goes or rather the title what would happen in that scenario is you would still have a separate element which has whatever icon and you can give it a title and we do that here on flow where when you hover over this you have alt text which is edit header there and it applies here too and essentially that's really all there is to it go ahead Sharon is there a way I don't know if there's a way less or something to make that sort of happen automatically I guess you wouldn't the individual user would have to know the edit the edit icon to represent edit title so I guess it can't really be generalized because the specific tool tip isn't just the meaning of the icon the meaning of that context exactly so I mean we can't do it in the less either way and even if we could it wouldn't make sense because like flow is case for example we use one icon in multiple places for different context alright so that's nice as far as stacking goes so what Territor is referring to is the ability to stack these icons now what you'll see here I'm gonna share my screen again here we've got a few glyphs that are actually separate this little lock here there's a little pencil what you could do is take this lock and put it on top of say this user now right now the CSS hasn't been implemented for this but essentially there will be a wrapping class that you would be able to start stacking icons with and the purpose for this would be so that you can layer multiple different icons with different colors so what this would allow you to do is kind of create more colorful icon sets as opposed to a single color that we have now so this has been a limitation of using this type of font as a glyph set but people have gotten around it simply by using multiple icons I think the best case the best example of this that I saw that Jared had sent me was the actual github logo that little tentacle creature I forget what it's called they've built that using entirely with a font set so it's like six or seven layers all separate colors and it looks great and it scales perfectly so that's something that's really available to us in this scenario because once we do have a larger set of icons you could take this male icon and back this on top of it and it would actually look alright because you could have them as separate colors as opposed to having two gray on gray icons which would not really make any sense so I don't have any examples of it in use right now but it's doable I pasted some URLs to some pretty neat examples of the exact same thing but using a different font people want to play with that later it's kind of neat another question from IRC is what would happen in text browsing what happens in text browsers is essentially nothing those browsers have because this is using what is it PUA there's basically a reserved range of font characters and all the glyphs are in that range so those browsers essentially show nothing in this scenario well it's also rendered using CSS which those browsers don't use it doesn't really matter what range you use well I think the concern was more because it still show a tofu character like just a square it's a text browser you don't use CSS you need CSS to play the icon the weird characters inserted with code in the border CSS3 if you're using a text browser it probably doesn't support CSS3 yeah content that's right I'm pretty sure that it doesn't support CSS3 it's not a text browser there's a question in the bug about whether this should be loaded first or not because if it's an external reference then in most browsers there's a flash one style content maybe that was covered before I got in no we haven't covered this I mean we could avoid that I guess by putting a data URI no it's not going to fit in a data URI there's a 2048 limit it's a 2048 limit so yeah I guess that's the downside of it presumably it appears as nothing because it's in this special Unicode block and then when the font loads in suddenly the icon snaps into view yeah honestly at this point I'm not really sure it does make sense to load it first but it does end up blocking further loads until that file gets picked up I don't know I'm not really sure what our solution could be in that scenario I'm open to suggestions no one knows what we should do to avoid a flash one style content the thing is even if we loaded it at the top you're going to end up with so many different ones it's going to like like the perceived performance of the page because you're going to have to block on GRLs that are loading like fonts for every single extension and yeah I would I would suggest not trying to do that well sorry not trying to make sure that the fonts are all loaded before just accept it so I have another question which is kind of about the open source nature of it all I know the get a repository is BSD licensed but I don't seem to get a repository or maybe it's there but I just haven't seen it is like the actual source like the format that you would make most of the pages to the icons in is that in the scg file or is it in some other file that's not in the repo may you can answer that where are the original source files for the glyphs in the scg I assume yes like if you're making a modification to an existing glyph what file would you edit you can take ttf file and unfortunately you can just do that okay so ttf file is the one that you would edit and you would generate the other ones for a ttf file and if you were trying to review that that would sort of change on gear that's your problem which doesn't get up right now well in any code review tool I guess like the point he's making which I share concerns that this is like this current process I believe this can be done in a way that can be more open source friendly and custom font for instance like you can just give it a directory of SVG files that are built for you but like we need to move to that before this is even reasonably viable because it's like not a cloud format is ttf binary yeah oh god yeah that's not gonna be very good um well you have the SVGs which are essentially plain text inside whereas ttf and eotr binary again if you can modify the source in an open format that's not binary you could do it with SVG SVG is open right so that's what I'm saying is we're gonna need to migrate toward that being the build process yeah it makes sense and I'm okay with that I need to look into that I think I'm good sure sure yeah I just you know without that we're gonna end up with like there's a few people who have like the software set up and the expertise to work on it it's gonna be this whole gatekeeping mechanism and there's always gonna be somebody who wants to use font sorry an icon that hasn't been accepted yet or hasn't been like brought into the ecosystem or is like one version of me would be behind or whatever and it's like a total nightmare we're we yeah we need to make sure that it's possible to contribute an icon directly to like the source repository in its source form and then just add it to the build process and they're right yeah I think essentially the SVG would probably be the best step for that we could probably automate this with Grunt or something that would be pretty straightforward I think to add on to the last question about the licensing currently the license is supposed to be BSD however the font files themselves accidentally have CC5SA 3.0 as their license that'll be rectified this week I think May is updating the font files on Friday with some other changes and the license should be fixed at that point as well there is a concern that the commons logo is probably not BSD compatible I have a meeting with legal to discuss the W mark on the commons logo and how we'll handle that okay I've really doubted that W is going to be an issue but the commons logo could pose problems so I mean you let us know what happens there and we'll see whether or not we pull that out in this particular scenario assuming legal does decide that no this does not qualify to stay in this font set for what do you call it wikimedia itself we'll have to create a separate build that includes our own logos in general is this something where if a site wants to reskin or change it or would we say just to make your own copy of wikifont or would we encourage them to make my special wikifont and change CSS rules to point to that I think the majority of use cases will simply be using the font set as is however once we do switch to an automated build process especially if it's as simple as something like grunt or like a little make file then other people can very easily have their own custom sets with their own fonts and it doesn't really conflict because A the font file name would be different and B since we're just depending on class names what this does is even if they were to add their own icons that conflict with an icon in the exact same space as one of our fonts the class name is different and that's all that's important so yeah ideally people would be able to make their own cliffs and have their own little font set and I'm fairly sure that will be the case at the wikimani foundation since we'll want to drop in the various logos that we have which are not in a public license that may be a good segue for me to jump in and show a little bit about how we've used this on the app project thus far because we've had that exact issue come up where there were a few glyphs that weren't quite what we wanted for a particular layout and we've done something a little bit different we've created just a second font where we have some of these supplemental characters yet we're still using the core font and that's allowed us to kind of experiment with these glyphs that may or may not make their way back into the wiki font or option that people can use you can have this and then add your own if that's an approach that's working for your particular project on the screen share right now basically every icon you see on that screen is from a font the wiki font characters are the W and the supplemental characters are the other ones that you're seeing with the exception of the pencil which is defined in CSS if we actually tap on the edit pencil for this particular article those icons that you see at the top are both wiki font and if we make a change to this piece of wiki text you can see how we're able to encode you know change the background color of the right arrow we're actually flipping that encode as well and we can do that in a RTL aware fashion and changing you know the background color to represent a disabled state versus a disabled state is just trivial now and as a result of using wiki font we were able to take a few dozen PNGs and I think their total size exceeded like 150k and we're able to reduce that to because we had to have separate PNGs to all these various states and some of these buttons have many different states that can be in and now that's just a single file that I believe covers around 20k for the entire wiki font some other examples in the app are like if I tap it might be hard to see on the screen share but as I tap on any of these icons like I'm tapping on the W there there's actually a tiny animation that I'm able to run natively and because we're doing this I suppose you'd have similar tricks you could do you know if you're using this in HTML but because we're using native iOSE things here we can do fun little tap animations and things like that if I bring up this secondary menu you'll see a bunch of other font glyphs which this might be changing because we're kind of tweaking this particular menu specifically but those are also wiki font characters and from a code complexity kind of standpoint it's just been very nice we've been able to eliminate entire parts of the code that had previously gone in and automated kind of the process to crank out the SPGs that we needed for all of these various things and it's kind of simplified the objects that now handle those sorts of buttons and button states so it's actually been pretty easy to use let's see we're even probably going to be doing a few stacking related things in the future we're not presently doing anything with that but I could see like if we're displaying an edit pencil for an article that has like a protection status using those icons of layer and coloring say the edit pencil a lighter gray than the lock because if you gray out the lock you know it just maybe starts looking a little confusing and if you can draw more attention to the lock it could be a little clearer we're also able to not only do the sorts of animations that might just pulse but we could do any sort of either directional rotations or just whatever we would need but what's been cool for the apps project is this has kind of given us a nice touchstone that allows our designs to be kind of more consistent with a lot less work presently we're only using this on iOS because there are some compatibility issues with older versions of Android so they're still doing the you know PNG to SVG process there but yeah it's been a really neat tool that maybe we can experiment a little more freely with because the apps are kind of more experimental right now so I think maybe one thing we didn't cover was just an actual example of the stacking and I'll just bring up a page really quick that shows kind of a neat example of that let me switch my share real quick so this is one of those links that I pasted into the chat and it's a little small so let me show them but it's just showing an example of the sorts of things you can do and you can see how a lot of these icons have many colors going on because they're able to stack and change the colors of the individual parts when they do that probably from the apps perspective the thing that's coolest about this is when we get to the point where we're going to do a sprint where we're focusing more on how's the app going to lay out on a tablet we'll be able to increase the size of say the chrome at the top and the bottom and then just pick a larger size for these visual icon elements and because they're you know not raster they're going to scale and they're going to look crisp you know even at that larger size and from a code perspective it's trivial then to manage that so mobile targets you guys use and it doesn't support SVG it goes pretty far back I'm sorry what mobile targets are you guys trying to support that doesn't support SVG well specifically for let's say the native iOS app they don't have a process right now like a built-in object for rendering SVGs and I think they do that kind of for performance reasons perhaps and so if you're going to display an image you create basically a raster version of it or if you really want to do it quote-unquote the right way you do it in core animation or something like that where it's basically allowing you to present vector information in a you know nice way it's like on mobile web like it goes back pretty ancient like well before I signed for it it was still like it was a launch on the clock but I'm going to just ask yeah it's pretty far back just as I got a launch like like what percentage like are you 67%ish I think it's double good two phones easily like yours like there's a lot of the cheaper knock-off phones or a lot of cheaper phones in general and that as a requirement may change as those usage numbers change but I think just for the first version of the rebooted app we said we're going to support like 2.3 yeah that's kind of what we've been doing on the app with it does anyone have any questions about that so May did you want to chat a little bit yeah so on the design side it's also been very easy for us because previously what we had to do was change icons and has been really challenging to let other people know that you know this icon has been iterated on and to update everyone every engineer and every designer that this icon has been changed has been proven very challenging and every single icon that we create new we would have to pass it on to the developer and they would have to convert it to PNG and whatsoever and that was a long process we also had to create each SMG file for any color that we're using so that was a pain too so hopefully this could help streamline that process a little bit and make it so much more easier on both ends so if you have any icons that you guys meet from us in the future you can go to the site on media we can use right here on my screen share so if you go down to icon requests at the bottom of the page you can see that I set up this thing here this is what I can think of that we can start to do for now I'm sure we can come up with better process in the future but for now I think this could be the best place to start that's all for me any other questions shoot if you're on the hangout and you have a question you can just unmute yourself now is there an easy way to get from the picture of the icon to the CSS class I think that's just one giant image they don't yet have an HTML demo which is probably it's not loaded on media well the demo right now is just one big empty image of all the icons or an SMG or whatever but they could probably fairly easily build an original icon demo which is what we have at OUI as well which is just like use every single icon with the tooltip it's like the CSS class or whatever or a description or whatever you generate it for the simple HTML page you slap the CSS on it it just works it better just work it's like your proof that your thing that can work but yeah we found that in OUI development HTML demos like that with explanatory sort of clear labels help a lot in making itself document so I believe we have this demo thing going on right now here it's also on a github it's called demo.html try our make list I believe say eventually something like this would be integrated into the living style guide so it would just be a section of the living style guide that would cover the icon font pretty much this is what I was talking about you might want to increase the font size of the icons whatever I think it's a really really great thing in general some small steps is to try to all these things to make it more automated like if you there's a more automated process you add the icon and automatically that's a demo that would be nice and the part that I was worried about the automation there is the stacking idea with colors I think that the ideal solution to support that would be perhaps for example in the source SVG some kind of naming convention or you add some information to some layers that become separate and then separate things because otherwise I find it a bit hard to imagine which would be the process of adjusting an icon like this that people post in many different places you can probably just have a JSON manifest with the entire directory and build on that that's going to be a lot of information I'm sure we can come up with something reasonable I don't know the accessibility but it's just, I mean I would like us at least to have something in mind before we start creating a lot of these composable elements but it's the both things that later we want to keep track of even if this file just presented say of the icons that save a little lock overlaid nicely and had those kind of groups even if it was just for the purposes of the presentation here yeah yeah so that I can work with them modify them yeah that's a suggestion that's good I've also found the concept I think it's really cool just driving consistency for the desktop web and apps any kind of kind of experiences that we build so one thing that I think would be great is I don't know how we would share the SVGs or the AI file of a lot of group of people we were talking about including the source files in our request but that's I think probably the biggest challenge that we maybe identified today is just how to open that process up and automate it something that I would in an ideal world, something that I would build which I don't know how feasible it is to build with like today's technology is if we had all the I mean we'll probably end up with Rust where we have all the icons we'll have some builds but like that still leaves the problem of like what if you want to add icons to the standard set or whatever if the font build process were fast enough and were quarters of languages that are using using the web you could just do it on the client resource I mean it's probably not very feasible with today's technology but I like want the future to happen that's the font's written in Ruby for instance that's probably great but I mean all they're really doing is interfacing with font forge so I don't know there's a huge difference it's probably you know how we know it's like C is a janitor like C is a janitor it's a simple stream processing library it's easy to port it's like zero lines of code, easy to port to php whatever it's probably not going to be true for like a free font system I like to dream resource loader Node.js that also needs to happen there's also another kind of small element that complicates this when it comes to designing a font glyph you have considerations like with a letter G the part of the G that descends below the line and the part of the letter that might ascend above a certain range and it's not necessarily you can just take an SVG that's trimmed around the elements and instantly create a font glyph there may be some other considerations that are required usually the way it works is it just based on the view box currently with the way it's been set up all of the glyphs are the exact same size like they have the exact same size bounding box and we kind of build all of the glyphs to be within that size currently we're not doing anything where a particular is kind of paying slower or something okay it's not really a line that well with text so it's the extra instance it will actually be fixed after this Friday I'm already fixing it so I think that's the part that when we say this is part of media UI that's the thing that there's still that kind of hand needed if someone submits an icon where it is maybe mathematically centered but not optically centered that's the kind of thing where an automatic process might not catch those kinds of things there's also the potential for us to use combining characters like we could have an icon that automatically overlays on previous pictures instead of having to position that I'm sorry, multi-byte strokes there was something some minutes ago it's using the ligature features of fonts to deal with that but that probably will not allow to have different colors but it could help in also composing elements so it's also something to explore I mean right now like we're a super basic tool layer you could simply use before and after what I mean if you wanted something a bit more complex than just two layers and you'd have to create multiple elements in HTML and then there will be a parent element that kind of stacks them on top of each other without you having to do anything I mean basically the SVGs and PNGs they already have limitations this has limitations as well this is a hack it's a clever hack but at some point the web will have a better way to handle this and just like PNGs you have to replace the SVGs at least for a short time this will replace something else so I think the important thing is so far with the approach is like it's based on CSS classes so like we can adjust the implementation I don't think that in all cases it's going to be enough of an abstraction but it should I think it's a pretty defensible first line of events like giving too deep into having to have all these layers all these crazy things but like this will have limitations like right now because of like visual trends everybody uses monochrome icons but like five years ago we didn't and nobody else did either and once that becomes out of style and like everybody starts using colored icons we're going to be like going crazy trying to figure out how to make these things look color and then we're going to switch back to SVGs so I mean you know I think it's as long as we can keep it abstract enough at the actual at the actual access point level I think we should be in good shape but if we get too crazy with like trying to like maximize I think it's going to be for not so we're going to hurry all the way just a reminder we have five minutes left and so if there's anything else that needs to be covered otherwise we have five minutes we'll have to stop one time I was wondering the flow is using WikiGlyph and the example CSS is using WikiFont or maybe vice versa is that which is the recommended CSS names there is a patch in Garrett that corrects it to the latest version but what is it? WikiFont? The class name is WikiGlyph the font name is WikiFont-Glyph So the thing in GitHub is the way it's the way you want it to be and this was asked a while back on Bugzilla is when will it be available for people to start using in Core? That is a good question it's still in its infancy I wouldn't put it into Core just given that there's a lot of work that needs to be done I would not wager it to be there for at least minimum in another month we still need to figure out any RTL issues there's a lot of things that need to be done before we get to that point so that's where you guys really you guys got to get in touch with May in particular get up on that GitHub page and let us know what your needs are what your requirements are what issues you have with this thing and we'll see what we can do about getting those things out there Can we not use GitHub for this bit of our development isn't on GitHub except for this There's already a patch to putting in Core I get it 1,3,7,8,8,8 we'll eventually move to that I think that has the assets in but maybe not the SVGs and stuff I wanted to get it a bit more cleaned up fix up the string issues and everything before we put it out to Core In the meantime can we just make it a Garrett project that's not Core Yeah I'm okay with that Yeah it was just on GitHub for convenience I guess we'll get in touch with one of the projects over here Alright any other questions concerns arousals Not yet I think we're done Okay thanks everybody