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

Re: W3C TPAC 2019 - Will your Community Group meet in Fukuoka?

Source: public-mathonwebpages@w3.org Mail Archives • Alexandra Lacourba (alex@w3.org) • April 04, 2019 • Permalink

[This e-mail is bcc'ed to all public lists of existing W3C Community 
Groups]

Dear participants of the W3C Community Groups,

Please fill in the form below if your Community Group wants to meeting 
during TPAC2019, before *12 April 2019*:

https://www.w3.org/2002/09/wbs/1/CGsTPAC2019/

For the W3C TPAC 2019 Event team
Alexandra Lacourba
W3C Global Event Coordinator

On 03/07/2019 21:21, Alexandra Lacourba wrote:
>
> [This e-mail is bcc'ed to all public lists of existing W3C Community 
> Groups]
>
> Dear participants of the W3C Community Groups,
>
> Once again, the Community Groups have the possibility to meetduring 
> TPAC2019 which willbe held in Fukuoka, Japan at the "Hilton Fukuoka 
> Sea Hawk"[1].
>
> TPAC 2019
> 16 - 20 September 2019
> Fukuoka, Japan
> https://www.w3.org/2019/09/TPAC-template/Overview.html We ask you to 
> start discussions to determine whether and when yourgroup(s) would 
> like to meetduring this week. Please complete the following 
> questionnaire by 12 April 2019:
> https://www.w3.org/2002/09/wbs/1/CGsTPAC2019/ W3C Community Groups can 
> hold 2-hour meetings on Monday, Tuesday, Thursday, Friday. The 
> Available slots willbe: 8:30 - 10:30 10:30 - 12:30 13:30 - 15:30 15:30 
> - 17:30 We willbe able to accommodate 4 meetings per day, so 16 over 
> the entire TPACweek. Outside of their Community Groupmeetings, non 
> W3C-Member CG participants may attend as observers the Working and 
> Interest groups meetings who accept observers, as well as the 
> Technical Plenary Day willbe held on 18 September from 08:30-18:00. 
> There will be registration fees to offset a portion of the meeting 
> costs. If you have any questions, please contact 
> <w3t-tpregister@w3.org <mailto:w3t-tpregister@w3.org>>. We look 
> forward to another successful meeting!
> For the W3C TPAC 2019 Event team
> Alexandra Lacourba
> W3C Global Event Coordinator
> [1] 
> https://www3.hilton.com/en/hotels/japan/hilton-fukuoka-sea-hawk-FUKHIHI/index.httm
>

-- 
Alexandra Lacourba - Administration             mailto:alex@w3.org
World Wide Web Consortium                       http://www.w3.org
W3C/ERCIM - 2004 route des Lucioles - Sophia Antipolis 06410 Biot - FR
Voice: +33.4.92.38.50.76                                        Fax: +33.4.92.38.78.22

RE: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Source: public-mathonwebpages@w3.org Mail Archives • Sina Bahram (sina@sinabahram.com) • April 04, 2019 • Permalink

Will do as I get a chance.

 

 

President, Prime Access Consulting, Inc.

Phone: 919-345-3832

https://www.PAC.bz

Twitter: @SinaBahram

Personal Website:  <https://www.sinabahram.com> https://www.sinabahram.com

 

From: Charles LaPierre <charlesl@benetech.org> 
Sent: Wednesday, April 3, 2019 3:53 PM
To: Sina Bahram <sina@sinabahram.com>
Cc: public-mathonw. <public-mathonwebpages@w3.org>; George Kerscher <georgek@benetech.org>
Subject: Re: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

 

Hi Sina,  

I think it would be good for you to review/comment on these two pull requests they will be discussing tomorrow.

* https://github.com/w3c/aria/pull/923
* https://github.com/w3c/aria/pull/924

 

Thanks
EOM
Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301 





On Apr 3, 2019, at 12:51 PM, Sina Bahram <sina@sinabahram.com <mailto:sina@sinabahram.com> > wrote:

 

I’m at a conference, so my regrets on this, but I’m really passionate about this topic. Please let me know if there’s questions I can answer or things I can comment on/provide feedback for.

 

 

President, Prime Access Consulting, Inc.

Phone:  <tel:919-345-3832> 919-345-3832

 <https://www.pac.bz/> https://www.PAC.bz

Twitter: @SinaBahram

Personal Website:  <https://www.sinabahram.com/> https://www.sinabahram.com

 

From: Charles LaPierre < <mailto:charlesl@benetech.org> charlesl@benetech.org> 
Sent: Wednesday, April 3, 2019 3:04 PM
To: public-mathonw. < <mailto:public-mathonwebpages@w3.org> public-mathonwebpages@w3.org>
Cc: Sina Bahram < <mailto:sina@sinabahram.com> sina@sinabahram.com>; George Kerscher < <mailto:georgek@benetech.org> georgek@benetech.org>
Subject: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

 

Hello everyone, 

I wanted to let you know that in tomorrows ARIA WG call the topic of new Braille Properties added to ARIA will be discussed.

 

Unfortunately I can not attend as I am presenting at that time, but I hope those who joined the ARIA WG from this group will be able to attend.

Here is the agenda Item and information regarding the call which is tomorrow April 4th at 10AM Pacific / 1PM Eastern

* New braille properties:
   - aria-roledescription-braille
   - aria-label-braille

 


Time:
 <https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA&iso=20190404T13&p1=43&ah=1> https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA&iso=20190404T13&p1=43&ah=1

If you would like to add an item to the agenda please reply to this mail.

 * New issue triage:

 <https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-03-28+> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-03-28+
 * New pull-request triage:

 <https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+created%3A%3E%3D2019-03-28+> https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+created%3A%3E%3D2019-03-28+
 * Quick status check of active role-parity issues:
   - fieldset/legend:  <https://github.com/w3c/aria/pull/911> https://github.com/w3c/aria/pull/911
   - label:  <https://github.com/w3c/aria/pull/886> https://github.com/w3c/aria/pull/886
   - time:  <https://github.com/w3c/aria/pull/895> https://github.com/w3c/aria/pull/895
 * Quick, straw-poll-level discussion:
   - Keep children-presentational on math role?
      <https://github.com/w3c/aria/issues/425> https://github.com/w3c/aria/issues/425
   - Do we want aria-rowtext, aria-coltext, and/or aria-listitemtext?
      <https://github.com/w3c/aria/issues/667> https://github.com/w3c/aria/issues/667
 * New braille properties:
   - aria-roledescription-braille
   - aria-label-braille

Previous Meeting Minutes:
 <https://www.w3.org/2019/03/28-aria-minutes.html> https://www.w3.org/2019/03/28-aria-minutes.html

IRC:  <http://irc.w3.org:6665/> irc.w3.org:6665 #aria

Call Details:  <https://www.w3.org/2017/08/telecon-info_aria> https://www.w3.org/2017/08/telecon-info_aria

To join the audio conference only:
To receive a call back, provide your phone number when you join the
meeting, or call the number below and enter the access code.
US Toll Number:  <tel:+1-617-324-0000;641%20291%20851> +1-617-324-0000
 <tel:+1-617-324-0000;641%20291%20851> Access code:641 291 851
Mobile Auto Dial: <tel:+1-617-324-0000,,,641291851%23> +1-617-324-0000,,,641291851#

 

