WEBVTT 00:00.000 --> 00:09.480 Next, we are going to talk about Mademell and Interup with Erie. 00:09.480 --> 00:14.600 So no more French accent, it's going to be a part of the music. 00:14.600 --> 00:20.000 So welcome, thank you all for being here today, my name is Erie, and I work at the web 00:20.000 --> 00:22.400 platform team at Igalia. 00:22.400 --> 00:29.280 So for those who don't know yet, Igalia is an open source consultancy, which started in 00:29.280 --> 00:32.960 Galicia, a beautiful region in Spain. 00:32.960 --> 00:39.920 We are working on company with a flat structure and great people all over the world. 00:39.920 --> 00:44.480 We do a lot of things, but today we're going to focus on the first one, since I'm going 00:44.480 --> 00:49.840 to talk about how we made Mademell Interup Erie. 00:49.840 --> 00:51.320 So what is Mademell? 00:51.320 --> 00:54.840 Don't worry, you don't need to know it from before. 00:54.840 --> 01:01.320 Similar to HTML or XML, it's a markup language, but for mathematics. 01:01.320 --> 01:09.720 So it was first published in 1998, the same CSS for me, but we're now at version 3, 01:09.720 --> 01:18.040 which is a W3C standard that is recommended in a recommendation, and it is used in many 01:18.120 --> 01:24.920 applications with young browsers, like ebook readers or office streets. 01:24.920 --> 01:30.640 So here we have a very simple example of how writing an Intrural Anifraxion 01:30.640 --> 01:31.640 good look. 01:31.640 --> 01:40.280 You see that the syntax is similar to how HTML or website would work, but we have operators 01:40.280 --> 01:43.800 and so on. 01:43.880 --> 01:49.720 So let's do our brief history, work up very, very brief, but as I said, it was first published 01:49.720 --> 01:55.880 in 1998, and it's 3 years later, Mademell version 2 followed, around the time Masilla 01:55.880 --> 02:01.320 was the first to implement it, and it's still like that for a few years, until the next 02:01.320 --> 02:08.040 rows are opera, which nothing had its own engine implemented in 2007. 02:08.040 --> 02:15.480 The big milestone was when HTML5 came, it included Mathemell as well as other things as 02:15.480 --> 02:21.720 a web standard, and from there WebKit also implemented the version that we're currently 02:21.720 --> 02:29.480 on landed, and the last one to the party was Chromium in 2012, but this only lasted for a 02:29.480 --> 02:33.400 year because it was removed, so what happened? 02:34.360 --> 02:40.200 The thing is that Mathemell 3 is a very, very complex standard, it features more than 200 02:40.200 --> 02:46.840 elements, very difficult rules, so it is intended to be a complete representation of mathematics, 02:46.840 --> 02:53.000 but this is not really physical to implement in practice, especially in a moving target, 02:53.000 --> 03:00.120 like the web, so as such, like the behavior was inconsistent across engines, and the code 03:00.120 --> 03:06.680 was very difficult to maintain, a lot of depth accumulated, so almost a decade passed, 03:06.680 --> 03:14.120 because before we had a proposal, which is Mathemell Core, it is a subset of Mathemell 3, 03:14.120 --> 03:22.680 a much smaller subset, but it is tailored for browser implementations, so instead of like having 03:22.680 --> 03:29.320 everything, they look at what is used in practice, and how we can have like the important things, 03:29.880 --> 03:36.760 and then mix in implementation details from text, and open type, and also try to reuse the things 03:36.760 --> 03:44.520 that exist in browsers, as much as possible, like CSS, and also it has a lot of tests, which is good. 03:45.480 --> 03:56.360 So, thanks to this, Chromium got back in the Mathemell 3, and in 2003, so now we are in a great 03:56.360 --> 04:03.480 position, because for the first time in forever, all three major browser engines, except several, 04:05.480 --> 04:13.480 have Mathemell support, and so like finally you can write a web page or write a thing 04:13.560 --> 04:18.600 using Mathemell, and users will be able to see it, but the work is still not done, 04:20.440 --> 04:29.480 oh, sorry, just one, another example first, this is a bit more complex, but we can see here that 04:29.480 --> 04:38.040 we can use the features in the browser, just like we would in HTML or other things, we can have 04:38.120 --> 04:49.000 animations, we can have links, we even have events, and we can modify the features, 04:50.680 --> 04:57.880 like the Mathemell features, like we would other other things, so what I was saying is that 04:57.880 --> 05:05.720 what is left, a lot actually, because we need to make sure that all of the browsers agree and follow 05:05.720 --> 05:12.360 the standard, which can be tricky, because for Chromium, it may be easier, because they didn't 05:12.360 --> 05:17.880 have any implementations, so you could write one from scratch, but for other browsers, as we saw, 05:17.880 --> 05:24.760 sometimes there is up to 25 years of legacy code, and code that is being made for one standard, 05:24.760 --> 05:31.240 then the next, and it is complicated, and browsers have very huge and very different code bases, 05:31.720 --> 05:38.280 they are one of the most complicated programs ever, they have, it's not a great metric, 05:38.280 --> 05:44.680 but they have roughly the same amount of lines of code that the Linux kernel, so yeah, it's not 05:44.680 --> 05:52.200 easy, so what we do is there's this project called Interup, which is a cross browser effort 05:53.000 --> 05:59.320 to improve the interoperability of the world, so all browsers can tackle certain features 06:00.040 --> 06:07.560 that are very important, and it's decided between browser vendors, spec writers, developers, 06:08.200 --> 06:13.480 all of them agree on a set of features to tackle each year, which is what was mentioned in the 06:13.480 --> 06:21.960 text before, and this benefits all users, so this year, at the Galiah, we got an agreement 06:22.280 --> 06:29.080 to work on mathematical code with the software and tech fund, which is part of an European agency 06:29.080 --> 06:37.240 that invest on open source infrastructure, so what have we been up to this past few months, 06:39.080 --> 06:45.000 so first we've tackled a few CSS features that mathematical core introduces, 06:45.480 --> 06:53.640 first one is MathF, so if you look here, you can see that the subberscripts and the 06:54.600 --> 06:59.800 inner members of fractions, they get progressively smaller because otherwise they couldn't fit, 06:59.800 --> 07:06.760 if you have a lot of them and formulas get complicated and they couldn't look good, so before 07:06.840 --> 07:13.240 this was a hard-coded set of very complicated rules, but the beauty of mathematical 07:13.240 --> 07:22.040 core is saying, okay we have CSS, we have things we can reuse that, instead of this hard-coding, 07:22.040 --> 07:31.000 we have this rules in the user agent style sheet of each browser, which implement all of that 07:31.000 --> 07:39.560 complex behavior, just from these three rules, and doing it in CSS makes it easy to write 07:39.560 --> 07:46.440 polyfields and to implement new features, there's different things, another example of, sorry, 07:47.960 --> 07:51.960 we also need another piece of the puzzle because font sizes don't change on their own, 07:52.920 --> 08:02.280 so we have this font size math with Chisano 3 word, it is implemented for all math elements, 08:03.480 --> 08:08.440 and what it does is it gets inherited, it works the same as inheriting font size, but 08:09.720 --> 08:18.040 if there's a math depth it will reduce progressively the size too much, the depth, 08:18.520 --> 08:27.800 and also we try to keep compatibility with existing content as much as possible because 08:27.800 --> 08:34.840 there's 25 years of existing content more than 25 years of existing content, so for example there was 08:34.840 --> 08:41.960 this scribblevel attribute which did more or less the same as math depth, and now instead of having 08:41.960 --> 08:46.600 to handle all of that and use the hard-coding rules, we just map it to math depth with 08:46.600 --> 08:51.880 a set of rules, so browsers don't get any more complex and there's no more complementing, 08:51.880 --> 09:00.760 but existing web pages display as better as possible. The other example is math shift, so 09:01.800 --> 09:07.400 I know that it may not be easy to see, but the two on the left is much is a bit lower than 09:07.400 --> 09:15.080 the two on the right, that's because it has to fit inside of the square root, and if it was in the 09:15.080 --> 09:22.520 same height it wouldn't, and especially in a more complex example it would start to look messy, 09:22.520 --> 09:31.640 a text has this concept of cramped which is more or less the same idea. This is also implemented 09:31.640 --> 09:40.360 as CSS property, and we have this user agent style sheet that implements this behavior. 09:41.640 --> 09:50.360 So I'm very happy to say that both math shift and math depth are now usable across every browser 09:50.360 --> 09:59.880 in the latest versions, and enabled by default. So here we have a right-left mirroring, 10:00.520 --> 10:10.120 so okay, make a note for font math fonts, because this is not displaying correctly because of 10:10.120 --> 10:19.480 math fonts, we will come back to that later and internet connection, but what would happen is that 10:19.480 --> 10:25.480 there are some languages that write from a right-to-left and mathematics too, especially the 10:25.480 --> 10:34.360 Arabic mathematical notation, and usually in some cases they use the same Latin and Greek symbols, 10:34.360 --> 10:47.080 but flipped, and we have two cases, so one is where we have rockets or other characters that have 10:47.080 --> 10:55.880 a corresponding inverse, so for example we would change the right bracket to the left bracket in 10:55.880 --> 11:03.960 in the other case, but there are more complex cases like square roots or one we will see next, 11:05.240 --> 11:11.640 where just like changing a character is not possible, so that's called leaf level mirroring, 11:11.720 --> 11:19.720 and here we have an example of what could go wrong, so this is a clockwise counter integral, 11:20.280 --> 11:27.320 the clockwise part is important, so if we just mirror it like we put a mirror and for the other part, 11:27.960 --> 11:34.840 it becomes a counter clockwise integral, which changes the meaning and it's wrong, so there's 11:34.920 --> 11:42.280 an open type font feature called RTLM, so math fonts can provide a different set of symbols, 11:43.160 --> 11:49.160 like in this case the last one, which are mirror but still have the correct meaning, 11:53.080 --> 12:00.520 so all of these is implemented in our browsers except leaf level mirroring in web kit, which we are 12:00.600 --> 12:09.320 working on, and now we go to font families, so math fonts are very important for good rendering 12:10.840 --> 12:17.560 because they have a specific set of symbols and they also have rules for big operators like 12:17.560 --> 12:25.560 integrals or square roots that can grow and have different things inside, and it is very important 12:25.560 --> 12:33.400 to have a font family available, browsers used to have a harco-ded list of these fonts, 12:34.680 --> 12:44.680 but that became, it didn't work for systems, it was ugly to have all of them there, so now we have 12:45.640 --> 12:54.040 a font family math, which is a CSS and a family, and it's the way of saying give me a good 12:54.040 --> 13:02.120 math font whatever it is, so here we have a comparison and the comparison is actually wrong, but 13:02.920 --> 13:09.240 so the first one is using font family math, which in my system it resolves to lapping more 13:09.240 --> 13:17.400 bit of math popular math font, the second one could be using a style font, it was like handwritten 13:17.400 --> 13:24.680 math, which a website would provide, but we can see because we don't have internet, I didn't manage 13:24.680 --> 13:29.720 to get internet connection, it's not loading the font from the website, so because we don't have 13:29.720 --> 13:36.680 font family math, it's not falling back to a proper font, and the last one was intentionally 13:36.680 --> 13:44.680 like that, you can see that for example the integral is not extending all the way down, the font 13:44.680 --> 13:50.600 for the numbers and the font for the letters is different, and it's a best effort, and this is what 13:50.600 --> 13:57.720 happened before in the in the mirroring example, because that only certain font super mirroring, 13:57.720 --> 14:04.840 so I provided a specific one, and since it didn't load, everything was not as it should be, so 14:05.400 --> 14:12.520 font family math is quite important, aligning with a standard not only involves adding features, 14:12.520 --> 14:20.520 but also removing them, as we say we have tons of legacy code, and that legacy code is based on 14:20.520 --> 14:31.000 standards that may no longer be available, so for example, a mathematical three have 200 elements, 14:31.000 --> 14:36.520 but mathematical code only has about 30, so what do we do with the rest, with the ones that 14:37.640 --> 14:45.160 we don't support, for example this M-thensed element, which added the correlations along the other 14:45.160 --> 14:52.440 things, since we want to give some idea of the compatibility before, but we don't have the resources 14:52.440 --> 14:59.800 for everything to make special rules for all of these elements, at least now, what we do is they 14:59.880 --> 15:08.840 render as a name row, which is HTML equivalent of deep, so instead of that fancy thing, 15:08.840 --> 15:13.960 we get the content, which at least is something, this does mean that we can do the same thing as before, 15:13.960 --> 15:20.760 is just we have to combine different building blocks, but existing content at least renders 15:20.840 --> 15:31.000 somewhat good, the other case is math variant, so in formulas, it's used to be a convention 15:31.000 --> 15:38.920 that you write variables in italics, you can see it's slightly slanted, and this is still supported 15:38.920 --> 15:50.680 by MathML Core and done by default on identifiers, however, we now use a text transform for this, 15:50.760 --> 15:59.640 which is nice, but a lot of other cases were previously supported by MathML, like Gothic, 15:59.640 --> 16:08.200 Test, or Mono Space, which it's better for implementation and for everything to just use the correct 16:08.200 --> 16:15.400 unicode code point instead of having all of this complexity, so that's been deprecated, and 16:16.280 --> 16:21.720 the thing with this is that we can just like say, okay, let's remove it from all browsers and 16:21.720 --> 16:27.320 call it a day, because there are websites that still have this thing, so for now, it's a feature 16:27.320 --> 16:36.760 that you can toggle to the Procades, and if you do, it will have the new thing, but we can just 16:36.760 --> 16:45.000 see this, and the final thing is that, not always everything goes to plan, so there are some 16:45.000 --> 16:52.760 things that you have to live with, so for example, there's some staking canryamath by Microsoft, 16:53.480 --> 17:02.040 two of the open type fields are changed, and this wasn't realized until recently, so this 17:02.040 --> 17:08.040 meant that, for example, Office relies on those two fields being changed, but all of the other things 17:08.040 --> 17:18.520 rely on them being the correct thing, and Office is used a lot, so we can, and this has been 17:18.520 --> 17:24.520 a shipping form for years, so we can just say, okay, let's change everything, we need work around, 17:24.520 --> 17:33.480 and there are a few work-arounds like this that we need to do, but instead of having it in every 17:33.480 --> 17:41.480 browser and having to update that code and keep track of it, what we do is, for example, in this 17:41.480 --> 17:48.040 case, we went to hard pass, the text library, this used by all of these browsers, except 17:48.360 --> 17:55.240 the Apple ports of work with, but those don't have canryamath to begin with, and we handle that 17:55.240 --> 18:01.560 case there, so it's in the values, it's a similar thing that text us, for example, so people can 18:01.560 --> 18:08.680 steal, use this font, because it's the default by Windowsystem, and all of these only works, 18:08.680 --> 18:15.240 if there's communication between people making browsers and people writing the specs, so as part 18:15.240 --> 18:22.680 of our work, we also attend like the MathML working group meeting, we investigate and view issues, 18:22.680 --> 18:28.680 we talk with processors, and sometimes we may contributions back to the spec, the latest one is 18:28.680 --> 18:35.720 quite funny, which is adding animations to mass CSS properties, because that's something you can't 18:35.720 --> 18:42.440 do in a book, but you can do in a website, which is good, and I'm really happy to say that all 18:42.440 --> 18:47.480 of the things that we've been talking about, have shipped across, or browsers, except of the 18:47.480 --> 18:54.920 Procating Mathvariant that's there, but we didn't enable it by default to avoid breaking pages yet. 18:56.280 --> 19:05.480 So what's next, we have a few more improvements, there's a handling position elements and float in layout, 19:06.200 --> 19:13.160 we have a B, we operate the dictionary with each operator, it says if it's stretchy, if it's 19:13.160 --> 19:20.760 an accent, and it's been updated and based on different specs, so we have to fix that, and also 19:20.760 --> 19:28.360 a few more changes to stretching spacing, so all of the browsers don't change the layout too much. 19:29.240 --> 19:34.920 So thank you so much for joining, I hope that you'll learn a little bit about mathematics. 19:39.320 --> 19:44.920 Yeah, if you have any questions regarding Open Specification, please don't hesitate to contact us, 19:45.720 --> 19:50.920 and I have one more thing prepared, we can leave it playing while we have the Q&A. 19:51.800 --> 20:07.240 It's a small project, but let me see if I can avoid it, it's there, it's already in a different page here. 20:10.280 --> 20:17.240 But, oh, maybe it's not loading. We can start with the Q&A, and I'll get you a working. 20:17.560 --> 20:23.000 Can I ship MathML to normal web users today? 20:25.000 --> 20:32.040 I think it's in a quite good state to be shipped, the fewer main things that are missing are 20:32.040 --> 20:39.160 like small tweaks and small things, but it is ready, yes. 20:39.640 --> 20:41.640 Thanks. 20:43.320 --> 20:50.360 Yeah, first of all, thanks a lot. I'm from archive, the one with the X, and we have 20:50.360 --> 20:57.080 used MathML Core in our HTML papers, which I was a resounding success, so big thanks to you, 20:57.080 --> 21:03.400 and everyone working on this. It wasn't mentioned clearly, it is an incredible improvement for 21:03.480 --> 21:10.600 accessibility people, being able to get a proper semantic correct read out of mathematical 21:10.600 --> 21:16.680 text from HTML pages, so a big thanks for also all, and contraend you question, yes, it is, 21:16.680 --> 21:23.560 you can ship it, we ship like a million of HTML pages generated from that code, so that 21:23.560 --> 21:27.320 people can actually access. Yeah, thanks a lot. 21:28.120 --> 21:35.480 Yeah, the copy accessibility, it's a real improvement, because you can have the 21:36.520 --> 21:41.720 screen readers say what it's actually there with, and I'll pre-wander you much, you don't get that. 21:42.920 --> 21:52.520 Hi, thanks. I wonder if MathML Core has pseudo elements selectors to further customize certain 21:52.680 --> 22:01.880 elements. How rich is the API, I mean, basically? So, you can, for MathML Core, the elements are 22:03.880 --> 22:10.600 in CSS, you can have the elements selected, like, for example, MO, and so, and you can 22:11.240 --> 22:17.080 use the same selectors that you would use in CSS, or hover, or things. No, but I meant, for example, 22:17.160 --> 22:26.520 for the operators, are there? Yes, each element is a different type of, like, elements of operators, 22:26.520 --> 22:31.800 are MO, for example, and you can select those in CSS, and do all of the things that you could 22:31.800 --> 22:39.400 normally do to style them. And it's actually a lot of the rules in MathML Core are done like that. 22:39.480 --> 22:47.960 They select certain type of elements, and they apply styling to them. And this is only because 22:48.840 --> 22:56.200 you're unlucky to be after the previous presentation, but do you also provide CSS for different 22:56.200 --> 23:06.440 types of media, like TV or printed media, like, books? I'm not sure about that, but MathML, 23:06.600 --> 23:15.720 regular MathML is implemented for books, for PDFs, for everything, and there's an effort to keep 23:15.720 --> 23:22.840 MathML Core and MathML compatible between each other. So, if you bring something, it's going to 23:22.840 --> 23:30.680 be translated to MathML, and it hopefully should work. And you didn't mention Safari? Is it not? 23:31.240 --> 23:40.920 WebKit is Safari for, sorry, WebKit is the Apple ports are Safari, and we also have WebKit for 23:40.920 --> 23:49.240 links. Can you speak on annotation, specifically with the accessibility, and also annotation, 23:49.240 --> 23:58.520 logic, annotation, other forms? So, I'm not sure of the top of my head, but I think annotations 23:58.600 --> 24:04.920 are not rendered by default by MathML, but they do still appear in the render tree. So, 24:04.920 --> 24:13.080 regarding accessibility, they would like be read aloud. Thank you. 24:19.480 --> 24:26.920 Yeah, I'm curious about if you know any issues, when it comes to allowing users to 24:26.920 --> 24:35.080 author content on websites using MathML. So, it uses generated content. Like, as an example, 24:36.120 --> 24:41.000 for HTML, you can't allow users to write script elements for various reasons, hopefully, 24:41.880 --> 24:45.240 but I'm curious, is there any equivalents of that kind of thing? 24:47.960 --> 24:56.760 Again, I would have to check, but I think it's inside of MathML, it's a different context 24:57.400 --> 25:03.400 so it only allows certain elements. You start with the Math tag, and then inside, 25:03.400 --> 25:08.920 you can put the name row or wherever. If you put other tags, it will just read it as a 25:12.200 --> 25:19.080 row and style row, which is one of the things we did. So, I'm not sure if there's like script 25:19.160 --> 25:27.160 support, but I don't think so, but I want to be careful and say that, we would have to take it out. 25:31.160 --> 25:31.880 One last question? 25:37.480 --> 25:43.800 It may be a little bit out of your area, but you mentioned that Sovereign Tech Fund had 25:44.680 --> 25:50.680 funded this. I was wondering if you had any thoughts about how infrastructure projects 25:50.680 --> 25:54.920 like this should be funded versus, you know what I mean? 25:56.600 --> 26:04.280 It is a complicated question, and I think there's going to be a lot of discussion about these 26:04.280 --> 26:12.280 for example in the other rooms. It is tricky, for example, MathML was stuck like this for an 26:12.280 --> 26:21.320 long time, because it's not seen as an immediate necessity, maybe like other projects, 26:21.320 --> 26:28.200 but it is really useful, it is used in a lot of places, so it's good to have funding to be able 26:28.200 --> 26:37.240 to work on projects like this, which may not be like the most appealing at first, but they do have 26:37.240 --> 26:43.560 a lot of funding, line value for accessibility, for cross browser, compatibility, for site 26:43.560 --> 26:50.040 like Wikipedia, that everybody uses, but yeah. Thank you. Well, thank you so much.