Planet MathML

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.

Latest articles

[Minutes] 2015-03-30 Digital Publishing Interest Group Teleconference

Source: public-digipub-ig@w3.org Mail Archives • Thierry MICHEL (tmichel@w3.org) • March 30, 2015 • Permalink

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

    [2]Agenda

       [2] 
https://lists.w3.org/Archives/Public/public-digipub-ig/2015Mar/0049.html

    See also: [3]IRC log

       [3] 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

      * [4]Topics
          1. [5]ARIA DPUB Module
          2. [6]Packaging use cases
          3. [7]NYC f2f reminder
          4. [8]MathML
      * [9]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
    [10]http://www.w3.org/2015/03/23-dpub-minutes.html

      [10] http://www.w3.org/2015/03/23-dpub-minutes.html

    Tzviya: "Minutes from last week: please comment/review"
    ... "Minutes approved"

    <tzviya> [11]https://rawgit.com/w3c/aria/master/aria/dpub.html

      [11] 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>
    [12]https://github.com/w3c/aria/blob/master/aria/dpub.html

      [12] 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> [13]http://www.w3.org/TR/role-attribute/

      [13] 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>
    [14]http://www.w3.org/dpub/IG/wiki/UseCase_Directory#Packaging_
    and_Distribution

      [14] 
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> [15]http://www.idpf.org/epub/previews/

      [15] http://www.idpf.org/epub/previews/

NYC f2f reminder

    tzviya: "Reminder - NYC Face-to-face, please add if you are
    going

    <tzviya>
    [16]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."

      [16] 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 [17]scribe.perl version
     1.140 ([18]CVS log)
     $Date: 2015/03/31 13:02:11 $
      __________________________________________________________

      [17] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
      [18] 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 [19]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

      [19] 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: [20]https://lists.w3.org/Archives/Public/public-digipub-ig/2015M
ar/0049.html
Found Date: 30 Mar 2015
Guessing minutes URL: [21]http://www.w3.org/2015/03/30-dpub-minutes.html
People with action items:

      [20] 
https://lists.w3.org/Archives/Public/public-digipub-ig/2015Mar/0049.html
      [21] 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 [22]scribe.perl diagnostic output]

      [22] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm

Meeting minutes, 2015-03-23

Source: public-digipub-ig@w3.org Mail Archives • Ivan Herman (ivan@w3.org) • March 23, 2015 • Permalink

The full, technicolor and Dolby Stereo version:

http://www.w3.org/2015/03/23-dpub-minutes.html

The B&W, pedestrian version below:

Ivan



   [1]W3C

      [1] http://www.w3.org/

            Digital Publishing Interest Group Teleconference

23 Mar 2015

   [2]Agenda

      [2] http://www.w3.org/mid/5509EBBF.1090504@gmail.com

   See also: [3]IRC log

      [3] 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

     * [4]Topics
         1. [5]review on CSS fragments
         2. [6]Identifiers
         3. [7]latinreq
         4. [8]action items in tracker
         5. [9]plan face-to-face meetings
         6. [10]ePub 3.1 call for functionality
     * [11]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 23 March 2015

   <scribe> scribe:NickRuffilo

   <scribe> scribenick:NickRuffilo

   !scribenick:NickRuffilo

   <tzviya> agenda
   [12]https://lists.w3.org/Archives/Public/public-digipub-ig/2015
   Mar/0022.html

     [12] https://lists.w3.org/Archives/Public/public-digipub-ig/2015Mar/0022.html

   <tzviya> scribenick: NickRuffilo

   <ivan> Chair: Tzviya

   Meeting begin!

   <tzviya>
   [13]https://lists.w3.org/Archives/Public/public-digipub-ig/2015
   Mar/0019.html

     [13] 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> [14]http://dev.w3.org/csswg/css-break-3/
   ...: "Next agenda items - review/comments on CSS fragments from
   liza and brady."

     [14] 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:
   [15]https://lists.w3.org/Archives/Public/www-style/2015Mar/

     [15] 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>
   [16]https://www.w3.org/dpub/IG/wiki/Task_Forces/identifiers

     [16] 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> [17]http://w3c.github.io/dpub-pagination/

     [17] 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> [18]http://w3c.github.io/dpub-pagination/

     [18] 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> [19]http://www.w3.org/dpub/IG/track/actions/21

     [19] 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> [20]http://www.w3.org/dpub/IG/track/actions/27

     [20] 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> [21]http://www.w3.org/dpub/IG/track/actions/31

     [21] 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> [22]http://www.w3.org/dpub/IG/track/actions/34

     [22] 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> [23]http://www.w3.org/dpub/IG/track/actions/42

     [23] 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> [24]http://www.w3.org/dpub/IG/track/actions/43

     [24] 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> [25]http://www.w3.org/dpub/IG/track/actions/44

     [25] 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> [26]http://www.w3.org/dpub/IG/track/actions/45

     [26] 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> [27]http://www.w3.org/dpub/IG/track/actions/46

     [27] 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> [28]http://www.w3.org/dpub/IG/track/actions/47

     [28] 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> [29]http://www.w3.org/dpub/IG/track/actions/48

     [29] 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:
   [30]http://dev.w3.org/houdini/font-metrics-api/

     [30] 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>
   [31]https://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_
   Details

     [31] 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> [32]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."

     [32] 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 [33]scribe.perl version
    1.140 ([34]CVS log)
    $Date: 2015/03/31 13:02:11 $

     [33] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
     [34] 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