[CSSWG] Minutes Telecon 2019-04-03 [css-easing] [css-env] [css-text]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • April 04, 2019 • Permalink

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Easing functions to CR
----------------------

  - RESOLVED: Ask to take Easing Functions to CR once these editorial
              changes [for Issue #3205] are made.

CSS Environments
----------------

  - The proposal to get document title using css env() (Issue #3685)
      met with skepticism from the working group. In order to proceed
      with this approach the group needed to see more evidence that
      this would solve most of the potential use cases either as is or
      as an enhancement to the original proposal or that there are
      other document properties that would want to have the same
      functionality as proposed for document title. Interested parties
      will continue to investigate the use cases.

High Contrast Spec
------------------

  - Rossen wrote up a proposal to bring the Edge high contrast
      behavior into CSS specifications. There was debate on where this
      work should go so the group will review it this week and then
      decide where this should be put in the official CSS repo.

CSS Text
--------

  - When looking into a new property for MathML a larger question was
      raised concerning if the stated design of text-transform when
      applied to something like a screen reader needed to change in
      order to align with current implementations (Issue #3775:
      text-transform's design, intent and reality resolution)
  - It was questioned if the difference is actually as large as the
      issue indicated since the text-transform is not changing the
      fundamental structure of the document and cannot be treated as a
      core part of the document since some view modes remove the CSS.
  - text-transform contains many possible values so there will be a
      need to either split this into more than one property or spec
      how the properties differ as there are different solutions per
      property.
  - Other groups will need to be brought into this conversation to
      ensure that the decision reached is correct for a wide audience.
      CSSAAM was specifically called out at a task force which should
      discuss this.
  - A possible way forward is to expose detail of transform and
      original content at the same time instead of only exposing the
      transformed content so that screen readers can make a smarter
      decision then they can today.
  - Discussion will continue on the issue.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Apr/0000.html

Present:
  Rossen Atanassov
  Amelia Bellamy-Royds
  Brian Birtles
  Oriol Brufau
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brian Kardell
  Peter Linss
  Myles Maxfield
  Cameron McCormack
  Ian Pouncey
  François Remy
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Greg Whitworth

Regrets:
  Tab Atkins
  David Baron

Scribe: dael

  astearns: We should get started
  astearns: We will skip item #7 and add Rossen's addition after
            item #2
  <Rossen> Thank you!
  astearns: Anything else people would like to change?

Easing functions to CR
======================

  birtles: I don't have anything that needs to be added. Ready to go.
  astearns: No more edits?
  birtles: Not that I'm aware of
  astearns: This isn't the first time to CR so there's not much
            besides deciding to
  birtles: Good point

  <fantasai> only open issue is https://github.com/w3c/csswg-drafts/issues/3205
  <fantasai> which is editorial
  <fantasai> significantly editorial, but still editorial :)
  birtles: That's [the open issue] probably worth doing
  fantasai: Worth doing but not block CR. Nothing technically wrong
            with document and won't effect impl. Editorial that can be
            done during CR. We should signal this spec is done and
            people should impl and deploy
  astearns: Not concerned with review before this change?
  fantasai: This change is about making spec easier to reuse in area
            that need timing mapping but aren't animations and
            transitions so I don't think that will make a difference
            to implementations. I don't think it needs to prevent CR
  astearns: birtles what do you think? Change in first or CR update?
  birtles: Can I do the change today and get a resolution?
  fantasai: Sure. I just didn't want to wait for some indefinite years
  AmeliaBR: We're agreeing to change words timing function to easing
            function and relating edits? That's all you're changing?
  birtles: Yeah and all the descriptions that say these can be applied
           to animations to say things like animations
  florian: But it's a generalization of sentences, not a deep re-write
  birtles: Yep
  florian: Then I see no problem resolving before edits
  <Rossen> Ship it!

  astearns: Objections to Take Easing Functions to CR once these
            editorial changes are made?

  RESOLVED: Ask to take Easing Functions to CR once these editorial
            changes are made
  astearns: Thanks birtles to getting to those edits

CSS Environments
================

Getting access to the document title
------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3685

  astearns: This was introduced last week, discussion of scope and
            that it's not useful in all situations. What else did you
            want on this florian?
  florian: Not much to add, just cut by clock. I think it would be
           useful to be able to access doc title from env. tantek
           pointed out this is not powerful enough for general problem
  florian: The generic solution pretty much calls for regions, though.
           This is much simpler and solves some cases so I think it's
           good to do. I recognize it's not a full solution

  AmeliaBR: One thing is that CSS has a mechanism for what florian
            wants in GCPM module. That is a much more complex and
            nuanced system of pulling bits of text from a heading and
            reusing in other parts of layout.
  AmeliaBR: I don't know if there's any interest in getting that
            cleaned and into browsers or if we want the quick win
  florian: I think we should do this regardless. Other is slightly
           more powerful, but it's still plaintext only and only works
           in paged margin boxes so if you don't paginate you get
           nothing. So this is less expressive but more applicable and
           simpler
  florian: I was discussing in context of Viviostyle and there were
           cases to not invoke the whole complex process, just I want
           the title and put it there.
  florian: I don't think I wouldn't be pushing if we didn't have nth
           function. We have the mechanism so this is exposing a value
           through it

  Rossen: Main motivation is in paginated scenarios?
  florian: Commonly seen in paginated but this doesn't have to be
           restricted. With nth works everywhere. If you want
           something pagination-like you can invoke things like this
  Rossen: Just curious use cases
  florian: Same type of layout as paginated media but actual
           pagination with css level of page is one thing, but
           something that visually looks like pages is another. I'm
           aware of wanting to do things that look page-like is a use
           case

  fantasai: Concern is this is too simple for what's wanted. If we go
            in this direction we'll be too limited. Don't know how
            urgent this is. If it's not something we have to do really
            soon might be worth trying to sort out more generic that
            solves this class of problems rather then special casing
            this
  <bkardell> it seems like we have maybe a lot of things that are
             almost related to this
  florian: Don't think particularly urgent. In that sense okay with
           punting. More generic is way more complicated. I don't see
           this as trying to solve whole problem. If want to expose
           more through nth it seems reasonable.
  fantasai: If it would solve 80% use cases it's worth, but seems
            closer to 20% so I don't know it's worth introducing a new
            pattern if we're not planning to pursue patterns
  florian: I think for ebook this would solve most of the problems.
           Depends on how you say 100%
  fantasai: But they also want page number and chapter
  florian: But in ebooks, chapters are HTML files, so, it is
           sufficient for that case. It is simple

  bkardell: I'm interested in this use case. I feel like I would like
            to talk to florian a bit to understand more off call. If
            it only can give you the plain text would you not be able
            to achieve most by setting a custom prop for now? I think
            we said it's just plain text so the 20% of use cases
            wouldn't they be served equally as well with a css custom
            property?
  astearns: It's content duplication and you run the risk of out of
            sync. This is slightly better then duplicating in custom
            properties
  florian: ebook with 25 chapters if you use nth you pull from doc,
           custom prop you have it for each chapter
  bkardell: That's what I'd like to understand more. They're not input
            manually, they're built.
  bkardell: Would mean multiple rules
  astearns: Prob enough for now. Not hearing enough to pursue for now.
            Maybe if we saw use of custom properties for this could
            make better solution

  florian: I'm hearing sufficient skepticism we're punting
  AmeliaBR: florian worth looking if there are similar doc properties
            where worth a common mechanism. Doc URL or parts of URL
            might be similarly useful. Have permalink on a file. I
            haven't looked and it's a matter of looking at what people
            are actually using to insert into the generated content
  florian: We can think of a few more, but that's enough for the topic
           today. We can go offline

High contrast spec
==================
  link: http://htmlpreview.github.io/?https://github.com/atanassov/css-high-contrast/blob/master/Overview.html

  Rossen: I don't have a github issue for this
  Rossen: I had an action after the F2F to go and put what we had in
          an explainer and add more spec text to introduce high
          contrast feature as is defined and working inside of edge
          and IE
  Rossen: The pretty print of the HTML is linked above
  Rossen: Request is to move this out of my github and into CSSWG repo
          as one venue or pursuing this. Or identify parts of spec
          that will go to currently worked on specs. I can see a MQ go
          to MQ spec, cascade going to cascade. That's what I wanted
          to get from WG and figure out next steps

  Rossen: Not sure if anyone had a chance to review, it's fairly short
  fantasai: I haven't but TabAtkins and I plan to tomorrow. I can get
            review by next week
  Rossen: Sounds great. I just want to take it out of private repo and
          get it into CSS
  Rossen: I'm okay breaking this apart into appropriate specs or keep
          as one until it solidifies more and then break. Either is
          okay
  fantasai: Ultimately want all MQ to go int MQ5. High contrast props
            should go together, don't know spec
  <fantasai> there was a printer color adjust control as well that
             should go together with this
  Rossen: This is something...this is why I wanted to keep it as one
          spec to begin so it brings whole picture together in terms
          of what the high contrast feature does. Once this is better
          understood we can break apart into appropriate modules
  florian: Depends how many we want to break into. Mostly together
           makes sense. I'm interested in splitting MQ early because
           the whole thing is interaction between that MQ and others
           in that domain. I'd hate to go too far and it doesn't mesh
  Rossen: You suggesting break MQ out now and add to MQ5?
  florian: And the rest in the stand alone ED and work on that
  AmeliaBR: Looking at Rossen's draft there isn't a lot of the rest.
            Any problem with all into MQ5 for now and maybe we find a
            better place for the extra property later?
  Rossen: Not opposed
  fantasai: Makes sense. Not stay indefinitely but for current state
            of discussion makes sense to have a section that deals
            with color adjust stuff

  florian: Rossen do you want to be a coeditor of MQ5?
  Rossen: Sure

  astearns: Do we want to resolve to add this to MQ5 now or give a
            week for review?
  <fantasai> MQ is re-used outside of CSS, so definitely shouldn't
             stay there :) But fine to be there for a few months while
             we figure out where things should go
  <heycam> +1 to move it all into MQ5 for now
  Rossen: Comfortable with either. If people feel this is better in
          MQ5 and this is where we're going to go let's just go. We
          can always make changes
  fremy: Agree with Rossen. We can start to files issues against it
         which is better then filing issues when it's not official. If
         we all agree it's in MQ5 let's agree on it
  fantasai: I'd say wait a week. I can do a review and maybe we have
            clearer idea of what we want to assign
  fremy: I have issues I'd like to file but I don't know where
  fantasai: We do have a single repo so you can file and tag later

  Rossen: If it's okay with WG I cam move spec as-is right now knowing
          it's unofficial into CSS Repo. I'm attending blink-con next
          week during call so I'm not going to be present. I would be
          happier if people started shooting issues into a repo and
          tag against spec
  florian: Okay with that
  astearns: I'd rather not put it in repo as-is if going to put it
            into MQ. Rather open issues on repo and tag later. Just @
            Rossen and melanierichards

  <AmeliaBR> We also have another proposal for a "media-query
             adjacent" CSS property in `supported-color-schemes`,
             which should probably go in the same place as this
             high-contrast override property.

  florian: There's 2 parts in this to me. MQ and high-contrast-adjust.
           high-contrast-adjust is a pattern I think we'll see so it
           belongs. The new cascading border doesn't belong. It's got
           the backdrop in there?
  Rossen: It's not there. It's not currently expressed as a reachable
          entity through style layer. If you recall the discussion I
          did point out to be successful for impl. There was some
          interest this could apply to things like captions. In event
          that we believe this new feature should surface on CSS layer
          I can add the spec text. For now not exposed because can't
          be reached by author
  florian: That part just doesn't feel like it should be in MQ
  Rossen: Agree, totally different. Maybe it's B&B if anything

  astearns: Let's keep in Rossen's repo for now. Please review doc and
            open issues on our repo and we'll descide after a bit of
            review what we'll do

CSS Text
========

text-transform's design, intent and reality resolution
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3775

  astearns: Wanted to have this introduced so can make a bit of
            progress before bringing in more people
  bkardell: I don't see where this was spec originally in the design,
            but at some point it became a stated thing we have talked
            about about the intent of text-transform and what it
            exposes to screen readers and why
  bkardell: Feel like I dropped the ball a bit on kana discussions
            because I know it wasn't reality and assumed other people
            did too. Some of the text stuff I don't feel I can comment
            so wasn't paying close attention
  bkardell: Opened a different issue requesting something that is
            inline with how screen readers work. That changes to how
            we have designed to not expose text to screen readers.
            It's come up that it does not match reality
  bkardell: AT and browsers have chosen universally to expose
            transform text. I'd like to consider that so that we can
            properly discuss the other issue
  bkardell: My position is that the ones that exist and in wide use
            are stated design principle is out of touch with reality.
            It's a conscious choice that's what users want. At a
            minimum our principle needs some finesse

  florian: The discussion is a bit long winded, I'll jump to where we
           are. I don't see the same contradiction as bkardell if we
           look a little deeper. Don't think it's interesting to
           debate what screen reader users what, the experts have
           said. Screen readers do not give access to raw doc, they
           present it. It's easier to include the transform. I don't
           think that makes semantics change
  florian: I don't think we could do that. There are places where we
           don't present CSS so we can't say that text-transforms are
           an intrinsic part of doc that can't be removed. If screen
           readers as one UA think best way to present is to apply the
           text-transform, great. But I don't think we can go from
           there to never not allow them to be applied. If you
           introduce a new text-transform old browsers won't know
  florian: I think we have to recognize that the doc is the doc and
           the text-transforms need to be allowed to apply. I think
           the claim that case transforms are desirable is credible,
           but I don't want to generalize to say all transforms always
           must be preserved. I think cjk and i18n transforms you want
           the other way.
  florian: I think we need to discuss transform by transforms, but
           can't say all must be preserved

  fantasai: I agree with florian that text-transform can't be
            intrinsic part of doc semantics. They were designed as a
            way to have this distinction partly. If we don't have them
            to different doc and visual rendering we'll have to find a
            way to do it.
  fantasai: Someone suggested creating a custom font, I don't want to
            get into that arms race
  fantasai: I'm not sure how deeply this was investigated in the past.
            I don't see anything in bugzilla. Chrome issues had people
            arguing on both sides. I don't know if this has been
            investigated deeply enough. We need to talk to the people
            we need to talk to and figure out what to do. It's
            possible the current situation is what fell out of
            original implementations, and screen readers just dealt
            with it but it's not ideal. If no discussion on Gecko it's
            probably what's convenient

  IanPouncey: Few points, to reiterate bkardell's point it seemed to
              those of us who work with screen readers that this was
              common knowledge, that's on us. For what florian said I
              think misconception about where problem lies. It's not
              screen readers doing transform, it's the browser and
              a11y tree exposing it
  IanPouncey: It's not screen reader doing anything in most modern
              browsers. Any of the ideas of a screen reader making a
              decision about what to present is problematic because
              you cannot reverse a transform to uppercase because you
              don't know what char were uppercase
  IanPouncey: Speculating on this, I wonder if there's a similar issue
              for content on the radar. I think there was an
              assumption when property introduced that it's not
              exposed to screen readers and it is now. I wonder if
              there's a similar problem there
  <fantasai> Point about delivering transformed text through AT
             meaning screenreaders can't access original text even if
             they want to is imho important

  Rossen: Way screen readers work is a long discussion. How text is
          represented also heavily depends on current platform support
          and AT consuming that information. nvbia on windows will
          have different characteristics to express richness of text
          compared to narrator using ui automation
  Rossen: One thing I know from interacting with the community and
          a11y wgs and impl a11y the thing I can tell you is a lot of
          people think of screen readers for the blind. It's part of
          the users but not all. Most people are those with low
          vision. They can see parts of the screen. So when you start
          producing disparity between rendered results and what screen
          reader represents it becomes confusing
  Rossen: Consider editing scenarios- most people will navigate text
          by character to check spelling. If at that time you have
          text-transform that caps for example for them to not know
          it's upper case will be confusing. Same reason why we map
          ital to em, lots of font features that map to a11y prop I
          don't see why this should be unique
  Rossen: Other thing I want to give a big shout out, CSSAAM would be
          ideal place to continue this discussion
  <fantasai> wrt checking spelling in editing environment... ideally
             you want to know what text you're actually typing, for
             when the text-transform goes away -- source text should
             be following standard capitalization rules, would be
             problematic if ::first-line { text-transform: uppercase;}
             led someone to type in all-caps when replacing one word
             with another in the first phrase of a para
  <fantasai> generally, editing text with text-transform turned on is
             going to be very confusing regardless...

  AmeliaBR: There's 2 aspects to the discussion. What should happen,
            how is best way to expose full information. Then specific
            practical issue in that we have recently added values of
            text-transform with some impl and this new prop for math
            variants
  AmeliaBR: By putting it all in text-transform it forces us to treat
            them the same for exposing before or after transform values
  AmeliaBR: Even if not complete agree on optimal for exposing case
            changes I'm trusting florian that exposing CJK
            typographical is a problematic situation from a11y.
  AmeliaBR: If mathML comes through it's very important to expose
            transformation.
  AmeliaBR: With these different semantic impacts it might be worth
            discussing if these should be split up, even if it's
            transform to long hands that could all reset by a
            shorthand but there is a text-transform case that's
            different then CJK text-transform. If we separate to
            different properties we can start talking semantics and
            what strange transformations happen
  AmeliaBR: Especially in terms of what's exposed to a11y, innerText,
            copy/paste APIs, lots of places where people use
            text-transform and if they're not all equal maybe use
            different properties
  <fantasai> reason to have separate longhands is needing them to
             cascade separately... if the only concern is what impacts
             they have, we can categorize within the spec

  florian: I am aware about difference IanPouncey mentioned between
           what screen readers do and what's in at. Idea is that text
           in AT would be end transformed text and have the original
           information so screen readers can make decision. In case of
           case transforms if every screen reader wants to do the same
           thing with it and the current AT does the transform already
           it will be uphill to un-transform. For case transforms if
           it's a standard today fine let's leave it
  florian: But that's what I want to Japanese which is keep
           untransformed text and keep information about transforms so
           that screen readers can add extra information if they want.
           The Math case I think is kind of related. I don't think we
           can rely on the transforms to change document semantics.
  florian: If we want to introduce a new semantic differences we have
           to introduce it in the document and that can impact the AT
           tree. We can't just change the font and claim it lets us
           introduce semantic differences that would change the
           meaning of the document. Upper case is useful but not
           changing doc meanings. If we want to introduce math it will
           fail in all cases

  astearns: To respond to AmeliaBR- I think the idea of separating
            properties is interesting but maybe not entirely
            necessary. If we want we can spec what happens to values
            or properties and they can differ.
  astearns: To respond to florian I think there is prob a fallback
            that can work for new math transforms. If you see support
            you get fractor, if you don't you do extra styling
  florian: And it disappears in reader modes
  astearns: Fair
  florian: If you want to style that's fine. Introducing fundamentally
           different semantics won't work.

  IanPouncey: Cautious +1 to expose detail of transform and original
              content. I can see if there's any appetite for that.
              Hopefully we can get idea if that's possible. Also
              acknowledging the prompt to add CSSAAM to this discussion

  AmeliaBR: Follow up on florian's concern about semantics in
            document. The request for math transforms is from MathML
            as a way to describe behavior of MathML attribute in a way
            that can be consistently impl. That is something where
            there is semantics in doc level but nice to be able to
            describe it. Maybe also use same effects in more
            decorative cases
  florian: Fair and useful so thing into a11y tree is the transformed
           and may be useful

  astearns: We're at time. The call bridge will stay open if people
            want to chat and then put the discussion in the issue
  astearns: Thank you all very much

Re: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Source: public-mathonwebpages@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • April 03, 2019 • Permalink

Hi Sina,
I think it would be good for you to review/comment on these two pull requests they will be discussing tomorrow.
* https://github.com/w3c/aria/pull/923

* https://github.com/w3c/aria/pull/924


Thanks
EOM
Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301

On Apr 3, 2019, at 12:51 PM, Sina Bahram <sina@sinabahram.com<mailto:sina@sinabahram.com>> wrote:

I’m at a conference, so my regrets on this, but I’m really passionate about this topic. Please let me know if there’s questions I can answer or things I can comment on/provide feedback for.


President, Prime Access Consulting, Inc.
Phone: 919-345-3832<tel:919-345-3832>
https://www.PAC.bz<https://www.pac.bz/>
Twitter: @SinaBahram
Personal Website: https://www.sinabahram.com<https://www.sinabahram.com/>

From: Charles LaPierre <charlesl@benetech.org<mailto:charlesl@benetech.org>>
Sent: Wednesday, April 3, 2019 3:04 PM
To: public-mathonw. <public-mathonwebpages@w3.org<mailto:public-mathonwebpages@w3.org>>
Cc: Sina Bahram <sina@sinabahram.com<mailto:sina@sinabahram.com>>; George Kerscher <georgek@benetech.org<mailto:georgek@benetech.org>>
Subject: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Hello everyone,
I wanted to let you know that in tomorrows ARIA WG call the topic of new Braille Properties added to ARIA will be discussed.

Unfortunately I can not attend as I am presenting at that time, but I hope those who joined the ARIA WG from this group will be able to attend.
Here is the agenda Item and information regarding the call which is tomorrow April 4th at 10AM Pacific / 1PM Eastern
* New braille properties:
   - aria-roledescription-braille
   - aria-label-braille


Time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA&iso=20190404T13&p1=43&ah=1


If you would like to add an item to the agenda please reply to this mail.

 * New issue triage:

https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-03-28+

 * New pull-request triage:

https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+created%3A%3E%3D2019-03-28+

 * Quick status check of active role-parity issues:
   - fieldset/legend: https://github.com/w3c/aria/pull/911

   - label: https://github.com/w3c/aria/pull/886

   - time: https://github.com/w3c/aria/pull/895

 * Quick, straw-poll-level discussion:
   - Keep children-presentational on math role?
     https://github.com/w3c/aria/issues/425

   - Do we want aria-rowtext, aria-coltext, and/or aria-listitemtext?
     https://github.com/w3c/aria/issues/667

 * New braille properties:
   - aria-roledescription-braille
   - aria-label-braille

Previous Meeting Minutes:
https://www.w3.org/2019/03/28-aria-minutes.html


IRC: irc.w3.org:6665<http://irc.w3.org:6665/> #aria

Call Details: https://www.w3.org/2017/08/telecon-info_aria


To join the audio conference only:
To receive a call back, provide your phone number when you join the
meeting, or call the number below and enter the access code.
US Toll Number: +1-617-324-0000<tel:+1-617-324-0000;641%20291%20851>
Access code:641 291 851<tel:+1-617-324-0000;641%20291%20851>
Mobile Auto Dial:+1-617-324-0000,,,641291851#<tel:+1-617-324-0000,,,641291851%23>

RE: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Source: public-mathonwebpages@w3.org Mail Archives • Sina Bahram (sina@sinabahram.com) • April 03, 2019 • Permalink

I'm at a conference, so my regrets on this, but I'm really passionate about
this topic. Please let me know if there's questions I can answer or things I
can comment on/provide feedback for.

 

 

President, Prime Access Consulting, Inc.

Phone: 919-345-3832

https://www.PAC.bz

Twitter: @SinaBahram

Personal Website:  <https://www.sinabahram.com> https://www.sinabahram.com

 

From: Charles LaPierre <charlesl@benetech.org> 
Sent: Wednesday, April 3, 2019 3:04 PM
To: public-mathonw. <public-mathonwebpages@w3.org>
Cc: Sina Bahram <sina@sinabahram.com>; George Kerscher
<georgek@benetech.org>
Subject: ARIA WG Meeting tomorrow to discuss the new Braille Proposal

 

Hello everyone, 

I wanted to let you know that in tomorrows ARIA WG call the topic of new
Braille Properties added to ARIA will be discussed.

 

Unfortunately I can not attend as I am presenting at that time, but I hope
those who joined the ARIA WG from this group will be able to attend.

Here is the agenda Item and information regarding the call which is tomorrow
April 4th at 10AM Pacific / 1PM Eastern

* New braille properties:
   - aria-roledescription-braille
   - aria-label-braille

 


Time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA
<https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA&iso=20190404
T13&p1=43&ah=1> &iso=20190404T13&p1=43&ah=1

If you would like to add an item to the agenda please reply to this mail.

 * New issue triage:

https://github.com/w3c/aria/issues?utf8=%E2%9C%93
<https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+cr
eated%3A%3E%3D2019-03-28+>
&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-03-28+
 * New pull-request triage:

https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+created%3A%3E%3D2019-0
3-28+
 * Quick status check of active role-parity issues:
   - fieldset/legend: https://github.com/w3c/aria/pull/911
   - label: https://github.com/w3c/aria/pull/886
   - time: https://github.com/w3c/aria/pull/895
 * Quick, straw-poll-level discussion:
   - Keep children-presentational on math role?
     https://github.com/w3c/aria/issues/425
   - Do we want aria-rowtext, aria-coltext, and/or aria-listitemtext?
     https://github.com/w3c/aria/issues/667
 * New braille properties:
   - aria-roledescription-braille
   - aria-label-braille

Previous Meeting Minutes:
https://www.w3.org/2019/03/28-aria-minutes.html

IRC: irc.w3.org:6665 <http://irc.w3.org:6665>  #aria

Call Details: https://www.w3.org/2017/08/telecon-info_aria

To join the audio conference only:
To receive a call back, provide your phone number when you join the
meeting, or call the number below and enter the access code.
US Toll Number: +1-617-324-0000 <tel:+1-617-324-0000;641%20291%20851> 
Access code:641 291 851 <tel:+1-617-324-0000;641%20291%20851> 
Mobile Auto Dial:+1-617-324-0000,,,641291851#
<tel:+1-617-324-0000,,,641291851%23> 

ARIA WG Meeting tomorrow to discuss the new Braille Proposal

Source: public-mathonwebpages@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • April 03, 2019 • Permalink

Hello everyone,
I wanted to let you know that in tomorrows ARIA WG call the topic of new Braille Properties added to ARIA will be discussed.

Unfortunately I can not attend as I am presenting at that time, but I hope those who joined the ARIA WG from this group will be able to attend.
Here is the agenda Item and information regarding the call which is tomorrow April 4th at 10AM Pacific / 1PM Eastern
* New braille properties:
   - aria-roledescription-braille
   - aria-label-braille


Time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=ARIA&iso=20190404T13&p1=43&ah=1

If you would like to add an item to the agenda please reply to this mail.

 * New issue triage:

https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-03-28+
 * New pull-request triage:

https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+created%3A%3E%3D2019-03-28+
 * Quick status check of active role-parity issues:
   - fieldset/legend: https://github.com/w3c/aria/pull/911
   - label: https://github.com/w3c/aria/pull/886
   - time: https://github.com/w3c/aria/pull/895
 * Quick, straw-poll-level discussion:
   - Keep children-presentational on math role?
     https://github.com/w3c/aria/issues/425
   - Do we want aria-rowtext, aria-coltext, and/or aria-listitemtext?
     https://github.com/w3c/aria/issues/667
 * New braille properties:
   - aria-roledescription-braille
   - aria-label-braille

Previous Meeting Minutes:
https://www.w3.org/2019/03/28-aria-minutes.html

IRC: irc.w3.org:6665<http://irc.w3.org:6665> #aria

Call Details: https://www.w3.org/2017/08/telecon-info_aria

To join the audio conference only:
To receive a call back, provide your phone number when you join the
meeting, or call the number below and enter the access code.
US Toll Number: +1-617-324-0000<tel:+1-617-324-0000;641%20291%20851>
Access code:641 291 851<tel:+1-617-324-0000;641%20291%20851>
Mobile Auto Dial:+1-617-324-0000,,,641291851#<tel:+1-617-324-0000,,,641291851%23>

Using MathML-Based Speech to Edit Math in Different Math Models

Source: Murray Sargent: Math in Office • MurrayS3 • March 28, 2019 • Permalink

This post discusses how an Assistive Technology program (AT) can use Presentation MathML to create consistent speech for editing equations created with different math models, such as OfficeMath and MathType. A goal is to make the speech and editing experience be as similar as possible, even though the underlying math models differ in significant ways. An important aid for editing is that the editor handle navigation so that the insertion point (IP) and speech are synchronized. When navigation occurs in a MathML copy of the math zone, editing isn’t possible unless there’s a way to convert a location in the MathML copy to the corresponding character position (cp) in the document. Such synchronization is also needed in calculating the bounding rectangles of the math being spoken. Math keyboard input is facilitated by sophisticated input methodology, such as special hot keys, autocorrection, and autocompletion. The AT should not attempt to handle math keyboard input.

The post Speaking of math… describes two granularities of math speech: coarse-grained (navigate by words—siblings), which speaks math expressions fluently in a natural language, and fine-grained (navigate by characters), which reveals the content at the insertion point (IP) in enough detail to enable unambiguous editing. It seems clear that an AT can generate the same coarse-grained math speech from the MathML for an equation regardless of the underlying math model. The question arises as to whether the fine-grained math speech can also be the same for different math models.

Math speech generality

To create math speech for all math models, the MathML and the speech generated therefrom need to be rich enough semantically to describe the union of all arguments of all math objects (fractions, subscripts, integrals, math functions, etc.) of the various math models. The post Integrands, Summands, and Math Function Arguments compares some math objects for OfficeMath, Presentation MathML, Content MathML, [La]TeX, MathType/Equation Editor, and Nemeth math braille. To illustrate one difficulty, Presentation MathML, LaTeX and Nemeth braille don’t have explicit ­N-ary elements, while the others do. If the same fine-grained math speech is to work for all models, they all need to supply MathML that lets the AT announce that the insertion point is at the end of an integrand, for example.

Another case is the OfficeMath math-function object which has a function-name argument and an argument for the function. For example, in memory sin 𝑥 is stored as a math-function object with the name “sin” and the math argument 𝑥. It’s important for fine-grained speech to announce, “end of function name” when the user navigates past the ‘n’ and “end of argument” when the user navigates past 𝑥 but not yet out of the math-function object. That notifies the user that subsequent keyboard input will be in the function name or argument, respectively. The user might want to change sin 𝑥 to sin 𝑥², for which the math-function argument is 𝑥² and thereby not mean (sin 𝑥)².

Math semantics are important for correct math speech. For example, most superscripts represent raising a base to a power, so that speaking 𝑎² as “a squared” is correct. But in tensor analysis, superscripts are used as indices and 𝑎² should be spoken as “a superscript 2” or “a sup 2”. Presentation MathML 3.0 doesn’t have a way to distinguish between these cases. Adding new MathML attributes could provide a concise way to convey the semantics for speech. Alternatively, the <semantics> tag could be included with the corresponding Content MathML, but that approach is probably too involved for most ATs.

Differences in MathML and OfficeMath models

To illustrate differences in computer math models, consider how MathML, MathType, and OfficeMath represent sin 𝑥. In the PowerPoint and RichEdit OfficeMath memory layouts, sin 𝑥 appears as <U+FDD0>sin<U+FDEE>𝑥<U+FDDF>. Here the Unicode character <U+FDD0> is the math-object start delimiter, the <U+FDEE> is the argument separator, and the <U+FDDF> is the math-object end delimiter. Word also has such delimiters but with different values. Starting at the <U+FDD0>, each → arrow key moves past one of these characters. In a math model that doesn’t have the math-function object, no → arrow key is needed to move to the start of the function name or to move out of the math-function argument. That’s a basic difference in UI between models that affects fine-grained math speech. It doesn’t affect coarse-grained math speech, which in English is “sine x” for all math models.

Ideally the Presentation MathML for sin 𝑥 is

<mrow><mi>sin</mi><mo>&2061;</mo><mi>𝑥</mi></mrow>

How do you relate a position in this MathML to the corresponding position in the OfficeMath memory? Do the <mrow> and </mrow> each have a character position (cp)? They do for OfficeMath, but not for MathType. Are <mi>sin</mi> and <mi>𝑥</mi> separated by a character? They are in OfficeMath, but not in MathType. MathType represents the difference between the sin and the 𝑥 by character formatting and doesn’t use object delimiters for math functions.

Another cp mapping example is <mfrac><mi>a</mi><mi>b</mi></mfrac>. In MathML, there’s nothing between the numerator <mi>a</mi> and the denominator <mi>b</mi>, while in the OfficeMath backing store, there’s the U+FDEE argument separator. In a MathML model, when at the start of <mi>a</mi> the → arrow key might move directly into the denominator, while in OfficeMath it moves to the end of the numerator, allowing the user to insert characters there. It takes an additional → arrow key to move to the start of the denominator.

In addition to location differences in MathML and math-zone spaces, there are text-length changes resulting from automatic conversions of ASCII and lower-case Greek letters to math-italic letters, hidden text, revision marks, and special objects not representable in MathML such as images, hyperlinks, and fields. So, mapping from MathML space to editing space needs special assistance.

Navigating in MathML space

MathPlayer uses a MathML representation of an equation and navigates in the abstract MathML space, not the editing space. Hence it needs a way to transfer MathPlayer locations to the user selection for inserting/deleting/selecting text and displaying bounding rectangles. In principle, the MathML writer can create a cp array indexed by the MathML-tag index. Every MathML tag would have an entry in the array, including all closing tags. Then a new UIA method could allow an AT navigating in the MathML space to set a client selection end to the cp for the nth tag. In particular, the AT could set the edit insertion point and bounding rectangles corresponding to locations in the MathML space.

This approach requires that the AT keep track of the MathML tag indices. The post Math Accessibility Trees compares a display tree to a semantic tree for the equation

This equation appears in Nemeth braille as

⠹⠂⠌⠆⠨⠏⠼⠮⠰⠴⠘⠆⠨⠏⠐⠹⠨⠈⠈⠙⠨⠹⠌⠁⠬⠃⠀⠎⠊⠝⠀⠨⠹⠼⠀⠨⠅⠀⠹⠂⠌⠜⠁⠘⠆⠐⠤⠃⠘⠆⠐⠻⠼

There are nodes in both trees to attach the MathML tag indices to. Each node needs to cache the tag indices for the start and end tags that delimit the node.

This approach isn’t likely to be implemented by Microsoft Word since Word creates MathML by converting the OMML for the requested math to MathML using OMML2MML.xsl, a process that doesn’t keep track of MathML tag cp’s. Word would have to create a native MathML writer to implement a tag-cp mapping array. Such an array could be implemented in the RichEdit native MathML writer, thereby enabling tag-cp mapping in PowerPoint and OneNote. The RichEdit MathML writer was created before the OfficeMath build up/down facility was written. That facility uses a subset of the TOM interfaces that is implemented by Word and OfficeArt enabling them to use the facility. The RichEdit MathML reader also uses the TOM subset and in principle could be used by Word instead of converting MathML to OMML using MML2OMML.xsl. In contrast, the RichEdit MathML writer is pretty RichEdit-specific. Math zones can be copied from Word into RichEdit, but the original Word cp’s aren’t copied.

Navigating in editing space

If navigation is done in the editing space, the post Editing Math using MathML for Speech describes two ways for an AT to produce fine-grained math speech from MathML: 1) the MathML contains an <maction> element that gives the explicit math speech for the content at the insertion point, or 2) the MathML represents the math object in which the insertion point is located and includes an <maction> element identifying the insertion point. The first approach typically leads to different speech for different programs.

