W3C home > Mailing lists > Public > www-style@w3.org > February 2017

[CSSWG] Minutes Seattle F2F 2017-01-11 Part VI: Writings Modes, CSS Tables, Values & Units 4

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 13 Feb 2017 20:20:53 -0500
Message-ID: <CADhPm3v-X0=9ZZONs+t3zFLQ8fqwNBVXscsXB_NkPbAtYQZvog@mail.gmail.com>
To: www-style@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.
=========================================


Writing Modes
-------------

  - RESOLVED: No interaction between ::first-letter and
              text-combine-upright (other than what's already
              specified -- that text-combine-upright can't combine
              across element boundaries). The use case can be solved
              using markup and 'text-combine-upright: all' if needed.
              https://github.com/w3c/csswg-drafts/issues/653
  - RESOLVED: Create Level 4 of Writing Modes as current draft,
              Level 3 to drop all at-risk items, publications TBD

CSS Tables
----------

  - RESOLVED: Publish new WD of css-tables

Values & Units 4
----------------

  - RESOLVED: Reject all changes in
https://github.com/w3c/csswg-drafts/issues/837
  - There was resistance to adding support for pica because it
      doesn't parse well
  - RESOLVED: Add cap unit (In response to
https://github.com/w3c/csswg-drafts/issues/660)
  - RESOLVED: Add issue to css-values-4 asking for whether didot,
              cicero, ens are needed.
  - RESOLVED: Add an issue to ask if there's a need for ideographic
              character face unit.
  - RESOLVED: Add unit math to css-values-4
  - RESOLVED: add min() and max() to css-values-4, valid within and
              without calc(), accepts calc expressions as arguments,
              N arguments

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/seattle-2017

Scribe: fremy

Writing Modes
=============

  <koji> https://drafts.csswg.org/css-writing-modes-3/issues-cr-2015
  koji: Last tpac I was actioned to update the
        https://drafts.csswg.org/css-writing-modes-3/issues-cr-2015
  koji: We have two open issues.

text-combine-upright and initial-letter
---------------------------------------

  koji: Myself and Florian think issue 8 should go to css-pseudo
  florian: There is another sub issue in issue 8
  florian: about what happens to quotation around text-combined text.
  fantasai: The answer should be no, if you want this, you put a
            span around it.
  florian: Is skk in the room?
  skk: Yes, I can agree with this.

  RESOLVED: No change on the sub-issue
(https://github.com/w3c/csswg-drafts/issues/653),
            this can be solved using markup if needed.

Publication
-----------

  koji: I propose we move this to PR, is there any objection?
  <dbaron> Where's the link to the test results?

  astearns: What about the various categories of failures?
  florian: We don't have two implementations for sideways, so we
           would need to drop them.
  jensimmons: I don't like that.
  astearns: Delay them to next level is what we meant.
  jensimmons: Could we sponsor another implementation to get rid of
              this problem?
  koji: We are looking into it but it won't happen very soon.
  florian: So you don't think that changing the level will make it
           slower to be implemented? that is right?
  myles: I can't comment on plans, we won't change them based on the
         level.
  florian: Then I am fine.
  <jensimmons> is there a link to the issue for implementing
               sideways-* in Blink?
  <jensimmons> well, of course…. I should say, could someone drop
               the link
  <jensimmons> here’s the ticket for implementation in webkit
               https://bugs.webkit.org/show_bug.cgi?id=166941

  tantek: A behind-flag implementation counts btw.
  myles: That sounds weird though.

  fantasai: Since we have received a lot of help from the Japanese
            government, and they care a lot about schedules, we
            should consider moving forward without this feature
            rather than waiting for it to be completed.
  fantasai: How long does it take to go from one stage to the other?
  Bert: Six weeks.
  dbaron: Plus some one month or two of padding (laugh)
  Bert: (details the "six" weeks which means three weeks minimum but
        a few more weeks of padding)
  fantasai: Ten weeks before the Tokyo f2f then?
  dbaron: That seems pretty soon, February 6.
  dbaron: So we can delay for as much as two weeks without risking
          not having a rec in Japan.
  dbaron: Seems short to attempt any implementation.
  <dbaron> CSP2 did it in about 6 weeks
  <dbaron> actually CSP2 did it in 5 weeks and 2 days

  astearns: Proposal is therefore to drop sideways and go to PR as
            soon as possible then.
  florian: Is there anything else waiting for level 4?
  florian: Otherwise you can make a level 4 right away and push a
           very light level 4, we could get sideways pretty soon.
  gsnedders: I thought we could get away with the waiting time if
             there is good indication the features aren't likely to
             cause trouble.
  gsnedders: Since they are in current CR, that match the criteria.
  tantek: I had the same point; plus you can also overlap the
          exclusions periods.
  tantek: The process doesn't have special consideration for levels.
  tantek: Other solution would be to spit the spec.
  Florian: We won't get an implementation in the time we would save
           anyway, lets just do the normal way.

  astearns: Can we resolve on taking the current spec to PR minus
            the sideways features?
  dbaron: Can we get the link to the implementation report?
  <Bert> http://test.csswg.org/harness/review/css-writing-modes-3_dev
  <gsnedders> https://test.csswg.org/harness/results/css-writing-modes-3_dev/grouped/filter/1/
              specifically shows what doesn't meet CR-exit criteria
  <koji> http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-09.html
  fantasai: Since some tests are failing, we would need to write a
            document on why some of the tests do not really matter..
  Florian: We really need some document because some things are red
           and we will need to justify why for the transition
  Florian: and don't forget to also include all the tests that we do
           pass, there should be a lot of green and a bit of red to
           put all the chances on our side.
  Florian: 232 tests don't pass because new tests seem to have been
           added
  Florian: that seems a lot
  <tantek> also need to have feature coverage in tests
  koji: In September there were 118
  Florian: The other problem is that features themselves have
           failure, even if we can always find two implementations
           for any test.
  Rossen: Well the criteria is clear, it is by feature.
  Florian: Yes, and features can require more than one test.
  ??: so what do we do?
  ???: Also we can draw a line on the test suite, and keep letting
       people contribute tests, we cannot keep the report up to date
       all the time.

  Florian: Is there a text-combine implementation?
  Rossen: Yes, in Edge it now does.
  tantek: Second implementation?
  Florian: So do we drop?
  Florian: Also some features we will remove may need errata in the
           future.
  Florian: The look-ahead feature.
  ????: we could make it undefined in the level 3 then.

  (Florian and fantasai reviewing the features)

  fantasai: multicol + orthogonal flow which is too long for the
            document => do something smart (but nobody implemented
            it)
  Florian: But this is not a feature, just a behavior clarification;
           we can use SHOULD and get away with it without actually
           removing the recommendation.

  gsnedders: Are webkit and blink able to be considered two
             implementations?
  eae: That happened during the fork, so a fair amount is shared,
       but a fair amount is likely not too.

  Florian: So, anyway, can we use SHOULD, I don't like un-defining
           the feature, we have a goal.
  fantasai: Or we could use MAY.
  astearns: So, looks like we need an updated draft, then we can ask
            for PR.
  fantasai: I will work on the edits.
  astearns: And koji will work on the implementation report.
  Florian: With a test snapshot from September minus things we will
           have removed?
  plinss: It is possible (but requires some work).

  astearns: And then we split the spec, with what name for the
            second version?
  fantasai: Writings Modes Level 4; levels is a css thing not in the
            process.
  SteveZ: I don't see any rule who seem to either encourage nor
          discourage that.
  SteveZ: The other problem is that changing the MUST to SHOULD risk
          to be considered a substantial change and trigger another
          CR.
  Florian: Well, the change will not risk having an impact on
           existing implementations, everyone that was compliant
           still is.
  tantek: I disagree with SteveZ too.
  Rossen: Let's keep the split process out of the f2f.

  <dauwhe> does anyone know if the new PR of writing modes will
           cover all the prefixed features in EPUB?
  <skk> dauwhe, do you mean EPUB3.0.1? or EPUB3.1?
  <dauwhe> 3.1

  ACTION fantasai: drop at-risk features that were not implemented
         (with possibly a "soft-drop") and publish updated L3, and
         republish what we have now as L4.
  <trackbot> Created ACTION-815
  ACTION koji compile impl report for writing-modes
  <trackbot> Created ACTION-816
  ACTION plinss create snapshot of writing modes test suite
  <trackbot> Created ACTION-817

  RESOLVED: Create Level 4 of Writing Modes as current draft, Level
            3 to drop all at-risk items, publications TBD

CSS Tables
==========
  Scribe: Florian

  <gregwhitworth> https://github.com/w3c/csswg-drafts/projects/3
  fremy: We added some text for width distribution in fixed table
         layout.
  fremy: Please review.
  fremy: Also fixed some bugs.
  fremy: The spec missed some references to css2.1.
  fremy: It's been clarified with regards to percentage heights.
  fremy: It would be good to have a new WD.

  Florian: We have a bit of an ongoing discussion on repeated
           headers and footers, but that doesn't have to block.

  RESOLVED: Publish new WD of css-tables

  gregwhitworth: Please give feedback on the things that are marked
                 as "need UA review"
  dbaron: It's called "ready for UA review"
  gregwhitworth: This is better to get confirmation from existing
                 implementation first that this is fine before
                 trying to get WG discussions / resolution.

  [discussing what to discuss]

Scribe: fantasai

Values & Units 4
================

  <fantasai> https://drafts.csswg.org/css-values-4/
  <fantasai> https://drafts.csswg.org/css-text-decor-4/
  <astearns> https://drafts.csswg.org/css-values-4/#changes
  <fantasai> https://drafts.csswg.org/css-values-4/#changes
  <fantasai> Added the vi, vb, ic, lh' and rlh'' units.

  fantasai: Should we publish FPWD, or are there other things we
            want to handle before FPWD?
  fantasai: calc() serialization rules are also "new", marked as
            under discussion.
  jensimmons: Aspect ratio unit?
  fantasai: Still not clear whether that should be unit or property.
  Florian: Lots of proposals for units.

Issue 837
---------

  dauwhe: I propose closing issue 837 with prejudice.
  Florian: And person proposing them explicitly said, not discussing
           use cases.
  astearns: So, resolve to close issue?
  tantek: I propose requesting that the person proposing these units
          incubate them in the WICG. :)
  astearns: I'm hearing no objection to close this issue per WG
            resolution.

  RESOLVED: Reject all changes in https://github.com/w3c/csswg-drafts/issues/837

Adding older typographic units
------------------------------

  fantasai: Wanted to see if anyone has other things to add to this
            draft before FPWD.
  dauwhe: Have we discussed adding old-school typographic units?
  dauwhe: I've done a bunch of conversions from pica notation.
  dauwhe: <picas>p<points>
  astearns: I've been waiting for properties and values to get to
            the point where you can put your own parsing for this.
  astearns: Would you want to see picas in this draft, or wait for
            the future, or...?
  dauwhe: As long as we're drawing up a FPWD, might be worth putting
          in.
  SteveZ: Role of FPWD is to trigger patent review, so more complete
          is better than less complete.

  astearns: Would anyone object?
  fantasai: Would like to hear from dbaron/TabAtkins because this
            involves the parser.
  TabAtkins: This doesn't parse well with CSS.
  TabAtkins: Strongly opposed to that particular notation going into
             CSS, unless we adjusted Syntax to allow for it.
  TabAtkins: And then I'd still be unhappy about it.
  dbaron: are you allowed to use e notation in both halves?

  Florian: What about introducing a functional notation?
  Florian: It would at least allow you to convert existing designs
           very easily.
  TabAtkins: Kinda would prefer to wait for Houdini to see if it's
             popular enough.
  Florian: Doubt these units are patented.
  * liam notes to dauwhe that Point Cicero is still in use (or was
         last time I checked) in Europe as well
  dauwhe: There's 19th century prior art here.
  dauwhe: It's nice, but not critical.
  <liam> thinks it'd be better to add @unit tip { size: 12cm; range:
         linear; } or something rather than every possible unit
  <TabAtkins> liam: Yeah, a Houdini API for units (+ a declarative
              version) would be nice.

