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.
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.
A typical refreshable braille display has a row of braille cells with a button above each cell as illustrated in the figure of a HIMS Braille Edge 40. The purpose of a button is to move the insertion point (IP) to the character or abbreviation represented by cell below the button.
This post discusses how pressing a cell button associated with a
math braille cell can move the text selection to the closest
matching character position (cp) in the corresponding math zone.
The algorithm accounts for the many-to-many relationship between
braille cells and OfficeMath character positions (cp’s). A single
math symbol may be represented by multiple braille cells (‘=’ is
represented by the four braille cells “⠀⠨⠅⠀”) and characters appear
in math zones that aren’t shown on a braille display (there’s a
start delimiter for 𝑎² that has no counterpart in the corresponding
braille “⠁⠘⠆”. This is discussed further in
Math Braille UI and below. And there are other cp differences
such as hidden text as discussed in the post
Using MathML-Based Speech to Edit Math in Different Math
Models. In math braille, abbreviations are not used, a
simplification that
allows Nemeth math braille to be embedded in the braille for
any language.
The algorithm given here to synchronize the math-zone insertion point with a braille-cell button is analogous to the algorithm for finding the cp from a mouse-button hit on a line of text. For the latter, you measure the text until its width equals or passes the hit position. For the braille-cell button press, you
The left and right arrow keys can traverse every valid cp in an OfficeMath math zone, while the braille-cell buttons only have access to cp’s that have braille counterparts. Let’s consider the two cases mentioned in the introduction. The ‘=’ sign is represented by “⠀⠨⠅⠀”. If you press the button above the starting braille space (U+2800), the corresponding math-zone cp should be in front of the ‘=’. Remember that insertion points in rich text like math zones are in between characters, not on top of characters. If you press a button above any of the remaining three braille characters, the math-zone cp (IP) should follow the ‘=’. Meanwhile a single → key press in front of the ‘=’ moves past the ‘=’.
Now consider 𝑎². In a math zone this is represented by {𝑎|2}, where { stands for the superscript-object start delimiter, | is the argument separator, and } is the superscript-object end delimiter. In RichEdit these delimiters are given by the Unicode characters U+FDD0, U+FDEE, and U+FDEF, respectively. The start delimiter has no counterpart in the corresponding superscript braille string “⠁⠘⠆”. So, pressing the braille-cell button above the ‘⠁’ could set the IP in front of the superscript object or at the start of the superscript-object base (in front of the 𝑎). Structured navigation that selects the whole superscript object or just the ‘⠁’ could be used to choose between these two possibilities. Meanwhile a single → key press in front of the superscript object moves to the start of the superscript-object base.
The subscript object 𝑎₂ also appears as {𝑎|2} in the OfficeMath backing store. The object type is specified in the character formatting of the start delimiter. But in Nemeth math notation, 𝑎₂ is given simply by “⠁⠆”. The subscript operator ‘⠰’ is implied. In computer braille notation, this is “A2”. So, for such simple subscript objects, the start, middle, and end points are all ambiguous. For example, in the string “⠁⣀⠆”, with ‘⣀’ marking the insertion point, the next character typed could be at the end of the subscript base (first argument) or at the start of the subscript (second argument). Math Braille UI disambiguates the two by including a dot 8 (‘⠠’) in the braille-cell character(s) in the object argument that contains the insertion point. If the IP is at the start of the subscript, the math braille for 𝑎₂ is “⠁⣀⢆”, whereas if it’s at the end of the base, the math braille is “⢁⣀⠆”.
Similar cases include the ends of integrands, summands, accents and math-function objects as well as optional arguments like missing integral limits and radical indices (a square root has a missing radical index).
A braille user should have at least three kinds of OfficeMath navigation: braille-cell buttons and vertical scrolling, structured navigation, and the ←/→ keys. Currently, I have to use a keyboard for structured navigation and the arrow keys. But we should be able to assign keys on refreshable braille displays to perform such navigation in addition to the braille-cell button navigation.
The MathJax team has been working hard on a major rewrite of MathJax from the ground up, with the goal of modernizing MathJax’s internal infrastructure, bringing it more flexibility for use with contemporary web technologies, making it easier to use with NodeJS for pre-processing and server-side support, and making it faster to render your mathematics. We have made headway in all these areas and we are pleased to announce the fourth public beta release of MathJax v3.
The code for the release is available in the beta branch of the MathJax v3 github repository.
The mj3-demos repository includes examples of how to use MathJax v3 in web browsers, including interactive examples, custom configurations, custom tex extensions, and custom builds that you can use as a starting point for your own projects. See the instructions in that repository for more details.
The mj3-demos-node repository includes examples for how to use MathJax v3 in NodeJS applications, and includes sample tools and examples of how to use a number of MathJax v3’s features.
This beta version includes two input processors (TeX and MathML) and two output processors (CommonHTML and SVG). Other input and output processors (e.g., AsciiMath input) will be added in the future.
The current TeX input processor has all the core functionality of the MathJax v2 TeX input, and nearly all the extensions that are now available in v3.
The CommonHTML and SVG output implement all the MathML elements that they do in v2, but do not yet include support for line breaking (neither automatic nor explicit ones); this will be implemented in a later version. Both output renderers currently only support the MathJax TeX font; other fonts will be added in the future.
This beta includes a number of important improvements over the beta.3 version.
The biggest change is the ability to create MathJax “components” that can be dynamically loaded by MathJax as needed (much as could be done in version 2). This allows portions of MathJax to be bundled together into components that include most or all of what you need to run MathJax, but still allows less-used pieces to be loaded on demand later when needed. This is similar to v2’s combined configuration files and TeX extensions.
The main goal of these components is to use them for the delivery of MathJax from the CDNs that host MathJax. This allows you to customize the MathJax components that you use without having to have (as single files on the CDN) every possible combination of parts that anyone would need packaged together. We will provide a number of all-in-one packages that include an input and output jax together with the data for a font to be used, but also will provide separate components for the individual input and output jax, fonts, TeX extensions, and so on, so that you can mix-and-match them as needed.
MathJax components can be used in the browser as well as on the
server in NodeJS
applications, so browser and server-side applications can use the
same code base and configurations. Components can be combined
together into larger packages, either with other MathJax
components, or with your own code, via webpack, for example.
Moreover, the tools for building components are available so that you can create your own custom components that you can serve from your own website if you have special needs not addressed by the CDN. For example, authors writing TeX extensions for MathJa can create their own components that can be loaded into MathJax from a different server even if the core MathJax is loaded from a CDN.
Although components are a convenient way of working with
MathJax, those writing NodeJS scripts that use MathJax need not
use the components as we have packaged them at all; they can
continue to import MathJax into their projects directly, as in
previous beta versions.
The component system described above can be configured using a
global variable MathJax that
you set before loading the main MathJax component that you are
planning to use. The MathJax
variable specifies configuration blocks for the various components
in much the same was as was done in version 2 (this is illustrated
in the examples below, and described in more detail in a separate
section below). MathJax will modify this global variable to include
the methods and data that it creates during the startup process for
your use in your applications.
The mechanism for rendering expressions in previous beta
versions of MathJax 3 involved calling a sequence of MathJax
commands to perform the individual actions required to find,
compile, typeset, and insert the math into the page. These
functions are still available, but there are now several new
functions to make that process easier and more natural to perform.
The render() method of the
MathDocument and
MathItem classes will
perform all the actions normally needed for typesetting math to the
page, and the convert()
method will perform conversion from the input format to the output
format of the page (or to MathML, which is used internally by
MathJax).
These methods use an internal list of actions to be taken when
they are called, and those lists are updated automatically when
extensions are loaded. For example, when the semantic-enrichment
extension is loaded, the action that performs the enrichment is
added to render() and
convert() automatically, so
you don’t have to call the extension’s methods yourself. You can
even add your own actions to the list, if you want, or could remove
the automatic ones to fully customize the rendering process.
If you use the MathJax components described above, MathJax will
set up short-hand functions for you for typesetting the page or
converting from input to output formats. For example, if you load
the input/tex and
output/chtml components (or
the tex-chtml combonent that
combines them), you automatically get methods Typeset() and TypesetPromise() for typesetting the
page, and tex2chml(),
tex2chtmlPromise(),
tex2mml(), and tex2mmlPromise() that convert from TeX
to HTML or MathML. You also get texReset(), TypesetClear(), and chtmlStylesheet() that reset TeX’s
labels and equation numbers, reset the typesetting system entirely
(the information about CSS used, font caches, etc.), and produce
the CSS stylesheet object used by CommonHTML for the expressions
you have processed so far. The ones ending in Promise return a promise that is
resolved when the math is completed (use this if there is a chance
that an external module needs to be loaded, e.g., with \require), while the others perform the
typesetting or conversion and return the result immediately (they
will throw an error if an external module needs to be loaded).
If you are using the MathJax components, then the MathJax.startup object includes
references to the important objects created by MathJax
automatically, like the input and output jax, the DOM adaptor, and
the MathDocument. You may reference these as needed in order to
access their methods for more special-purpose needs. Some of the
examples below illustrate this.
A contextual menu similar to the one in version 2 has been added to MathJax v3 in this beta version. It has the actions familiar from version 2, but also includes some new features like copying to the clipboard.
This beta version now includes support for assistive technology via the generation of speech strings attached to the math elements, and via an interactive expression explorer like the one in version 2. These can be activated using the contextual menu, as in version 2, or by importing the a11y components into your node project or custom webpacked version of MathJax.
The CommonHTML output now produces only the CSS needed for the
expressions on the page, rather than the CSS for every possible
character in the font being used. This reduces the number of CSS
rules used by CommonHTML considerably, and improves performance of
browser refreshes and zooming. If you use NodeJS applications to preprocess math
expressions and capture the CSS output to a separate CSS file, you
may need to process all the math expressions before generating the
CSS file. Alternatively, there is a new adaptiveCSS option for the CommonHTML
output jax that you can set to false to have MathJax return to the
beta.3 behavior.
The SVG output now includes the option of caching the glyphs
used to render the mathematics so that the paths are shared if a
character is used more than once. The cache can either be global
(all expressions on the page share a common cache) or local (each
expression has a cache for glyphs used within it, but they are not
shared between expressions). This can be set using the fontCache option for the SVG jax, and it
can be set to 'global',
'local', or 'none'. The default is 'local' so that conversion of math to
SVG will produce self-contained SVG expressions.
As part of the new components feature discussed above, the TeX
input jax can load TeX extensions in much the same way that v2
could. This is accomplished through the new require extension that implements the
\require macro to load
extensions. There is also and autoload extension that will load
extensions automatically when their macros or environments are
first used. These are included in the default input/tex component, so you if you use
that component (or one of the combined components based on it, like
tex-chtml or tex-svg), you should have access to
these extensions automatically. For example, \require{physics} will load the
physics package.
Another new TeX package is the configMacros extension that allows you
to configure pre-defined macros using the TeX input jax options,
much like you could do in v2.
The new tagFormat
extension allows you to customize how tags are handled in MathJax,
and provides the equivalent of the formatNumber(), formatTag(), formatID() and formatURL() options of the TeX
equationNumbers
configuration block from v2.
The new braket extension
implements the physics bra-ket notation macros. They will be loaded
automatically if you use the input/tex component, or include the
autoload extension in your
project.
In version 2, the \color
macro worked in a non-standard way. The LaTeX \color macro acts as a switch, to change
the current color for all the math that follows it, while the
MathJax version took a second argument that enclosed the math to be
colored. Version 2 included a color extension that implemented the
LaTeX \color behavior, but
it was not loaded by default.
In version 3, the LaTeX \color macro will be the default
behavior if you are using the input/tex or input/tex-full components, or any
component build on them (e.g., tex-chtml or tex-svg). You can restore the v2
behavior by setting color:
[] in the autoload
configuration for the tex
component (when using input/tex), or by removing the
color extension from the
package list using packages:
{'[-]': ['color']} in the tex configuration (for input/tex-full).
This is the fourth public beta release of MathJax v3.
Mathjax v3 is in beta release. Do not use this in production, but please test it and report issues on the MathJax v3 issue tracker!
This is the final planned beta version. We expect an official 3.0 release in the near future.
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Getting images' aspect ratio right from html attributes (continued from Monday) ------------------------------------------------------- - After a few days to think about the proposal as there was no consensus on what was the best way forward - add new attributes (original plan) or do property mapping (new plan). - Chrome is committed to investigating further and will analyze both approaches before selecting one and putting the work into WICG. CSS Inline ---------- - RESOLVED: We'll add a separate property for this [first/last baseline values of `vertical-align`] (Issue #861: Should first/last baseline values of `vertical-align` belong to `alignment-baseline` or separate longhand?) Houdini <3 Text (aka Houdini and text layout) --------------------------------------------- - There are several different paths the group could take when Houdini builds its API for interacting with Text (Houdini Issue #854). These range from a region-like API, where your content flows from one box to the other to exposing glyph indices and font metrics through the API. These approaches also come with a similar range of potential for footguns. - Widely the group leaned toward collecting use cases and solving the safest of them first (that still would have broad usage) before extending the API further. - Exposing justification was one possible first step. Another possibility was a property set to assist minority languages such as what's being done in Graphite and AAT. - Work will continue one scoping out a preliminary feature set and drafting a proposal. CSS Text -------- - RESOLVED: Add the stable value [to text-wrap] (Issue #672: Allow for paragraph-level line breaking) ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/sf-2019 Scribe: argyle Getting images' aspect ratio right from html attributes (continued from Monday) ------------------------------------------------------- florian: My understanding is that we all agreed this would be a good idea if possible, and we should check if possible florian: Tab disagrees, I want to hear that florian: For context: "it" is using the width and height HTML attributes to trigger the intrinsic aspect ratio fantasai: Specifically, where we map the width and height HTML attributes to width and height CSS properties, we could also use them to calculate the ratio and also map that back to CSS (using the new aspect-ratio property). fantasai: That would solve the problem around the aspect ratio information would be lost due to waiting for the image to load, waiting to discover auto sizing fantasai: so the proposal was to do that instead of introducing new attributes to solve the same problem Rossen: What is the data we need to gather then? florian: So we don't break the web Rossen: For the width and height florian: Do we not agree? TabAtkins: Having width and height be presentation attributes, and not affecting those new and exciting ways TabAtkins: The other reason I liked it, some of the other things, like picture, you wanted to give an intrinsic size to them, and it feels semantically better to be specific about being intrinsic than doing css things that also set intrinsic sizes. florian: There's no intrinsic tools to do this * fantasai thinks ojan should be here <AmeliaBR> +1 to Tab's argument about `<picture><source intrinsicsize="...">` making more sense than width & height myles: What about canvas? myles: We should consider the interaction with canvas where w and h have other meanings other than mapping to css TabAtkins: It sets the backing store on width/height, which is compatible dbaron: ... If this is a major thing sites can do to improve loading, if a cms can just do this, that's great, and it means that lots of sites can get it cheaply dbaron: I think, if it's it's own attribute it we can do that, I don't think it's as safe to do if we're re-using width and height florian: If the cms wanted to check if there was previously a width and height, they could still inject the w/h and multiply by what's needed, but they also need to check min-height and max-height, and then it gets messy astearns: We're theorizing about things Ojan has experience in, at the most this conversation should inform what he continues to do as he tries to find a solution astearns: but I'm not sure I see the utility of theorizing when we have an experimenter florian: Utility is we don't need to experiment if we have other demos, not worth checking if we don't want to do it anyway <TabAtkins> `<style>img { width: 100%; }</style> <img intrinsicsize="350x450">` works by default. Changing it to <img width=350 height=450> doesn't work; you have to manually set `height: auto` in CSS too. jensimmons: I think the original intention behind what fantasai was saying, here's an idea, might be much simpler than adding new attributes, we'd like this considered jensimmons: I do think there's a way to do it that hooks into CMSes and existing things, instead of making it more complicated jensimmons: If only width is coming out of a cms, and there's no height, there's no mapping to intrinsic, we can map with that limited data jensimmons: Maybe there's something more complex needed, and we do both jensimmons: But I think there's an elegance here tapping into what we already have. Perhaps that's what ojan is intending jensimmons: Hey, we're going to solve some of this in css, and to have that really heard, .. that's what I'd like to see happen Rossen: Where does this leave us? jensimmons: Sounds like someone's going to find something out AmeliaBR: I think it's great, we're leveraging something that already works, but I think I agree with the arguments there's too many cases where things can get messy for repurposing AmeliaBR: If browsers implemented the attr() function that maps values to lengths, ... any image, grab these values, put them together, here's the ratio AmeliaBR: Not sure if there's utility if no one's has implemented it yet <jensimmons> +1 to what AmeliaBR just said <jensimmons> maybe that could even be included in a project called CSS Remedy TabAtkins: I feel like there's just more discussion, but in the way of being explicit with cases and approaches, and I don't know if I want to spend time trying to nail it down fantasai: There are advantages of using existing attributes. Like for images in pages already out there, we get the faster layout/loading for free. Info is already there fantasai: No updating cms, no html file updates, it would let browsers hook into it via current functionality jensimmons: There's 100,000s of sites that put height and width on images in the CMS already. Then in their code, put width: 100%; height: auto in their CSS. Decade of work is built that way, and likely aren't maintained jensimmons: Quick way to boost all sites by re-using existing attrs jensimmons: Don't get deep into picture element, ..., hey this is a performance thing, but it back in and it'll be faster jensimmons: Other proposals will use it for be used for simple and complicated things, and some it'll be too much fantasai: Historically, we've asked users to put weight and height on images for performance, all the way back into the 90s, and we'd be hooking into that advice. This proposal hooks into existing content and knowledge better. It won't only work on new things developed by people who keep up with latest tech. TabAtkins: Happy to do more discussion, but not confident enough to decide now, or for us. chrishtr: Maybe we could break out and talk about it? chrishtr: I don't think I fully understand, and I'd like time for that Rossen: Okay so, I didn't hear that say the HTML width and height attributes is the worst idea I've ever heard, we shouldn't do it Rossen: I also didn't hear we shouldn't think about the intrinsic aspect ratio, because it'll just work Rossen: TabAtkins has committed to work on this fully TabAtkins: Chrome people will be working on this Rossen: Kidding aside, we'll close this issue for now. Thanks for introducing it to the working group, and making it an actual proposal Rossen: I think there was another bit in this, which was css property, which will then have to map using either the height or width attributes, as a ratio, or whatever else is there, if anything is added as an additional attribute Rossen: I think the property can be discussed at a later point, or is this something you want to discuss later today fantasai: It's already in the draft, we resolved to add awhile back https://github.com/w3c/csswg-drafts/issues/333 https://drafts.csswg.org/css-sizing-4/#aspect-ratio jensimmons: So this discussion about not doing other things in HTML, just stuff we've already talked about jensimmons: There will be more to talk about aspect-ratio with min-height and min-width jensimmons: There is a question of: do we put in what's there already in the draft, support for ??, whether it's happening in the UA style sheet, we do have the ability to grab information about height and width jensimmons: Might be right in between, and I think we should do what Rossen mentioned Rossen: Great point, thank you. Before we move on AmeliaBR: I have a question: it's not being proposed by a web group. Before we get a css spec, we need to get that moving up into the HTML wg, so it's outside our scope, so long as it's going through process and getting standardized. chrome pushed it without standardization, we need to make sure that happens TabAtkins: Definitely should be in wicg - we'll get it there CSS Inline ========== Should first/last baseline values of `vertical-align` belong to `alignment-baseline` or separate longhand? --------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/861 dauwhe: No opinions fantasai: Ditto fantasai: This issue keeps coming up because I don't have any points in favor or against either options, and I'd like to hear why we should pick one over the other fantasai: Do we have the board, do you want the [..] baselines, [fantasai explains the problem] fantasai: When aligning inline boxes to each other, you first match corresponding baselines, then you shift if there's an offset fantasai: Once one of those has multiple lines of text in it, do we use first or last? We wanted to add keywords to choose. fantasai: Do we put it in it's own property, align-baseline-preference, and it cascades independently? fantasai: Or do we merge it with alignment-baseline, which chooses the type of baseline (alphabetic, mathematical, ideographic, hanging)? AmeliaBR: Reminder: long hands exist for legacy compat. So svg had alignment-baseline, baseline-shift, css had vertical-align...they describe the same functionality but behave slightly differently AmeliaBR: ..., adding new features to the longhand, when it's just for compat, seems questionable. Also, not sure how first/ last would work in SVG. I don't see benefit there [fantasai outlines things on the easel] fantasai: We can't just add values to the vertical-align shorthand: they need to be part of a longhand, too. So if there's a reason to choose one over the other, it'll help us resolve AmeliaBR: New property may not be used fantasai: Related issue: from the MATH ML folks, they want to take the baseline not from the first or last item, but from a specific item [See https://github.com/w3c/csswg-drafts/issues/1339 ] fantasai: So that ties in a little bit with this. We don't have a proposal, but we have an idea we should do it. So that might tie into we end up with another that helps us solve this as well. AmeliaBR: I suppose the value of a new property is that vertical align is already supported with current functionality AmeliaBR: you may end up with duplication anyway fantasai: Does anyone want to think about it more, or push it off to later? dbaron: I can imagine there's reasons you want them separate, unknown how important they are. Consider multiple languages [...] fantasai: Alright, we have a reason, we can resolve the issue! dbaron: I'm not convinced anyone will want to do this, but it does seem like a good thing to do dbaron: You might want to set alignment-baseline as a function of the language without messing with the first/last choice set for other reasons AmeliaBR: Resolve to make a new longhand property astearns: We figure the name out later fantasai: No matter how silly, make suggestions in IRC, we'll evaluate later <astearns> best-baseline <dauwhe> good-baseline | better-baseline | best-baseline <TabAtkins> west-baseline <AmeliaBR> baseline-line Rossen: Okay, any other opinions that can top dbaron's? Rossen: Anyone object to dbaron's proposal? or oppose? Rossen: No objections. Resolved. astearns: So, dbaron, could you put your actual suggestion into resolve line dbaron: The question was a boolean, do we want a separate prop or not RESOLVED: We'll add a separate property for this astearns: Great fantasai: Thank you Houdini <3 Text =============== Scribe: emilio Houdini and text layout ----------------------- github: https://github.com/w3c/css-houdini-drafts/issues/854 myles: So, houdini has a lot of stuff, and I think everything is things that browsers do already, which is cool myles: There's one of these things that is not in houdini so far, which is text myles: so there's a chance that authors are going to want text layout myles: There's a lot of ways this could go. Text is complicated, and different to other parts of houdini, in the sense that (a) it's pretty easy to get wrong and (b) if it is, users will be misled and confused myles: It's easy to get it wrong when things like how BiDi works should work by default, we don't want authors to have to remember how to do these myles: There's a bunch of things like that listed in the issue myles: so I wanted to discuss how should we approach such an API to avoid causing pain myles: A strawman proposal just to get the discussion started would be a region-like API, where your content flows from one box to the other, and regular CSS properties apply in that box myles: That'd be very high level. Another approach would be to expose glyph indices and fonts and let the author place all of them myles: I think that'd be bad <fantasai> +1 to that being bad myles: So, there are these two extremes, these high-level things, and there's this low-level thing which we can agree it's a bad idea. There's a range in there that we should figure out AmeliaBR: (summarizing her comment in the issue) AmeliaBR: (https://github.com/w3c/css-houdini-drafts/issues/854#issuecomment-459146355) AmeliaBR: There's a lot of steps, like [...], that we need to break this down into. AmeliaBR: Within all the individual steps which happen during text layout, we need to figure out which of them authors want to customize. One of them could be justification AmeliaBR: other things like bidi unicode stuff we don't want to ever expose AmeliaBR: We could expose (though maybe trickier) glyph selection (sounds scary, but there's lot of fun stuff you could do with OT glyph selections instead of having to create a new font because you want to create a space-maximizing layout) AmeliaBR: That's something that people may want but that is easy to get wrong / break AmeliaBR: Also, the steps are very dependent on one another, so we need to come up with a nice model of the data that goes through the pipeline if we want authors to insert their custom stuff fantasai: This is not just a sequential pipeline, some of the steps interact with each other. An excellent line-breaking engine will account for glyph selections and such fantasai: so you can't just break that up into ordered steps iank: I think we agree in spirit with myles, we don't want to get into the business of bidi resolution or glyph selection or such iank: We may want to get smarter about where to break and such, but not atm iank: The current model in the spec is a box where you run layout giving the available width and you get back an inline box / line box fragment iank: You can re-request that if the resulting height is too big for your layout iank: Some layouts require the available width to change on a per-line-box basis iank: We want to prototype that myles: So, I also agree that we mostly agree myles: The idea of giving available width works well if the area has vertical end, but if you're not a perfectly vertical container it doesn't, it's not clear how much we care for shapes in Houdini iank: We care about shapes a lot iank: In our engine we do at most two layout passes to avoid shapes iank: which sort of fits in this model myles: I think doing two layouts is unfortunate, describing geometry would be nicer iank: That'd be difficult, a lot of the use cases that devs want to place a line depending on how the previous line has been laid out iank: I think describing all the geometry upfront would be limiting iank: One of the examples we want to work is an arbitrary line grid iank: The avail width of the next line really depends on the line height of the previous line box dauwhe: My industry is very interested in using Houdini to improve justification / hyphenation, since the browsers have different requirements florian: I share the concern that this is important and hard to let people do a lot of random stuff florian: but Dave shared examples about hyphenation and justification, and there are many more of the same kind of when you consider i18n where a lot of effects needs a lot of low-level access florian: For example, Japanese people may want to increment distance between some glyphs or such florian: or implement stuff that isn't in browsers yet florian: The approach of getting line boxes doesn't get far enough, but I'm not sure how to get far enough but not being dangerous myles: You're right, but we have competing desires, letting authors implement nice effects, and making pages legible, the latter has been historically more of a priority <fantasai> +1 to ensuring legibility fantasai: Side comment, about justification and the model that is in Houdini, which I agree is the right one to get started. For justification would it make sense to return the fragment without filling the available width, but also let the user set it to be wider and that'd trigger justification and alignment fantasai: That way I can see where it fits much more easily, and position it more easily fantasai: and justification and alignment properties would work the same way it works when you place it in a bigger size. Justification would still be in control of the user-agent myles: dauwhe, when you said for example you wanted to improve justifications, is ^ what you were referring to? dauwhe: I think we want more Rossen: Thanks for bringing the issue, and I'm glad it's getting more and more traction. The one common theme that I see so far is that we are trying to get the "custom" part of layout out of custom layout. Everything that's been discussed so far how to force people to do the thing what we're already doing and tweak it a bit here and there Rossen: The nice thing of custom layout is that we're not giving restrictions for where people to position boxes in the block layout case, but when it comes around text we through our hands in the air and say it's too hard, and I don't agree with that TabAtkins: We have existence proof that every single custom layout has done bidi wrong. Rossen: It seems to me that we're talking about levels of customizability Rossen: one where you expose bidi and shaping at every breaking opportunity, the other where you give it a box and we'll do the layout inside Rossen: I'd be interested to go and explore the options in the middle which would allow most custom layouts that people want Rossen: so that we're still not insisting on that rigid one box Rossen: We're also assuming that we're doing inline layout the way browsers do it now, but maybe my lines are spiral, or I want to go on top of floats Rossen: Let's not try to take the custom part of layout outside of css dbaron: I just wanted to bring up another use case that hasn't come up today dbaron: I think having a low level API is very important for minority languages [general nodding] dbaron: Gecko has shipped graphite support <dbaron> https://en.wikipedia.org/wiki/Graphite_(SIL) dbaron: One of the things it does is let languages that have shaping requirements that aren't in browsers do it in fonts instead dbaron: Another approach for this would be a low-level JS API using houdini <dholbert> (I believe "glat" is one of these graphite font tables that dbaron is referencing) <dauwhe> "For example, it may be the case that a minority language is tonal, while the national language is not, and the orthographic solution involves using the standard writing system with some extra diacritics to indicate tone. Or the minority language might have a set of sounds characterized by a certain linguistic feature, such as aspiration or breathiness, that are not present in the national language, and the desire is to add to the standard orthography a set of variant characters to represent these variant sounds." dbaron: I think that's a potential real use case skk: From Japanese digital books perspective, more precise Ruby would be amazing skk: We'd like more control over ruby text positioning <xfq> more than what ruby-position/merge/align currently provides? dauwhe: Responding to the philosophical point, being able to explain and expose all the platform features? Rossen: It is, what I'm saying is, let's not prevent that Rossen: So that we can avoid limiting the inner pinnings of how things work. Said that, we want to open the engine so that we don't need to implement all the stuff people want, that's the fun part of it. Rossen: We've never said "and we don't want to let you do this because it's hard" Rossen: why? myles: If your layout is quite not what the author intended, the text still exists. For box layout, bad layout is wrong for everyone; for text, bad layout can be completely unreadable only for some Rossen: If it's unreadable it's unreadable because of me fantasai: It may be because somebody typed something you (the Houdini author) didn't expect fantasai: and you didn't care of thinking of those users fantasai: and those users are our users Rossen: That's my problem, those users are going to complain to me koji: From my POV I think "don't do bidi and don't you your own thing" is more "we want to start from simple things", and as we can confirm it performs properly and works we can extend further koji: but I'm not very confident that JS running through glyphs is performant enough, so box-level layout seems simpler koji: so re. Rossen's point, we're not against, but we want to start from the simple thing AmeliaBR: I agree with Rossen and dauwhe, the point of Houdini is being able to tweak one of the little things the browser does without having to re-implement the browser, and we want to let authors do what they want AmeliaBR: You can do some sort of custom layout with SVG, but probably badly. We should let authors do what they want without forcing to reimplement what they don't want to tweak AmeliaBR: I think we should prioritize our work to start with the safest things to change and isolate <dauwhe> I want to tweak what the browser does, not build my own rendering engine <skk> +1 to dauwhe <heycam> Agree with AmeliaBR -- we should bias towards coming up with APIs that allow users to benefit automatically from the browser implemented bidi, complex text shaping, etc. features that the author doesn't want to reimplement <heycam> make it harder for them to accidentally not support those things florian: So, I think when we say is "this is too hard", this is not saying that devs in this room are smarter than all of them. But very little people have resources to implement all the complexities right florian: Very few people have the business justification to deal with all languages florian: Minority languages is where this is interesting and dangerous florian: The low level things that enable minority languages to work on the web, are also what enable companies to write western-only layouts that don't work with other minority languages that browsers support today florian: In the process of creating an api that's good enough to support minority languages we'd have created the chance of Chinese pages where you only can write in Chinese, or English pages that allow you to only work in English florian: So if you force people to rebuild text-layout itself, they will not do the right thing, and we'd have disabled some languages instead of enabling others florian: So I'm more on the side of caution, and making sure that everything we add to this API is a thing we can tweak <fremy> very good point florian florian: And yes, people will break stuff for their own customers, but we'll also break the fact that the web is multilingual fantasai: I think koji and AmeliaBR and florian said everything I wanted to say myles: Most of my job is fixing bugs that the text experts in the piece of software they created because they only spoke English myles: There's tons of places in WebKit where there are assumptions because it was coded by English-only speakers myles: I agree we should investigate the middle parts in the spectrum, but I think we disagree with the criteria for success myles: I think text is different, where if you get it wrong it may work for you but not for your users myles: An approach where we take everything the browser does and making it scriptable is not the highest priority myles: Raising use cases is a good way to prioritize, the idea of tweaking specific parts of the browser is great and makes total sense myles: Picking specific use cases and filing in holes is probably the right idea, creating a low level platform and tell people to write it yourself is probably not <florian> +111!1!1 <fantasai> myles++ myles: Minority languages is a very interesting case, apart from Graphite we also have a similar thing with AAT myles: I wish we could find a way to solve that problem in a way where safety is preserved Rossen: I see a lot of passion and interest, zero reasons for us to stop working on this. A lot of things said will hopefully be taken into account as we move forward. One thing that I wanted to make sure that the record reflects what I said. Rossen: I wasn't suggesting to start exposing the far end, like glyphs Rossen: but as we go forward we should start walking towards the end, I just want to ensure that we don't preclude us from going forward Rossen: Myles, is there something that you think it wasn't discussed? myles: I think the next thing is gathering use cases, so we're done iank: To try to wrap up, is there anything inside of the current version of the spec that particularly scares you? myles: My biggest concern is about encouraging authors to do layouts in loops myles: where they try over and over, but I understand such an approach allows for dynamic use-cases, so I guess the question is to which side we fall iank: I think we agree, but we don't want to limit people which is why we chose this approach myles: We heard a lot of use-cases in this discussion that aren't covered by the API, so maybe it's too early to create APIs Rossen: We have a proposal and we have a lot of discussions, let's not say yay or nay dauwhe: I wanted to make a point regarding the responsibility about us making software for our use case vs. browsers dauwhe: We publish English and Spanish, I don't think there should be obligation for us to handle vertical or rtl * dauwhe admits that some of our books have snippets of Arabic, Hebrew, Japanese, Chinese, and MathML :) AmeliaBR: I'm glad myles brought this discussion AmeliaBR: One thing that myles and fantasai said is that text was different because it made stuff unreadable AmeliaBR: I don't think that's true, there are lots of ways you can break content in another ways AmeliaBR: I agree with Rossen that the developers of the websites are responsible for being user friendly and would be the ones to pay the price. I don't think that this proposed ways which could break websites are worse that other ways to break stuff with CSS fantasai: I think it is actually worse <astearns> I disagree with AmeliaBR's comment, and agree with fantasai. Bad text layout has uniquely bad ways of making content inaccessible <fremy> iank myles: I do have some ideas on how to progressively enhance the current api to cover more cases that have been discussed here without starting from scratch and would like your opinion, so maybe we can talk about this during break? or in the github issue if not. Rossen: This is not the end of the discussion, but some of the starting points Rossen: We need go back and work more on this, we should keep participating passionately Rossen: Next steps is engaging in the specs Rossen: So go help iank ;) iank: I'd love that CSS Text ======== Allow for paragraph-level line breaking --------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/672 myles: Similar to houdini, there are lots of different ways to do line-breaking. Houdini solves some of them. Other ways people want to do line breaking are some fancy book-like line-breaking myles: ine-breaking on the web is greedy, and doing something slower but higher quality is a longstanding request myles: I proposed a value for this, which got to the spec and then got removed because of lack of consensus myles: I'd like to see which opinions for this myles: it's a very high-level switch <xfq> will the behavior be UA-defined? florian: I want to know which one is the editing value florian: I want one of the values to be stable when you type <astearns> default is 'wrap' which is stable myles: Right now the default is stable in every browser florian: Not for print [PDF renderes like PrinceXML and AntennaHouse] myles: You don't type in print preview myles: I don't think you need another value, we already have it florian: I think there should be a stable value myles: I think reflecting reality and saying that auto should be stable is fine fantasai: I think the initial value should allow the UA to do whatever dauwhe: If the property is added to iBooks I'll add it everywhere fantasai: I think iBooks should just add it to its default UA stylesheet [ compat? ] dauwhe: I think you want to change it in existing books too dauwhe: Having the text break better is just going to be a win eae: I think this is a great idea, I'm a bit concerned that if we don't define what pretty does we'd get interop issue, so we should try to explain what pretty would do <xfq> https://github.com/w3c/csswg-drafts/issues/803 is the related issue for the algorithm ("pretty") myles: In the issue I listed a dozen different criteria myles: So describe it explicitly is probably not realistic, do you think agreeing on the goals is fine? eae: yeah, I think that's ok fantasai, dauwhe, myles: I think it's important to _not_ get compat <AmeliaBR> There will always be perf trade-offs, so that it makes sense that a print book will get prettier `pretty` results than a browser on a low-CPU device. heycam: I was going to make eae's point, though maybe I'm a bit more worried about the compat impact, I don't we can change the default algorithm because of compat, why wouldn't that happen with `pretty`? astearns: The current algorithm is not that interoperable myles: Also, this is an opt-in heycam: Once we have this, why would we not expect authors to just use it all the time. Why would they not do that? myles: It's the same answer for text-rendering: optimizespeed vs. optimizelegibility fremy: It's mostly useless myles, AmeliaBR: it's not heycam: I don't think people will think about speed, and many people will just use it without thinking about it, having a perf impact astearns: I think that's the reason for the auto value astearns: so that the UA can change it heycam: I'm skeptical about changing line-breaking (by default) myles: I'd like to keep the discussion less about the existence of auto dauwhe: I think there are a lot of trade-offs. Browsers are optimized for speed right now, and taking any step to opt in to better systems is going to be great regardless of interop dauwhe: text layout is so sensitive that there's never going to be interop myles: I want to resolve to put this value back in Rossen: Objections? florian: I want to make sure we have the three values, including stable. fantasai: I think we should rename it, but no objection fantasai: I'm a bit concerned that we are going to add another switch that does nothing fantasai: but if people feel strongly I won't object fremy: not an objection either but we need a better definition on what it does RESOLVED: Add the value back in fantasai: Are we adding stable? myles: There are three values: auto, balance and this new thing fantasai: I object to the multi-line name myles: Proposals? fantasai: 'pretty' sounds good to me fantasai: It's what we used to discuss it here RESOLVED: add the stable value
The post Using MathML-Based Speech to Edit Math in Different Math Models discusses the need to navigate math zones in the edit space rather than in a MathML copy of the edit space. This need arises for editing since the navigation location must be synchronized with the edit selection. It’s also important for defining the selection bounding rectangles even if editing isn’t allowed. The present post compares the math-zone edit navigation in Microsoft Office apps to the structured child/parent/next/previous tree navigation provided by MathPlayer and other systems. Combining both approaches results in rich navigation and editing experiences for blind and sighted users alike.
The OfficeMath math zone represents math as a “flattened” tree, in which nested math objects such as fractions and matrices have start and end delimiters. This allows character navigation to traverse every character in a math zone. Typing the → key at the start of a fraction moves into the numerator. Typing → at the end of the numerator moves into the denominator. Typing → at the end of the denominator moves out of the fraction. The → and ← keys let you “escape” from a math object (go to the next higher level in the tree) and to enter a math object (go down a level into the tree) as well as moving past characters.
Typing Ctrl+→ moves by siblings. So, typing Ctrl+→ at the start of a fraction moves past the fraction to whatever follows the fraction. A Ctrl+→ at the end of the denominator moves out of the fraction, so like the → key, Ctrl+→ can escape from down inside an object (go to the next higher level in the tree). But it cannot go down into a lower level of the tree. Both Ctrl+→ and → leave the selection as an insertion point (IP), ready for inserting more characters and math objects. Shift+Ctrl+→ and Shift+→ select the next object or character. The Ctrl+← and ← keys work the same ways but move toward the start of the math zone. (Note that Word hasn’t yet implemented this Ctrl+→ and Ctrl+←behavior, but OneNote and PowerPoint have).
All eight editing hot keys ([Shift+][Ctrl+]←/→) move out of the math zone when they come to the end of the math zone. The keys are usually geometric but are logical as well in that → moves from the end of a numerator to the start of the denominator. Such movement isn’t geometric since the motion is down and to the left rather than to the right. At any time, the user can enter and delete characters. If the selection is nondegenerate, entering a character replaces the selection and results in an insertion point (IP). If the selection is already degenerate, e.g., an IP following Shift-less key motion, the character is entered at the IP.
With OfficeMath speech, you can use this kind of navigation while entering and editing equations with a keyboard. You don’t need to see the screen. As far as I know, the Office apps Word, Outlook, PowerPoint, and OneNote are the only major apps that let blind users enter and edit equations using only speech and a keyboard.
Contrast these edit movements with structured Parent/FirstChild/LastChild/Next/Previous tree navigation. This structured navigation always selects a character or object unless it ends up inside an empty argument. At the start of a fraction, FirstChild selects the numerator and LastChild selects the denominator. If the numerator is selected, Next selects the denominator. But unlike Ctrl+→, another Next does nothing since a fraction only has two arguments. To get out of the fraction, you enter Parent and then Next to go to the next sibling of the fraction.
If an argument is only partially selected, then Next goes to the next sibling in the argument. If the last sibling in an argument is selected, Next does nothing. Entering Parent selects the whole argument and another Parent selects the math object. The highest level in the tree is the whole math zone and structured navigation commands won’t move outside the math zone.
If a selection consists of multiple characters, e.g., the “sin” in the math function object “sin 𝑥”, FirstChild selects the ‘s’ and LastChild selects the ‘n’. Next/Previous select the next/previous character, respectively, unless the last/first character is selected (in which case Next/Previous do nothing). In this way, you can examine every character in the math zone using structured navigation.
Possible hot keys for Parent, FirstChild, LastChild, Next, and Previous are Alt+↑, Alt+↓(or Alt+Home), Alt+End, Alt+→, and Alt+←, respectively. Since these differ from [Shift+][Ctrl+]←/→, both kinds of navigation can be used together. It’s desirable to have corresponding navigation buttons on refreshable braille displays.
While structure navigation takes more keystrokes than edit navigation, it’s valuable for understanding complicated equations, particularly if you cannot see the equations easily and are navigating with the help of math speech.
Ideally for editors like Word, Outlook, PowerPoint, and OneNote, both kinds of navigation would be available. If using structured navigation, you want to enter a character at the end of the current selection, type → to collapse the selection to an IP at the end and type the character. If you want to enter a character at the start of the current selection, type ← to collapse the selection to an IP at the start and type the character. With these techniques, visually impaired users can have a rich navigation experience and all users can enter and edit equations easily.
[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
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#
========================================= 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
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>
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>
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>
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.
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.
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.
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.
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.
========================================= 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> ∞ 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 ∞ (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.
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/> >
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/>
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>
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>
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
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 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.
Planet MathML features:
David Carlisle Design Science News FMath Getting Math
onto Web Pages Community Group MathJax Murray Sargent: Math in
Office SF.net - ASCIIMathML SF.net - DocBook to LaTeX
Publishing SF.net - MathCast Equation
Editor SF.net - MathStudio SF.net - Open Math Edit SF.net - PyMathML SF.net - SVGMath SF.net - UniWakka SF.net - jsMath SF.net - jscl-meditor SF.net - pMML2SVG Updates | Frédéric Wang W3C Blog W3C Math Home W3C News WebKit public-digipub-ig@w3.org
Mail Archives public-html-a11y@w3.org
Mail Archives public-html@w3.org Mail
Archives public-mathonwebpages@w3.org
Mail Archives public-webapps@w3.org Mail
Archives www-math@w3.org Mail
Archives www-style@w3.org Mail
ArchivesIf 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.