Character navigation in the editing space depends on the order in which math-object arguments appear in memory and how the arrow keys are handled. All math models put the numerator of a fraction before the denominator and can in principle be traversed using the ← and → arrow keys. MathType puts the integrand of an integral object first, followed by the lower limit and then the upper limit, while OfficeMath puts the limits first followed by the integrand, which is the visual order. Also, MathType uses ↑ and ↓ to navigate between N-ary object arguments vertically, perhaps because the arguments aren’t located in visual order and the ← and → arrow keys are strictly geometric and don’t traverse every character in an equation. In OfficeMath, the ← and → arrow keys move logically, rather than purely geometrically, and traverse every character in an equation. For example, the → arrow key at the end of a numerator moves to the start of the denominator. The MathML <mroot> puts the index after the radicand, while OfficeMath puts it before (in display order).

The most straight-forward approach is to navigate in the editing space as done with character and word (sibling) navigation with OfficeMath speech and Narrator. Then the insertion point is always synced to the speech. Characters are entered and deleted correctly, and information that MathML doesn’t represent is retained. MathPlayer was designed to explore equations and wasn’t intended to be used for creating and editing equations. The MathType editor has no accessibility support so editing equations using speech wasn’t a design scenario. In contrast, it was an essential design scenario for OfficeMath. It wouldn’t be hard to duplicate the richer MathPlayer navigation experience in OfficeMath but by navigating in the editing space rather than in a virtual MathML space.

