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

[CSSWG] Minutes Seattle F2F 2017-01-12 Part II: Text Breakout - Text Decoration, Step-Sizing/Rhythm [css-text-decoration] [css-rhythm]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 13 Feb 2017 20:58:20 -0500
Message-ID: <CADhPm3ueY51=gLxCJNegQh5bp_iKJr=JQbhQp8H25S1pymXgrQ@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.
=========================================


Text Track
++++++++++

Text Decoration
---------------

  - fantasai introduced her draft of Text Decoration Level 4 for
      discussion: http://drafts.csswg.org/css-text-decor-4/
      - She will add examples for offset based on different anchor
          points.
      - There was some question as to if 'width' was the right word
          for text-decoration-width. It was given that name for
          consistency with properties like with border-width and
          stroke-width, but may still need bikeshedding.
      - There was support for use-font to allow specifying user
          value in the font.
  - RESOLVED: FPWD of text-decoration level 4
              (http://drafts.csswg.org/css-text-decor-4/)
  - The relative position example for text-underline-position was
      reviewed and found helpful in identifying correct behavior.

Step-Sizing/Rhythm
------------------

  - There was concern about having this as a separate spec from line
      grid as they'll be used together frequently. They will stay
      separate for now and an issue about it will be raised on the
      FPWD.
  - The name also concerned some people, but there wasn't a better
      idea right now.
  - RESOLVED: First published working draft for step sizing
              (https://drafts.csswg.org/css-step-sizing-1/).
  - RESOLVED: koji, fantasai, and dauwhe as co-editors.
  - RESOLVED: Rename to css-rhythm

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

Agenda: https://wiki.csswg.org/planning/seattle-2017
Note: The group split the morning of the 12 January on two
      tracks: FX and Text.

Scribe: zcorpan

Text Track
++++++++++

Text Decoration
===============


  <fantasai> http://drafts.csswg.org/css-text-decor-4/
  fantasai: I drafted up a text decoration module.
  fantasai: Plan so far is to add ... text-shadow I haven't added.

text-decoration-width
---------------------

  fantasai: Added text-decoration-width
  fantasai: ideally you get that info from the font for auto
  fantasai: but here can specify a length
  fantasai: doesn't cascade independently from color etc.

text-underline-offset
---------------------

  fantasai: text-underline-offset which needs overline offset also...
  fantasai: if you specify a length, disables automatic adjustments,
            just starts at origin point
  fantasai: which origin depends on the value of
            text-underline-position.
  fantasai: (reads from spec)
  fantasai: Positive moves up, consistent with how vertical-align
            works.
  Florian: I expected the opposite.
  fantasai: Wanted to align with vertical-align.
  fantasai: Technically it's inward rather than up, so underline
            flips sides it goes in the right direction as
            appropriate.
  fantasai: If you're starting with under edge it will go up.
  fantasai: Consistency with vertical-align is important.
            Consistency with font coordinate is also important.
  eae: This makes sense to me.

  fantasai: Currently UAs are allowed to make automatic adjustments
            for font changes
  fantasai: but not the case of vertical-align changes
  fantasai: Similar effect with automatic baseline.
  fantasai: What happens is the underline is slicing through the
            text, so can move it.
  fremy: Green one is what edge is doing.
  koji: ???
  myles: 2 spans with different box sizes?
  fantasai: Inside there's a big text element. nested spans.
  fantasai: small text span has small underline ...
  koji: webkit and blink does low text position.
  fantasai: Question is, do we want this property to also disable
            these automatic adjustments?
  astearns: We can ask authors
  astearns: leave as is for now.
  astearns: Anyone have an opinion on this?

  fremy: Specifying the properties is fine but giving control to the
         author will produce different results anyway.
  fremy: Author will try in one browser and then give different in
         another browser.
  fremy: Auto value should just do nothing.
  fremy: Specify some other completely different behavior for other
         values, that can be consistent across browsers.
  astearns: Agree for the case where it is author-controlled.
  fantasai: We should do that also.
  fremy: Gecko is using only elements where you specify underline
  fremy: edge uses the entire text range.
  fremy: Violation of the spec but produces better results than
         gecko.
  jensimmons: link?
  <fantasai> https://drafts.csswg.org/css-text-decor-3/#text-underline-position-property

  koji: Question about offset:
  koji: Table sets initial position alphabetic baseline
  koji: What offset is not specified when it's under....
  koji: for auto we draw slightly below baseline.
  fantasai: 0 is exactly at alphabetic baseline.
  fantasai: If we start from the UA chosen position the author won't
            know where that is
  fantasai: 0 at baseline is better
  Florian: Is this going to make authors want a descender unit?
  fantasai: Have control over where the origin is -- use
            'text-underline-position: under' if you want the bottom
            edge

  ACTION fantasai: add example to offset from different anchor points
  <trackbot> Created ACTION-819

  myles: Is there a reason why you chose to center the thickness[?]
  myles: Should grow outward.
  fantasai: ok
  SteveZ: Can change width without changing position.
  fantasai: Sounds good.

  myles: Reason we use the word width?
  fantasai: Consistency with border-width.
  myles: Width is usually a metric vertically.
  fantasai: Not true for border-width.
  fantasai: Better to be consistent with border-width, stroke-width,
            etc.
  astearns: Should list it as a mistake to call things -width,
            should have been -thickness?
  Florian: Too long.
  <jensimmons> *** I want to concur with myles that
               text-decoration-width is confusing.
  <jensimmons> *** having a hard time getting a chance to speak

  koji: Proposal that we could have a value to specify user value in
        the font.
  fantasai: That's auto.
  myles: Don't think so.
  myles: I tried to make auto take into consideration what the font
         says.
  myles: Terrible results.
  myles: Having taken the font's metric into consideration ...
         should be separate thing
  myles: use primary ...
  Florian: Because fonts are broken?
  myles: Right.
  myles: So should be separate value.
  fantasai: We have a keyword somewhere for this.
  fantasai: Can't remember what we used it for.
  SteveZ: ???
  fantasai: Looking at text-decor-4....
  fantasai: use-font keyword.
  fantasai: Sounds good.

  SteveZ: Why vertical text is alphabetic baseline is the choice
  fantasai: Will want that in some cases.
  fantasai: Auto keyword, should be able to specify offsets from
            there...
  SteveZ: agree ...
  fantasai: For vertical text, Japanese/Chinese, will get left or
            right line rather than alphabetic line.
  SteveZ: Get ransom note underlines.
  fantasai: Position of underline in vertical text depends on
            language; English text in a Japanese book is on the left
            even when Japanese text is on the right.
  fantasai: Position of the underline is controlled by the
            underlining element, not descendants, so won't get
            ransom note effect.

text-decoration-width naming
----------------------------

  jensimmons: Concur with myles concern about having width for
              underline will be confusing.
  jensimmons: Can bikeshed it later.
  jensimmons: underline ... width seems like how wide it is.
  jensimmons: text-decoration is already hard to remember.
  myles: You still have to use the phrase "text-decoration" to turn
         it on.
  jensimmons: Yes. Not suggesting to change that.
  fantasai: We can in the future decide ...
  jensimmons: I'm advocating "thickness" or similar word
  fantasai: 1) too long
  fantasai: 2) because we're using width for stroke-width, is
               consistent, which is especially important for
               non-English speakers
  jensimmons: I understand. But still confusing I think.
  fremy: More people don't speak English.
  fremy: Size?
  myles: Might be worth it to be inconsistent.
  astearns: It might but will not figure this out today.

