- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 15 Nov 2016 20:57:19 -0500
- To: www-style@w3.org
- Cc: public-digipub-ig@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.
=========================================
Joint Meeting with DPUB
=======================
Media Queries - MathML
----------------------
- RESOLVED: Add a MQ that reports MathML support, with some way
for scripts to claim support.
- glazou will inform epub of the resolution and Florian will write
the new MQ.
Text - Character-based Alignment
--------------------------------
- Progress on this issue seemed to be awaiting good examples to
dauwhe will collect them and bring them to the attention of
the Text 4 editors.
- dino expressed that the way to get this on Apple's radar is to
reach out with statements of customer/publishing house need.
CSS vs XSL-FO: Gap Analysis
---------------------------
- liam will identify the things in XSL-FO that are hard to do in
CSS, and write up some results.
Page floats
-----------
- Johannes has done a bunch of work and has the basics of level 1
in places but it needs better error handling.
Text - Hanging punctuation
-------------------
- myles proposed waiting until level 4 of Text to address hanging
punctuation as it only works well for CJK in the current
definition.
- There was some proposals around solving for Latin punctuation.
- dauwhe will look more into what inDesign is doing.
- fantasai suggested pair-kerning against the margins
- RESOLVED: Keep hanging-punctuation in level 3, marked as
at-risk, study whether it needs to be punted.
===== FULL MINUTES BELOW ======
Agenda: https://www.w3.org/dpub/IG/wiki/Detailed_TPAC_2016_Agenda#Meeting_with_CSS_WG
and https://wiki.csswg.org/planning/tpac-2016#agenda
Scribe: TabAtkins
Joint Meeting with DPUB
=======================
dauwhe: We wanted to discuss a few issues with CSS, mostly to get
input as to what are good areas to continue working in, so
we don't conflict with design/impl of CSS.
fantasai: Work on hyphenation!
Media Queries - MathML
----------------------
dauwhe: The first thing is MQs. We have some interesting use-cases.
dauwhe: Daniel created one of the them.
glazou: The epub world has an issue with MathML. Legacy systems
don't know about it.
glazou: In particular, the image fallback for MathML.
glazou: The publishers are not really willing to invest in MathML
inside of ebooks, because they're pretty sure legacy
systems won't show anything.
glazou: MathML won't render, nor will the fallback.
glazou: One possible solution is to have a feature MQ for MathML
(like the script one).
glazou: So you can display:block/none for the (separate) image
fallback.
glazou: Not the *only* options for epub, but one of them.
TabAtkins: And this implies that the fallback is done outside of
the MathML, so it'll render normally?
glazou: Yes.
Rossen: You mean native support for MathML, not mathjax?
glazou: Yes. Generally just doesn't support MathML. Sometimes
they'll render the text, sometimes not; they usually don't
render the fallback.
Florian: And if you do have support for script, you load MathJax?
dauwhe: These usually don't have scripting
Bill_Kasdorf: And right now, because of no MathML support, the
epubs don't have accessible math at all.
dino: So let's say you're not in a legacy system. You'll say
display:block on the MathML and display:none on the fallback?
dino: So it's just testing for native; script support will be
something else?
TabAtkins: In script, if it runs, you can handle that yourself.
tzviya: We're not just talking about MathML here. We want to talk
about the future of MQs in general.
tzviya: Some work with ARIA has talked about using MQs for some
solutions there, so we wanted some more general ideas
about MQs.
tzviya: Maybe something about affecting the chrome?
Florian: One topic is that we used to have media types; these
worked poorly. We're deprecating as much as we can, and
instead finding the more granular level of things that
distinguish the types. Pages vs not, interactive vs
static, etc.
Florian: Granular rather than bundled. That's a big theme we've
been running towards.
Florian: Another is to expose various user prefs. User wants
high-contrast, etc.
Florian: Not working on that yet, sometimes tricky. Some OSes
forcibly invert the screen or contrast; others just
express the preference to the app.
Florian: We need to reflect both; whether you've been inverted
(and you should maybe respond to that), and whether the
user requests inverting (that you're expected to do).
duga: About native support, a lot of reading systems provide
polyfills.
duga: I don't necessarily care that the browser renders native
MathML; I care whether it'll look good on a device.
duga: So they need to be able to respond to that.
glazou: So we might to have the MQ respond to script backfilling
support. Some DOM API.
TabAtkins: I'm okay with adding a MathML query, with the added
clarification that having a switch to claim support
would be useful.
dino: That forces a style reflow?
TabAtkins: Yes.
RESOLVED: Add a MQ that reports MathML support, with some way for
scripts to claim support.
ACTION glazou to report to Epub about the MathML MQ being approved.
<trackbot> Created ACTION-789
ACTION Florian to write the MathML MQ.
<trackbot> Created ACTION-790
Rossen: We have a new CSS-AAM joint task force with APA.
Rossen: Intent is to define a11y APIs for all CSS modules/features
that are deemed inaccessible - like the 'order' property
of Flexbox.
Rossen: Just an FYI, I'll drop a link.
Rossen: Please reach out to us with a11y/CSS-related problems or
requests.
<Rossen> CSS Accessibility Task Force -
http://lists.w3.org/Archives/Public/public-aria-admin/2016Aug/0018.html
<Rossen> Here's the initial set of features interested to the
CSS/APA task force
https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features
Character-based Text Alignment
------------------------------
dauwhe: Next: tables.
dauwhe: Aligning on characters in table cells.
dauwhe: Old feature in specs; it's a high-priority for publishing
community. There's some Text 4 language for it.
dauwhe: dbaron did a quick reading from an implementor's POV and
raised 10 or 15 issues.
<dbaron> https://drafts.csswg.org/css-text-4/#character-alignment
dauwhe: We get to a point in these things where the issues need
more input from the impls than on the design.
dauwhe: Wondering what the next steps are on that.
dauwhe: And how we get more interest when we need browser details;
it gets over our heads, as people who don't write
rendering engines.
Florian: I get the impression both groups are waiting on each
other.
Florian: CSS is waiting on epub to come up with examples, so
dbaron's examples can be solved.
Florian: But I think this isn't happening, because those cases
don't happen in "normal" content, they're weird corner
cases.
Florian: Like, mostly aligning numbers with a period or comma.
Florian: So not really questions about nested markup, or different
font sizes, etc.
dbaron: One question is a really substantive one - about intrinsic
width.
dbaron: If you're in a constrained-width situation, is this
flexible? Do you break the char alignment - does your
min-content width include the char alignment? Or something
else?
dbaron: In general, if your table has char alignment but is too
small to fit.
dbaron: Different font size is mostly not much to care, but people
will use bold, and that's a different width. Maybe can
punt, maybe people will notice.
dauwhe: I can try to translate your questions into actual examples
to get feedback on.
dbaron: Another is what happens when you break a line in something
that specifies char alignment.
dauwhe: Interesting, don't have an answer.
David_Wood: Speaking as a rep of an editor company, all of these
are familiar use-cases. We run into all of them,
trying to make WYSIWYG of content, especially with
tiny mobile interfaces.
David_Wood: Bold fonts in a RTL in a list in a table.
[violent agreement]
david_wood: I can take an action to construct examples.
Florian: And preferably pair with preferred answers.
dauwhe: I can try to collect this info and bring it directly to
Text 4 editors.
astearns: I support this, but it's makework until browsers sign
onto it. Any chance browsers are going to do this?
dino: If your customers/publishing houses came to Apple asking for
it, you'd get results.
Tzviya, Wiley: Chemical journals have a huge need for it.
Bill_Kasdorf: And lining up numbers in financial contexts.
dino: I'd appreciate - you can send emails to me - an email saying
you're a publishing house, you have these customers, they
need X.
r12a: Dave, when you're doing these examples, can you put up some
rtl ones?
Florian: Hiroshi provided some Japanese examples, don't think
they're much different.
r12a: But the bidi ones I'd quite like to see.
dino: Send emails asap. Now is a great time to get into Apple's
planning cycle. ^_^
<dino> Send email to dino@apple.com
CSS vs XSL-FO: Gap Analysis
---------------------------
dauwhe: High-level future task thing.
dauwhe: Relationship between CSS and XSL-FO.
dauwhe: Seems to be a general trend of using CSS for a lot of
document creation tasks, rather than XSL-FO.
dauwhe: Might be useful to have a more formal summary of what we
can do right now in CSS, and what we can't.
liam: I've worked on that somewhat, but not made a document.
liam: Been writing a program the last few weeks to auto-convert
from XSL-FO to CSS, to try and find the easy vs hard things.
liam: Previously I approached it architecturally, but the specs
are so different that's hard.
ACTION liam to identify the things in XSL-FO that are hard to do
in CSS, and write up some results.
<trackbot> Created ACTION-791
Page floats
-----------
dauwhe: Status of Page Floats?
Florian: Johannes did a lot of work; at Vivliostyle we want to
work on it, but haven't prioritized it recently.
Florian: The basics of level 1 are in place, needs more
error-handling.
[discussing whether further topics are best done here, or in the
Houdini day]
Hanging punctuation
-------------------
<astearns> https://drafts.csswg.org/css-text/#propdef-hanging-punctuation
myles: In Text 3 we have a hanging-punctuation property.
myles: The keywords in this property describe character sets *and*
situations to apply hanging punctuation, and the amount to
hang that punctuation.
myles: A single keyword does all of these.
myles: These keywords are not very compatible with western-style
punctuation. They're designed for Japanese.
myles: Because this isn't very useful for western-style, and
keywords pull together all three pieces, it's impossible to
extend syntax in the future to separate these out.
myles: It's common for different authors to want to specify
different sets of characters to hang.
myles: It should be postponed to level 4.
fantasai: We had a long ML discussion on this.
fantasai: Both western and eastern hanging-punctuation wants to
say "put parens/quotes on outside"; hanging-punc does
that.
fantasai: In CJK you want to hang certain characters fully outside
the box, because want to maintain the character grid.
But in Western punctuation you want optical alignment
along that edge, don't have a grid.
fantasai: So it's not about specific chars, but based on the shape
of the glyphs instead.
fantasai: Different typesetting engines have different features to
try and get this effect.
fantasai: Some hang hyphens, some period, some both, some more...
fantasai: In each case you're not maintaining a grid, you're just
looking for a sharper edge.
fantasai: It seems to me that classing chars and saying how much
they hang isn't the ideal way to control this.
fantasai: You don't want that level of details, you want to say
"do optical alignment".
fantasai: So better solved by having a "pairs kerning" value that
pairs a character with the edge of the paragraph.
fantasai: So just a single switch in CSS that turns that on.
fantasai: Don't know much about font data, but there is a
kerning-pairs table. Is there an entry for char+end of
line?
lrosenth: No.
fantasai: Ah, would be useful. Powerful and simple for the author.
fantasai: I would rather provide that as a switch, rather than the
author listing all the unicode codepoints that should
hang, how much they hang--they're basically writing a
kerning table in CSS.
fantasai: Also, different fonts have different glyph shapes,
different amount of hang is appropriate.
fantasai: Then there's glyph variants, e.g. swash vs non-swash
fantasai: So then not even character-based, it's glyph-based.
fantasai: This is a font-based thing, so should be in the font.
CSS switch can then be simple.
fantasai: Just too much complexity for author and CSS otherwise.
dauwhe: I'm gonna action myself to see what InDesign does, to see
if they're that fancy.
liam: Saying the solution is simpler if it just requires all the
fonts in the world to be edited, slight problem there.
liam: There have been system in the past with "margin kerning", a
kern pair against a margin.
liam: Could see something like that added, with CSS being able to
augment/override the kerning.
liam: But not sure if that's simpler in practice than what we've
seen.
fantasai: We can also just have an automatic thing where the UA
just makes up values.
astearns: That's what InDesign does.
fantasai: So happy to have UA synthesize values when they don't
exist in the font.
fantasai: But adding character-based kerning in CSS is a lot of
complexity for everyone, and doesn't really belong at
this level.
SimonSapin: We already have codepoint sets in CSS with
unicode-range.
SimonSapin: But not maps.
ChrisL: Two ways of doing kerning - kern-pair table, and a new way
with gpos, based on contextual information.
ChrisL: No way to kern at end of line, because end-of-line isn't
given to the text renderer.
myles: People who know more about pPenType than me says the spec
allows kerning against margins.
lrosen: But nothing in the gpos or other font tables that define
that. You can synthesize something external, is all.
fantasai: So I'd say rather than doing this character-based (which
is wrong anyway, because it's really glyph-based), we
can add a switch that turns on automatic end-of-line
kerning, and that'd be as good as what InDesign does.
Then we can work with the fonts to bake this into the
data tables so they can get more fine-tuned results.
lrosen: If the goal is to do something with fonts, and we're okay
with it only working with future fonts, the OT group is in
the midst of doing OT advancements. Just completed SVG
fonts, now doing the variable fonts.
lrosen: So good opportunity for change right now.
dauwhe: I think we do want to decide on which chars hang and which
don't - only hang period and quotes, but not hyphens (more
subtle), or be really aggressive and hang em-dashes and
question marks.
dauwhe: Doing this off the spec list makes this an all-or-nothing
proposal, which I'm wary of.
fantasai: We also have requests from CJK that they want specific
punctuation chars as linebreak.
fantasai: And we're like, that's great, but we'll start with
generic sets, and in the future add specific controls.
fantasai: Much more complicated than doing presets.
dauwhe: The set here is inadequate right now, as it has no
quotation marks. Definitely want that, possibly a hyphen.
fantasai: Other than quotes, what common things do you want to
control? Chars that are common in books/etc.
dauwhe: open/close single/double quote, period, comma, hyphen
myles: In Latin it's uncommon to hang brackets/parentheses/etc,
but the spec hangs them.
Bill_Kasdorf: Even on a char basis, French quotes aren't the same
as English - French quotes might not want hanging
when you do want English ones.
fantasai: Could see wanting hanging on first/last, but not
internal lines.
fantasai: Spec currently does that. Only periods/commas/??? hang
internally.
David_wood: People want to quote English in French, this is common.
fantasai: You can use whatever quotes you want.
koji: I agree with fantasai about fonts.
koji: Some fonts want 49% hang vs 51% hang, we don't want to go
there.
koji: The idea of pair kerning on beginning/end of line isn't
great for browsers.
koji: We shape logical runs, *then* make linebreaks.
koji: When we pair-kern, we need to reshape on every linebreak,
and that's very expensive.
myles: My proposal was to push this out to Text 4. Judging by
disagreement, sounds like a good idea.
myles: It also seems very clear that some people want to hang
different punctuation. Maybe font is one input, but not
*only* input.
myles: I think having web author list codepoints would be
extremely easy to create typographically bad-looking
hanging paragraphs.
myles: People forget the codepoints all the time, or put in the
wrong codepoints.
<SimonSapin> http://www.fileformat.info/info/unicode/category/Pd/list.htm
Florian: I'm convinced there's no easy answer for western
punctuation. Not convinced the property as designed can't
be extended to this later. For CJK, it might need
extension, but it *works* and is clear.
* fantasai agrees with Florian
Florian: So I'd rather not push it, unless it currently prevents
us from extending in the future.
myles: I opened with the idea that the current values conflate
character sets and ways to hang them, and a reasonable
future will separate those out.
fantasai: I think they'll default; there would be an auto value.
fantasai: So we can add another property, or make this a
shorthand; as long as there's a good initial value
matching our current, I don't think we're blocked.
fantasai: So I also want to keep the current, as it does work for
CJK, and for pullquotes it works for Latin. Refinements
I think we can extend into later.
dauwhe: I would first like to get together and design it for
Latin, make sure there's no conflict.
Rossen: Objections to pushing to level 4?
fantasai: Implemented in WebKit?
Rossen: But they're the ones trying to defer it. ^_^
r12a: What about CJK users that want it now rather than in a few
years?
Florian: The JP gov *will* care about referring to something
that's not CR.
fantasai: I think we shouldn't push it unless we find that it's
not going to work.
koji: epub referred to the spec before it was CR...
<bobbytung> Hanging Punctuation not happens to Trad. Chinese.
Simp. Chinese ebooks recently follow japanese rules in
several Reading System.
myles: The keywords are "first", "force-end", "allow-end", "last".
And these specify char sets.
fantasai: Right. If we want to customize, we can add a different
property, or extend this prop to specify.
<fantasai> e.g. hanging-punctuation: first quotes last quotes;
<fantasai> i.e. hanging-punctuation: [ <position> <charset>* ]+
<fantasai> Can split into longhands, or add a parallel property
* skk thinks hanging-punctuation is not referred from EPUB3.0.1,
at least...
koji: correction: this property was not referred to by epub.
skk: epub already renders with hanging-punctuation, even if not
explicitly referencing the spec.
<addison> we implemented it...
fantasai: I think we should leave it at level 3, unless someone
shows me a problem.
dauwhe: I'll work on the syntax.
r12a: Worried we're on a closed community; leaving it off of epub
list might have just been an oversight.
Florian: I'd say you can't nicely typeset a book in Japanese
without this, and as it is works for most books.
<addison> +1
RESOLVED: Keep hanging-punctuation in level 3, marked as at-risk,
study whether it needs to be punted.
Received on Wednesday, 16 November 2016 01:58:26 UTC