W3C home > Mailing lists > Public > www-style@w3.org > November 2016

[CSSWG] Minutes Lisbon F2F 2016-09-19 Part III: Joint Meeting with DPUB [mediaqueries] [css-text] [css-page]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 15 Nov 2016 20:57:19 -0500
Message-ID: <CADhPm3uMfKnsR1RSJcn=4dowGcCSXwMciNywkPrqNK1Uf1gEMA@mail.gmail.com>
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:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 November 2016 01:58:28 UTC