Cap Height Unit
---------------

  fantasai: There was a request for a cap height unit.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/660
  myles: Problems with cap-height aren't any worse than ex-height

  SteveZ: i18n issues?
  Florian: Are there fonts that don't contain ASCII range?
  dauwhe: Inline does have heuristics for figuring these out,
          because it needs the cap height.

  astearns: Objections to cap height?
  SteveZ: Use case?
  astearns: Sizing things to match capital letters.

  SteveZ: Thai?
  <liam> +1
  myles: ex-height in Thai?
  myles: We've certainly had requests for this unit. Haven't had as
         many request for all of the various other typographic units.
  SteveZ: We don't get much requests for things that aren't English
          or European.
  SteveZ: Indic/SEAsian don't talk to us very much.
  Bert: There are various TFs writing typography requirements for
        various languages.
  Bert: Should at some point read them.
  SteveZ: I won't object strenuously.

  Florian: I would like to see specific use case.
  fantasai: Bert had a magazine where the title was in caps, and
            there was a wide stripe of color exactly the cap height.

  astearns: We need to know this measure for initial letter anyway.
  Florian: There we have the feature but not the unit.
  astearns: We know the feature is inadequate for some other
            languages. Adding this in would allow doing something
            slightly different if that's what you wanted.
  SteveZ: So for languages that have caps, you'd use this unit, and
          for others you'd use some other measure.
  astearns: Say you have fancy roman font, and fancy background.
            Initial letter will alight top of fancy background with
            top of first line. But what you really want to do is to
            match the perceived cap height of those glyphs.
  dauwhe: initial-letter will take the cap-height of the glyph.
  astearns: Depends on how the font is put together.
  Florian: But then the cap height unit wouldn't help either,
           because it comes from same source.
  Florian: Not strongly oppose, just might come up with better
           solution to use cases if we don't need the use cases.
  TabAtkins: Core use case is image replacement for glyphs that are
             matched exactly to the capital letters.
  plinss: That's what it use to be.

  astearns: Objections to cap unit?
  SteveZ: Given there's a definition in initial-letter, no objection.

  RESOLVED: Add cap unit

  ACTION TabAtkins Fix bikeshed errors in css-values-4
  <trackbot> Created ACTION-818