text-emphasis-skip
------------------

  fantasai: text-emphasis-skip
  fantasai: Allows you to say which characters are skipped
  fantasai: Typically you skip spaces and punctuation.
  fantasai: can skip other things as well
  fantasai: This is so you don't have to put spans to get correct
            effect.
  Florian: Do we need the same kind of split into longhands as
           text-decoration-skip.
  fantasai: Don't think so, related set of things.
  fantasai: That's it for what's in the draft.

  Bert: Is 'text-emphasis-skip' part of the 'text-emphasis'
        shorthand?
  fantasai: It's not.
  fantasai: It's usually a document-wide setting.
  fantasai: May change later, e.g. for a particular headline.
  fremy: If we have text emphasis and don't specify skip, value will
         be inherit.
  fantasai: Don't think we do that anywhere else
  fantasai: shorthand resets everything.
  astearns: things we decided to add ???

Miscellaneous
-------------

  Florian: We should get an ED.
  Florian: In the header you're linking to tracker, want to change
           that?

  fremy: Interested in having clear illustration for what expected
         result should be for auto.
  fremy: Should have pictures.
  fantasai: It's in Level 3
  fantasai: We'll add examples.
  astearns: Also example for positive vs negative offsets.

  fremy: ???
  Florian: Open issue for that.
  myles: Think it's doable for an impl to clamp values to reasonable
         extremes.
  fantasai: Good point. Should put that in.
  fantasai: Ink overflow?
  myles: Don't want super big underlines.
  fantasai: 1) should allow UA to clamp offset values
  fantasai: 2) specify that it's ink overflow
  astearns: Some % of an em?
  myles: Whatever is sane.
  eae: We clamp font size.
  ?: Why clamp this?
  fantasai: Features on the web are abusable.
  fantasai: Shifting an offset, why can't I move it to anywhere on
            the page...
  astearns: Should we close off the L4 discussion?

  astearns: Resolution for FPWD?

  fremy: webkit-text-field can specify an image
  fantasai: Issue for paint spec.
  fremy: If it's considered part of the text.
  fremy: ???
  myles: I imagine it would be, this is how I do overlines....
  myles: Should clarify to not use text-underline-offset for
         overlines
  fantasai: yeah ok

  fantasai: By April level 3 should be stable enough
  myles: Provides valuable use cases
  Florian: Together with cap-height ...
  Florian: The thickness/width thing

  Florian: when it's wavy, thickness of the stroke?
  fantasai: Don't think it's specified.
  fantasai: If you say straight/wavy, the amplitude of the wave is
            greater than the thickness of the straight line, which
            is more like the thickness of the wave stroke.
  SteveZ: ???

  astearns: Anyone object to FPWD of level 4
  Florian: Pending edits sounds good.

  RESOLVED: FPWD of text-decoration level 4.

  ?: Why is it a diff spec? Diff specs are bad.
  fantasai: Have to balance badness of diff spec with maintenance
            issue.
  fantasai: Atm, because Level 3 parts are going through changes,
            doing a diff spec to make it more maintainable and
            less risk to introduce errors
  fantasai: It's reasonable to fold in when the lower level draft
            has entered 2nd CR phase.
  fantasai: Flexbox went through this double phase, 2nd phase is
            much more stable.
  SteveZ: Content of this spec is what's in previous...
  fantasai: We should publish early and often.
  fantasai: Other option is to hold off publishing.
  tantek: Should have more info in intro about why it's so empty.
  SteveZ: Abstract could say that.
  tantek: Or status.
  fantasai: Section 1 is basically that...
  Bert: ok
  <tantek> I was thinking in generic language that we could perhaps
           include in other delta specs too
  <astearns> we should have a standard "include level n-1 content
             here" issue (from bikeshed?) and a standard intro issue
             describing diff specs

text-underline-position
-----------------------

  astearns: level 3?
  fantasai: text-underline-position
  fantasai: Auto value which is like alphabetic most of the time
  fantasai: used to have alphabetic, but request to drop that so we
            did
  fantasai: left/right which do under
  fantasai: restrictions/allowances of where to draw the underline.
  fantasai: (reads from spec)

  Florian: Subscript is not to avoid ???
  SteveZ: First 1st is correct? or both?
  fantasai: Both correct.
  fantasai: Can use offset value from OpenType.
  fantasai: Baseline alignment causes boxes to be positioned
            slightly offset
  fantasai: edges of the boxes won't necessarily all align
  fantasai: UAs is expected to accommodate those things
  fantasai: don't adjust for that shift
  fantasai: Just adjust for baseline alignment, not baseline
            shifting.
  SteveZ: No difference between font size change.
  fantasai: Right.
  fantasai: If alphabetic baseline in two different fonts are
            different... UA will account for that.
  SteveZ: Subscript can use skipping.
  fantasai: Yes.

  fremy: Transform?
  fantasai: We ignore transform
  SteveZ: Transform is applied after.
  fantasai: Yes.

  fantasai: Relative position is more interesting.
  fantasai: Different impl do different things, should try to make
            the spec match what UAs do or want to do.
  Florian: Do you know if the range of variations is inside the
           allowed spec things?
  fantasai: Outside, do the thing that is not allowed.
  fantasai: Red thing is wrong.
  myles: I think this is a good direction.
  myles: We don't follow it but that is bad. Positive feedback!
  astearns: A bug for this?

Step-Sizing
===========
  Scribe: eae

  <koji> https://drafts.csswg.org/css-step-sizing-1/
  astearns: Not sure what the right order of discussion is.
  koji: I have updated the spec since last time I asked for a
        review, primarily I got feedback on three items.
  koji: First one, inline-width stepping, we think it's nice to do
        but consensus was that it is lower priority than height.
        Propose to defer. Was removed from spec.
  koji: Second thing; baseline feature from previous draft. Similar
        feedback, concerns about baseline, lower priority than other
        features. Was also removed.
  koji: The only feature remaining is line-height stepping.
  koji: Last feedback, a few people wanted to have block height in
        addition to line height. Only line-height stepping is too
        fragile. Having block-height as well makes it more stable.
  koji: Spec has been under discussion for over a year, propose to
        publish draft as is and then work together with fantasai to
        update and come up with new working draft.

  fantasai: We should have all features for the first working draft.
  fantasai: Can sketch up for first publish based on email.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0089.html
  fantasai: The part you have written is more concrete, if we want
            to add more details later to this part we can do that.
  astearns: We should at least have the outline in the draft.
  dauwhe: Copy email into github issue 490.

  Florian: I used to have concerns with this spec, but I have no
           strong objections for the remaining parts. What has been
           sketched out so far has missing pieces but no worrying
           aspects.
  Florian: One of the reasons for the spec taking so long to approve
           is due to objectionable parts of the spec rather than
           missing pieces.
  Florian: Will not block current suggestion.

  fantasai: First public draft doesn't have to have all of the
            details, goal is to get the feature there so people can
            see what it looks like.

  astearns: If line-step sizing goes ahead and block step sizing
            does not we can then move that to the next level.
            Concerned about adding block step sizing later on.
  SteveZ: Not prohibited by process, there is a second step.
  Florian: Once we have sketched out the block part, if there are
           still concerns we should take it out.
  SteveZ: You can always mark it at risk.
  SteveZ: There are important use cases only addressed by block step
          sizing.
  fantasai: With block step sizing I think we can get to 80% of the
            uses cases, without it much less so.
  astearns: Getting the outline and publishing the draft sounds like
            the way to do it.
  myles: Is the idea that browsers in the future will support this
         *and* line grid?
  astearns: Yes.

  Florian: Once you have this and line grid, it is not clear that
           there are many cases where you want to use this alone but
           I can see uses for this and line grid being used in
           conjunction.
  Florian: You set your line height which gives the rhythm for the
           line grid, if you then have sup/sub or different font
           sizes...sometimes it is enough to adjust the line grid,
           sometimes not. You don't want double spacing. Combining
           line grid and step size might be a way to adjust the
           slack that sticks out.
  myles: Sounds like that shouldn't require this, should be part of
         line grid.
  fantasai: There used to be a slack property in line grid, iirc.
  astearns: One example I have considered, I'm using a line-grid for
            setting baseline. There are also graphics using line
            grid. Currently fuzzy, only does positioning of the
            elements. Only adjust positioning, seems appropriate,
            shouldn't also change sizing. Step size can be used to
            control the sizing.
  fantasai: I think line-grid proposal would support that and resize
            the box.
  astearns: Should be a separation of concerns, line grid should
            only change position and then step sizing can control
            size.
  fantasai: That reminds me of some of the grid proposals. Original
            Msft proposal separated grid start idex and grid span =
            specifying position & size, end position implied.
            But new grid proposal is based off start/end lines,
            which imply spanning size. Imho line grid should be the
            same.

  fantasai: When you fall off your rhythm, you have to figure out
            how to handle that case. Line grid and step sizing
            handle that differently. You might value one behavior
            over the other.
            When there is a missized item in line grid, you preserve
            rhythm absolutely but there is a gap. For step sizing,
            no gap, just break in rhythm. One might want one or the
            other. Not unreasonable to have both features.
  fantasai: Having a gap in the content on continuous media looks
            bad, little benefit. But if you have parallel columns,
            having the gap to get cross-alignment might be
            appropriate. Depends on use case.
  astearns: Put another way, there are examples in the line-grid
            spec that have examples that do not fit the rhythm as
            the gaps would be too big. There are extra things in
            line-grid to avoid that. We might be able to remove
            line-grid complexity be using step-sizing.
  fantasai: I think that's a different thing.

  myles: There are differences and both have uses cases. Interop
         between the two could be complicated and for many authors
         that might be confusing. Especially as authors might only
         know about one or the other. I think it would make a lot of
         sense to have both described in the same document to
         preempt that.
  fantasai: Quite different model and the interplay isn't that big
            between them. Would prefer to have them described
            separately. Technical details are different, would
            prefer in separate specs but am fine with a lot of
            references between the two.
  fantasai: In terms of technical work, having them in separate
            models preferred and make it easier.
  SteveZ: I can see a reason to put them together, there are
          conflicts if both are turned on. On the other hand, from
          an implementation point of view, step sizing likely to
          happen much quicker than line-grid so they'll be separate
          anyway. Having a note that explains how they work together
          would be helpful. Might end up in one of the specs
          eventually.
  Florian: The risk of getting interaction wrong from having two
           specs is minimized by having the same people working on
           both. There is tension.
  myles: If you fast forward 50 years, there will be two similar but
         very different specs that are confusing. An author will
         have difficulty figuring our which one to use.
  Florian: If you put too much into a single spec it'll be
           terrifying. The step-sizing part is comparably much
           simpler. If you combine it that might scare authors away.
  astearns: I share your (myles) concern for authors. We should
            raise issues on the specs to clarify the potential
            conflicts. Ideally before the 50 years pass.
  myles: Of course this should be defined and speced.
  SteveZ: No reason we cannot combine the two at some point in the
          future. If we do that I propose we change the name of
          step-sizing.
  fantasai: We could also rename it later.
  Florian: We might want to have a rhythm spec in the future.

  fantasai: As we're talking about flying cars and the future, I'd
            like to see not just snapping inlines but snapping to an
            explicit layout grid, which people have been asking
            about.
  fantasai: Had that in mind as eventually direction when working on
            the draft for line grid: support snapping to any line in
            either line grid or explicit grid.
  fantasai: Becomes a much more general purpose layout tool.
  Florian: We'll eventually need to integrate with multi-col.

  myles: Sounds like I'm being overruled, two documents solving
         similar problems.
  astearns: Wouldn't call it being overruled. I think this is a set
            of concerns we need to keep in mind. You are welcome to
            object to publishing a first working draft.
  myles: Won't object.
  SteveZ: Can we at least file an issue and put that into the first
          public working draft?
  Florian: Yes!

  astearns: Any other questions/comments?
  SteveZ: I really don't like the name step sizing.
  Florian: Suggests how, not why.
  astearns: Steve, are you going to object?
  SteveZ: No, name is confusing but won't object.
  dauwhe: Name is bad, also conflicts with snap.
  fantasai: We did rename that to scroll-snap.
  astearns: Lacking proposed alternate, will close subject.

  RESOLVED: First published working draft for step sizing.
  RESOLVED: koji, fantasai, and dauwhe as co-editors.

  <br size=15m>

  Scribe: fantasai

  <fantasai> text issues that need help:
  <fantasai> https://www.w3.org/mid/20150211003752.GA14268@pescadero.dbaron.org

  SteveZ: Offline discussion to change name of css-step-sizing to
          css-rhythm as CSS Rhythmic Sizing
  SteveZ: Reason that designers are more likely to recognize that.
  astearns: Actual reason is to see Koji dancing.
  astearns: We're only changing the name of the draft.
  astearns: Not making a property called rhythm, because nobody
            knows how to spell it.
  melanierichards: As a designer, I like the idea of using rhythm to
                   describe this, but line grid also seems like it
                   would fit under here.
  SteveZ: That was intended, so that in future we could fit line
          grid under here.
  SteveZ: Basically, I think there was sympathy to what myles was
          saying in the long term, just not in the short term.

  esprehn: What are you going to call the inline-axis version?
  dauwhe: Harmony.
  Florian: It's not a certainty that we'll merge the specs in, but
           we want to leave the door open.

  RESOLVED: css-rhythm

  Florian: Slightly related question: should lh and rlh be affected
           by line-height-step?
  fantasai, astearns: I think it should be.
  astearns: We could just open an issue on the spec.
  Florian: ok, I'll do that.
  https://github.com/w3c/csswg-drafts/issues/937<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:59:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 14 February 2017 01:59:26 UTC