One might ask whether it’s desirable to have a one-size-fits-all fine-grained editing experience. It might be unexpected or even confusing to say “end of argument” after the 𝑥 in sin 𝑥 in environments that don’t have a math-function object. That coupled with the differences in the way math text is laid out in memory makes the goal of identical fine-grained speech for all math models seem impractical. But for coarse-grained speech, these details are hidden, and it should be possible to have the same coarse-grained math speech for all math models.

It’s a pleasure to thank Doug Geoffray, Ron Parker, and Neil Soiffer for very helpful discussions on these topics.

[CSSWG] Minutes San Francisco F2F 2019-02-25 Part I: CSS Values, MathML Summary, WPTest Center, CSS Color, CSS Pseudo Elements [css-values] [css-color] [css-pseudo]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • March 26, 2019 • Permalink

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


CSS Values
----------

  - RESOLVED: We will use the bracket range notation (Issue #355:
              Define value syntax that limits <integer>, <number>,
              <length>, etc. to ranges)
  - Flag against the issue all specs that need to have their grammar
      updated and authors can remove the flag once they have made the
      changes.
  - Bikeshed might need an update to correctly parse the new syntax.

MathML summary
--------------

  - There is a new community group called MathML Refresh that is
      working on rewriting the MathML spec. It's starting to surface
      questions and issues for the CSSWG in github and those
      interested in Layout should take a look.

