[CSSWG] Minutes Seattle F2F 2017-01-11 Part II: Text Breakout - Hyphenation, Text Decoration

  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


  - There was a general sense that the least harmful behavior is to
      not hyphenate when there's no language declared.
  - zcorpan and myles will work together to see if it's possible for
      browsers to standardize the behavior based on how much is
      already in the wild.

Text Decoration

  - RESOLVED: defer issue 4
  - RESOLVED: defer issue 3 to next level
  - Issue 2 (https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-2)
      needs more investigation before a resolution can be reached.
      If it requires a change in initial value the change will have
      to occur in this level, but a new feature could be deferred.
  - RESOLVED: We reject issue 14.
  - RESOLVED: Reject issue 5 and follow up.
  - RESOLVED: undefined on issue #10.
  - RESOLVED: Go with Ken Lunde's suggestion for issue 13
  - RESOLVED: Accept fixes to handle fixes in default UA stylesheet.
              (Issue 11:
              Issue 19:
  - RESOLVED: text-emphasis-position: [ over | under ] && [ right |
              left ]?
              (Issue 17:
  - fantasai will reach out to i18n to see if there's a use case for
      the left value in text-emphasis-position.
  - RESOLVED: Update spec to handle sideways-lr/sideways-rl as
              rotated horizontal text
              (Issue 20:
  - RESOLVED: Omitted text-underline-position value defaults to auto.
              (Issue 18:
  - RESOLVED: Split text-decoration-skip into longhands.
             (Issue 1:
             Issue 22:
  - RESOLVED: In level 3, have text-decoration-skip-ink. Move all
              other parts of skipping to level 4.


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

Scribe: dauwhe

Text Track


  <astearns> hyphenation: https://github.com/w3c/csswg-drafts/issues/869
  <astearns> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4761
  <astearns> testcase^
  zcorpan: It's non-interop whether hyphenation happens if there's
           no language declared.
  Florian: For hyphenation to work we need language tagging.
  Florian: So if it works, this encourages authors to not pay
  Florian: So if you don't declare the language, it shouldn't work.
  zcorpan: There is resistance in the issue.
  myles: This property has been around for years
  myles: so they haven't been paying attention for years.
  myles: Our browsers hyphenate, users would think there's a
         regression if we changed this.
  koji: We already rely on system language for font selection, etc.
  koji: What's the criteria for when we do and don't want system
        language-related behavior.
  astearns: I think it's different than font selection.
  astearns: We can fall back to system fonts.
  astearns: I'm assuming there's lots of non-tagged content.
  zcorpan: This only affects hyphens: auto pages
  astearns: If we fall back to system...
  astearns: So we could get different behavior for same
            English-language page on different computers.
  fantasai: If it's dependent on your personal system, then that's
            bad for authors.

  Florian: Legacy is a problem.
  Florian: Having cjk look Japanese on Japanese computers and
           Chinese on Chinese computers was a legacy issue.
  Florian: The fact that hyphens: auto hyphenates is webkit only.
  frenemy: Microsoft does it too.
  fantasai: It won't make or break a web page.
  fantasai: It's not interoperable now.
  fantasai: It won't change how your layout works.
  fantasai: It's a slight regression of typesetting quality, but
            won't break pages
  fantasai: unless they're already broken.
  myles: Hyphenation will be off or weird if you have hyphens: auto
         in lang x and reading in lang y
  Bert: I often read pages in four languages, can't use my system
  astearns: Tagged in lang x, reading on system for lang y, wouldn't
            you still use lang x dictionary?
  myles: Only if it's not tagged.
  myles: Content says hyphens auto
  myles: written in lang x, not tagged, system in language y.

  SteveZ: We're lacking relevant information like frequency of these
  SteveZ: We're talking about the horses mouth without counting the
  SteveZ: If you're American, and you speak English, hyphenation
          probably works.
  SteveZ: If you have German system, read lots of English or Dutch
          content, then you get lost.
  SteveZ: It depends where you're looking.
  SteveZ: Better to turn off bad hyphenation.
  fantasai: Very common for people in Europe to read English
  fantasai: They'll get incorrect behavior
  Florian: Everywhere
  fantasai: Most of Europe has the same writing system as English ->

  fantasai: Our job is to promote interop.
  fantasai: There's a split in UA behaviors
  fantasai: it is not well established that you get hyphenation.
  fantasai: If we take interop seriously
  fantasai: then we need to not make things system-dependent.
  fantasai: There is legacy stuff, but this is not that kind of
  fantasai: It doesn't break pages.
  fantasai: Author can just tag the language.
  <Florian> +1
  <dbaron> +1

  <zcorpan> https://www.chromestatus.com/metrics/css/popularity#hyphens
            use counter for hyphens 1.8725% . in httparchive
            hyphens:auto appears in 27,173 resources from 494,891
  zcorpan: There's use counter for hyphens property.
  zcorpan: 27k resources out of half a million.
  zcorpan: for lang attribute it's 2.6%.
  zcorpan: 2.3% on root element.
  <zcorpan> https://www.chromestatus.com/metrics/feature/popularity#LangAttribute
  Florian: Are there stats for usage together?
  zcorpan: no
  <tantek> I'm curious what happens if we drop the <html lang="en">
           from the count
  <tantek> in my experience those are just copy/pasta from templates/
  astearns: Given these numbers, would webkit be willing to change?
  myles: This isn't enough information.
  myles: There's four pieces; it's the intersection of the four

  Florian: We have a limited time to deal with this.
  Florian: Because chrome didn't have hyphens, and has large market
  Florian: so few people are depending on it.
  fantasai: Very limited.
  fantasai: Now is good time to change.
  astearns: I agree we want interop
  astearns: Could chrome and FF match webkit?
  zcorpan: Chrome already matches webkit
  zcorpan: Firefox is different.

  myles: Having things be system language dependent is not contrary
         to interop.
  Florian: In font fallback there's two things-
  Florian: helvetica vs times is ok
  Florian: but Japanese can't look like Chinese.
  Florian: We should always tag languages
  Florian: but they don't
  Florian: so we have to take from system for Chinese vs Japanese.
  Florian: But with this case we don't have to take from system
  Florian: most English readers are not native speakers.
  koji: We do use sys lang for font selection.
  Florian: Spell check is less crazy.
  Florian: You're checking what the user is typing, and that's
           likely in their sys language.
  frenemy: On windows you have control
  frenemy: system settings are user-modifiable.

  astearns: We're drifting
  astearns: I want interop.
  zcorpan: I can file an issue on gecko
  zcorpan: and I can try to get a figure on hyphenation: auto with
           no declared lang.
  astearns: zcorpan and myles can work on standard behavior
  astearns: Is this a regression or whether this is something and
            you can stick you what you have.

  SteveZ: If I don't hyphenate that's safe from understandability
  SteveZ: If I do hyphenate in the wrong language, I can destroy the
          understandability of the text.
  SteveZ: Doing it when it's wrong is worse than not doing it.
  SteveZ: The other point is
  SteveZ: in this case, we shouldn't take the option of the easy way
  SteveZ: meaning FF doing what others do.
  SteveZ: We should try to make the change so that lang is required.
  SteveZ: It seems people want to do the right thing if possible.
  <fantasai> +1 to what szilles said
  dauwhe: hear hear
  astearns: The approach of requiring lang for hyphenation is better
            for readers.
  astearns: We need to see if browsers can change.

  koji: Same spelling of word can be different?
  astearns: There's a bob dylan record-
  astearns: the tambourine man-
  astearns: on 1st printing, it was hyphenated as tambor-urine
  astearns: which changes meaning.
  Florian: It's wrong hyphenation but not caused by wrong language
  astearns: That could be.
  astearns: We're not going to make more progress today.
  astearns: Need action for which way forward.

  Florian: Big difference between font selection thing is that font
           selection is local problem, mostly for non-international
  Florian: English is everywhere.
  Florian: hyphenation happens to international languages.
  Florian: there are more and more things in text that require
           language tagging.
  Florian: we should push on authors.
  koji: 60% of pages are lang tagged.
  myles: I'm not worried about pages in the future.
  myles I'm worried about pages that exist.
  Florian: We're not encouraging people to do the right thing

  <tantek> I'm really confused about the claims about language
  <tantek> specifically the <html lang="en"> problem, and if we can
           make things easier for authors we should! (instead of
           trying to "force" them to do something like language tag
  <Florian> tantek: which claim is confusing you? One I made?
  <tantek> Florian yes, more the assumptions behind your claim.
  <tantek> Florian we can discuss offline, usability vs making
           authors do more work.

Text Decoration

  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013
  fantasai: disposition of comments^
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Dec/0121.html
  fantasai: There are lots of issues that came up during CR.
  fantasai: Starting at bottom of list 'cause they're easier.

Issue 4: Allow arbitrary decorations

  fantasai: First set are things that should be deferred.
  fantasai: 1. allow arbitrary declarations, using @-rules
  fantasai: This is issue 4.
  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-4
  Florian: This was reinventing SVG
  Florian: Yes.
  myles: Can I anti-object?

  RESOLVED: defer issue 4

Issue 3: Allow specifying position and thickness of underlines

  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-3
  fantasai: Issue 3
  fantasai: We should do this, but since it's a new feature it
            should go in level 4
  astearns: Agree to defer?

  RESOLVED: defer issue 3 to next level

Issue 2: text-decoration-color vs SVG fills

  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-2
  Florian: Issue 2.
  Florian: Interaction between text-decoration-color and svg fills.
  Florian: We should work on this issue in the fills spec.
  Florian: Might require changes to text-decor but we're not sure.
  Florian: Isn't this a case of adding auto to solve the issue.
  fantasai: Possibly.

  astearns: Link in issue goes to a disambiguation page.
  fantasai: I complied this offline. I will fix it.

  Florian: Having text-decoration-color: auto is a possible solution.
  Florian: Why don't resolve?
  fantasai: Let's defer until paint spec is more complete, which
            deals with fills and strokes.
  astearns: Paint spec talks about script.
  astearns: This says what's in svg changes things.
  fantasai: I haven't thought thru how we'll make this all work.
  fantasai: Let's figure out the paint spec, then figure out if we
            need to change.
  tantek: I agree with fantasai.
  fantasai: SVG doesn't do anything for other things.

  astearns: I'm ok to defer.
  Florian: OK to keep issue open
  Florian: but I don't want to close.
  fantasai: We're not pushing for PR now
  tantek: Could it be a new feature?
  fantasai: It might need to be different initial value.
  astearns: More about interaction.
  tantek: We wouldn't add a new auto value?
  fantasai: Current value is current color.

  astearns: Leave issue open?
  tantek: Unless you want to keep it open for a solution without
          adding a feature, you should consider deferring.
  fantasai: If it's just changing an initial value, then that's a
            small-enough change.
  tantek: No one supports this today, so it's a new feature.
  fantasai: We can add new feature in CR if we need to.
  fantasai: We did that for flex.
  astearns: We need to determine whether we need to fix this now, or
            whether we can defer.
  astearns: If it's adding a new value we can defer.
  astearns: If we need to change initial value, we can't defer.
  tantek: You don't want implementations to shift with new default
  fantasai: Leave open for now.
  astearns: If we keep open, link is to email.
  astearns: We need github issue
  astearns: and add to issue whether we need to change initial value.
  Florian: This isn't shipping but it's in svg.
  astearns: I can see the default value ignore the svg.
  fantasai: The whole thing more investigation.

Issue 14: 'text-emphasis' shorthand should not allow only <color>

  fantasai: Two issues are rejected
  fantasai: #14
  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-14
  fantasai: A request to forbid text emphasis from having only a
  fantasai: We already allow this for border, etc.
  astearns: Have they responded to rejection?
  fantasai: I think he's ok with it but haven't found email.

  tantek: I'm missing why we should do this.
  tantek: Border color is right answer, we already have this pattern.

  RESOLVED: We reject issue 14 but will follow up.

  fantasai: tab followed up, there was no response for a year
  <tantek> tab's message URL?
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Nov/0355.html
  <tantek> (was not linked from Xidorn's message)
  <fantasai> because our archive software is terrible
  <tantek> agreed resolve per Tab's response / explanation

Issue 5: text-shadow should apply to inline images

  fantasai: Should text shadow apply to inline images.
  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-5
  fantasai: We've had it so long it would break things (issue 5).
  astearns: Any objections to the rejection?

  RESOLVED: Reject issue 5 and follow up.

Issue 10: Clarify whether emphasis marks are upright or sideways for

  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-10
  fantasai: Next set of issues:
  fantasai: Issue #10.
  fantasai: Text emphasis marks go on each char, older than
            underline, used in cjk
  fantasai: In vertical text they go on R side.
  fantasai: We added new mode for vertical, sideways-RL and
  fantasai: My proposal was to make sideways-* behave as rotated
            horizontal text wrt emphasis marks.
  fantasai: It's for graphical effects in English, like book titles
            or headings.
  fantasai: It also rotates cjk chars.
  fantasai: It's not a vertical writing mode.
  fantasai: Question was what do we do for emphasis marks??
  fantasai: If we turn all cjk sideways, we should also turn
  fantasai: So koji thinks we should make it undefined, since this
            is very rare
  fantasai: due to implementation issues--it's easier to do as for
  koji: And it's really edge cases.

  Florian: I can buy both those arguments
  Florian: this is not vertical-rl
  Florian: rather than undefined, how about should?
  koji: I agree
  koji: but most common case of sideways-rl is for non-cjk.
  koji: When ckj user tries to typeset English in a CJK document,
        they might want upright.

  astearns: (Draws) ??
  fantasai: They can be comma-shaped things, so the question is does
            the shape rotate.
  Florian: You might want cjk emphasis to be upright.
  Florian: I'm ok with undefined
  SteveZ: Would Japanese really like the variable distance between
          the emphasis marks?
  SteveZ: Is anyone going to use this kind of emphasis on rotated
  Florian: Then we should do should instead of undefined
  Florian: Japanese emphasis on Latin, I could argue for upright.
  SteveZ: I would expect emphasis to be rotated in the example on
          the whiteboard.
  koji: We're unlikely to do this.
  SteveZ: I'd expect to see that in a user interface, in a vertical
  fantasai: I'd expect it to be upright.
  astearns: this is VERY edge casey
  astearns: I'm usually not OK with undefined
  astearns: but I don't care.
  astearns: I'm hearing several people OK with undefined.

  RESOLVED: undefined on issue #10

  SteveZ: Which is a hint to don't do this.
  astearns: Or if someone provides good user feedback.

Issue 13: Should emphasis marks use 'font-variant: ruby'?

  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-13
  fantasai: Next issue is 13.
  fantasai: Should emphasis marks use ruby opentype feature?
  fantasai: Ken said they should.

  fantasai: Does anyone have opinion?
  Florian: I agree with the argument.
  fantasai: It's an OT feature, so if it's not there nothing happens.
  fantasai: When you draw emphasis marks.
  fantasai: You take this unicode code point, reduce by 50%, and set
            as ruby.
  fantasai: UA could use a dedicated font.
  fantasai: If you are using a real font, is that you enable OT ruby
  fantasai: it will be shrunk down, having extra bulk will work.

  myles: Should be like small caps, if anything in run doesn't
         support then you should synthesize.
  fantasai: You don't synthesize.
  myles: I meant disabled.
  fantasai: You don't disable
  fantasai: you tell font to turn on feature, if it's not there you
            do nothing.
  astearns: If run of ruby has fallback.
  fantasai: It's not ruby, it's emphasis marks.
  myles: Oh. I'm on board.
  fantasai: You just turn it on. If it doesn't do anything, it
            doesn't do anything.

  RESOLVED: Go with ken lunde's suggestion

Issues 11 & 19: Improvements to default UA stylesheet suggestions

  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-11
  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-19
  fantasai: Next issues on underline position.
  fantasai: Some were fixes to suggested stylesheet for nesting of
  fantasai: So if you put Japanese inside Chinese you'd get wrong
  fantasai: So we fixed that so nesting things would work.
  fantasai: That's issue 11.
  fantasai: 19 is same thing for different rule in stylesheet.
  astearns: Any opinions?
  astearns: Have we gotten i18n review yet?
  fantasai: No, I'll ping r12a

  RESOLVED: Accept fixes to handle fixes in default UA stylesheet.

 Issue 17: 'text-emphasis-position' requires too many arguments

  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-17
  fantasai: Issue 17, syntactic.
  fantasai: Takes two keywords, one for horizontal and one for
  fantasai: Nakamura Momdo says too wordy.
  fantasai: We just want to change in horizontal.
  fantasai: Can you make it easier to use one keyword.
  fantasai: The languages that use this feature usually have same
            opinion on which side.
  fantasai: If you want to change you should mention horizontal.
  fantasai: Suggestion is to make vertical component of
            text-emphasis-position to be optional.
  fantasai: There's an email to explain:
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Dec/0118.html

  SteveZ: If you set one it won't change the other.
  fantasai: Based on assumption that C and J prefer emphasis on the
  fantasai: Which can be checked by i18n.

  koji: Why do we have left?
  fantasai: I don't know.
  SteveZ: If you double mark, you can get emphasis on both sides.
  Florian: Like nesting emphasis.
  SteveZ: That's more likely.
  steveZ: I've seen examples with emphasis on both sides.
  fantasai: This is inherited property; never has both.
  Florian: So we can't do that.
  Florian: So we don't need left.
  Florian: Maybe right and both and not right and left.
  SteveZ: Can we ask if there's a case for left during i18n review?
  ACTION: fantasai to ask about case for left in i18n review
  <trackbot> Created ACTION-810

  astearns: Any objections to simplifying argument for

  RESOLVED: text-emphasis-position: [ over | under ] && [ right |
            left ]?

  <skk> I think the position of emphasis should be explored. I saw
        some cases that only left emphasis. If I misunderstood,
  <astearns> skk - that's the action on Fantasai - to look into only
             left or both in vertical text
  <skk> astearns, thanks for letting me know.

Issue 20: Update spec to handle sideways-lr/sideways-rl

  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-20
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Dec/0119.html
  fantasai: Issue 20, adding sideways-rl and sideways-lr
  fantasai: Introduced typographic modes, same as rotated horizontal
  fantasai: It will follow the horizontal settings for the text.
  fantasai: Any comments?

  RESOLVED: Update.

Issue 18: 'text-underline-position' should default to 'auto' for CJK,
  to avoid compat issues

  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-18
  fantasai: Issue 18.
  fantasai: Suggested UA rules for cjk used "under":
  fantasai: for Japanese right and under
  fantasai: for Chinese left and under.
  fantasai: We set the underline position for horizontal text as well
  fantasai: but that changes browser behavior.
  fantasai: Changed auto to under
  fantasai: but was changing things.
  fantasai: So I changed default user stylesheet
  fantasai: to minimize changes from current behavior.
  fantasai: This is important for Latin text inside cjk but didn't
            tag Latin text
  Florian: Which is common.
  fantasai: To avoid regression.

  fantasai: 2 changes: one to default UA stylesheet, other is to
            change omitted behavior for text-underline-position.
  fantasai: Assuming no objections to changing UA stylesheet.
  fantasai: You can always be more explicit.
  astearns: Is there any benefit to have text underline position
            behave like text emphasis position?
  astearns: Where we don't allow only setting to right?
  fantasai: Text underline position allows auto or under
  fantasai: You don't ever do underlines on over side in horizontal
  fantasai: otherwise you'd use an overline.
  fantasai: So it's a bit different.
  astearns: Seems ok to have omitted value default to auto. What
            does it do now?
  fantasai: Defaults to under.

  RESOLVED: Omitted value defaults to auto.

Issue 1: Allow UA to skip ink by default/Issue 22: CJK doesn't like
  skipping ink, shouldn't by default

  fantasai: issue 1
  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-1
  <fantasai> https://github.com/w3c/csswg-drafts/issues/727
  fantasai: Allow UA to skip ink by default
  Florian: Do we need to discuss with issue 22?
  <fantasai> https://drafts.csswg.org/css-text-decor-3/issues-cr-2013#issue-22
  <fantasai> https://github.com/w3c/csswg-drafts/issues/727
  <fantasai> https://github.com/w3c/csswg-drafts/issues/707

  koji: There are a few related issues:
  koji: Our goal... blink has implemented skip ink, it's currently
        opt in.
  koji: We want it on by default.
  koji: When get more implementations better to have on by default.
  koji: In doing so...
  koji: Currently value is part of text decoration skip ink.
  koji: There are side effects.
  fantasai: When you want to turn on ink skipping
  fantasai: it resets other things you might skip, like spaces.
  fantasai: Whether you skip ink can be language dependent
  fantasai: and a different question than skipping images.
  Florian: The language dependent part is tricky.
  Florian: We've talked of cjk and Arabic.
  Florian: In cjk you don't want ink skipping often.
  Florian: It's unclear in Arabic.
  Florian: May be influenced by position of underline.
  Florian: In cjk if you do it bad you may overlap bottom of cjk
           chars, which is bad
  Florian: might interfere with accents in Arabic
  Florian: but with better positioning data it's ok.
  Florian: Maybe we need auto.
  koji: Skip ink is different from others, take ink out from skip.
  Florian: It's an overlapping issue.
  koji: If we agree ink is different, and take it out from skip
  Florian: If we take ink out, it makes the other issues less severe
           but they don't go away.
  Florian: The ink-skip property is a list of on-off toggles, which
           cascades poorly
  Florian: because it's a bunch of flags, if we want to add more.
  Florian: The explicit things that authors already written mean new
           flags are overwritten unintentionally
  Florian: and if we want different defaults in different browsers.
  Florian: We should be inspired by pattern of font variant
  Florian: and have a separate property for every one.
  Florian: So ink could have on/off/auto
  Florian: So if you change an edge one, it defaults and cascades

  astearns: If we make all of this into longhands
  astearns: people using longhands will short-circuit new values.
  Florian: Just have the resets on the shorthands, for everything
           else go to longhands.
  astearns: Is the ink property the only one that is language
  fantasai: Edge is also language dependent.
  frenemy: In our implementations, we'll store each of these
  astearns: It's harder to author, 'cause setting five different
  Florian: Most of the time you're thinking about one thing:
  <Florian> text-decoration-skip: none | auto
  <Florian> text-decoration-skip-objects: none | all
  <Florian> text-decoration-skip-spaces: none | [leading ||
            trailing] | all
  <Florian> text-decoration-skip-ink: none | all | auto
  <Florian> text-decoration-skip-edges: none | all
  <Florian> text-decoration-skip-box-decoration: none | all
  koji: More comfortable not to have shorthand
  koji: unlikely to set all of them.

  astearns: Is there use case for reset for everything?
  fantasai: You'd need text-decoration-skip: none
  fantasai: There was a way to say "don't underline me".
  Florian: None is skip nothing, not everything.
  fantasai: Maybe that was dropped along the way.
  Florian: The way to skip is to use objects and turn to inline box.
  astearns: I like the proposal for separate properties.
  astearns: Does anyone object?
  Florian: The one I put on IRC has auto for ink-skipping.
  Florian: We haven't decided whether that should have an auto
  Florian: and the leading/trailing we've resolved to add to level 4.
  astearns: Any objection to the explosion of skipping properties?
  fantasai: I'm ok on principle

  RESOLVED: Add all of the skipping properties.

  <break duration="15minutes">

text-decoration-skip shorthand

  Florian: What we agreed during the break is
  Florian: having in the shorthand having on/off flags based on
           presence of keywords is bad.
  astearns: Do we have a shorthand with longhand-on longhand off
            anywhere else in css?
  Florian: font-variant is not on/off but A/B
  Florian: we're not sure about none value in shorthand.
  Florian: Current version of expanded longhand is bad
  Florian: for level 3 have shorthand with just initial.
  fantasai: What about auto?
  Florian: We can't defer removing things.
  Florian: So shorthand just has initial reset, possibly named auto.
  fantasai: What's implementation status?
  (mostly not implemented, except for ink)

  astearns: You're proposing to take the whole feature to level 4?
  fantasai: Yes.
  fantasai: If we need that switch we can have that switch.
  fantasai: I'm saying remove all author control over ink skipping
            in level 3; leave it up to the UA explicitly.
  eae: I think there's value in giving authors control.
  Florian: I don't have strong opinion on level 3 vs 4.
  jensimmons: I don't have opinion on level.
  jensimmons: Authors want ways to control underlining; the sooner
              the better.
  jensimmons: As soon as people learn about this they're going to
              want this.
  jensimmons: They want skipping behavior.
  fantasai: Putting them together makes sense.
  myles: Web authors don't care about levels.

  fantasai: If we're redesigning the world, we should put this into
            a new level.
  fantasai: We need to figure out what we need and how to make it
            easy to use.
  fantasai: Thickness etc are in level 4 'cause they're new
  fantasai: and it will be a package.
  jensimmons: I agree it makes sense to ship as whole.

  dbaron: It feels like ink skipping the most popular thing in whole
          spec, based on 15 years of feedback.
  fantasai: There's an argument it should be on by default
  fantasai: so if we have on by default, we can push control to next

  Florian: There are i18n concerns.

  frenemy: Most of other properties I'm ok with another level, but
           want control for skipping.
  frenemy: ink skipping: yes or no should be in level 3.
  astearns: That would be a proposal to leave ink in current level,
            and move everything else + shorthand to next level.
  Florian: ok with me
  Florian: but want to move simplified shorthand to next level.
  Florian: In level 3, have text-decoration-skip-ink: yes/no/auto/,
           level 4 has longhands and other values. start with

  astearns: Is this ok, koji?
  koji: Yes.
  tantek: My concern is with sweet spot of what authors not.
  jensimmons: Skipping ink alone is good.

  RESOLVED: text-decoration-skip-ink in L3, other skipping controls
            in L4

  <fantasai> Text Decoration 4: https://drafts.csswg.org/css-text-decor-4/

Skipping ink vs. underline position

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Feb/0336.html
  fantasai: Should position of underline depend on what we're
  Florian: If you're skipping spaces, and you have a space in a
           different font, do you want to move the underline so you
           go under the big space.
  astearns: Let's have this as issue on level 4.
  fantasai: Yes.
  <tantek> yes.<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
        <td style="width: 55px; padding-top: 13px;"><a
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
target="_blank" style="color: #4453ea;">www.avast.com</a>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"

Received on Tuesday, 14 February 2017 01:20:31 UTC