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

[CSSWG] San Francisco F2F 2016-05-11 Part II: CSS Text 3 & 4, Logical properties and margins in vertical text [css-text] [css-logical-props] [css-writing-modes]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 7 Jun 2016 21:25:15 +0300
Message-ID: <CADhPm3tfRrvULf_-SKVLFxvtybC505RRrVY_ip0GVUui8K=2xw@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.

CSS Text 3 & 4

  - RESOLVED: Not breaking on nbsp; for the break-all value.
  - RESOLVED: break-all should do the same as normal for preserved
  - RESOLVED: break-spaces goes into overflow-wrap instead of
  - RESOLVED: Keep current hanging-punctuation values in Level 3.
  - RESOLVED: Add note that more non-CJK-relevant keywords will be
              added to Level 4.

Logical properties and margins in vertical text

  - RESOLVED: margin/border/padding logical properties use the
              element's own writing-mode, not their parent's


Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics

Scribe: iank

CSS Text 3 & 4


  <smfr> https://drafts.csswg.org/css-text-3/#word-break-property
  Florian: If you have either a nbsp or whitespace-prewrap so you
           have a bunch of spaces go off the line.
  Florian: The spec just got updated to do nothing within the spaces.
  Florian: Firefox will break all types of spaces (preserved spaces
           and nbpsps).
  Florian: Safari will break nbsp;
  Florian: Safari doesn't preserve spaces at the end of lines.
  Florian: Chrome doesn't preserve, and doesn't break nbsp;
  TabAtkins: Firefox behaviors seems to be the best here.
  fantasai: I think we put the glue rules to be at a higher priority;
            nbsp should never break.

  Florian: break-all is poorly named.
  Florian: I don't strongly care either way, just want consensus.
  fantasai: break-all doesn't mean break everything. It also
            maintains a bunch of line-breaking rules.
  fantasai: word-break controls what is a word for line breaking
  fantasai: These are all used in normal text. In Japanese you'll
            have Latin text inside, which follows Japanese line
            breaking rules.
  fantasai: break-all makes Latin break like CJK text.
  fantasai: spacing controls and other breaking controls should
            be at a higher level.
  fantasai: These are formatting characters, which is why they
            should be at a higher level.
  TabAtkins: So this is really poorly named.
  <TabAtkins> So having your explanation, that one makes CJK act
              like Latin, and the other makes Latin act like CJK,
              really prominent in the spec would be great.

  Florian: For extra context the reason I run into this, for preserved
           spaces, we'll have an additional keyword called break-spaces.
  Florian: Didn't know if this was in addition or instead.
  fantasai: We made a decision on this.
  <fantasai> word-break is about what's considered a "word"
             for line-breaking, which is what this switch is about
  <Florian> I think break-spaces works as a value of overflow-wrap
            as well, since preserved spaces only need to be wrapped
            if they already overflow

  PROPOSAL: Not breaking on nbsp; for the break-all value
  Florian: What about preserve spaces?
  Florian: Firefox wraps, IE/Edge don't.
  Florian: Which way do we go?
  TabAtkins: I think nbsp; is different.
  tantek: Doesn't sound author intuitive?
  tantek: Treating them differently seems bad.
  TabAtkins: This is specifically about the word breaking behavior
             of CJK and making Latin act like that.
  Florian: Neither of them break on nbsp;
  RESOLVED: Not breaking on nbsp; for the break-all value.

  fantasai: Don't have an opinion for preserved spaces.
  TabAtkins: What is the ideal behavior for pure CJK
  TabAtkins and preserve spaces overflowing..
  Florian: I think this is (a) subjective and (b) not different to
  Florian: Don't care about default, just as long you can switch.
  Florian: Preserved spaces that overflow the end of line don't get
           wrapped, they overflow as inked overflow.
  Florian: ink-overflow unless the element is editable, then they
           should be scrollable overflow.
  TabAtkins: How much do we care about editable things.
  Florian: That's probably the behavior that people want.
  Florian: proposal: break-all should do the same as normal for
           preserved spaces.

  RESOLVED: break-all should do the same as normal for preserved

  Florian: Where does the break-spaces go?
  TabAtkins: Goes in overflow-wrap
  Florian: I'm cool with that.
  Rossen: <thinking looks>
  Rossen: Why overflow-wrap
  fantasai: I think this switch should be in word-break.
  TabAtkins: Let's move this to hallway discussion.
  Florian: Resolved to add break-word, does funky stuff.
  fantasai: A lot of these switches should exist just more clearly

  <br = 15mins>

  Scribe: Florian

  <Florian> Proposed resolution: break-spaces goes into overflow-wrap
            instead of word-break

  RESOLVED: break-spaces goes into overflow-wrap instead of