Making math on Wikipedia more awesome | an interview with Moritz Schubotz

Source: MathJax • March 20, 2015 • Permalink

Moritz Schubotz
Moritz Schubotz maintains the MediaWiki Math Extension

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.

hollingberry/texmath-ruby · GitHub

Source: mathml - Google Blog Search • Offeryour.com • March 19, 2015 • Permalink

texmath-ruby - Convert math markup between LaTeX, MathML, and OMML using Ruby.

Re: mstack and south carries

Source: www-math@w3.org Mail Archives • Neil Soiffer (NeilS@dessci.com) • March 17, 2015 • Permalink

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 <davidc@nag.co.uk> 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.
>
> ____________________________________________________________
> ____________________________________________________________
> ______________________________
>

Re: spec reading: semantics elements and styling

Source: www-math@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • March 17, 2015 • Permalink

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 <
peter.krautzberger@mathjax.org> 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 <davidc@nag.co.uk> 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
>>
>>
>

Re: mstack and south carries

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • March 17, 2015 • Permalink

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.

______________________________________________________________________________________________________________________________________________________

RE: mstack and south carries

Source: www-math@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • March 17, 2015 • Permalink

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:* neil.soiffer@gmail.com [mailto:neil.soiffer@gmail.com] *On Behalf
Of *Neil Soiffer
*Sent:* lunes, 16 de marzo de 2015 22:14
*To:* David Carlisle
*Cc:* www-math@w3.org
*Subject:* Re: mstack and south carries



I concur with David's reasoning.

    Neil



On Mon, Mar 16, 2015 at 9:12 AM, David Carlisle <davidc@nag.co.uk> 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.

______________________________________________________________________________________________________________________________________________________

Re: mstack and south carries

Source: www-math@w3.org Mail Archives • Neil Soiffer (NeilS@dessci.com) • March 16, 2015 • Permalink

I concur with David's reasoning.

    Neil


On Mon, Mar 16, 2015 at 9:12 AM, David Carlisle <davidc@nag.co.uk> 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.
>
> ____________________________________________________________
> ____________________________________________________________
> ______________________________
>
>

Re: template namespace attribute proposal

Source: public-webapps@w3.org Mail Archives • Benjamin Lesh (blesh@netflix.com) • March 16, 2015 • Permalink

> 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 <aaa@bzfx.net> wrote:

>
> On Thu, Mar 12, 2015 at 4:20 PM, Benjamin Lesh <blesh@netflix.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')[0].cloneNode();
> document.getElementsByTagName('body')[0].appendChild(c);
> document.getElementsByTagName('body')[0].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.
>

Re: mstack and south carries

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • March 16, 2015 • Permalink

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.

______________________________________________________________________________________________________________________________________________________

mstack and south carries

Source: www-math@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • March 16, 2015 • Permalink

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