ciceros, didot, and ens
------------------------

  plinss: Propose to add ciceros, didot, and ens
  <plinss> didot (dt) where 15dt=16pt, cicero (cc) where 1cc=12dt,
           en=0.5em
  <liam> +1 to adding didot and cicero and ens
  <dauwhe> https://github.com/w3c/csswg-drafts/issues/315
  Bert: People use mm now,
  smfr: Don't want to add if no one's going to use them.
  fantasai: Since these are simply multiples of existing units,
            might be worth waiting to see if there is author demand.

  Florian: What about height of kanji characters?
  fantasai: Why not use ems?

  <liam> +1 though to way of adding user-defined units instead.
  <liam> [en is useful because it approximates average character
         width for a lot of fonts]
  <myles> liam: isn't that just calc?
  <liam> [no, not calc really, although a preprocessor could do that
         for the static cases (not e.g. cap height)]

  astearns: dt, cc, etc. can be done through preprocessor
  astearns: For those units that aren't simple conversions, might
            want to see evidence
  astearns: that people are putting in the effort to make those
            conversions.
  dauwhe: Might be worth checking PDF renderers as well.
  plinss: It's a multiple, but not so convenient.
  SteveZ: Put an issue in the document?
  Florian: If you have use cases, come forward.

  RESOLVED: Add issue to css-values-4 asking for whether didot,
            cicero, ens are needed.

  myles: When do we know when to cut off feedback on this issue?
  astearns: When we want to close issues to go to CR.

  * liam notes indesign supports cicero

Kanji Unit
----------

  Florian: Kanji character
  Florian: If you size a gaiji image to 1em, ink area will be a bit
           too big.
  dbaron: ic unit is wrong axis?
  fantasai: It's equivalent to an em generally.
  fantasai: Includes the extra space around the glyph ink
  ....
  fantasai: I understand the use case perfectly, and if we get that
            request from CJK people, then I'm ok to add it. But so
            far doesn't seem to be a high request.

  dbaron: Are the font metrics for that any good?
  dauwhe: Font metrics are a constant disappointment
  myles: It's important for a UA to be able to figure out if the
         metric is bad and provide an alternate. For cap-height,
         very simple.
  fantasai: We actually have the heuristics for this in the initial
            letter spec, because needed there.
  SteveZ: People at Adobe reviewed that section and said it was OK.
  astearns: We have a use case, idea of how it'd be done...
  Florian: But don't have strong demand.

  RESOLVED: Add an issue to ask if there's a need for this unit.

Unit Math
---------

  astearns: Anything else for this draft?
  fantasai: unit math, e.g. divide length by length and use in a
            formula
  <fantasai> https://github.com/w3c/csswg-drafts/issues/545
  fantasai: Also min() and max()
  <fantasai> https://github.com/w3c/csswg-drafts/issues/544
  astearns: Do we want to put unit math in the draft?
  dbaron: I think we already have a resolution to do this.

  RESOLVED: Add unit math to css-values-4
  astearns: Don't have to get all the details in, just get it
            roughly sketched in.

min/max
-------

  astearns: I think we should get min/max in as well
  dbaron: Question about min/max
  dbaron: Are we only adding them inside calc, or also as top-level
          things?
  [discussion of what that means]
  TabAtkins: Would min() and max() accept expressions then at top
             level?
  dbaron: Early drafts of calc() accepted min() and max()
  dbaron: They were things that could be in calc()
  dbaron: If the calc() only contained min() or max() and nothing
          else, could eleminate the calc() wrapper

  RESOLVED: add min() and max() to css-values-4, valid within and
            without calc(), accepts calc expressions as arguments, N
            arguments<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
	<tr>
        <td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
		<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
		</td>
	</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Tuesday, 14 February 2017 01:21:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 14 February 2017 01:22:06 UTC