Hanging Punctuation
  Scribe: TabAtkins

  <dauwhe> https://drafts.csswg.org/css-text-3/#propdef-hanging-punctuation
  astearns: There was ML discussion about adding a "start" value so
            that the current hanging-punctuation property would be
            usable for roman text as well as CJK.
  fantasai: For level 4, right?
  fantasai: Level 3 was supposed to have been finished 2 years ago.
  smfr: Yes, we prefer that.
  astearns: Sure.

  astearns: So: add "start" as a value?
  fantasai: I think that was my goal, to have start and end be this
            parallel thing.
  fantasai: Open question is how it's defined.
  fantasai: Currently works for CJK - you have a grid, you want an
            optical alignment effect while preserving it.
  fantasai: Roman text doesn't do that, it's just optical alignment.
  astearns: It *can* be.
  fantasai: I want the visual effect of a strong line, that's what
            this is about.
  fantasai: There are various techniques; strictly hanging, half
            hanging, etc.
  fantasai: But we don't want that behavior to leak into CJK.
  fantasai: We need some syntactic flag to separate this out.
  fantasai: So we have a "roman" start and end.
  Florian: CJK doesn't matter because it *doesn't* hang on the
           start side.
  astearns: But roman start only makes sense if there's a roman end,
            which works slightly differently than CJK end.
  astearns: So question is if it needs to be a separate value, or
            if we can do some special accommodation.
  fantasai: I don't think we can - just because there's some Latin
            text at the end of a line, doesn't mean they want the
            roman-style hanging behavior.
  fantasai: Don't have opinion on how we do it - just an end-roman,
            or a pair of start-roman/end-roman; it just needs to be

  astearns: It sounded on the ML like Safari wanted roman hanging
            punctuation soon.
  smfr: We have a basic implementation already.
  fantasai: What do you do?
  smfr: For the punctuation chars listed in the spec, we hang them
        outside the line box. They're layout-overflow I believe
  smfr: Our main issue were posted by Jon Lee.
  <smfr> https://lists.w3.org/Archives/Public/www-style/2016Apr/0004.html.
  <fantasai> This was my reply:
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Apr/0105.html

  smfr: He has a proposal to amend hanging-punctuation to handle
        roman text.
  smfr: He intends to respond to the last mail in the thread, but
        hasn't sent it yet.
  astearns: My initial thoughts on his classifications is that this
            might be something that shouldn't be specifically in CSS
            as a property, but as a recommendation outside to handle
            different char classes differently.
  astearns: Unsure if it makes sense to specify "punctuation is this,
            dashes are this, other punctuation are this" - instead
            just say "here are the classes, come up with something
            that looks good".
  Florian: fantasai's point stands - author needs to indicate what
           style of hanging they want. Don't want to get Latin
           hanging just because the line ends in Latin.
  astearns: Right. I hadn't considered the mixed-language scenario
            at the time.
  Florian: CJK is commonly mixed with Latin, without wanting
           Latin-style typography.
  smfr: We definitely want a mode that looks reasonable with lots
        of scripts automatically.
  fantasai: Agree.

  fantasai: The ML proposal seems complicated. I'd rather have
            "please do some sort of hanging punctuation optical
            alignment thing".
  smfr: And for CJK what would you do?
  fantasai: The auto would just do whatever you'd do for Latin.
            CJK rules would still work.
  fantasai: Some Latin typographical engines, you can either
            hang a char or not, nothing in between.
  fantasai: So they can decide what chars look good with that.
  fantasai: Others might have special kerning for end-of-line/etc.
  fantasai: Or optical analysis of glyph shapes, whatever.
  fantasai: I haven't heard anyone arguing they want an engine
            to have both of these and switch between them; I've
            only heard people wanting them to look good.
  fantasai: I'd rather we had one switch which was "do some kind
            of edge alignment, whatever" rather than having the
            author have to specify everything, we have to deal
            with keywords for different scripts, etc.
  fantasai: There's a ton of scripts, we don't want that complexity.
  astearns: But they do need a switch for CJK vs Latin.
  fantasai: Yes.
  astearns: So what happens with the Latin-specific values later...?
  fantasai: Why use something different for Latin vs Cyrillic vs
            Thai? CJK is different because it has a grid system
            it aligns to. Everything else is basically similar.
  astearns: I think we don't know the conventions. We know CJK,
            we know some Roman conventions. There may be, for
            example, Indic hanging conventions that are different.
  fantasai: If they require an independent switch, we should deal
            with that. But so far as I know right now, everyone's
            the same.
  astearns: So if we add roman-specific values, it sounds like
            the extension point is more script-specific ones.
  Florian: I think she wants the new value to not be roman-specific;
           it'll apply to everything.
  Florian: And if another language comes up that doesn't use the
           CJK grid *or* the Latin-ish optical alignment, then we
           can add more values.
  Florian: But as long as we don't get into details, we don't need
           to be roman-specific.

  smfr: I think we'd like a switch that is like auto, make it look
        good as much as we can.
  Florian: How about calling it auto?
  myles: There are many different news publications on the web
         that have their own style guides.
  myles: "Just make it good" won't suffice.
  fantasai: What are the types of good we have to switch between?
  dauwhe: You mentioned hyphens - I probably don't want those to
          hang, but I do want quotes to hang, periods and commas.
  fantasai: What categories?
  dauwhe: I don't think they're categories...
  smfr: "I want W's to hang."
  myles: Or some chars, like em-dash, half-hang
  myles: I agree that a list of chars + percentages isn't a great
         idea. We just don't want a boolean, either.
  myles: In the middle is a series of keywords, the approach Jon
         has taken.
  fantasai: But the keywords are script-specific. As far as I can
            tell, your prefs aren't script-specific. They're
            varying *within* a writing system.
  fantasai: So we need some idea of what those variances are.

  astearns: So we have a plan to add non-CJK values for
            hanging-punctuation in Text 4.
  astearns: Do we have a resolution to do that?
  dauwhe: Leaving level 3 as it is.
  astearns: Yes. And leaving open the question of *how* to do
            the switches.
  Florian: I think we have consensus on adding *something*,
           just not what.
  astearns: I was thinking we understand prefixes exist, we just
            have no idea how to do them.

  <dauwhe> http://stevehickeydesign.com/blog/2012/12/04/hanging-punctuation-with-css/

  smfr: Another idea is to defer hanging-punctuation from level 3.
  smfr: Do we have enough implementations to keep it in level 3?
  dauwhe: I'm confused - if I read level 3 right now, there's no
          indication this is a CJK feature.
  TabAtkins: Like word-break!
  astearns: So *do* we have impls?
  Florian: AH and 超縦書 (BPS's viewer)
  astearns: And WK has started.
  dauwhe: Prince doesn't have it, though we've been bothering them.
  astearns: Doesn't sound like a *bad* plan to punt it to level 4,
            with an issue for roman, and a note that the current
            value is for CJK.
  fantasai: This was added for the Japanese community, and we have
            some implementations. Don't think the current set of
            values are problematic.

  smfr: My concern is that an author that uses hanging-punctuation
        will expect it to work on Latin text.
  TabAtkins: So punting it is just a signal to authors reading the
             spec? That would be served similarly by a prominent note
             in level 3?
  smfr: Yeah, maybe. Just concerned about locking on current values.
  astearns: I'd prefer to hit CR sooner rather later.
  TabAtkins: Are the current values bad, then?
  Florian: When we add the new values, we might rename the old ones.
  TabAtkins: Then it's not stable, punt it.
  fantasai: I don't want to punt it.
  TabAtkins: Are you sure the current values don't change?
  fantasai: No.
  TabAtkins: Then it's not stable, punt it. Or lock down the current
             values and resolve to work around naming issues in the
  fantasai: I want to keep it in level 3 and keep working on the new

  TabAtkins: Should Safari ship what they have?
  fantasai: What do they have?
  smfr: Certainly first, last, ...
  smfr: We somehow made them work in Latin languages.
  smfr: I think we just made more punctuation hangable.
  fantasai: I think just adding more chars is fine.
  astearns: I thought the problem is there wasn't a start value.
  astearns: You can hang at the start of first line, end of other
            lines, but not at the start of non-first lines.
  TabAtkins: We're consistent on letting Latin stuff go in level 4.
             Question is if the CJK stuff currently in 3 is stable
             or not. Can Safari ship with what's in the spec today,
             or something that's trivially fixable?
  fantasai: Dunno.

  astearns: I propose we put a note in the draft now saying that the
            current values are designed for CJK, and that level 4 is
            going to do Latin more significantly.
  fantasai: First definitely works on Latin, the end ones only work
            on CJK.
  dauwhe: Why that restriction? Looks Latin-ish.
  astearns: force/allow are accommodations for the grid, which makes
            them CJK.
  astearns: You wouldn't use force-end, just "end" for Latin.
  TabAtkins: Do they do different things in Latin text?
  dauwhe: I think you could. Maybe something weird if a period is
          *right* at the margin...

  astearns: If you have force-end and a short line, will it pull
            things out?
  fantasai: Yes. force-end doesn't count the punctuation for the
            purpose of justifying. It is *always* pushed out.
  fantasai: If you don't justify, nothing happens. But right-align
            also makes it hang.
  fantasai: For Latin there was some additional considerations about
            hanging hyphens and dashes, maybe brackets.
  dauwhe: Quotes are biggest one.
  fantasai: They're defined for CJK, but also work for Latin for a
            subset. Future Latin-y things (like brackets) will be
            additional keywords. That was my plan.
  fantasai: So current values are fine. New behaviors, we'll add
            new keywords.
  dauwhe: Current keywords look fine, just insufficient.
  <liam> [ some systems in the past have treated hung punctuation as
           a sort of kerning that could be overridden by particular
           fonts ]
  [??? something about periods at the beginning of the line]
  fantasai: So the keywords that would have start and end variants
            don't exist yet.
  fantasai: [current *-end keywords are for characters that don't
             appear at the beginning of lines, e.g. periods and

  RESOLVED: Keep current hanging-punctuation values in Level 3.
  RESOLVED: Add note that more non-CJK-specific keywords will be
            added to Level 4.

  ACTION dauwhe to work with fantasai to figure out what non-cjk
                keywords need to exist for hanging-punctuation
  <trackbot> Created ACTION-776

Logical properties and margins in vertical text

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016May/0098.html
  zcorpan: When you mix vertical and horizontal, for margin-block-
  fantasai: The spec hasn't been synced with implementations, it was
            resolved one way, now you're saying it should go another
  zcorpan: So impls use the element's own writing-mode to determine
           logical margin mappings; spec says to use parent's
  zcorpan: Since browsers use logical props in the UA style sheet,
           there may be content that depends on current behavior.
  zcorpan: So I suggest we align the spec with impls, and if we want
           to solve the use-case of using the parent's writing-mode,
           we use new properties.

  astearns: Are you aware of use-cases?
  zcorpan: Yes for both.
  zcorpan: Using parent is if you want to position children with
           margins and don't care about the WM of the children.
  fantasai: There's been arguments both ways, use-cases for both.

  fantasai: But insofar as m/b/p is concerned, they're used for
            lists, to control the indentation in the UA style sheets.
  fantasai: We'll have compat issues with just RTL, not even writing-
  fantasai: So we need margins to calculate according to impls,
            based on writing-mode of element.
  zcorpan: I think right now <ul> and <ol> use padding on the
           container to indent children, but <dl> uses margin on the
  TabAtkins: Wut???
  Florian: Can we separate direction and writing-mode?
  fantasai: No, you'd have only a partial mapping then, be very weird.
  TabAtkins: Ah, dt/dd use indentation to separate the elements.

  zcorpan: So can we resolve on the first proposal? To make spec
           match reality?
  Rossen: Every meeting we decide this back and forth. :/
  fantasai: But now we have a content dependency to stick ourselves

  RESOLVED: m/b/p logical properties use the element's writing-mode,
            not the element's parent's writing-mode.

  zcorpan: I think if we want to solve the use-case of getting
           parent's writing-mode, we can use a new property.
  Florian: Is this parent, or containing block?
  fantasai: Parent. CB is better, but this has to be done at cascade
            time (determining CB is complex at that point) and CB
            can be arbitrarily high up the tree.
  Florian: What's use-case for abspos basing on parent/CB?
  fantasai: If abspos is like a display mode, you're positioning in
            some container, and there you care about the container
  fantasai: You can get around this today by using a wrapper element
            with the parent's writing-mode
  fantasai: Think we'll end up sticking with that, instead of new
            properties. It's simpler.
  fantasai: Or maybe have some notion of an "internal" writing mode.

<br dur=1h>
Received on Tuesday, 7 June 2016 18:26:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:03 UTC