WPTest Center
-------------

  - TabAtkins did a demo on http://wptest.center/ and how it can help
      the group in writing tests.

CSS Color
---------

  - RESOLVED: Updated WD of css-color-4

CSS Pseudo Elements
-------------------

  - RESOLVED: pseudo() must always return the same object. Note that
              object can be GC'd if this is unobservable. (Issue
              #3607: Identity of Element.pseudo() return value)

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/sf-2019

Present:
  Rachel Andrew, Fronteers
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  Amelia Bellamy-Royds, Invited Expert
  Tantek Çelik, Mozilla
  Emilio Cobos, Mozilla
  Dave Cramer, Hachette Livre
  Elika Etemad, Invited Expert
  Jihye Hong, LGE
  Koji Ishii, Google
  Brian Kardell, JS Foundation (phone)
  Ian Kilpatrick, Google
  Rune Lillesveen, Google
  Chris Lilley, W3C (phone)
  Cameron McCormack, Mozilla
  Theresa O'Connor, Apeoplee
  François Remy, IDLAB
  Manuel Rego, Igalia
  Florian Rivoal, Invited Expert
  Hiroshi Sakakibara, BPS(Beyond Perspective Solutions)
  Jen Simmons, Mozilla
  Hyojin Song, LG Electronics
  Alan Stearns, Adobe
  Morten Stenshorne, Google
  Greg Whitworth, Microsoft
  Fuqiao Xue, W3C

Scribe: gregwhitworth

CSS Values
==========

Adding min/max constraints
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/355#issuecomment-458324757

  AmeliaBR: Currently we have something like <length-percent> and in
            the prose it says negative values are invalid
  AmeliaBR: The idea is to get that into the actual syntax grammar
  AmeliaBR: Especially with various houdini APIs we're providing
            authors with access to the syntax
  AmeliaBR: The issue is to discuss what this syntax looks like
  AmeliaBR: My proposal was to look like something like sgml
            attributes, we're using angle brackets for data types
  AmeliaBR: fantasai concern is that that can get verbose
  AmeliaBR: If you go down to the second to last issue I have the
            different options with 4 real world examples
  AmeliaBR: Any pros/cons - I've listed mine but would like to hear
            people's feedback
  fantasai: I like my proposal
  fantasai: I really don't want to make things too verbose, the more
            the grammar has to wrap lines the harder it is to read
  fantasai: I prefer the more human readable version
  <astearns> https://github.com/w3c/csswg-drafts/issues/355#issuecomment-458324757

  [TabAtkins shows options on screen]
  [TabAtkins explains the various proposals in the link above]
  fantasai: A minimum in human readable could be 0+

  TabAtkins: I'm most a fan of the bracket range syntax
  fantasai: If you're going to use multipliers, it uses similar syntax,
            so anyone reading the grammar already needs to learn the
            pattern.
  TabAtkins: This is already in the syntax
  TabAtkins: I agree with the idea in general
  TabAtkins: I agree with AmeliaBR that with Houdini we need to
             provide access to this

  heycam: A non syntax question
  heycam: When we have prose that restricts these values, when we have
          calc expressions, when we have negative inside the calc -
          would a change to this syntax make some values invalid
          earlier?
  TabAtkins: This shouldn't change anything this is just moving the
             prose into the grammar
  TabAtkins: calcs() are still valid and clamp to the range
  heycam: If you have a property number 1-1000
  heycam: and you use any calc inside that
  TabAtkins: Yep, that should work

  astearns: Does anyone have any objections to bracket notation
  astearns: I would prefer to have explicit rather than empty
  TabAtkins: What about writing infinity rather than the symbol
  fantasai: No, too long
  iank: Are we allowing the word infinity?
  iank: I'm biased to the Javascript
  TabAtkins: What about both?
  iank: I'm fine with both
  AmeliaBR: That sounds the best for me
  AmeliaBR: The infinity symbol is nice in a spec but not necessarily
            for typing in code
  <myles> +1 to what AmeliaBR said
  heycam: Rather than brackets and commas you can use ..
  heycam: Some languages include two dots others use three dots
  <astearns> ∞ in the grammar is the start of a slippery slope to
             writing css specs exclusively in emoji
  gregwhitworth: I would prefer no on that
  AmeliaBR: As fantasai noted the brackets are known in CSS in the
            grammar
  iank: Also the ... may get confused with the destructioring in JS
  TabAtkins: We will go with the bracket version and allow Infinity
             and the infinity symbol
  TabAtkins: I would never propose the infinity symbol for CSS itself,
             this is for syntax

  florian: Bikeshed feature request, convert infinity word to symbol

  fantasai: There is an infinity code and ampersand version
  <TabAtkins> &infin;

  fantasai: What's the case sensitivity of the infinity keyword?
  TabAtkins: In JS it's Infinity
  fantasai: As a string?
  TabAtkins: it would be <number [1, Infinity]>

  <AmeliaBR> Proposal: Use the bracket range notation (from the
             issue), but with infinite ranges (no max/min) represented
             by either `Infinity` or &infin; (or negative thereof)
  AmeliaBR: It's not a string it's a token within the syntax

  fantasai: Question, is our syntax types case sensitive
  TabAtkins: The Houdini syntax cares
  fantasai: Yeah we're consistent in our specs but I was curious
  <TabAtkins> `syntax: "big | BIGGER"` in registerProperty() is
              already case-sensitive
  astearns: Any objections to the proposal

  RESOLVED: We will use the bracket range notation

Go through the specs and update the grammar
-------------------------------------------

  AmeliaBR: I can maybe do some PM on that, but I'm hoping the spec
            editors will do some work
  <myles> I can do fonts
  <chris> I can do color
  heycam: Does that require Bikeshed changes?
  TabAtkins: No
  TabAtkins: We can tag the specs that need the changes and then untag
             as you make the changes
  astearns: If you could please make sure that they all get changed

  florian: Do we do that for specs that are RECs?
  TabAtkins: Do it to the ED and wait for it to get to rec - it's an
             editorial change
  <fantasai> We need to push out the changes to css-values-3 first

  <chris> did people hear? I asked that Rec changes get propagated to
          errata
  [working on getting chris audio]
  astearns: Unless there's a really good reason to do that extra work,
            I would prefer not to [in relation to chris's question]
  <chris> I'm not sure why not update the errata
  <chris> it's much less than making a new Rec
  astearns: I'm just looking at it as make work, this isn't adding
            anything to the Recs it's just a shortcut
  <chris> ok in his case, yes, no normative change

MathML summary
==============

  rego: This is a quick point - we were talking with Google about the
        state of things
  rego: Wanted to make everyone aware
  rego: There has been work to update the spec and align closer to how
        the browser works
  rego: There is a new CG called MathML Refresh to write a new spec
        that focuses on what browsers do
  <rego> BTW some related links
https://people.igalia.com/mrego/mathml-refresh-community-group.html
  rego: Basically they are starting to move this to a Github repo
  rego: There is a MathML core there to implement in Webkit
  rego: This was planned to be implemented in Chromium but we need to
        clarify some issues with CSS, etc
  rego: There are WPT tests and we'll be creating more tests and
        porting the ones from webkit
  rego: There are some new CSS proposals, but just in case someone is
        interested in it to go take a look
  rego: That's mostly all of it, Igalia has begun implementing MathML
        in LayoutNG in collaboration with Google. It's currently in a
        private Igalia fork
  rego: Let me know if you have any questions
  <gsnedders> there's a whole load of tests for the MathML subset
              Opera supported in the old presto-testo repo, though I
              don't know if they're very useful (they probably aren't
              reftests :()

  TabAtkins: These CSS proposals, they haven't showed up in the group
             at all?
  rego: No - people are just starting to talk about it, if people are
        interested they can take a look
  TabAtkins: Can you open an issue to link to the ideas so that we can
             go look at them?
  astearns: I was going to say similar, as things get further along it
            would be good to bring them here
  iank: I'm going through and filing some core issues with MathML
        today and tomorrow, how should margin collapsing work in
        MathML? Because there is currently no interop, etc
  iank: Those that know layout and have opinions should probably chime
        in
  rego: That's all

  dauwhe: How is the quality of the current MathML spec
  dauwhe: Had to look at it and it's written in this older style that
          is hard to follow
  rego: The meaning of the group is meant to work on that, I can't
        necessarily speak to the quality of the spec
  rego: You can implement in many different ways, the spec didn't
        necessarily define how to implement things
  <bkardell> I believe one task the group wants to do is also spec it
             out more like the newer HTML specs
  dauwhe: Are they considering splitting out the presentational markup
          from the content markup?
  <bkardell> yes that is my understanding
  <bkardell> to what dauwhe said
  bkardell: One task group wants to do things like newer HTML specs
  TabAtkins: Yeah, that's what they're currently doing
  dauwhe: That's good to hear
  dauwhe: afaik semantic MathML is only used in XML  toolchains,
          is not exposed to the Web

WPTest Center
=============

  TabAtkins: A little while ago fremy gave a presentation about
             wptest.center
  TabAtkins: I've been using it to write the CSS syntax tests from the
             past 5 years
  [TabAtkins shows a demo on how to do this]
  TabAtkins: Syntax tools are almost all in JS
  <bkardell> this is awesome
  <chris> is there a way to add reftests?
  <bkardell> was just asking someone about this
  <astearns> no reftests from this tool
  <bkardell> thank you astearns
  <chris> I like that this lowers friction for a quick test
  fremy: It's primarily to help unblock the CR so people can quickly
         submit a test
  astearns: I was going to encourage everyone to take a look and try
            it out
  astearns: and we need to be writing more of these tests, maybe the
            ease of this will be nice to add a reftest for this
  astearns: It's OSS so it may be nice to add a file picker to add a
            reftest
  TabAtkins: You don't have to deal with the repo
  astearns: We are still waiting on hearing from external people

[20 min break]

CSS Color
=========
  Scribe: fantasai

Updated WD of css-color-4
-------------------------

  chris: Hello everyone!
  chris: Quick request to update Color
  chris: Someone was saying "oh, there haven't been changes since
         2016" and I realized they were looking at /TR
  chris: Over weekend I made a list of changes
  chris: Lots of issues still open, but just asking for updated WD
  <AmeliaBR> https://drafts.csswg.org/css-color-4/#changes-from-20160705

  fantasai: Any changes in scope?
  chris: No just improvements to what's there
  chris: Actually, one change in scope, removed color modification
         function
  chris: It was problematic and people weren't happy with it
  chris: We need functionality like that, but not that particular thing
  chris: Became an issue that people were trying to implement what was
         on /TR and we didn't want that implemented

  astearns: any objections to publishing?
  <florian> +1 to publication

  RESOLVED: Updated WD of css-color-4

CSS Pseudo Elements
===================

Identity of Element.pseudo() return value
-----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3607

  heycam: Last time we discussed this on a call, I was suggesting that
          the pseudo() function which returns a CSSPseudoElement object
  heycam: should always return the same object regardless of what
          values content has
  heycam: just so that we don't have to rely on what the current style
          state is to know when these objects should be dropped and
          recreated
  heycam: It felt a little strange at the time
  heycam: One thing that might argue against returning same object is
          if we have an API in the future that can create from script
          one of these objects and insert it into the tree
  heycam: Might be problematic to have stable object identity created
          for style, vs created from script
  heycam: But that's similar to what we do for @font-face

  TabAtkins: If you re-parse the style sheet, we'll create new objects
  myles: Actually, I spent a week of my time making that not true.
  TabAtkins: Can you open an issue on not doing that?
  myles: I originally wanted to do the thing you said
  myles: It was brought to my attention that it was very common in JS
         that authors would tack on properties to random objects
  myles: so you can't just delete and recreate them
  futhark: For Blink implementation, we used to recreate the
           pseudo-element internally when content changed, but we
           don't do that anymore
  futhark: When content property changes, we regenerate ... but the
           object stays the same
  emilio: But you still regenerate when you switch content property to
          none and back again, right?
  TabAtkins: If you turn content to none and then ask for the pseudo,
             you do return an object that you can return style on
             right?
  futhark: Are you talking about the pseudo() method or gCS()
  TabAtkins: pseudo()
  futhark: We don't implement it

  emilio: Do we want to keep them lightweight objects or do we add
          .style?
  emilio: If we add .style we need to keep the ? around anyway
  fantasai: Currently we've dropped .style from the spec
  TabAtkins: Wait, we dropped .style?
  heycam: We kept .type and .element and it's an event target
  TabAtkins: OK
  emilio: If you add some stateful thing that we don't want to
          disappear randomly, then keeping object itself around is not
          a huge deal because you need to keep that info around
  emilio: but if not, then recreating it would be better
  TabAtkins: I think it should have .style
  TabAtkins: later
  TabAtkins: Because pseudos act like DOM elements, they fill a
             similar purpose
  TabAtkins: Having object identity work it's nice
  TabAtkins: Without that it's more annoying
  TabAtkins: ...

  TabAtkins: Myles's argument about FontFace objects suggests that
             they should stay around on these objects, too.
  myles: I don't know how applicable that argument is to pseudos
  dbaron: I think one other comment about expandos is that CSSOM
          objects are historically one of the objects where expandos
          don't stay around
  dbaron: They stay around in lots of places, but not in CSSOM objects
  TabAtkins: Is it just font face objects that are connected, or
             [missed]
  myles: Font face rules will change... I don't remember.
  <AmeliaBR> https://developer.mozilla.org/en-US/docs/Glossary/Expando
             "Expando properties are properties added to DOM nodes
             with JavaScript, where those properties are not part of
             the object's DOM specification"
  <AmeliaBR> in case anyone else hadn't heard that JS jargon before...

  florian: Another argument in favor of long-lived is if they're not,
           we need to specify in detail what their lifecycles are
  florian: And if we don't we'll expose a lot of implementation details
  florian: Do you regenerate on content property changing from one
           string to another? Flip to none and back? a display : none
           subtree?
  florian: etc.
  TabAtkins: If we just make the element have a weak ref to its
             pseudo, then expandos let you observe GC.
  TabAtkins: Need to be either long-lived or regenerated on every call
  myles: Most important part is that right now it's undefined when the
         CSS engine decides to reparse rules or recreate derived
         objects
  myles: That's pretty important for optimization
  myles: so tying JS-visible semantics to that schedule would be scary
  myles: Instead we should define something more rigorous

  dbaron: Why is your GC idea not viable?
  TabAtkins: It allows you to detect when GC happens by seeing how
             long the expando survives
  dbaron: Traditional way around that is that the expando makes it not
          collectible
  TabAtkins: OK. My idea was to just hold it as a weak ref
  dbaron: I think your weak ref idea is workable if we make expandos
          not collectible.
  myles: It's true in our engine also
  TabAtkins: If that's the case, then all the exposed possibilities
             for GC are handled if expando force a strong reference
  TabAtkins: Incompatible with .style

  fantasai: One concern was about keeping around a lot of memory if
            you iterate the entire tree
  fantasai: If the pseudo doesn't generate a box, you return null, but
            as soon as you generate a box you generate the object and
            keep it around
  emilio: That's also incompatible with making that API work with
          stuff like selection
  emilio: For ::first-line ::first-letter, fine, but won't work for
          some other stuff
  TabAtkins: I think returning null is OK only for things that don't
             exist, like the name is invalid
  <fremy> +1
  fantasai: Shouldn't that throw an error?
  TabAtkins: No
  astearns: We already talked about that

  florian: How long-lived is it?
  heycam: So we always return the same object, and it's kinda like
          it's connected to the element you call it on
  TabAtkins: You're allowed to drop the object if doing so is
             unobservable
  TabAtkins: e.g if no expando, no references, can drop it and
             recreate it
  TabAtkins: I guess you can't observe object identity without a
             reference

  smfr: Same object in IDL?
  TabAtkins: That's advisory in the IDL. Have to say in algorithm what
             happens
  myles: Can we make another IDL attribute that means "for real"? :)
  heycam: What it means for a particular API is not particularly
          clear, so need to say in the prose what type of object and
          stuff.
  myles: So it means nothing
  heycam: It's a hint to the JS engine, that's all.
  florian: There's a hint to the spec reader that there's some prose
           somewhere that matters?
  TabAtkins: Yes

  astearns: So afaict, the proposed resolution is that pseudo() will
            return the same object always
  astearns: and we will have text suggesting that this can be GC if
            that is unobservable
  <TabAtkins> Proposed Resolution: pseudo() must always return the
              same object (up to observability)
  <TabAtkins> "same object" for a given element/pseudo pair
  astearns: Objections/concerns?

  RESOLVED: pseudo() must always return the same object. Note that
            object can be GC'd if this is unobservable.

Re: meetings

Source: public-mathonwebpages@w3.org Mail Archives • Han (laughinghan@gmail.com) • March 21, 2019 • Permalink

Shoutout to Peter for all the organizational work you've done.

Han


On Thu, Mar 21, 2019 at 12:36 PM Kaveh Bazargan <
kaveh@rivervalleytechnologies.com> wrote:

> I need to thank you too for all your effort, although I have not been able
> to make any of the meetings. What you all are doing is an important subject.
>
> Regards
> Kaveh
>
> On Thu, 21 Mar 2019 at 19:30, Joanmarie Diggs <jdiggs@igalia.com> wrote:
>
>> Also please remember that with respect to accessibility support, the
>> ARIA Working Group is happy to help in any way we can.
>>
>> A number of members of this CG have already joined ARIA, which is great.
>> And any math-specific needs can be raised at the dedicated
>> first-meeting-of-the-month math-topic slot. (They can, of course, be
>> raised at any time; the dedicated slot is to prevent people from having
>> to go to meetings that might be irrelevant to them.)
>>
>> If there's anything else I or ARIA can do to help the effort, you know
>> where to find me. :)
>>
>> --joanie
>>
>> On 3/21/19 12:32 PM, Daniel Marques wrote:
>> > Hi Peter,
>> >
>> > That's a pity but fair. I would like to thank you for all efforts done
>> > during all this time.
>> >
>> > But remember that despite no meetings, maths are already in the browser
>> > in one way or another.
>> >
>> > Good luck! We are in time to setup a meeting if the occasion arises!
>> >
>> > Regards,
>> >
>> > Dani
>> >
>> >
>> >
>> > On Wed, Mar 20, 2019 at 11:43 AM Peter Krautzberger
>> > <peter@krautzource.com <mailto:peter@krautzource.com>> wrote:
>> >
>> >     Hi everyone,
>> >
>> >     Due to the lack of interest, there will be no meetings until further
>> >     notice.
>> >
>> >     Best,
>> >     Peter.
>> >
>> >
>> > ------------------------------------------------------------------------
>> > MathType 7 is out! Check the new version at wiris.com/mathtype
>> > <http://www.wiris.com/mathtype?utm_source=emailfooter>
>>
>>
>>
>
> --
> Kaveh Bazargan PhD
> Director
> River Valley Technologies <http://rivervalleytechnologies.com/> • Twitter
> <https://twitter.com/kaveh1000> • LinkedIn
> <https://www.linkedin.com/in/bazargankaveh/>
>

Re: meetings

Source: public-mathonwebpages@w3.org Mail Archives • Kaveh Bazargan (kaveh@rivervalleytechnologies.com) • March 21, 2019 • Permalink

I need to thank you too for all your effort, although I have not been able
to make any of the meetings. What you all are doing is an important subject.

Regards
Kaveh

On Thu, 21 Mar 2019 at 19:30, Joanmarie Diggs <jdiggs@igalia.com> wrote:

> Also please remember that with respect to accessibility support, the
> ARIA Working Group is happy to help in any way we can.
>
> A number of members of this CG have already joined ARIA, which is great.
> And any math-specific needs can be raised at the dedicated
> first-meeting-of-the-month math-topic slot. (They can, of course, be
> raised at any time; the dedicated slot is to prevent people from having
> to go to meetings that might be irrelevant to them.)
>
> If there's anything else I or ARIA can do to help the effort, you know
> where to find me. :)
>
> --joanie
>
> On 3/21/19 12:32 PM, Daniel Marques wrote:
> > Hi Peter,
> >
> > That's a pity but fair. I would like to thank you for all efforts done
> > during all this time.
> >
> > But remember that despite no meetings, maths are already in the browser
> > in one way or another.
> >
> > Good luck! We are in time to setup a meeting if the occasion arises!
> >
> > Regards,
> >
> > Dani
> >
> >
> >
> > On Wed, Mar 20, 2019 at 11:43 AM Peter Krautzberger
> > <peter@krautzource.com <mailto:peter@krautzource.com>> wrote:
> >
> >     Hi everyone,
> >
> >     Due to the lack of interest, there will be no meetings until further
> >     notice.
> >
> >     Best,
> >     Peter.
> >
> >
> > ------------------------------------------------------------------------
> > MathType 7 is out! Check the new version at wiris.com/mathtype
> > <http://www.wiris.com/mathtype?utm_source=emailfooter>
>
>
>

-- 
Kaveh Bazargan PhD
Director
River Valley Technologies <http://rivervalleytechnologies.com/> • Twitter
<https://twitter.com/kaveh1000> • LinkedIn
<https://www.linkedin.com/in/bazargankaveh/>

Re: meetings

Source: public-mathonwebpages@w3.org Mail Archives • Joanmarie Diggs (jdiggs@igalia.com) • March 21, 2019 • Permalink

Also please remember that with respect to accessibility support, the
ARIA Working Group is happy to help in any way we can.

A number of members of this CG have already joined ARIA, which is great.
And any math-specific needs can be raised at the dedicated
first-meeting-of-the-month math-topic slot. (They can, of course, be
raised at any time; the dedicated slot is to prevent people from having
to go to meetings that might be irrelevant to them.)

If there's anything else I or ARIA can do to help the effort, you know
where to find me. :)

--joanie

On 3/21/19 12:32 PM, Daniel Marques wrote:
> Hi Peter,
> 
> That's a pity but fair. I would like to thank you for all efforts done
> during all this time.
> 
> But remember that despite no meetings, maths are already in the browser
> in one way or another.
> 
> Good luck! We are in time to setup a meeting if the occasion arises!
> 
> Regards,
> 
> Dani
> 
> 
> 
> On Wed, Mar 20, 2019 at 11:43 AM Peter Krautzberger
> <peter@krautzource.com <mailto:peter@krautzource.com>> wrote:
> 
>     Hi everyone,
> 
>     Due to the lack of interest, there will be no meetings until further
>     notice.
> 
>     Best,
>     Peter.
> 
> 
> ------------------------------------------------------------------------
> MathType 7 is out! Check the new version at wiris.com/mathtype
> <http://www.wiris.com/mathtype?utm_source=emailfooter>

Re: meetings

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • March 21, 2019 • Permalink

Hi Peter,

That's a pity but fair. I would like to thank you for all efforts done
during all this time.

But remember that despite no meetings, maths are already in the browser in
one way or another.

Good luck! We are in time to setup a meeting if the occasion arises!

Regards,

Dani



On Wed, Mar 20, 2019 at 11:43 AM Peter Krautzberger <peter@krautzource.com>
wrote:

> Hi everyone,
>
> Due to the lack of interest, there will be no meetings until further
> notice.
>
> Best,
> Peter.
>

-- 

MathType 7 is out! Check the new version at wiris.com/mathtype 
<http://www.wiris.com/mathtype?utm_source=emailfooter>

meetings

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • March 20, 2019 • Permalink

Hi everyone,

Due to the lack of interest, there will be no meetings until further notice.

Best,
Peter.

Re: Styling Content in <img> Elements

Source: www-style@w3.org Mail Archives • Tab Atkins Jr. (jackalmage@gmail.com) • March 13, 2019 • Permalink

On Tue, Mar 12, 2019 at 6:19 PM Adam Sobieski <adamsobieski@hotmail.com> wrote:
> CSS Working Group,
> MathML Refresh Community Group,
>
> In a recent MathML Refresh Community Group teleconference call, we briefly discussed styling content (e.g. SVG) loaded via <img> elements.
>
> If there isn’t already a means of utilizing CSS to style content loaded via <img> elements, I would like to propose a new combinator – perhaps “>>”.
>
> img >> svg { background-color: blue }
>
> What do you think?

I've moved your email to a GitHub issue:
https://github.com/w3c/csswg-drafts/issues/3730

~TJ

Styling Content in <img> Elements

Source: www-style@w3.org Mail Archives • Adam Sobieski (adamsobieski@hotmail.com) • March 13, 2019 • Permalink

CSS Working Group,
MathML Refresh Community Group,

In a recent MathML Refresh Community Group teleconference call, we briefly discussed styling content (e.g. SVG) loaded via <img> elements.

If there isn’t already a means of utilizing CSS to style content loaded via <img> elements, I would like to propose a new combinator – perhaps “>>”.

img >> svg { background-color: blue }

What do you think?


Best regards,
Adam Sobieski

Regrets RE: Meeting today

Source: public-mathonwebpages@w3.org Mail Archives • George Kerscher (kerscher@montana.com) • March 11, 2019 • Permalink

Regrets flying to CSUN/g
 
From: Peter Krautzberger <peter@krautzource.com> 
Sent: Monday, March 11, 2019 7:49 AM
To: mathonweb <public-mathonwebpages@w3.org>
Subject: Meeting today
 
Hi everyone,
 
Regrets from me today, I have a conflict.
 
Best,
Peter.

Re: Meeting today

Source: public-mathonwebpages@w3.org Mail Archives • David Farmer (farmer@aimath.org) • March 11, 2019 • Permalink


Me too.

On Mon, 11 Mar 2019, Peter Krautzberger wrote:

> Hi everyone,
> Regrets from me today, I have a conflict.
> 
> Best,
> Peter.
> 
>

Meeting today

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • March 11, 2019 • Permalink

Hi everyone,

Regrets from me today, I have a conflict.

Best,
Peter.

W3C TPAC 2019 - Will your Community Group meet in Fukuoka?

Source: public-mathonwebpages@w3.org Mail Archives • Alexandra Lacourba (alex@w3.org) • March 07, 2019 • Permalink

[This e-mail is bcc'ed to all public lists of existing W3C Community 
Groups]

Dear participants of the W3C Community Groups,

Once again, the Community Groups have the possibility to meetduring 
TPAC2019 which willbe held in Fukuoka, Japan at the "Hilton Fukuoka Sea 
Hawk"[1].

TPAC 2019
16 - 20 September 2019
Fukuoka, Japan
https://www.w3.org/2019/09/TPAC-template/Overview.html We ask you to 
start discussions to determine whether and when yourgroup(s) would like 
to meetduring this week. Please complete the following questionnaire by 
12 April 2019:

https://www.w3.org/2002/09/wbs/1/CGsTPAC2019/ W3C Community Groups can 
hold 2-hour meetings on Monday, Tuesday, Thursday, Friday. The Available 
slots willbe: 8:30 - 10:30 10:30 - 12:30 13:30 - 15:30 15:30 - 17:30 We 
willbe able to accommodate 4 meetings per day, so 16 over the entire 
TPACweek. Outside of their Community Groupmeetings, non W3C-Member CG 
participants may attend as observers the Working and Interest groups 
meetings who accept observers, as well as the Technical Plenary Day 
willbe held on 18 September from 08:30-18:00. There will be registration 
fees to offset a portion of the meeting costs. If you have any 
questions, please contact <w3t-tpregister@w3.org 
<mailto:w3t-tpregister@w3.org>>. We look forward to another successful 
meeting!

For the W3C TPAC 2019 Event team
Alexandra Lacourba
W3C Global Event Coordinator

[1] 
https://www3.hilton.com/en/hotels/japan/hilton-fukuoka-sea-hawk-FUKHIHI/index.httm

RE: [MathML4] Multiple Formats for Presentation and Semantics

Source: www-math@w3.org Mail Archives • Adam Sobieski (adamsobieski@hotmail.com) • February 28, 2019 • Permalink

