The Planet MathML aggregates posts from various blogs that concern MathML. Although it is hosted by W3C, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of W3C.
Design Science will be exhibiting and presenting at the DITA North America Conference in Chicago, April 20-22. If you want to learn the proper way to implement math with your content, this is a great opportunity to meet with the experts.
Plan to see Design Science's Autumn Cuellar and Aaron Guigar present the topic Introducing DITA 1.3's Equation Specialization and Its Star: MathML, on April 21st at 10:20am. In this session they will describe what MathML is and the advantages of using it, its role in DITA 1.3, and the available tools for authoring, display and accessibility of MathML.
Also, stop by our booth in the exhibit hall so we can answer your specific questions and try to help with your project.
If you cannot make the conference, we'll be posting the slides/text on our website after the conference.
We hope to see you in Chicago!
At the Principals of Schools for the Blind (POSB) Math/Science Institute this week in Boston, Neil Soiffer will demonstrate MathPlayer 4 and its ability to read math in Internet Explorer, Firefox, and Microsoft Word. Design Science has been working jointly with Educational Testing Service (ETS) and assisted by some of the country’s leading subject matter experts and developers of assistive technology. With this free tool from Design Science, students with blindness or other visual impairments are able to learn, practice and take math and science tests on a more equal footing with their classroom peers.
If you're able to attend the conference, join us tomorrow at 1:35 PM, when Neil will present MathML to Voiced Math, along with Lois Frankel and Beth Brownstein from ETS. Neil will also be at the Design Science table in the exhibit area today and tomorrow.
Visit the MathPlayer Download page for more information and to download the latest version of MathPlayer, and the test build of NVDA. The initial release works with a test build of the NVDA screen reader to speak and Braille math. We expect to announce MathPlayer support with other assistive technology software products in the coming weeks and months.
Just an afterthought on this. The MathML spec actually enforces one use of data-* in HTML, namely for custom maction types, see http://www.w3.org/Math/draft-spec/mathml.html#chapter3_id.22.214.171.124. Peter. On Tue, Nov 4, 2014 at 3:33 AM, William F Hammond <firstname.lastname@example.org> wrote: > > > <mi jats:foo="bar"> is valid to the MathML3 schema (as long > > as jats: namespace is declared somewhere) it's just that you > > don't want to let attributes with colons in their name > > anywhere near an HTML parser, ... > > I've never thought that xml-namespaces are of much real > value for xml document instances (as opposed to xml > electronic data instances). > > In particular, I've understood the banishment of namespaces > from HTML 5 to represent revulsion toward xml-namespaces of > those who produce documents. > > I think it should be possible to structure the world of HTML > so that automatic generators (from various profiles of LaTeX > or DocBook or ...) to HTML5 can switch easily between the > text/html and the application/xhtml+xml serializations. > This would mean, in particular, not really using > xml-namespaces with the latter serialization, but keeping > within a reasonable framework for validation. Maybe one > could introduce for MathML a value something like html's > "style". For example, instead of <mi jats:foo="bar"> > something like <mi mmdata='ns: jats; foo1: bar1; foo2: > "bar2a bar2b"; foo3: bar3;'> which would, with mmdata added > to the definition of html as an unspecified cdata attribute, > be able to pass html validation. As with css a separate, > less essential, and perhaps not universal, validator could > check mmdata values. > > -- Bill > >
Hi all, The minutes of the Digital Publishing Interest Group Teleconference dated 2015-03-30 are now available at http://www.w3.org/2015/03/30-dpub-minutes.html These public minutes are also linked from the dpub wiki http://www.w3.org/dpub/IG/wiki/Meetings Also find these minutes in a text version following, for your convenience. Best, Thierry Michel ________________________________________ Digital Publishing Interest Group Teleconference 30 Mar 2015 Agenda  https://lists.w3.org/Archives/Public/public-digipub-ig/2015Mar/0049.html See also: IRC log  http://www.w3.org/2015/03/30-dpub-irc Attendees Present Charles LaPierre (clapierre), Tzviya Siegman (Tzviya), Karen Myers (Karen_Myers), Nick Ruffilo (NickRuffilo), Ivan Herman (Ivan), Paul Belfanti (pbelfanti), Thierry Michel (tmichel), Dave Cramer (dauwhe), Brady Duga (duga), Phil Madans (philm), Ayla Stein (Ayla_Stein), Michael Miller (AH_Miller), Peter Krautzberger (pkra), Matt Garrish (mgarrish), Rego Casasnovas (rego). Regrets Tim Cole, Julie Morris, Liza Daly, Alan Stearns, Ben De Meester, Vlad Levantovsky, Markus Gylling (Markus). Chair Tzviya Siegman Scribe Nick Ruffilo Contents * Topics 1. ARIA DPUB Module 2. Packaging use cases 3. NYC f2f reminder 4. MathML * Summary of Action Items __________________________________________________________ <trackbot> Date: 30 March 2015 <ivan> Scribe: Nick i am here, will scribe/call in 5 minutes, finishing up something <ivan> for the time being, there are some issues with zakim:-( <brady_duga> Ivan, I assume that comment was about dialing in. Are you having troubles as well? <ivan> the zakim bot has died:-( <brady_duga> zakim has fallen and canâ€™t get up <Ayla_Stein> D: <brady_duga> I am unable to dial in <ivan> brady, you are not the only one:-( <Ayla_Stein> zakim says no to Monday <ivan> a reboot is happening in the background <ivan> :-( <brady_duga> Aha - working now <tzviya> ivan, brady is on now. Are you able to join? <pkra> reverse-regrets from me -- I could make it after all. Zakim - you shouldn't drink on sundays, it's not wise <scribe> scribenick: NickRuffilo <pkra> dauwhe :-) <tzviya> minutes http://www.w3.org/2015/03/23-dpub-minutes.html  http://www.w3.org/2015/03/23-dpub-minutes.html Tzviya: "Minutes from last week: please comment/review" ... "Minutes approved" <tzviya> https://rawgit.com/w3c/aria/master/aria/dpub.html  https://rawgit.com/w3c/aria/master/aria/dpub.html ARIA DPUB Module Tzviya: "Matt Garish - please walk through the not-yet-working draft of ARIA dpub module" Matt: "The big change is that we've gone through and been tightening up some of the defintions and making them more broad. They were book-centric, but take for granted that people had a book/publishing background, so we cleaned that up." ...: "Make things more broadly understood and for a web audience. Revisited a meaning of the different definitions. Made some minor adjustments to names to remove hyphens, as those may be used for prefixes/namespaces" ... "We also started dropping very domain-specific roles. Assessments terms in the original submission are now removed - they will be handled in another group in the future. Likewise it was noted that without those in there, we'll look to take out others that are too domain specific. Removal doesn't mean they aren't in future plans, but we want to approach the vocab in more holistic terms. " ...: "There are a number of terms that are 'gone' for this original draft, but they aren't forgotten." ... "General structures that are useful in broad ways. Landmarks from epub-now was a roadmap into the document - glossary or index. Aria itself has landmarks which are major structures. Allows users to jump to different sections. Rather than doing something fast-and-simple we've decided to just remove it so that we can figure out what is the best way to solve the issue of landmarks without conflict/confusion with ARIA." ...: "Still a few issues in the ARIA module, glossterm? possibly not necessary as it's covered elsewhere. Some generic naming issue with things like 'help' or 'part' might mean many things to many people, so we're looking for a better term." ... "Subtitle/title we're still looking for a way to help people and use those best. Referrer is the link back from the content/footnote. Referrer isn't exactly the best thing to call it, so we're changing the name to locator. These things are still up for discussion/debate. Ultimately if you can go through the terms/definitions, but if you want to be thorough, please go through the role descriptions and characterstics. Take a look at the super-class roles." ...: "There's another: Required Owned Elements, and Required Context Roles - used in Bibliographies and glossaries. The symantics noted have to occur. Required context role means that an item must have a parent. Glossary must always have a term, but a term may not be part of a glossary..."" ... "Final to look at is the 'Name from' field. Author or content. Means that the author has created a label. You're creating it yourself through an ARIA role. if it's content then it's actually picking up the text-node of the element. A link can use the text of the link, but by-and-large you don't want the entire contents to be picked up - for example, an entire chapter." Tzviya: "first draft mid-april. if you have comments, reach out. Issues are meant to be commented on and the issues need to be resovled." ...: "Feedback VERY welcomed. Looking at the spec might be confusing if you are not familiar with the ARIA docs. if you have questions, please reach out." Bill: "Part issue - You want to get rid of that work. People think a part is a subset of something, but for books, part is a container. So there is a definition conflict." Matt: "Correct - that's what we're working on." Bill: "I think we should not use part. We should have a less-ambiguous term that is a 'group' of chapters" Matt: "Is there a generic ARIA concept for a wrapper?" Tzviya: "We can achieve that through HTML." Bill: "You have to worry about the semantics of the sections. For example units in textbooks" Ivan: "Many readers of the documents will be people who don't know the details of ARIA or what it stands for ( should go to publishers who may not know). Explanations or examples to make clear what the usage of the various of the aria- attributes : why are they there, would be very important." <clapierre> +1 for examples for Publishers ...: "It's more a presentation issue. At the moment the document is very abstract and I miss this gentle introduction for those who are not familiar to accessability or ARIA" ... "Human readable documentation would improve things alot." ... "Second question: if I look at the end/appendix. it talks about XHTML+ARIA DTD and open HTML. HTML 4.1... What happens with HTML5? " Tzviya: "Some of this is written by us, some is generated by PF-Magic. It was generally agreed upon that the PF-magic stuff needs to be worked on. " Ivan: "Until that is properly fix, something in the document should be added about HTML5 - such as 'HTML5 is coming' if you look at this now, you'll get a huge rejection of people who are against XHTML, etc." Matt: "It was picked up from ARIA 1.1, so it needs to be brought up with them, so we don't fall out of line." <tzviya> https://github.com/w3c/aria/blob/master/aria/dpub.html  https://github.com/w3c/aria/blob/master/aria/dpub.html Ivan: "To have something that puts ARIA clearly into the domain of HTML5 - that is a great thing. We also need to ensure all our documents are adapted to HTML5 Tzviya: "There was an update and there was an announcement that they want to release ARIA into HTML5" karen: "Wanted to build on Ivan's comments - we don't want to educate EVERYONE about accessibility, but if there were a couple of points - from different perspectives on the importance of accessibility. Being able to point out some business cases/value proposition that show support for accessibility. Put in the Kudos there for everyone who is committed to this." Tzviya: "Charles - this overlaps with some of the other work we're doing in other groups. I'll send an e-mail and copy matt." Karen: "i'm happy to talk with charles further about that." Ivan: "Another editorial/presentation issue: Something in this document should be said about how these things relate to the current epub-column-type usage, in longterm and the work done in edupub. To relate this to existing work that is going on. Don't want people to be completely worried about what's going on here." <tzviya> http://www.w3.org/TR/role-attribute/  http://www.w3.org/TR/role-attribute/ Bill: "Is the role attribute confined by what is being defined by ARIA, or if a publication can use arbitrary terms within the role attribute. Obviously if we unplug epub type to the role attribute." Tzviya: "ARIA roles are not the only allowed value for roles." Matt: "Semantics in roles, if they aren't understood, it will default to its' base." Bill: "I don't think i'm the only one with that question. Pearson and O'Reilly debated where to put this information. They ended up putting things in 'class' when they could have done it in 'role'." Matt: "You'd want to make sure that you prefix things so that they don't get picked up or confused." Bill: "So, even if you're using role, you'd want to prefix it." <tzviya> http://www.w3.org/dpub/IG/wiki/UseCase_Directory#Packaging_ and_Distribution  http://www.w3.org/dpub/IG/wiki/UseCase_Directory#Packaging_and_Distribution Packaging use cases Tzviya: "Started to put together some use cases for packaging. All the cases don't address the basics but they are packaging requirements required to workflow. Requirements of publishing a journal with a dataset; annotations (which borders on having an annotations requirement) and how peer-review will factor into the publication itself. Share resources - such as CSS files - the publication should be able to tap into those shared-resources and make the streamed download process. If a package contains 12 abstracts, the user should be able to access just the abstracts. In downloading a package, it would be great if the user/agent would recognize what is new content VS existing content, which makes offline reading possible." ...: "I think Matt is planning on adding more basic use-cases for packaging. If you can add additional packaging use-cases, we'll be happy to review them." Ivan: "What is the roadmap with these use-cases? I think the idea would be that we have to see whether these use-cases make it into the use-case collection that Yves was talking about a few weeks ago on packaging." Tzviya: "When we have more use-cases we'll share them with Yves and go from there." Ivan: "So we should share these use-cases on the list and have disucssion." <tzviya> nickRuffilo: is a DRM use case allowed? <tzviya> tzviya: i think it would be OK to explain that allowing a hook for encryption is a good use case Bill: "I'm on a campaign to discuss Rights Metadata within the package. Publishers need to be able to denote rights to specific items within a package. So the big question - how do we associate rights with different components of the package, and how do we get publishers to specify that information." ... "For example - photo metadata could be provided in different items within Charles: "A couple things - under accessibility use cases (which is great) what about discoverability using metadata? Then a few questions on personalization." Tzviya: "Accessibility use-cases have been up for a while, but you're welcome to update/add at any time." Ivan: "The technology that shall not be named/mentioned - it is a use-case that we need to think about and compare with what the technology is. That said, and my impression is - if I look at the current packaging specification, or if I look at this; it is not an issue in the sense that it is a technical problem. Adding a part that is the rigth metadata is a key description of the encryption of the content. All of these things are fairly trivially doable within the packaging. They are use-cases that can possibly be fulfilled by the current packaging. I don't think the goal is to encrypt the package itself, just parts of it. The current spec allows you to do that, as you can add any binary data in any format or any media type" bill: "Sounds like I was conflating two issue - Rights & access information. The other is the actual encryption. we already have font-obfuscation." Tzviya: "Fonts are a big issue that we may have to look at" <tzviya> http://www.idpf.org/epub/previews/  http://www.idpf.org/epub/previews/ NYC f2f reminder tzviya: "Reminder - NYC Face-to-face, please add if you are going <tzviya> http://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_D etails ...: "If there are any specific topics taht you'd like to discuss, please let us know and comment there so we can prepare."  http://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_Details MathML Tzviya: "next week is a European holiday, so no meeting. We will resume on 4/13 <tzviya> 13/4 April 13th, 2015 to be verbose Summary of Action Items [End of minutes] __________________________________________________________ Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log) $Date: 2015/04/21 05:01:52 $ __________________________________________________________  http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm  http://dev.w3.org/cvsweb/2002/scribe/ Scribe.perl diagnostic output [Delete this section before finalizing the minutes.] This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/ scribe/  http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/?GLOSS-TERM/glossterm/ Succeeded: s/different types of the package/different components of the package/ Found Scribe: Nick Found ScribeNick: NickRuffilo WARNING: No "Present: ... " found! Possibly Present: AH_Miller Ayla_Stein Bill_Kasdorf Charles Ivan LJNDaws on Matt NickRuffilo ShaneM astearns bill brady_duga brady_duga_ clapierr e dauwhe david_stroup dkaplan3 dpub https iank joined karen liam mgarris h mihnea_____ pbelfanti phil_m philm pkra plinss rego scribenick tmichel trackbot tzviya You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: Peter Ben Tim Alan Liza Julie Vlad Markus Agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2015M ar/0049.html Found Date: 30 Mar 2015 Guessing minutes URL: http://www.w3.org/2015/03/30-dpub-minutes.html People with action items:  https://lists.w3.org/Archives/Public/public-digipub-ig/2015Mar/0049.html  http://www.w3.org/2015/03/30-dpub-minutes.html WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. [End of scribe.perl diagnostic output]  http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
The full, technicolor and Dolby Stereo version: http://www.w3.org/2015/03/23-dpub-minutes.html The B&W, pedestrian version below: Ivan W3C  http://www.w3.org/ Digital Publishing Interest Group Teleconference 23 Mar 2015 Agenda  http://www.w3.org/mid/5509EBBF.email@example.com See also: IRC log  http://www.w3.org/2015/03/23-dpub-irc Attendees Present Charles LaPierr (clapierre), Tzviya Siegman (Tzviya), Phil Madans (philm), Mike Miller (MikeMiller), Karen Myers (Karen_Myers), Nick Ruffilo (NickRuffilo), Liam Quin (Liam), Vlad Levantovski (Vlad), kwkbtr, Deborah Kaplan (dkaplan3), Brady Duga (duga), Shinyu Murakami (murakami), Ivan Herman (Ivan), Peter Krautzberger (pkra), Bill Kasdorf (Bill_Kasdorf), Liza Daly (Liza), Markus Gylling (Markus), Alan Stearns (astearns), Laura Fowler (lfowler), Paul Belfanti (pbelfanti), Ben De Meester (bjdmeest), Dave Cramer (dauwhe) Regrets Luc, Heather, Thierry, Julie, David_Stroup Chair Tzviya Scribe NickRuffilo Contents * Topics 1. review on CSS fragments 2. Identifiers 3. latinreq 4. action items in tracker 5. plan face-to-face meetings 6. ePub 3.1 call for functionality * Summary of Action Items __________________________________________________________ <trackbot> Date: 23 March 2015 <scribe> scribe:NickRuffilo <scribe> scribenick:NickRuffilo !scribenick:NickRuffilo <tzviya> agenda https://lists.w3.org/Archives/Public/public-digipub-ig/2015 Mar/0022.html  https://lists.w3.org/Archives/Public/public-digipub-ig/2015Mar/0022.html <tzviya> scribenick: NickRuffilo <ivan> Chair: Tzviya Meeting begin! <tzviya> https://lists.w3.org/Archives/Public/public-digipub-ig/2015 Mar/0019.html  https://lists.w3.org/Archives/Public/public-digipub-ig/2015Mar/0019.html Tzviya: "Any comments on the notes from last meeting?" ...: "Minutes approved." review on CSS fragments <tzviya> http://dev.w3.org/csswg/css-break-3/ ...: "Next agenda items - review/comments on CSS fragments from liza and brady."  http://dev.w3.org/csswg/css-break-3/ Brady: "Not sure who has read the spec of css-break - introduces fragmentaners. Covers page-break, column break, fragment break, etc. How that works in various situations, floats, etc. Seems obvious but it's actually alot trickier than it sounds, so it goes into lots of details. I've posted some comments. No responses yet, but I just posted them. Overall spec looks good, tackles difficult area, and would be great to have it implemented." Ivan: "Can you post a link to reply?" Brady: "I'm doing multiple replies, but everything has CSS-BREAK in the title." Ivan: "In the WWW Style mailing list, right?" Brady: "Yes" <astearns> many threads here: https://lists.w3.org/Archives/Public/www-style/2015Mar/  https://lists.w3.org/Archives/Public/www-style/2015Mar/ <ivan> comments on the www-style mailing lis Liza: "I reviewed it in the context of having implemented pagination using web technologies (aka terrible hack using something existing like columns or regions or by hand). For me, the problems I was looking for this to solve - which is solves some and not others - such as how to break up complex object like tables. There are some rules on how to break out tables. What I found is that alot of concept we have at Safari, in which this spec doesn't address, is with placed elements like images, video, and movable blocks. So if you were making print-layout, you would deal with widows, orphans, images by making the page smaller and dealing with those cases individually. Certain kinds of content wouldn't find this solution particularly attractive as it would still wouldn't work wonderfully for highly disjointed content. Images, widows, captions, etc." ...: "This won't solve those issues, but it will solve lots of other complex layouts. Most of publisher content will still not make publishers feel like pagination is a solved problem." Brady: "I agree with that. It does not handle the dynamic reflow you want when dealing with pagination. Unfortunately I don't quite understand how tables break if you're breaking within a table-row. Easy to break within the boundaries, but not sure how a page has multiple page-breaks" Alan: "I believe multiple-page-breaks is trying to address that. The section on parallel flows. Examples may not be sufficient or explicable, so feedback on that would be wonderful. Spec is just on how things are layed out, but nothing on how fragment containers are adjusted. Interesting to see if resizing monolithic elements within a container is possible within break opportunities. It tries to deal with widows/ophans and captions in check. You can have breaks prohibited between paired items. Only issue is when the two items are unable to fit within the unbreaked container." Liza: "Surprised to see lots of examples where the page size varied from page-to-page. It would describe the behavior if the pages were extremely varied different sizes. Only time I would see something like that in real-life publishing is if a page went from portrait to landscape." Alan: "Happens more in magazines when you go from full-page to column-based layouts. Most of CSS assumes you have a particular length to work in." Identifiers <Bill_Kasdorf> https://www.w3.org/dpub/IG/wiki/Task_Forces/identifiers  https://www.w3.org/dpub/IG/wiki/Task_Forces/identifiers Bill: "I can be brief: Thanks to Tzviya and Ivan we've made great leaps forward. The Wiki (link above) has a good group of people signed up, but more are welcome. What Tzviya contributed was a great start on a background section. Earlier, Ivan started to develop a strategy around how we would identify identifiers that are specific to media types. Just use them, don't define them. Secondly identifiers that get you into the package/some place within the package. Please read the Wiki as there is wonderful information in there." ...: "I will see if Tzviya/Ivan have anything to add." Tzviya: "I think we may just want to outline the goal of the TF." Bill: "The overarching goal is identifiers in general for ebup web. Identifying the publication will be messy, so lets first start with identifying fragments. Ideally the outcome is to recommend to the W3C refinements to the existing spec or some other solution that gets us where we need to get. Now we need to identify fragments as that will be important to annotations and other sections of publishing." Tzviya: "Ideally we take an existing spec with no changes, IDEAL world..." <Zakim> liam, you wanted to mention xpointer framework Bill: "Thats the thing we've identified. Noting what is needed and hopefully we find that is already out there and the diffs." Liam: "We have a framework for XML document called XPOINTER where you name a scheme - cfi or xpath, that is probably worth looking at as it provides you the ability to define what you're pointing at and the pointing mechanisms." ...: "People have been doing it for 20 years which is fairly robust to changes/namespaces" Ivan: "In a sense, my view is that XPOINTER is something we should - of course - use as a black box, as well as all the other fragment identifiers for different media types. Because they are there and we should not reinvent the wheel. What is unique is that we have a package and we have to find a way to get into the package. To all the various schemes in the background, only CFI and those that are in the package, are those that are too be reviewed, critisized, etc." ...: "What both do is start with the package, then identify the document within the package. The 2nd step is to go within the document which is in the package. The CSI doesn't do a really good job because they also specify the fragment into the HTML document, which should be left to the XPOINTER. The goal is to get to the document when starting within a package. I have tried to collect the requirements for having such a mechanism. Whether those requirements are the right ones, or if there are others to be looked at, that is something we need to find together. For example: My understanding of CFI is that actually it can go through several documents from the package. From the Package you can get to HTML, then to an object, then to something else. So it hops through steps before getting to a media type, something that the package identifier does not do." ...: "Not sure this is a requirement for the publishing industry or not. If it is, it is something we need for the web packages. CFI doesn't lose any of the fragments. My preferences would be to rely on fragment identifiers." ... "That would be a way for us to focus on what is specific." tzviya: "part of it has to do with how we get inside the package, which is dependent on HOW we structure the package..." Ivan: "Indeed. the CFI and package fragment take a different part simply because the package is different. But they do the same thing." Markus: "Two things. First - when it comes to fragments - we have many simple questions to ask. Given the HTML document that is part of the package. I want to define something that is a text-fragment, is there a way for me to do that today? What are the things we would need to do to allow that? That's pretty straight-forward, but we need to list the requirements but we need to list the stuff that we would want to identify." mgylling: "I wanted to - in terms of ultimate goal - which pertains to fragments, paths, and identifiers, it isn't just about packages. If you look at it from the whitepaper, it shouldn't matter if the package is an archive or exploded and online. If I create a URI, that URI should look the same no matter what the publication is (archive or online) which is an important thing to remember moving forward. If we don't get there, we will end up reinventing things with different syntax, but we've painted ourselves into a corner. We shouldn't have syntax based off a state of the publication." Ivan: "we have to deal with the most specific one - identifying something within one document; The classical fragment issue. Must have a clear idea on what our requirements are on this term. What I'm saying is that we should at least try." <tzviya> me/ hi, dave - still on fragIDs, already did CSS fragments ...: "If it is an xpointer scheme we haven't implemented yet, ok, but we need to reply on it. The fundamental approach should be - whatever possible, rely on existing fragment IDs. This is one end of the spectrum. The other end of the spectrum is identifying a BOOK or a document. Which is about giving an identifier. This is complicated because it isn't a fragment, it's in the Identifier world, which is messy. There is something in between which is a different set of requirements. " Bill: "I thought we were going to have a TF call? Should we have the call, or have the discussion via e-mail?" Tzviya: "Conversation started on the list, then schedule a call." latinreq <tzviya> http://w3c.github.io/dpub-pagination/  http://w3c.github.io/dpub-pagination/ Dave: "update is that there isn't much to update. Where do we go from here? Prince is using it as a blueprint for book products to try to increase the value of that PDF forematter. I would love to add/flesh out more too it, but not sure what I should be adding right now. Contributions/comments are very welcome!" Nick: "What is latinreq?" Dave: "How page layout should be done in western languages. Inspired by JLreq - spec for japanese. What do they do for pagenumbers, running headers, typesetting, line-heights, headings." ...: "Alot of this stuff has not been written down anywhere. Just been the oral traditions of typesetters and composition people. For the web/electronic documents, been trying to write it down." Markus: "What happened with JLReq - it was completed, finalized, then the editors retired. Do you see latinreq as a living rec that will not go that path? Or should we maintain the idea of completeness/final?" <tzviya> http://w3c.github.io/dpub-pagination/  http://w3c.github.io/dpub-pagination/ Dave: "I have no intention of ending things. So I think of it as a living thing. I would like it to keep evolving and getting bigger/better." ... "Edits will ebb/flow, based on the community and people who are willing to help. In this case, I don't want to declare victory and go home. I feel like there is much more." Tzviya: "There were some areas we would hope there would be work with other communities, such as STEM. We might find the results of Peter's survey we might have additional information, such as equations, etc." <pkra> +1 Dave: "We'll take contributions in any forms. Sketches, examples, etc. I'll do the formal writing, but I need feedback/input" Alan: "Liza brought up something with fragmentation spec - how publishing deals with fitting monolithic content into fixed-size page. There might be useful notes in latinreq about how such content fits within it's containers." Tzviya: "Page-break-inside, etc. Sometimes it works, sometimes it doesnt." Alan: "Based on the aspect ratio, the caption could be on the left, right, a different page (the facing page, etc)... Lots of things that happen around the placement of captions relative to images." Tzviya: "Another issue we discussed is tables. Not sure we discussed diagonal headers... Probably a good discussion about offline." ...: "When the header is on an angle, but the body content is normal. Timetables are often done like that." Tzviya: "if you have exmaples of wacky content, Dave can write it up." action items in tracker <ivan> action-21 ? <trackbot> action-21 -- Peter Krautzberger to Publish first draft of stem use cases and pain points summary -- due 2015-02-28 -- OPEN <trackbot> http://www.w3.org/dpub/IG/track/actions/21  http://www.w3.org/dpub/IG/track/actions/21 Peter: "We are deferring this..." tzviya: "We need to prioritize. Peter has too many action items." ...: "Will this come out of the STEM survey?" Peter: "Yes." ... "Survey going out this week, so we'll be able to do this after that." <ivan> action-27? <trackbot> action-27 -- Peter Krautzberger to Compare mathml tables with html, and write it up on a wiki page -- due 2015-03-19 -- OPEN <trackbot> http://www.w3.org/dpub/IG/track/actions/27  http://www.w3.org/dpub/IG/track/actions/27 Peter: "I have done some work, but it hasn't been completed. Can we just push this? I need to do some stuff for the math working group. The STEM survey has my priority." Tzviya: "Do you want to bring this task to the Math working group and have them do this?" Peter: "Yes." <ivan> action-31? <trackbot> action-31 -- Karen Myers to Initiate business use case -- due 2015-01-31 -- OPEN <trackbot> http://www.w3.org/dpub/IG/track/actions/31  http://www.w3.org/dpub/IG/track/actions/31 Tzviya: "We'll change this to 'by the math working group'" <ivan> action-34? <trackbot> action-34 -- Peter Krautzberger to Send stem survey -- due 2015-01-31 -- OPEN <trackbot> http://www.w3.org/dpub/IG/track/actions/34  http://www.w3.org/dpub/IG/track/actions/34 Karen: "Yes. I've made some progress, but please give me 2 weeks. Wnat it by first week in april" <ivan> close action-34 <trackbot> Closed action-34. <ivan> action-42? <trackbot> action-42 -- Ivan Herman to Find someone to review i18n web page -- due 2015-01-15 -- OPEN <trackbot> http://www.w3.org/dpub/IG/track/actions/42  http://www.w3.org/dpub/IG/track/actions/42 <ivan> close action-42 <trackbot> Closed action-42. <ivan> action-43? <trackbot> action-43 -- Tzviya Siegman to Dpub to read i18n documentation from epub perspective for gap analysis -- due 2015-01-31 -- OPEN <trackbot> http://www.w3.org/dpub/IG/track/actions/43  http://www.w3.org/dpub/IG/track/actions/43 <ivan> close action-43 <trackbot> Closed action-43. <ivan> action-44? <trackbot> action-44 -- Markus Gylling to Talk to brady about fleshing out the pagination use cases -- due 2015-01-19 -- OPEN <trackbot> http://www.w3.org/dpub/IG/track/actions/44  http://www.w3.org/dpub/IG/track/actions/44 <ivan> close action-44 <trackbot> Closed action-44. <ivan> action-45? <trackbot> action-45 -- Brady Duga to Add information to personalization use cases -- due 2015-02-16 -- OPEN <trackbot> http://www.w3.org/dpub/IG/track/actions/45  http://www.w3.org/dpub/IG/track/actions/45 <brady_duga> I dropped (deadzone), but I think I still have something to do on 45 <brady_duga> I forgot it existed - sorry <ivan> action-46? <trackbot> action-46 -- Tzviya Siegman to Contact the html wg for a working definition of footnote -- due 2015-02-16 -- OPEN <trackbot> http://www.w3.org/dpub/IG/track/actions/46  http://www.w3.org/dpub/IG/track/actions/46 Tzviya: "Two weeks will be added to give Brady time." <ivan> action-47? <trackbot> action-47 -- Thierry Michel to Create new wiki for identifiers tf -- due 2015-03-02 -- OPEN <trackbot> http://www.w3.org/dpub/IG/track/actions/47  http://www.w3.org/dpub/IG/track/actions/47 <ivan> close action-47 <trackbot> Closed action-47. <ivan> action-48? <trackbot> action-48 -- Peter Krautzberger to Gather font metric info from the mathwg for houdini -- due 2015-03-09 -- OPEN <trackbot> http://www.w3.org/dpub/IG/track/actions/48  http://www.w3.org/dpub/IG/track/actions/48 <pkra> Sorry I dropped off the call. <pkra> This was actually two items. <pkra> a) use case of font metrics for MathJax / MathML polyfilling Tzviya: "Hoping peter can get in touch witht he Match working group" <pkra> b) talk to MathWG about other use cases. <dauwhe> Link for Houdini Font Metrics spec: http://dev.w3.org/houdini/font-metrics-api/  http://dev.w3.org/houdini/font-metrics-api/ <pkra> a) I have started on <pkra> b) I will bring up on the next call with the MathWG. Tzyiva: "Is there anyoen else who can help peter with this?" <tzviya> thanks, Peter - is 4 weeks enoughs? <pkra> tzviya yes, 4 weeks will do it. plan face-to-face meetings <tzviya> https://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_ Details  https://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_Details Tzviya: "we have May meeting scheduled for 26th May, NYC. Please add your information to the wiki to let us know you're coming. We would like to start planning the agenda." ...: "I think we also talked about broader issues, such as packaging." Markus: "Rather than just having reports, which we do on these calls. So bigger topics such as packaging." Tzviya: "Please add your name to the May meeting. If you're in the new york area, please show up. It's the time for IDPF and BEA. Information for hotels is there. Book early." ...: "TPAC? in Sopporo Japan. We are supposed to respond to a questionnaire. Organizers need to know if we're going." <ivan> TPAC: Week of the 26th of October, Sapporo Ivan: "I think the TPAC meeting is a little different than the previous. Going through the TF reports we can do elsewhere. What was very useful in the last one was to talk to a number of other groups. That would be one of the main reasons that having the meeting there would be important, even though I realize not many people will show up. Having our voice heard is important. Other things we should try to do is we have unfortunately only a few people from east-asia in the group and this is a chance for their voices to be heard." <tzviya> http://www.w3.org/2015/11/TPAC/ ...: "Also good to get a japanese/east-asian perspective. We should give a slightly different view on the meeting and try to have it." ... "IETF meeting there as well previous, so Heather may be there as well."  http://www.w3.org/2015/11/TPAC/ ePub 3.1 call for functionality Markus: "In the next 2 months, the IDPF is collecting suggestions for the upcoming epub 3.1 revision. Which will be proposed in May, and kickoff in the summer/end of year. 3.1 is first revision that IDPF is running in the lifetime of Digital Publishing WG and since the relationship and desire for convergence. That said, 3.1 is not the new big epub web, but an increment to the existing." ...: "There is an opportunity, even though it can't be dramatic, to propose features/change requests based on our work. If you're interested in coming up with such proposals/suggestions, feel free to contact me." Ivan: "Typical case - something that may come back to bill - if you take a look at the document that the Metadata group produced, there are very specifically things that we say "The open web platform has the technologies to do this. The DPUB WG may not use these technologies yet. These are the things that may come to this." Summary of Action Items [End of minutes] __________________________________________________________ Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log) $Date: 2015/04/21 05:01:52 $  http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm  http://dev.w3.org/cvsweb/2002/scribe/ ---- Ivan Herman, W3C Digital Publishing Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704
We haven’t done one of these in ages! Here’s our fifth interview with interesting people in the MathJax community. This time we had the pleasure to talk to Moritz Schubotz (Technische Universität Berlin) about math on Wikipedia.
You are the volunteer lead on MediaWiki’s Math Extension. Can you tell us a little bit about the Math Extension?
The Math Extension is the MediaWiki component responsible for rendering mathematical expressions. In order for Wikipedia editors to enter formulae they will need to employ the MediaWiki LaTeX dialect texvc.
The extension offers a lot of options already. What is different about your new work?
The original extension version “Math 1.0,” forced users to select from one of several rendering options and required administrators to configure and install Math extension dependencies, which was rather time consuming. In the latest version “Math 2.0” the new MathML rendering mode provides “robust, scalable, fast, and accessible math rendering for Wikipedia” and also supports private wikis. Furthermore, it no longer requires any configuration by either administrators or users. It uses a new rendering backend, which can be hosted on a different server. In our Mathoid paper, Gabriel Wicke and I explain why this new rendering mode is preferred.
Can you tell us a little bit about your background and the history of the project?
After having completed my Diplom (equivalent to a Master’s degree) in Physics, I started my PhD studies in Computer Science with a focus on Math Search. Since Wikipedia contains most of the Mathematical World Knowledge and the articles are written in a quite uniform, continuously improving language and style, the Wikipedia corpus is a great corpus to test new search and information retrieval methods. Since neither PNG images nor the TeX source are suitable for math search, I changed the math to output MathML as well. As a hobby project, I kept working on the Math Extension, in order to contribute to Wikipedia and transform my research prototype into production software.
The Wikipedia community can be challenging given the different groups involved (Wikimedia Foundation, MediaWiki community, and the Wikipedia editors). What has your experience been like?
First and foremost I have to state that every employee of the Wikimedia Foundation (and its chapters) that I have met have been extremely helpful and friendly. However, the Foundation is a fast growing organization with an extraordinarily huge and heterogeneous community with different interests. While I wish that one employee would be assigned to do code review for the Math Extension once in a while, I have to respect the Funds Dissemination Committee decision not to fund math search related efforts. My volunteer predecessors who tried to take care of the Math Extension before I joined resigned at some point in time since their proposed improvements did not end up in the production system. In contrast to them, I’m in a more comfortable situation to have two individuals, Frédéric Wang and Gabriel Wicke who are enthusiastic about conducting code reviews on a volunteer basis.
How have the responses to the new Math Extension been so far? Any surprises?
No, no surprises. The new rendering looks different, i.e., the specification for spaces and font sizes in MathML (that’s the new output) are slightly different from TeX. That people discuss which version looks better was therefore expected. Furthermore, there are some bugs that have been discovered. But I think this is normal when a new feature is launched on Wikipedia sized websites.
What are your near and long term plans for the future of MediaWiki Math Extension?
The near future plan certainly is to enable the new rendering mode for unregistered visitors as well. Before we can do that some issues need to be resolved. I think there are good chances that this will happen in 2015.
Are there any other projects of yours people should keep an eye on?
There is also the MathSearch Extension, but this is still a research prototype. However, even today this extension indexes all formulae in your wiki, provides a search interface and tries to automatically infer identifier semantics from the surrounding text contents. For those who may be interested, have a look at demo demo.formulasearchengine.com.
Again, I concur with David. After a fix for a crash (MathPlayer 4, public beta 2 will have the fix), I get what David indicated. Neil On Tue, Mar 17, 2015 at 4:07 AM, David Carlisle <firstname.lastname@example.org> wrote: > On 17/03/2015 09:48, Daniel Marques wrote: > > <mstack> > <mscarries><mn location="s">1</mn></mscarries> > <mscarries location="s"><mn>2</mn></mscarries> > <mn>3</mn> > <mn>4</mn> > </mstack> > > > Then, >> >> . >> >> . >> >> 3 >> >> 2 >> >> 1 >> >> 4 >> >> Where the dots ‘.’ are used only to indicate some amount of vertical >> space. >> >> Is that correct? >> >> > > No. the first is unaffected by the location attribute of the second row. > It is positioned _as if_ the second row had location="n". > so it is positioned above the first real row 3 > > % where 2 would have been with location=n > 1 % south of where 2 would have been > 3 % first normal row > 2 % south carries on row 3 > 4 % second normal row > > > > David > > ____________________________________________________________ > ____________________________________________________________ > _____________________________ > > The Numerical Algorithms Group Ltd is a company registered in England and > Wales with company number 1249803. The registered office is: > > Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. > > > > This e-mail has been scanned for all viruses by Microsoft Office 365. > > ____________________________________________________________ > ____________________________________________________________ > ______________________________ >
FYI this particular example was resolved https://bugzilla.mozilla.org/show_bug.cgi?id=1131000 (i.e., Gecko and MathJax align again though further issues have been spotted). Peter. On Wed, Jan 14, 2015 at 12:55 PM, Peter Krautzberger < email@example.com> wrote: > > We could add it to the tracker, even better we could actually do it:-) > > I was hoping the former would help ensure the latter but yes, let's get > started. Where/how should we set it up? (I'd like to finish my other items > before getting into a new one though.) > > Peter. > > > On Wed, Jan 14, 2015 at 12:50 PM, David Carlisle <firstname.lastname@example.org> wrote: > >> On 14/01/2015 11:41, Peter Krautzberger wrote: >> >>> Yes. Can we add this to the WG tracker? >>> >> >> We could add it to the tracker, even better we could actually do it:-) >> >> David >> >> >
On 17/03/2015 09:48, Daniel Marques wrote: <mstack> <mscarries><mn location="s">1</mn></mscarries> <mscarries location="s"><mn>2</mn></mscarries> <mn>3</mn> <mn>4</mn> </mstack> > Then, > > . > > . > > 3 > > 2 > > 1 > > 4 > > Where the dots ‘.’ are used only to indicate some amount of vertical space. > > Is that correct? > No. the first is unaffected by the location attribute of the second row. It is positioned _as if_ the second row had location="n". so it is positioned above the first real row 3 % where 2 would have been with location=n 1 % south of where 2 would have been 3 % first normal row 2 % south carries on row 3 4 % second normal row David _____________________________________________________________________________________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ______________________________________________________________________________________________________________________________________________________
Thanks for the responses but we are not done! Assuming that both rows off carries are at south. <mstack><mscarries><mn location="s">1</mn></mscarries><mscarries location="s"><mn>2</mn></mscarries><mn>3</mn><mn>4</mn></mstack> Then, . . 3 2 1 4 Where the dots ‘.’ are used only to indicate some amount of vertical space. Is that correct? In addition, south carries move the rows the necessary amount of vertical space in order to do not overlap (the row with the ‘4’ has been moved two rows below). Do you agree? Dani *From:* email@example.com [mailto:firstname.lastname@example.org] *On Behalf Of *Neil Soiffer *Sent:* lunes, 16 de marzo de 2015 22:14 *To:* David Carlisle *Cc:* email@example.com *Subject:* Re: mstack and south carries I concur with David's reasoning. Neil On Mon, Mar 16, 2015 at 9:12 AM, David Carlisle <firstname.lastname@example.org> wrote: On 16/03/2015 16:02, Daniel Marques wrote: Hi all, The MathML specification allows specifying carries at south positions. In this case, when other rows of carries exists it is not clear how the formula must be rendered. For example, in the following formula <mstack><mscarries><mn>1</mn></mscarries><mscarries location="s"><mn>2</mn></mscarries><mn>3</mn><msline/><msrow/></mstack> What’s is the expected rendering? 1 3 2 Or maybe 1 3 2 ? Dani personal response but the spec says > the first row of carries annotates the second (following) row as if the second row had location="n". so the position of the 1 isn't affected by the fact that the 2 has location=s, it is positioned as if the 2 had location=n so just above where that would have been. But it goes on to say > This means that the second row, even if it does not draw, visually uses some (undefined by this specification) amount of space when displayed. so the exact amount of space below the 1 is implementation defined. David _____________________________________________________________________________________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ______________________________________________________________________________________________________________________________________________________
I concur with David's reasoning. Neil On Mon, Mar 16, 2015 at 9:12 AM, David Carlisle <email@example.com> wrote: > On 16/03/2015 16:02, Daniel Marques wrote: > >> Hi all, >> >> The MathML specification allows specifying carries at south positions. >> In this case, when other rows of carries exists it is not clear how the >> formula must be rendered. >> >> For example, in the following formula >> >> <mstack><mscarries><mn>1</mn></mscarries><mscarries >> location="s"><mn>2</mn></mscarries><mn>3</mn><msline/><msrow/></mstack> >> >> What’s is the expected rendering? >> >> 1 >> >> 3 >> >> 2 >> >> Or maybe >> >> 1 >> >> 3 >> >> 2 >> >> ? >> >> Dani >> >> > personal response but the spec says > > > the first row of carries annotates the second (following) row as if > the second row had location="n". > > so the position of the 1 isn't affected by the fact that the 2 has > location=s, it is positioned as if the 2 had location=n so just above > where that would have been. > > But it goes on to say > > > This means that the second row, even if it does not draw, visually > uses some (undefined by this specification) amount of space when displayed. > > so the exact amount of space below the 1 is implementation defined. > > David > > > ____________________________________________________________ > ____________________________________________________________ > _____________________________ > > The Numerical Algorithms Group Ltd is a company registered in England and > Wales with company number 1249803. The registered office is: > > Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. > > > > This e-mail has been scanned for all viruses by Microsoft Office 365. > > ____________________________________________________________ > ____________________________________________________________ > ______________________________ > >
> Could you post the specific regression you ran into? Specifically this was around platform development. Let's say I have my developers (those that use my platform) all define their templates in <template/> tags. This is used for all components, including components that are partials or are "composable"... One specific example is this: <my-graph domainx="0,100" width="200" domainy="0,100" height="100"> <my-line data="0,1 1,1 2,2 3,3 4,4 ... snip ... 100, 100"></my-line> </my-graph> - the shadow root of `<my-graph>` has an <svg> element that contains it's "content" (which also doesn't work well in SVG). - the shadow root of `<my-line>` has a <path> element. So we'd *hope* that you could define the templates for the above (roughly) as follows: <template id="my-graph"> <svg> <content/> </svg> </template> <template id="my-line"> <path /> </template> This, of course, is broken all over the place. 1. Last I checked (6 months ago), <content/> is an SVGElement, not an HTMLContentElement. 2. template#my-line has a `content` with a single HTMLUnknownElement, meaning trying to use it purely as a document fragment is broken. 3. As the platform author, there is no way for me to know that the developer intends template#my-line to be an SVG fragment so I can at least polyfill a solution for them automatically As a platform author, a namespace attribute would enable me to easily identify the developer's intent so I can polyfill the behavior before the browser even supports it. The idea of having <template> "just work" with SVG without some sort of attribute like this seems like pie in the sky, and worse, it doesn't give me an immediate way to solve the problem other than checking the firstElementChild.tagName of every template and praying developers know the edge cases like <a/>. Even if it's implemented in every browser, the developer would still need to know the edge cases. With an attribute, the developer just needs to know that they're dealing with SVG or not. On Sat, Mar 14, 2015 at 6:04 PM, Austin William Wright <firstname.lastname@example.org> wrote: > > On Thu, Mar 12, 2015 at 4:20 PM, Benjamin Lesh <email@example.com> wrote: > >> For my part, I disagree slightly with this statement. If you just drop a >> <circle> tag in a <div>, you're going to get an HTMLUnknownElement. This is >> by design and to spec, of course. But it unfortunately means you can't >> clone() the element over to an SVG parent and hope it will work.d >> > > Could you post the specific regression you ran into? The behavior you > describe should only true for text/html parsing; it doesn't apply to DOM > and application/xhtml+xml. > > For instance, given an arbitrary, conforming HTML document containing an > SVG circle element, this should work: > > var svgns = 'http://www.w3.org/2000/svg'; > var c = document.getElementsByTagNameNS(svgns, 'circle').cloneNode(); > document.getElementsByTagName('body').appendChild(c); > document.getElementsByTagName('body').lastElementChild.namespaceURI == > svgns; // true > > text/html just isn't cut out for the sort of complex stuff we're > discussing. For instance, what if I want to start using the proposed > application/api-problem+xml format? You can't. text/html simply isn't built > for the complex features being proposed. This is made explicit in HTML5: > > The DOM, the HTML syntax, and the XHTML syntax cannot all represent the > same content. For example, namespaces cannot be represented using the HTML > syntax, but they are supported in the DOM and in the XHTML syntax. > Similarly, documents that use the noscript feature can be represented using > the HTML syntax, but cannot be represented with the DOM or in the XHTML > syntax. Comments that contain the string "-->" can only be represented in > the DOM, not in the HTML and XHTML syntaxes. > > > There's a craptonne of XML based markup languages and file formats out > there. We can't just keep importing all of them into HTML every time we > decide one of them might be useful to embed inside HTML. THERE is a > usability and complexity nightmare. > > Explicit is better than implicit, so I like the idea of a namespace > attribute element, it is forward-compatible with future vocabularies we may > wish to use. > > Namespaces aren't *that* hard to understand. In my code above, I added one > line declaring the namespace (`var svgns`). Is that really so hard? If you > want to use the more advanced features of HTML, use namespaces, or import > whatever vocabulary I want - DocBook, OpenDocument, music notation, XSL, > without worry of collision. That's what they're there for, and at least a > handful of client-side libraries already do this, e.g. <http://webodf.org/ > >. > > (Certainly much simpler than, say, the parsing differences between script, > style, pre, and attributes, which I only understand well enough to know to > stay the cuss away from putting user content in script tags. The amount of > inconsistency and complexity of text/html parsing is single-handedly > responsible for most of the XSS injections I come across. This isn't just > matter of having a feature or not, this is a matter of security... why not > fix *this*? /rant) > > I understand the URI may be too much for people to grok, maybe instead use > a tag name ("html", "svg" or "mathml"): > > <template namespace="svg"> > <circle cx="10" cy="10" cr="10" /> > </template> > > The application/xhtml+xml parser would simply ignore the namespace > attribute, using xmlns on children instead. Polyglot HTML would use both > attributes. > > If two separate attributes is too much, then just add xmlns= support to > text/html. > > Austin. >
On 16/03/2015 16:02, Daniel Marques wrote: > Hi all, > > The MathML specification allows specifying carries at south positions. > In this case, when other rows of carries exists it is not clear how the > formula must be rendered. > > For example, in the following formula > > <mstack><mscarries><mn>1</mn></mscarries><mscarries > location="s"><mn>2</mn></mscarries><mn>3</mn><msline/><msrow/></mstack> > > What’s is the expected rendering? > > 1 > > 3 > > 2 > > Or maybe > > 1 > > 3 > > 2 > > ? > > Dani > personal response but the spec says > the first row of carries annotates the second (following) row as if the second row had location="n". so the position of the 1 isn't affected by the fact that the 2 has location=s, it is positioned as if the 2 had location=n so just above where that would have been. But it goes on to say > This means that the second row, even if it does not draw, visually uses some (undefined by this specification) amount of space when displayed. so the exact amount of space below the 1 is implementation defined. David _____________________________________________________________________________________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ______________________________________________________________________________________________________________________________________________________
Hi all, The MathML specification allows specifying carries at south positions. In this case, when other rows of carries exists it is not clear how the formula must be rendered. For example, in the following formula <mstack><mscarries><mn>1</mn></mscarries><mscarries location="s"><mn>2</mn></mscarries><mn>3</mn><msline/><msrow/></mstack> What’s is the expected rendering? 1 3 2 Or maybe 1 3 2 ? Dani
On 15/03/2015 10:30, David Carlisle wrote: > Thanks, fixed those in latest checkin. The ? was I suspect showing some > doubt about that character and I note that U+2A5E was added at Unicode > 3.2 which looks very similar and unicode-math assigns \doublebarwedge > giving the new name \vardoublebarwedge to U+2306. > > I've just removed the ? for now, but I wonder if the AMS entry should > align with unicode-math. I'll check with Barbara how she aligns the AMS > name to STIX. Confirmed with Barbara Beeton, the STIX mapping of AMS names does use 2A5E here so I moved the <AMS> entry to that. (No change in the mathml/html entity definitions) David
On 14/03/2015 14:29, Frédéric WANG wrote: > Hi all, > > I don't know if there has been progress regarding the fixes to > unicode.xml, but I still see two obvious errors in the AMS set: > > For U+21CE: <AMS>\nleftrightarrow</AMS> (should be an uppercase L as > for other sets and similarly to U+21CD ; note that this is different > from U+21AE) For U+2306: <AMS>\doublebarwedge ?</AMS> (question mark > should be removed) > > Thanks, > Thanks, fixed those in latest checkin. The ? was I suspect showing some doubt about that character and I note that U+2A5E was added at Unicode 3.2 which looks very similar and unicode-math assigns \doublebarwedge giving the new name \vardoublebarwedge to U+2306. I've just removed the ? for now, but I wonder if the AMS entry should align with unicode-math. I'll check with Barbara how she aligns the AMS name to STIX. David
On Thu, Mar 12, 2015 at 4:20 PM, Benjamin Lesh <firstname.lastname@example.org> wrote: > For my part, I disagree slightly with this statement. If you just drop a > <circle> tag in a <div>, you're going to get an HTMLUnknownElement. This is > by design and to spec, of course. But it unfortunately means you can't > clone() the element over to an SVG parent and hope it will work.d > Could you post the specific regression you ran into? The behavior you describe should only true for text/html parsing; it doesn't apply to DOM and application/xhtml+xml. For instance, given an arbitrary, conforming HTML document containing an SVG circle element, this should work: var svgns = 'http://www.w3.org/2000/svg'; var c = document.getElementsByTagNameNS(svgns, 'circle').cloneNode(); document.getElementsByTagName('body').appendChild(c); document.getElementsByTagName('body').lastElementChild.namespaceURI == svgns; // true text/html just isn't cut out for the sort of complex stuff we're discussing. For instance, what if I want to start using the proposed application/api-problem+xml format? You can't. text/html simply isn't built for the complex features being proposed. This is made explicit in HTML5: The DOM, the HTML syntax, and the XHTML syntax cannot all represent the same content. For example, namespaces cannot be represented using the HTML syntax, but they are supported in the DOM and in the XHTML syntax. Similarly, documents that use the noscript feature can be represented using the HTML syntax, but cannot be represented with the DOM or in the XHTML syntax. Comments that contain the string "-->" can only be represented in the DOM, not in the HTML and XHTML syntaxes. There's a craptonne of XML based markup languages and file formats out there. We can't just keep importing all of them into HTML every time we decide one of them might be useful to embed inside HTML. THERE is a usability and complexity nightmare. Explicit is better than implicit, so I like the idea of a namespace attribute element, it is forward-compatible with future vocabularies we may wish to use. Namespaces aren't *that* hard to understand. In my code above, I added one line declaring the namespace (`var svgns`). Is that really so hard? If you want to use the more advanced features of HTML, use namespaces, or import whatever vocabulary I want - DocBook, OpenDocument, music notation, XSL, without worry of collision. That's what they're there for, and at least a handful of client-side libraries already do this, e.g. <http://webodf.org/>. (Certainly much simpler than, say, the parsing differences between script, style, pre, and attributes, which I only understand well enough to know to stay the cuss away from putting user content in script tags. The amount of inconsistency and complexity of text/html parsing is single-handedly responsible for most of the XSS injections I come across. This isn't just matter of having a feature or not, this is a matter of security... why not fix *this*? /rant) I understand the URI may be too much for people to grok, maybe instead use a tag name ("html", "svg" or "mathml"): <template namespace="svg"> <circle cx="10" cy="10" cr="10" /> </template> The application/xhtml+xml parser would simply ignore the namespace attribute, using xmlns on children instead. Polyglot HTML would use both attributes. If two separate attributes is too much, then just add xmlns= support to text/html. Austin.
Planet MathML features: