- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 12 Nov 2018 19:22:32 -0500
- To: www-style@w3.org
- Cc: www-math@w3.org, public-test-infra@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Math on Web Pages Joint Meeting
-------------------------------
- The Math on Web Pages group presented a list of challenges they
face trying to style math using CSS:
https://lists.w3.org/Archives/Public/www-archive/2018Oct/0002.html
- There were several proposals and use cases for the working group
to review later which could be added to current or future specs.
The ones touched on briefly during the meeting were a better way
to handle baseline alignment and creating sticky fences to
handle things like long brackets.
WPT Joint Meeting
-----------------
- A year ago the CSSWG resolved to always require tests with CR
changes; this meeting was to review the ramifications of that
decision a year later.
- There continues to be a resource problem where there are more
changes put into specs than there are people writing tests and
PRs still aren't getting reviewed in a timely manner.
- A suggestion was to change the requirement to one test per commit
which reduces the burden on authors, but still increases the
likelihood that changes are noticed.
- gregwhitworth and jensimmons also said they would continue to look
into more community support for testing.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule
Scribe: fantasai
Math on Web Pages Joint Meeting
===============================
Full Presentation:
https://lists.w3.org/Archives/Public/www-archive/2018Oct/0002.html
Simplified Presentation:
https://github.com/w3c/mathonwebpages/wiki/%5BCSS-TF%5D-TPAC-2018-preparations
Introductions
-------------
arno: I used to be in CSSWG many years ago, but no longer with that
employer so here representing myself
arno: Wanted to talk about opportunities to make representing math
on the Web better
daniel: I'm co-chair of Math on Web Pages community group
pkra: I'm an independent consultant working with STEM publishers
VolkerS: I'm here in my role as 1/2 of mathjax development team. I'm
mainly on the a11y side and parsing, but know a bit about
the css
Overview of Challenges
----------------------
arno: We only have 25min before the break, so we're going to try
arno: Don't expect to solve the world's problems, but want to talk
to you about some of the challenges we face in using HTML+CSS
to present equations on the Web
arno: There's lots of solutions that do that, not that it's
unsolveable, but what we think is worth exploring is how we
can make the authoring of this content easier using CSS
arno: Using a lot of workarounds and hacky solutions
arno: Have some solutions of improvements to make it easier for this
type of content.
arno: Also want to look at improvements that are not just beneficial
for authoring MathML content
arno: But some of these solutions could also benefit others
arno: Talking about some of the things important to us, and
solutions to those problems
arno: First of all we care a lot about quality of the rendering
arno: Our goal is to achieve the same quality on the Web as on print
arno: No reason why you can't have the same precision in layout and
same typographical quality on the web as you have in print
arno: We recognize that getting there will take some time, but want
to shoot for.
arno: One issue we have, a lot of layouts we have to do in css for
math, is that we have to use a lot of inline styles
arno: Improved a lot so we don't have to do as much computation on
the client side to do positioning
arno: CSS added a lot of additional features which gives us more
control to do layout
arno: But still many cases where we have to bake in inline styles,
e.g. exact lengths for vertical alignment
arno: We'd prefer not to do that
arno: ... content on the fly
arno: If you modify the content, vertical alignment, inline styles
have to be recalculated
arno: This is acceptable if you're authoring a library or tool, but
if we want the authoring to be more accessible
arno: To be able to author math content with a text editor, need to
get past this
arno: So need a solution for that.
arno: Would also like solutions that improve the stability of the
layout
arno: So if you make some changes to the content, would like to be
able to do that without modifying the rest of the layout,
having to recalculate everything and re-inject inline styles
into the markup
arno: Math fonts is a sort of emerging technology
arno: For those not familiar, they're an OpenType standard that lets
you put inside a font side metadata that will allow adapting
mathematical glyphs, e.g. stretched fences and integrals
arno: It's great to have that part of the font file
arno: Today, oftentimes you have to carry them alongside a hard coded
knowledge of specific fonts. Which is terrible
arno: This isn't great because user can't just change the font
arno: So having metric information about the layout, very promising
technology
arno: So that's an overview of where we're looking for improvements
arno: Some of the challenges we have
arno: Not an exhaustive list
arno: Some of them we can sort of work around, but it's ugly
arno: Focusing on ones where the workarounds are the ugliest
arno: And try to have improvements that benefit beyond just math
arno: One example is stretchy fences
arno: Here's an example, it's genealogy
arno: When you have a genealogical tree, you connect the parents and
offspring with long brackets
arno: This is something very common in math, that's used for group
equations
arno: Matrices
arno: And other cases
arno: Point of this is to remind you that this is something that's
used beyond math cases
arno: Doing stretchy fences is possible today, but requires a lot of
trickeries and is very fragile
<jensimmons> We (dauwhe, florian and I) were just saying this
yesterday — it’d be awesome to have a ‘stretchy’ open
bracket
arno: Have to composite multiple glyphs together and hope they don't
break as the layout changes, zoom level is increased, etc.
arno: Wouldn't it be great if there was a simpler way to do this
with CSS?
arno: Especially to use the stretchy bracket as the border of a box.
arno: And have the rendering engine take care of that
Myles: Idea that you just described, stretchy... would you expect
that the browser would create the form of the stretchy glyph
itself or pick out glyphs from a font?
arno: Ideally, information from the font would be used
arno: in traditional typography, e.g. serif font and sans-serif font
are different
arno: Unicode has codepoints for this
arno: So ideal world, we'd use the info from the font
arno: Moving on to another challenge
arno: Baseline alignment
arno: It's one of those where it's not an unsolved problem, there
are ways to do them, but all of them involve inline styles and
positioning and vertical-align and all unpleasant
arno: Depends on the content, and if the content changes, have to
change the values for the line
arno: Want to move away from inline styles as much as possible
arno: Needed for lining up equations
arno: But also needed for lining up fonts and icon text
[arno shows example from his doc]
arno: Don't have one specific solution in mind
arno: There are some imperfect solutions today, and some discussed
e.g. in css-inline-3
arno: Having that incorporated into inline layout model would be
fantastic
arno: We'd love to make ourselves available if you have more
questions
arno: If that's the direction that you'd like to go
TabAtkins: In the example the baseline is being taken from some
descendant. It's not an arbitrary position.
TabAtkins: If that's the case, I think the implementation shouldn't
be too unreasonable, because we already drill down into
descendants to find a baseline
TabAtkins: So just need to be able to have a child say "I'm the
baseline for this container" and the container to look
for that child
TabAtkins: This other example doesn't have such a case, the baseline
is totally arbitrary place
heycam: I've always thought that there should be some way for
external svg elements should be able to declare where their
baseline is
fantasai: There were proposals in the past to be able to specify
where the baseline of an atomic inline is. (Was deferred
to later, not prioritized for this level.)
koji: If there is another example that doesn't have text of the same
font size, how do you align it?
arno: If the size changes, would still use the baseline. Would still
want to align along that axis.
koji: So not really aligned to that red line (running along the
alphabetic baseline)
arno: There's another axis for the exponent, e.g. aetc.
emilio: Webkit and Gecko have MathML implementations where you could
do this?
arno: We want improvements so you could express things with HTML and
CSS only
arno: Built in support is great, but ...
emilio: Why?
emilio: Why not use MathML which was explicitly designed to do this?
arno: There are some use cases where MathML doesn't work.
arno: For example, some software does interactive editing.
arno: To be able to do the layout with CSS + HTML is better
emilio: I don't know why you wouldn't be able to mutate MathML
astearns: There's some cases here that aren't MathML, like the
genealogical case
florian: Another case where MathML isn't ideal, the type of MathML
needed here is the presentational version, but for a11y the
semantic version is better
florian: Could instead render to HTML+CSS
florian: Also presentational MathML is less interoperably and
robustly implemented, so use a different technology
florian: Store the semantics differently and render to HTML+CSS
arno: So let me go quickly to another example of things that we're
looking for
arno: Here is enclosures, which is a way to annotate a MathML
equation
arno: This is something that is often used to highlight ? equation
arno: This is also defined in MathML, but would also want to use it
in other context
arno: Want to use those constructs in other contexts
arno: These are currently difficult to implement using CSS + HTML
arno: Need to do the layout twice, calculate the size of the
bounding box that you want to decorate
arno: We hope it to be easier
TabAtkins: I would think that a lot of this can be done in the Paint
API
TabAtkins: We've done a lot of work with Google teams about shaping
around content, and would love to get more use cases
TabAtkins: Talk to iank next to you :)
myles: When you render to HTML+CSS, presumably the result is
positioned... how?
myles: Is it abspos?
arno: No
arno: Software I worked on -- there are others out there --
mathdive, as much as possible the layout and positioning of
glyphs is deferred to the layout engine
arno: So horizontal positioning is done by the HTML. I just have to
do some adjustments, especially for stacking, of the boxes
arno: Used to be much more difficult to do
arno: Other implementations that used abspos for glyphs, but I think
that things have progressed enough
arno: Now looking at the remaining gaps
myles: But you don't use grid/flexbox?
arno: Some implementations are
arno: They're looking into it
arno: A good opportunity to simplify some of the layout, especially
for stacked constructs
arno: baseline alignment
arno: but in terms of making it able to have fewer inline styles,
it's a good way
Summary
-------
arno: Few more things to talk about
arno: Roots, a special case of enclosures
arno: stretch fences
arno: Accents and decorations are a related topic
arno: A few other topics
arno: More on the list, less straightforward or more specific in
their use cases
arno: So wanted to focus on these
arno: Wanted engagement with this community, how can we address
these things
arno: Use some features in CSS, or some features you're working on
for next level of the modules
arno: Happy to be sounding board, provide use cases
arno: So that's what we're looking for
astearns: Is this document public?
arno: Can make it public
florian: Please output to HTML or PDF and send to www-archive@w3.org
florian: More long-lived than google docs
astearns: Thanks, can work on some or all of these issues
astearns: For now, let's work on break
<br type=tea end=4pm>
Joint Meeting with WPT
======================
Scribe: TabAtkins
zcorpan: A year or so ago this group adopted a testing policy for
some specs, including OM and OM-View
zcorpan: And also specs in CR, that normative changes should be
coupled with wpt
zcorpan: I want to understand how this policy is working in
practice, and if there are any blockers to using this for
spec editors
zcorpan: If there should be someone to work on testing specifically,
or if it should be editors' responsibility.
zcorpan: What is the process, and what do we want it to be? What, if
anything, is blocking no-test-no-merge policy for CSS specs?
florian: I think what happened is what we feared would happen. Some
editors, like myself, who are responsible for a few specs
but not the overall health of CSS, were able to stick to
that policy. But Tab and Elika can't do that without
dropping the amount of work they do on specs, and we don't
want them to do that.
florian: And nobody's picked up the tests to go with their changes.
florian: So, it's not just the three of us in this WG that do specs
and tests and such. But the policy as a group, is indeed
blocked by the fact that there's not enough people writing
tests to go along with the edits.
florian: For some editors it's reasonable to drop spec output to
increase test output, but not for other editors. I don't
know how to solve that.
florian: I'll keep doing my part, but... I don't think it's possible
for the WG unless we have more people to do just tests to
compensate.
Chris_Lilley: We need more people to do edits, too, is the thing.
fremy: Same point - I disagree we should say there should be
spec-specific people, and I disagree that Tab and Elika
should be reducing their output to write tests. We have a big
group, we have a lot of ideas. We have big companies here, we
should make sure we staff the testing group specifically.
fremy: If we don't have enough people to even do the editing work,
obviously we don't have enough for the testing work.
rbyers: Of these changes that don't have tests, are there impl
changes happening too?
rbyers: In Chromium, devs need to land tests at the same time. Does
that apply here?
florian: A success here is the Contain spec. As an editor I focused
on writing a test for every change I made, but we didn't
have tests at the beginning. Igalia implemented, and wrote
tests as they went; I also commissioned tests from Gérard
to fill the gaps.
dbaron: Another risk with not having tests is the implementor
doesn't notice the change.
dbaron: Because we don't have a great mechanism for making sure
changes get into implementations... there's still a problem
with noticing the change.
<cbiesinger> agree with dbaron -- there's several flexbox spec
changes I didn't notice until someone filed a bug
<cbiesinger> or mozilla upstreamed a test :)
foolip: Are bugs being filed in the issue trackers to track changes?
fantasai: Not systematically done or tracked right now. We have a
label for changes that need tests, but not one to track
things that need bugs.
Chris_Lilley: When I was doing Fonts 3, we were already well-tested
and most things were implemented, so I was able to
keep track of everything. But across all specs,
they're at much different levels of implementation.
foolip: What's also been happening is the spec change is made, then
we have tests written before the change that contradict them.
foolip: But the big risk is changes that don't get noticed by anyone.
gsnedders: And the spec is then not implemented as written, because
the change was never made in implementations and no test
was written for it, and that isn't noticed.
foolip: All the changes being made, what would happen if changes
*were* blocked on tests.
foolip: Where's the pressure to make changes in the first place?
fantasai: It comes from people giving feedback on specs. Some are
implementors, who can write a test immediately because
they're implementing, but sometimes they just notice
something but aren't working on it, and won't get back to
it for a year.
fantasai: Some are filed by users of the tech that have issues with
how it behaves. Some are filed by WG members or other
reviewers.
fantasai: So some of these have incentive to write a test, others
don't.
foolip: So either they care enough to share a burden, or they don't.
In HTML, random person writes a PR, then we require them to
write a test.
cbiesinger: Sometimes people in general will just file an issue that
something needs to be clarified. It may not be clear
what the right behavior even is, so it might be
low-priority. By the time we get around to fixing the
issue, the reporter might not even be around.
florian: We have many cases of people qualified to point out a
problem, but not qualified to fix it.
florian: So it's we as a group that need to make the fix, and make
the test.
jensimmons: I'd have a big problem with this group deciding that
only people who have the time and skill to write tests
can contribute to CSS. That's not a route we want to go
down.
jensimmons: I do think we need more test-writing. I've had
conversations; there are many people who'd like to write
tests, but there's no clear way to get involved.
jensimmons: And even when they do get wind of how to get involved,
the tools are complex and there's lots of blockers that
make people give up.
jensimmons: There are people in this group, like Greg and Rachel,
that have said that is an important thing they want to
work on.
jensimmons: I think there are hundreds of people who want to
contribute, with an easier on-ramp.
<florian> +1000 to what Jen said
<heycam> a few years ago we had the Test the Web Forward project --
was that successful?
<TabAtkins> not really
<glazou> heycam yes it was immensely helpful
<gsnedders> I'm unaware of any repeat contributor we got from TTWF
<glazou> gsnedders right, but it did help
fremy: I think to answer your question, the answer is "backlog".
There's already more work pouring in everyday than this group
can work on.
fremy: We as a group still care about fixing the spec, because it's
wrong.
foolip: For any big project, obviously there's a big backlog. Given
the resources available, is it more effective to just work
on the spec, or ensure that spec and test work happen
together.
foolip: Hypothesis I put forth last year is that if you do the test
work, people will notice something has changed, and
implementors will follow along faster.
foolip: That's not proven, but if that's true, whatever amount of
resources are available, doing this work together makes more
sense than doing just the spec work.
zcorpan: I think the experience with HTML is that it does result in
impl changes more consistently.
zcorpan: Before this policy we'd sometimes have spec changes, not
write tests, then revert the change because nobody
implemented it.
zcorpan: I think this proposal helps with that issue.
gregwhitworth: I still stand by what we said last year - we all have
wpt.fyi externally, so we can see the changes.
gregwhitworth: To Jen's point, I've set up some mentorships with
folks; there's a lot more ramp-up to writing good
tests than I think we realize. There's a lot of
webdevs out there, but when we narrow it down, the
number who have the time is quite small, but still
something we should pursue.
gregwhitworth: I'll grab some of the people that might be relevant
and talk about this.
gregwhitworth: I don't want us to focus so hard on the suites
themselves. Is it worth spending 80% of time on the
20% of effort to perfect the testsuite?
gregwhitworth: I don't want fantasai to spend so much time writing up
tests just because she's the most knowledgeable.
gregwhitworth: I bet we have about 70 people in this room. Some of
us are tied to more implementors. So instead, just
think about a *single* test that fails.
gregwhitworth: Putting together a *single* new test for a change
that would fail in non-conforming browsers would
still be a ton of help.
foolip: And there's also the problem of big new features, where it's
too formative to be worth writing a comprehensive suite.
TabAtkins: I think I can commit to writing a single test per change.
Just as a signaling mechanism that something has changed,
that seems sufficiently high-value and low-effort that I
think I can gate myself that way without a significant
slowdown.
heycam: I think I agree that making tests at same time as changes is
ideal. Given resource constraints of the group, wonder if
it's more important to track things that do need tests;
seems that could be mostly automated.
heycam: So when we have free time, or external people look at
something, or a new implementor comes in...
astearns: We do have a "Needs Tests" tag that we give to issues.
heycam: That's tied to GH issues; not all changes are tied to GH
issues, particularly early on.
dbaron: There's been a lot of talk about resource constraints for
editors.
dbaron: Think about that in a different way.
dbaron: One of the things we end up doing a lot is we end up
revisiting changes, discussing multiple times, because
they're not implemented and now we have a compat constraint.
dbaron: There are reasons why, when we started using tests in
software dev, even tho we spent more time writing tests, I
think people agree that we overall moved faster.
dbaron: I think HTML editors found the same thing. Even tho you're
stopping to do this extra work, you can accomplish more,
because it makes the work more likely to stick.
dbaron: It also sometimes causes you to think more about the change,
think about other cases.
dbaron: But mostly it makes it less likely we have to revisit things
later.
<tantek> +1 what dbaron is saying
dbaron: So I think the "one test per change" is good.
florian: Another bottleneck is test reviews.
florian: I have 13 open PRs right now, oldest back from April.
florian: I can write as many tests as I want, but I can't review my
own tests.
foolip: What do you do when tests get stuck?
florian: Poke, but often the best people to poke are Tab and Elika,
and we're back to the bandwidth problem. ^_^
foolip: This is an issue for many groups.
foolip: I don't think it's a tooling problem.
foolip: Say we add a role for someone to go thru Needs Tests label,
or to write together with spec changes. Unless that's
blocking, and keeps blocking, any changes you make will be
eroded.
florian: Another thing about test reviews is that they seem trivial,
but they're not.
florian: Ask the editor, it's probably not hard. Ask someone else,
it's not. Reviewing one test might be a 20-hour task, as
you have to read the spec first.
krit: For Transforms there are some PRs I've put up, and they still
need review.
krit: For editors of the spec, could we lift the requirement that
someone else needs to do a review?
florian: I think it's good to have reviews, but if you're blocked...
gregwhitworth: And they'll get reviewed by the implementors when
they review the test later anyway, when they see that
they're failing it.
foolip: We could tweak wpt-pr-bot to not require reviews from
certain people...
<rachelandrew> having dug through all the legacy multicol tests
recently, and inlined them in the spec, very grateful
for the work TabAtkins did adding that functionality
to Bikeshed.
<gregwhitworth> https://www.irccloud.com/pastebin/LvLPxBCS/
<zcorpan> ty all
<dbaron> I'm in favor of allowing editors to land tests without
review.
<AmeliaBR> The problem with editors writing their own tests without
review is that sometimes they are testing what they
*meant* the spec to say, not what it currently says. Can
end up with requirements that only exist in the tests,
not the spec.
<foolip> I filed https://github.com/web-platform-tests/wpt-pr-bot/issues/47
Received on Tuesday, 13 November 2018 00:23:27 UTC