Re: Remaining errors in unicode.xml (http://www.w3.org/TR/xml-entity-names/)

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • March 15, 2015 • Permalink

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

Re: Remaining errors in unicode.xml (http://www.w3.org/TR/xml-entity-names/)

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • March 15, 2015 • Permalink

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

Re: template namespace attribute proposal

Source: public-webapps@w3.org Mail Archives • Austin William Wright (aaa@bzfx.net) • March 15, 2015 • Permalink

On Thu, Mar 12, 2015 at 4:20 PM, Benjamin Lesh <blesh@netflix.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')[0].cloneNode();
document.getElementsByTagName('body')[0].appendChild(c);
document.getElementsByTagName('body')[0].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.

Remaining errors in unicode.xml (http://www.w3.org/TR/xml-entity-names/)

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • March 14, 2015 • Permalink

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,

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic



Re: template namespace attribute proposal

Source: public-webapps@w3.org Mail Archives • Benjamin Lesh (blesh@netflix.com) • March 12, 2015 • Permalink

> So much of the rest of how SVG/MathML are handled in HTML is seamless by
design. 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. This
was a problem in Angular's $compile that I helped sort out. Angular would
simple clone() partials straight from the DOM and insert them, if that
partial happened to be some fragment of SVG, you were then sticking
HTMLUnknownElements in your SVG Doc. Ultimately, Angular ended up tracking
namespace changes as it traversed the DOM looking for directives, as well
as specifying a starting namespace for directives with template strings
that were SVG partials.

Ember and Handlebars had similar issues with this. Handlebars had to use a
wrapMap technique to create DOM elements in the proper way, but that didn't
account for the <a> tag which exists in both namespaces. I'm not sure what
HTMLBars is doing to solve this problem, honestly. I'd be shocked if
whatever they were doing didn't require some sort of namespace
specification somewhere, or simply didn't work with certain edge cases like
the <a> tag.

I think this feature is really something that will help framework
developers and component library developers create generic code to
accommodate their needs. It's more for code sanity than anything.

<template><svg><circle/></svg></template> will clearly work, but then
you're putting the onus on the framework authors to make conditional checks
that might not always be accurate "is the firstElementNode svg?" If I'm a
framework author, I can't dependably check that and just assume it's an SVG
partial. It could be a full SVG-based web component.

On Thu, Mar 12, 2015 at 2:08 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Mar 12, 2015 at 8:24 PM, Adam Klein <adamk@chromium.org> wrote:
> > Is your thinking that adding special-casing for SVG-"looking" (as in, tag
> > names appearing in the list of SVG tags but not in the list of HTML tags)
> > inside <template> has fewer compat risks than a wholesale change of the
> HTML
> > parser to recognize SVG-looking tags anywhere?
>
> It was more principled, not sure about compatibility. Most of the HTML
> parser depends on modes. Then requiring <svg> makes sense. Just like
> it "makes sense" to require <table> for <td> not to be dropped.
> However, <template> was designed to work with any element,
> irrespective of mode. So <td> should work without <table> anywhere.
> Following that logic, it would make sense if <circle> worked without
> <svg> anywhere.
>
>
> --
> https://annevankesteren.nl/
>

RE: template namespace attribute proposal

Source: public-webapps@w3.org Mail Archives • Travis Leithead (travis.leithead@microsoft.com) • March 12, 2015 • Permalink

I would also prefer to enable this to work without any extra annotation. So much of the rest of how SVG/MathML are handled in HTML is seamless by design.

From: adamk@google.com [mailto:adamk@google.com] On Behalf Of Adam Klein
Sent: Thursday, March 12, 2015 11:17 AM
To: Benjamin Lesh
Cc: WebApps WG
Subject: Re: template namespace attribute proposal

On Wed, Mar 11, 2015 at 8:32 PM, Benjamin Lesh <blesh@netflix.com<mailto:blesh@netflix.com>> wrote:
I'd like to propose that the <template> tag have a namespace="" attribute that allows the user to specify namespaces such as "http://www.w3.org/2000/svg", so that the document fragment that comes from `.content` is created properly.

e.g.:

<template id="my-svg-template" namespace="http://www.w3.org/2000/svg>
  <circle cx="10" cy="10" cr="10"/>
</template>

For clarity, is this significantly different from the below (which works today)?

<template id="tmpl">
  <svg>
    <circle .../>
  </svg>
</template>

Clearly there's an extra step here, in that accessing the SVG elements requires hopping into firstElementChild, but adding new namespace-related features seems unfortunate.

- Adam

Re: template namespace attribute proposal

Source: public-webapps@w3.org Mail Archives • Dimitri Glazkov (dglazkov@google.com) • March 12, 2015 • Permalink

On Thu, Mar 12, 2015 at 4:13 AM, Robin Berjon <robin@w3.org> wrote:

> On 12/03/2015 11:07 , Anne van Kesteren wrote:
>
>> On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh <blesh@netflix.com> wrote:
>>
>>> What are your thoughts on this idea?
>>>
>>
>> I think it would be more natural (HTML-parser-wise) if we
>> special-cased SVG elements, similar to how e.g. table elements are
>> special-cased today. A lot of <template>-parsing logic is set up so
>> that things work without special effort.
>>
>
Love this idea.


>
> Or even go the extra mile and just slurp all SVG elements into the HTML
> namespace. There are a few name clashes, but we ought to be able to iron
> those out.
>
> And ditto MathML.


Not sure what the timeline would look like for this work. I guess this
would depend on whether there's existing content counting on namespaces
being different?

:DG<

Re: template namespace attribute proposal

Source: public-webapps@w3.org Mail Archives • Robin Berjon (robin@w3.org) • March 12, 2015 • Permalink

On 12/03/2015 11:07 , Anne van Kesteren wrote:
> On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh <blesh@netflix.com> wrote:
>> What are your thoughts on this idea?
>
> I think it would be more natural (HTML-parser-wise) if we
> special-cased SVG elements, similar to how e.g. table elements are
> special-cased today. A lot of <template>-parsing logic is set up so
> that things work without special effort.

Or even go the extra mile and just slurp all SVG elements into the HTML 
namespace. There are a few name clashes, but we ought to be able to iron 
those out.

And ditto MathML.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Feeds

Planet MathML features:

If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.

(feed)This page as an Atom feed

A mechanical calculation machine (with an added W3C logo)

Bert Bos, math activity lead
Copyright © 2008–2015 W3C®

Powered by Planet