- From: Neil Soiffer <soiffer@alum.mit.edu>
- Date: Thu, 12 Sep 2019 16:25:22 -0700
- To: public-mathml4@w3.org
- Message-ID: <CAESRWkCC4nwZCC2jaQ=reU-cxF2rB0EwHR2hTc5KmfB0qv=Fig@mail.gmail.com>
MathML Core Meeting of Sept 12, 2019
There were some strange problems with zoom (said there was another meeting
going on, but apparently there wasn’t). We used hangouts. Apologies to
those who tried to join but couldn’t. The meeting was not recorded
Next meeting 11 days (23 Sept).
Attendees:
-
Neil Soiffer
-
Fred Wang
-
Rob Buis
-
Brian Kardell
-
Patrick Ion
Agenda:
https://github.com/mathml-refresh/mathml/issues/8#issuecomment-530938147
https://github.com/mathml-refresh/mathml/issues/56
<https://github.com/mathml-refresh/mathml/issues/8#issuecomment-530938147>
-
Rob did some experimentation
-
RB: Worked on all elements, the math element itself is a little trickier
-
NS: Why?
-
RB: It interacts with the parent, depends if it is block/inline… we're
still figuring some of this out
-
FW: It seems table alignment is broken in the experimental build, I'm
not sure if ours ever worked here, we have to go and check… but we can fix
this
-
NS: any problems with leaf elements that interact with foreign content?
-
FW: not a problem.
-
RB: could use more tests
-
FW: We experimented some with flexbox/grid
-
https://people.igalia.com/fwang/mathml-css-display-values/grid-flexbox.html
-
Green is flexbox, blue is grid
-
We have some more issues, we think they are primarily implementation
issues in chromium
-
BK: Do we want to put it on the agenda at tpac formally, or just shop it
for approval/build consensus?
-
Agreed to informally attempt to get some review. If people are
enthusiastic, then see about getting on agenda.
percent width/height for foreignObject: <mtext><span style="inline-block;
width: 50%"></span></mtext>. #49 (comment)
<https://github.com/mathml-refresh/mathml/issues/49#issuecomment-529412104> #50
(comment)
<https://github.com/mathml-refresh/mathml/issues/50#issuecomment-529412323>
-
RB: did a test and block width/height is already passed in, so would be
easy.
-
NS: sounds like the right way to go.
-
RB: needs more testing
-
BK: will we get this into the spec soon?
-
FW: only have Friday to get into spec, not sure I can get it done in time
display values and CSS properties: #31 (comment)
<https://github.com/mathml-refresh/mathml/issues/31#issuecomment-529409481> #56
(comment)
<https://github.com/mathml-refresh/mathml/issues/56#issuecomment-529406477>
-
BK: We have three other issues we want to be part of CSS; would prefer
not to be internal.
-
FW: We can say it is not urgent. Worried about negative feedback
-
BK: Last time we barely had anything implemented, not much of a spec,
etc.
-
BK: Now we have a nearly complete implementation, have thought it through
-
NS: These three values come from standard math rendering, so we know
they are needed and also know that there is not really anything similar
needed.
-
BK: I think we are at a different point than at last meeting. I’ll get
together with some key people first and try to convince them before
bringing it up to the full group.
css painting order #52 (comment)
<https://github.com/mathml-refresh/mathml/issues/52#issuecomment-529411128>
-
Not important for TPAC
invalid markup #15 (comment)
<https://github.com/mathml-refresh/mathml/issues/15#issuecomment-529418395>
-
FW: agrees with NS comment to send a message to the console when there
is an error
-
FW: PI felt bigger warning for users would be useful, but is ok with
decision to make invisible.
-
FW: need to decide between just use mrow or add anonymous nodes to
preserve some layout.
-
RB: if there are too many in-flow/box* children, they will be put in a
mrow. Experiment worked and easy to do for most MathML elements.
-
FW: mmultiscripts is more complicated.
-
FW: anonymous children caused problems in Gecko
-
RB: it would be good if there was some similar case in HTML that I could
copy.
-
NS: what about definition lists -- they come in pairs
-
(several checking) -- pairs not really required; layout is fine if only
one of the pairs is present
-
BK to ask google about box fixup in LayoutNG
out-of-flow positioned elements #16 (comment)
<https://github.com/mathml-refresh/mathml/issues/16#issuecomment-529425202>
-
NS: Fred, you thought it was important to make absolute positioning
against the containing block
-
FW: I don't know if it is important, but it is the only thing that is
really useful probably. Ian had suggested that if we determine that
something can't be a containing block we need to discard some properties
like filter
-
NS: One of the things that surprised me is that you wanted to ignore
float, which seems contradictory to me
-
FW: I don't think it is contradictory, there are others that do this:
display: none, position: absolute - there are other cases - grid and
flexbox I think do this. They are "ignored" in that they become non-float
-
NS: But why?
-
FW: Because it is very complicated and I can't see any use cases - it
really doesn't make a lot of sense for a lot of these
-
NS: I could see it making sense, I haven't entirely thought it through,
but maybe an annotation where you are explaining some element and you want
to create some explanation
-
FW: But again it can be outside the math and float it if it is against
the whole thing
-
NS: I have seen in american textbooks for example where fractions want
to call out the numerator and the denominator for example… I don't know,
maybe float isn't the best way?
-
FW: position absolute could do that
-
NS: Float would prevent if from overwriting though
-
FW: I don't know, it definitely doesn't make sense without linebreaking,
so if we want to get to float capability we should tackle linebreaking first
-
NS: I don't know what the vision of the spec is though… If you have the
spec say float is ignored, I don't think we can come back and say it isn't.
Maybe we can say it isn't _implemented_?
-
PI: What is it that you want to float? It seems that if you want to
float you want to know relative to what. I think I agree we have to tackle
linebreaking some day, but it seems easier; all you need is a linelength
and an algorithm to fold stuff. Floats are more vague.
-
NS: I think it's just that everything goes around it
-
PI: But presumably for some motive?
-
NS: <cites the numerator/denominator with labels again>. It's not
something you see everyday - unlike linebreaking which you do see. Maybe
my issue is that I'm not understanding what you mean by 'not supported'?
-
FW: We were tasked with creating something interoperable from what we
have - we have to be careful we don't invent things that are useful or we
wind up with MathML3. At the same time we have to concretely answer
questions asked by google "do we support float"? One option is to say "it
is not supported at this time" with a note/issue. I guess it is not great
for a spec, but it is still a draft.
-
BK: <suggests some language - fill this in later>. It seems like
linebreaking is the bigger deal here - the inability to linebreak at all
seems … tough.
-
NS: How is that handled in other things?
-
<some discussion>
-
FW: We can't get linebreaking in, we had a proposal for supporting width
on math element, but that was too complicated - it involved overflow. When
you have text and inline math, you can linebreak in the text.
-
PI: If you were actually trying to do that more fully, you would have a
rather long mathematical expression next to some text and you'd say to the
algorithm you'd like to have a 40pt bit and a 60pt bit.
-
FW: Gecko has some support for bits of this, but it's limited
-
NS: I have a proposal, would like to know if this would be an
appropriate thing to sit down and try to work out at the upcoming hackfest
- this was actually my thesis dissertation many years ago. I have plenty of
experience in this area and expertise, maybe we can work something out at
the hackfest.
-
FW: getting back to “float”...
-
BK: I think we decided to craft some language that it will be ignored
for now but authors should not use it as it may change in the future.
-
FW: This issue also has the question what is a containing block and what
do things resolve against.
-
BW: I think we should we resolve against the containing block
-
FW: What is the containing block?
-
FW:if you have an element in the fraction, we have to decide the
containing block - I think we decided it is the fraction. What does top:
10px; left: 10px: what are you moving from. inline start top/left of the
containing block, depending on orientation and so on. Always the parent.
-
BK/FW -- some discussion of static position within an absolutely
positioned element
-
FW -- the children would have normal layout -- ie, if a fraction were
absolutely positioned, it would display it’s children normally at that
position.
-
BK: I’m concerned about CSS selectors
-
FW: they only apply to DOM elements
-
BK: what about cycles: 2nd child display:none, 3rd child is styled.
Remove 2nd child, now 2nd child should have display:none, etc.
-
BK: the CSS layout properties get affected by out of flow elements.
Needs to be called out in spec
-
FW: if first element has display:none, the first displayed child will
actually be the second child, and that second child will have scriptlevel
incremented even though it is displayed as the base
-
FW: argument for exposing CSS properties like scriptlevel so they can be
properly set and people can fix things up.
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Received on Thursday, 12 September 2019 23:25:55 UTC