Math Working Group,
MathML Refresh Community Group,

I put together some discussion notes on these MathML4 and related Web technology topics. Attached is a PDF version. I hope this brainstorming is useful to the MathML4 endeavor and, in the event of interest, I could open a Google Documents document of this content.


Presentation and Semantics

<math id="eq1">

<presentation>

<annotation-xml encoding="application/xhtml+xml">...</annotation-xml>

<annotation-xml encoding="application/svg+xml">...</annotation-xml>

<annotation encoding="image/png" src="data:..." />

<annotation-xml encoding="MathML-Presentation">...</annotation-xml>

</presentation>

<semantics>

<annotation-xml encoding="application/openmath+xml">...</annotation-xml>

<annotation-xml encoding="MathML-Content">...</annotation-xml>

</semantics>

</math>

Presentation, Semantics and Metadata

<math id="eq1">

<presentation>

<annotation-xml id="eq1-p-xhtml" encoding="application/xhtml+xml">...</annotation-xml>

<annotation-xml id="eq1-p-svg" encoding="application/svg+xml">...</annotation-xml>

<annotation id="eq1-p-png" encoding="image/png" src="data:..." />

<annotation-xml id="eq1-p-mathmlp" encoding="MathML-Presentation">...</annotation-xml>

</presentation>

<semantics>

<annotation-xml id="eq1-s-om" encoding="application/openmath+xml">...</annotation-xml>

<annotation-xml id="eq1-s-mathmlc" encoding="MathML-Content">...</annotation-xml>

</semantics>

<metadata>

<annotation-xml encoding="application/rdf+xml">...</annotation-xml>

<annotation encoding="application/json+ld">...</annotation>

</metadata>

</math>

Multiple Notations

Expression “metadata” could be utilized to describe and interrelate multiple “presentation” annotations, e.g. to describe “presentation” annotations as utilizing distinct notations. With ontology for describing “presentation” annotations’ notations in “metadata”, one or more JavaScript libraries could be authored to facilitate navigating notation, e.g. selecting which notations are displayed for expressions in documents.

<math id="eq1">

<presentation>

<annotation-xml id="eq1-p-n1" encoding="MathML-Presentation">...</annotation-xml>

<annotation-xml id="eq1-p-n2" encoding="MathML-Presentation">...</annotation-xml>

<annotation-xml id="eq1-p-n3" encoding="MathML-Presentation">...</annotation-xml>

</presentation>

<semantics>

<annotation-xml id="eq1-s" encoding="MathML-Content">...</annotation-xml>

</semantics>

<metadata>

<annotation-xml encoding="application/rdf+xml">...</annotation-xml>

</metadata>

</math>



Should, instead, notation be an attribute on “presentation” annotations?

<math id="eq1">

<presentation>

<annotation-xml notation="Notation 1" encoding="MathML-Presentation">...</annotation-xml>

<annotation-xml notation="Notation 2" encoding="MathML-Presentation">...</annotation-xml>

<annotation-xml notation="Notation 3" encoding="MathML-Presentation">...</annotation-xml>

</presentation>

<semantics>

<annotation-xml id="eq1-s" encoding="MathML-Content">...</annotation-xml>

</semantics>

</math>

Multiple Presentation Formats and Multiple Notations

This example shows a combination of multiple presentation formats with multiple notations.

<math id="eq1">
<presentation>
<annotation-xml notation="Notation 1" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml notation="Notation 2" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml notation="Notation 3" encoding="application/xhtml+xml">...</annotation-xml>
<annotation-xml notation="Notation 1" encoding="application/svg+xml">...</annotation-xml>
<annotation-xml notation="Notation 2" encoding="application/svg+xml">...</annotation-xml>
<annotation-xml notation="Notation 3" encoding="application/svg+xml">...</annotation-xml>
<annotation notation="Notation 1" encoding="image/png" src="data:..." />
<annotation notation="Notation 2" encoding="image/png" src="data:..." />
<annotation notation="Notation 3" encoding="image/png" src="data:..." />
<annotation-xml notation="Notation 1" encoding="MathML-Presentation">...</annotation-xml>
<annotation-xml notation="Notation 2" encoding="MathML-Presentation">...</annotation-xml>
<annotation-xml notation="Notation 3" encoding="MathML-Presentation">...</annotation-xml>
</presentation>
<semantics>
<annotation-xml encoding="application/openmath+xml">...</annotation-xml>
<annotation-xml encoding="MathML-Content">...</annotation-xml>
</semantics>
</math>

Internationalization

For scenarios where natural language is utilized in the “presentation” annotation content, a BCP47 language attribute can adorn annotation markup and “presentation” annotations can also be described in expression “metadata”.

<math id="eq1">
<presentation>
<annotation-xml id="eq1-p-l1" lang="en" encoding="MathML-Presentation">...</annotation-xml>
<annotation-xml id="eq1-p-l2" lang="fr" encoding="MathML-Presentation">...</annotation-xml>
</presentation>
<semantics>
<annotation-xml id="eq1-s" encoding="MathML-Content">...</annotation-xml>
</semantics>
<metadata>
<annotation-xml encoding="application/rdf+xml">...</annotation-xml>
</metadata>
</math>

Multimodality

“Presentation” annotations can include multimodal content, e.g. SSML or audio, and “presentation” annotations can also be described in expression “metadata”.

<math id="eq1">
<presentation>
<annotation-xml lang="en" encoding="MathML-Presentation">...</annotation-xml>
<annotation-xml lang="fr" encoding="MathML-Presentation">...</annotation-xml>
<annotation-xml lang="en" encoding="application/ssml+xml">...</annotation-xml>
<annotation-xml lang="fr" encoding="application/ssml+xml">...</annotation-xml>
<annotation-xml lang="en" encoding="audio/mpeg" src="...">...</annotation-xml>
<annotation-xml lang="fr" encoding="audio/mpeg" src="...">...</annotation-xml>
</presentation>
<semantics>
<annotation-xml encoding="MathML-Content">...</annotation-xml>
</semantics>
</math>

Quality Scores

With quality score attributes, algorithms for selecting content from alternatives can resemble agent-driven or reactive content negotiation (https://en.wikipedia.org/wiki/Content_negotiation).

<math id="eq1">

<presentation>

<annotation-xml q="0.9" encoding="application/xhtml+xml">...</annotation-xml>

<annotation-xml q="0.9" encoding="application/svg+xml">...</annotation-xml>

<annotation q="0.9" encoding="image/png" src="data:..." />

<annotation-xml q="1.0" encoding="MathML-Presentation">...</annotation-xml>

</presentation>

<semantics>

<annotation-xml encoding="application/openmath+xml">...</annotation-xml>

<annotation-xml encoding="MathML-Content">...</annotation-xml>

</semantics>

</math>

Remote Content

<math id="eq1">

<presentation>

<annotation-xml encoding="application/xhtml+xml" src="eq1.xhtml" />

<annotation-xml encoding="application/svg+xml" src="eq1.svg" />

<annotation encoding="image/png" src="eq1.png" />

<annotation-xml encoding="MathML-Presentation" src="eq1.mmlp" />

</presentation>

<semantics>

<annotation-xml encoding="application/openmath+xml" src="eq1.om" />

<annotation-xml encoding="MathML-Content" src="eq1.mmlc" />

</semantics>

</math>

Content Negotiation

Using agent-driven or reactive content negotiation over HTTP, URL’s can be provided for “presentation”, “semantics” and “metadata” (https://en.wikipedia.org/wiki/Content_negotiation).

<math id="eq1">

<presentation src="eq1.php?content=presentation" />

<semantics src="eq1.php?content=semantics" />

<metadata src="eq1.php?content=metadata" />

</math>

Toward a Single URL per Mathematical Expression

<math id="eq1" src="eq1.php" />

Extensibility

Are there any other varieties of content for a mathematical expression beyond “presentation”, “semantics” and “metadata”? Might we want to include “other” for extensibility?

<math id="eq1">

<presentation>

<annotation-xml id="eq1-p-xhtml" encoding="application/xhtml+xml">...</annotation-xml>

<annotation-xml id="eq1-p-svg" encoding="application/svg+xml">...</annotation-xml>

<annotation id="eq1-p-png" encoding="image/png" src="data:..." />

<annotation-xml id="eq1-p-mathmlp" encoding="MathML-Presentation">...</annotation-xml>

</presentation>

<semantics>

<annotation-xml id="eq1-s-om" encoding="application/openmath+xml">...</annotation-xml>

<annotation-xml id="eq1-s-mathmlc" encoding="MathML-Content">...</annotation-xml>

</semantics>

<metadata>

<annotation-xml encoding="application/rdf+xml">...</annotation-xml>

<annotation encoding="application/json+ld">...</annotation>

</metadata>

<other rel="http://www.<http://www.semantic.com/example-uri/>example.com/semantic-uri/<http://www.semantic.com/example-uri/>">

<annotation-xml id="eq1-o" encoding="...">...</annotation-xml>

</other>

</math>

Interrelating Expressions and Mathematical Proofs

Is content which interrelates mathematical expressions, e.g. for mathematical proofs, expression “metadata” or is it another variety of content?

Clipboarding

Some preliminary thoughts on clipboarding mathematical expressions include a consideration of multipart MIME. A mathematics expression can map to data of type multipart/related which contains multiple, nested contents of type multipart/alternative (https://en.wikipedia.org/wiki/MIME#Multipart_messages). The root part or the main part of the multipart/related message, the part which references content in the other parts, can be the “metadata” content.

Content Negotiation and Semantic Web Formats

In the section Multiple Notations, it was asked whether mathematical notation should be an attribute on “presentation” annotations.

We could also add “notation” to a list of parameters for local and remote content negotiation: encoding, language, quality and notation. Perhaps, the parameters of content negotiation could be extensible. Adding a parameter for “notation” could be as simple as utilizing a URI in content returned during agent-driven or reactive content negotiation.

“Unfortunately HTTP leaves the format of the list of representations and metadata along with selection mechanisms unspecified.” – https://en.wikipedia.org/wiki/Content_negotiation

If the format of the content returned accompanying an HTTP 300 or 406 during agent-driven or reactive content negotiation were a Semantic Web format, e.g. RDF/XML, then these matters would be tractable. We could readily add “notation” as a content negotiation parameter.

We could specify the use of Semantic Web formats, e.g. RDF/XML (application/rdf+xml), during agent-driven or reactive content negotiation. This would facilitate extensibility in terms of the parameters of content negotiation (adding “notation” to encoding, language and quality).



Best regards,
Adam Sobieski





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