W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Sydney F2F 2015-02-09 Part IV: Writing Modes, Multi-line/Block-Ellipsis

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Mar 2015 20:33:12 -0400
Message-ID: <CADhPm3uRdBJgYg97W1Q3hUpAiwBg2S_4XDC47mOwTJX+dTp55Q@mail.gmail.com>
To: www-style@w3.org
Writing Modes
-------------

  - RESOLVED: Keep sideways-left, mark as at-risk, possibly punt if
              it threatens CR-exit.
  - GregWhitworth will look at what options are valid for where
      writing-modes should propagate from - if it can be from <body>
      or if it has to come from root or if there are other
      approaches entirely.
  - RESOLVED: writing-mode: vertical-lr on the <rt> based on
              parent's 'display' & 'ruby-position'
  - RESOLVED: Drop the values if the SVGWG drops the
              values/properties, otherwise keep them.

Multi-line/Block-Ellipsis
-------------------------

  - RESOLVED: Replace region-fragment with 'fragmentation', written
              by Florian, determine where it belongs.
  - RESOLVED: Split fragmentation values of 'overflow' into a
              separate property. Further develop this in the
              overflow module.
  - RESOLVED: region-break gets folded into the new property, too.
  - RESOLVED: Florian added as editor to Overflow.

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

Writing Modes
=============
  Scribe: TabAtkins

sideways-left value
-------------------

  fantasai: Writing modes!
  fantasai: We don't have impls of the sideways-left value. Options:
  fantasai: 1) Leave it as is.
  fantasai: 2) Mark it as at-risk, and note that if someone
            implements just sideways-right, don't implement sideways.
  fantasai: 3) Punt it to level 4.
  fantasai: I think we should do #2 because it's important for
            non-CJK upright scripts.
  fantasai: Like a caption on the left side of a table, or table
            column headers that are vertical in English, you need
            this value.
  fantasai: So I don't think we should remove it.
  fantasai: But if it's the only thing blocking writing modes from
            exiting CR, it might be worth dropping it.

  TabAtkins: I say keep it in until CR-exit is imminent.
  koji: I say move it to Level 4.
  koji: Concerns about how it is designed today were raised, and I'd
        like further discussion.
  koji: So punting is appropriate.
  fantasai: Nobody has raised an issue with the design afaik.
  fantasai: People have said "I don't like this, it's confusing and
            complicated".
  koji: Rossen suggested rotating the line 180deg inline.
  fantasai: We could make it apply to blocks only if that's the
            issue.
  plinss: I don't see the harm in marking it at-risk versus punting
          it for now.
  plinss: Has anyone implemented sideways-right but not
          sideways-left?
  <koji> AH, Blink, and WebKit does.
  fantasai: Yeah, because sideways-right is needed for CJK.
  astearns: At-risk seems the right thing to do for now.
  Rossen: We can always push it to 4 later.
  plinss: Any objections?

  RESOLVED: Keep sideways-left, mark as at-risk, possibly punt if it
            threatens CR-exit.

  fantasai: Next is propagation of writing-mode and direction from
            <body>
  koji: Did we decide on 'sideways'?
  fantasai: Same deal - if you can't do sideways-left, you can't do
            sideways.
  koji: Okay.

Propagation of writing-mode and direction from <body>
-----------------------------------------------------

  fantasai: Right now in HTML we propagate from root to the ICB, and
            the proposal is to ignore the value on the root and
            propagate from the body to both the root and the ICB.
            Ignore the root's value entirely.
  Rossen: So if you have <html dir=rtl><body dir=ltr>, it's ltr?
  Rossen: Is that a good idea?
  fantasai: We need to do something like this. For background, we
            can do the "check to see if root has it specified, if
            not, check body".
  fantasai: But this is inherited - there is always a valid value.
            So you have to choose one or the other unconditionally.
  Florian: I believe direction is a web-compat issue; it's been that
           way forever. We'd prefer it inherit normally, but we
           probably can't change it.
  Florian: And writing-mode should act similarly.

  Rossen: We have logic that doesn't match that since IE6.
  Rossen: We take root if specified, and use body otherwise.
  Rossen: Same for overflow.
  Rossen: This suggestion may have compat issues in cases where both
          html and body specify a direction.
  Rossen: Before we decide how to spec this, we need to understand
          how we're all doing.
  Rossen: I hope this is something we can keep consistent for
          overflow too.

  <fantasai> testcase: data:text/html;charset=utf-8,<!DOCTYPE html>
             %0D%0A<title>..]<%2Ftitle>%0D%0A<style>%0D%0A%0D%0A
             head%2C title { display%3A block%3B }%0D%0A body
             { border%3A solid%3B width%3A 150%25%3B text-align%3A
             center%3B }%0D%0A<%2Fstyle>%0D%0A<body dir%3Drtl>
             %0D%0A..]

  zcorpan: In Blink it used to use the root element if it was
           specified on both, but it was changed to always use
           <body>, claiming compat with Gecko and IE.
  fantasai: Gecko seems confusing...
  dbaron: Gecko is inconsistent based on what is happening.
  dbaron: You can test how direction behaves on root by...
  dbaron: 1) Which side you can scroll to when there's overflow from
          the viewport.
  dbaron: 2) If the root element is relpos and has both left and
          right set, which one wins.
  dbaron: 3) If the root element has overconstrained margins, which
          gets ignored.
  dbaron: 4) If the root or body is abspos, which position gets used
          for hypothetical box calcs.
  dbaron: Probably most likely to cause breakage in scroll direction.
  <fantasai> dbaron: data:text/html;charset=utf-8,<!DOCTYPE html>
             %0D%0A<title>..*<%2Ftitle>%0D%0A<style>%0D%0A%0D%0A
             head%2C title { display%3A block%3B }%0D%0A html
             { border%3A solid silver%3B width%3A 80%25%3B margin%3A
             0%3B }%0D%0A body { border%3A solid%3B width%3A
             150%25%3B text-align%3A center%3B }%0D%0A<%2Fstyle>
             %0D%0A<body dir%3Drtl>%0D%0A..*

  [some discussion about <title> direction]

  <fantasai> Presto scrolls as LTR (follows root).
  <fantasai> Gecko aligns as LTR, but scrolls as RTL.
  <fantasai> which is not helpful at all.
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctitle%3E..*%3C%2Ftitle%3E%0A%3Cstyle%3E%0A%0A%20%20head%2C%20title%20{%20display%3A%20block%3B%20}%0A%20%20html%20{%20border%3A%20solid%20silver%3B%20width%3A%2080%25%3B%20margin%3A%200%3B%20}%0A%20%20body%20{%20border%3A%20solid%3B%20width%3A%20150%25%3B%20text-align%3A%20center%3B%20}%0A%3C%2Fstyle%3E%0A%3Cbody%20dir%3Drtl%3E%0A..*
  <zcorpan> <title> seems like UI QoI.
  <fantasai> Blink aligns and scrolls as RTL.
  <fantasai> IE shows the whole canvas and can scroll to it, and
             aligns per RTL, but the initial scroll position is per
             LTR.

  Florian: So more testing to see what exactly is happening, and
           which is interoperable?
  fantasai: Whichever one is less likely to cause breakage is what
            we should do.
  dbaron: Fixing the spec might make things inconsistent too.
  dbaron: You'll need to make up some new term, not computed value,
          and you'll need to make sure everything refers to this new
          term, not "computed value".

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0272.html
  <fantasai> 710 pages with <body dir=rtl> and not <html dir=rtl>.
            (0.24%)
  <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1071098#c16
           is where I got the list of ways to test direction on the
           root
  <dbaron> fantasai: could propagate from the HTML attribute on the
           body, but not propagate CSS 'direction'
  <TabAtkins> html:has-child(body[dir=rtl]) { direction: rtl; }
  <TabAtkins> DONE

  ACTION GregWhitworth to figure out what options are sensible for
        the html/body dir thing.
  <trackbot> Created ACTION-672

  <br dur=15m>

Loop from Ruby and Writing Modes
--------------------------------

  dbaron: Xidorn tried to implement something, and we found a
          problem.
  dbaron: In CSS sometimes the process of computing one property
          depends on another one.
  dbaron: And we need to keep these in a partial order, so no loops.
  dbaron: We discovered that Ruby and Writing Modes added a loop.
  dbaron: It's between 'display' and 'writing-mode'.
  dbaron: There's also an influence from 'ruby-position'.
  dbaron: display:ruby-text-container && ruby-position:inter-character
          => writing-mode computes to vertical-rl
  dbaron: Because intercharacter ruby needs to be drawn that way.
  dbaron: I've seen elevator signs in Taipei look like this.
  dbaron: When writing-mode changes between parent and child, and
          display is inline, it's changed to inline-block.
  dbaron: Because you can't really display a writing mode change
          unless the parent establishes a block.

  dbaron: I think most of us agree that writing-mode has to mess
          with display.
  dbaron: So it's not strictly a loop, but this still doesn't work
          in our architecture.
  dbaron: roc suggested that the vertical-lr change be triggered by
          something else that display:ruby-text-container elements
          have.
  TabAtkins: So our problem here is that we have a strict separation
             of properties into "levels" that compute in order.
  dbaron: Ours isn't strict, but we do have a strict ordering of
          inherited vs non-inherited properties, which ends up being
          the same thing.
  fantasai: We could make the inline->inline-block a used value.
  dbaron: Making the computed value out of sync with the real value
          will be a security issue.

  [missing some minuting]

  TabAtkins: I think roc's suggestion can work. Add a magic property
             to <rtc> and anonymous ruby text containers. Authors
             have to add it manually if they're making their own.
  fantasai: Can this just be an implementation issue? That's a weird
            contorsion for authors.

  [dbaron's thinks furiously]
  dbaron: What does it look like in inter-character ruby when there
          is an <rtc> with multiple <rt>s?
  fantasai: Each rt is after each rb. The rtc and rbc both encircle
            the entire thing.
  dbaron: That makes it sound like it's the rt that's vertical-rl,
          not the rtc.
  dbaron: If so, can we fix by changing the condition to "my
          parent's display is rtc and my ruby-position is inter-
          character"?
  fantasai: Or parent's ruby-position is inter-character.
  dbaron: If it's the ruby-text that becomes vertical-lr, I think
          that's okay.
  fantasai: Sounds good.

  RESOLVED: writing-mode: vertical-lr on the <rt> based on parent's
            'display' & 'ruby-position'

all shorthand question
----------------------

  heycam: The 'all' shorthand is designed to exclude direction and
          unicode-bidi.
  heycam: Why?
  fantasai: Direction and unicode-bidi should never have existed.
            They're not stylistic, they're content properties.
  fantasai: So when resetting stylistic stuff, they shouldn't be
            reset.
  fantasai: But writing-mode *is* a stylistic choice.
  heycam: And text-orientation too?
  fantasai: Yes.

SVG Keywords - kill them?
-------------------------

  heycam: There are some SVG-specific keywords in writing modes.
  heycam: text-orientation:use-glyph-orientation, which means "do
          what the SVG-specific glyph-orientation-
          vertical/horizontal properties say".
  heycam: I was going to suggest to SVGWG to just drop those, since
          nobody implements them.
  heycam: Presumably you'd drop the value if we drop the properties.
  fantasai: Yes.
  heycam: Next is some writing-mode values, coming from XSL.
  heycam: We're going to drop all of those, and just refer to
          current CSS spec.
  heycam: So I suggest they get dropped from CSS.

  fantasai: Can you actually drop them?
  fantasai: It's reasonably likely there's no web content that uses
            them, but may be off-web content that uses them.
  TabAtkins: Can we just death-pact with the SVGWG and choose to
             drop them if they do?
  heycam: At least we'll drop them from SVG2.
  fantasai: But you'll still need the definition.
  fantasai: We might deprecate and define them simultaneously.
  heycam: In WM atm, there's wording that says "if you support these
          values, do XXX".
  heycam: We'll let you know what we decide.
  heycam: I found an old email of mine saying that some browsers do
          implement glyph-orientation-*, but they didn't do it
          interoperably.
  fantasai: If the values only show up in attributes, you can use UA
            CSS to convert it to the proper values.
  fantasai: But if the existing content uses the CSS syntax, you
             need to keep it.

  RESOLVED: Drop the values if the SVGWG drops the values/
            properties, otherwise keep them.

  <krit> This is exported from Photoshop:
  <krit> .cls-15 {
  <krit> writing-mode: tb;
  <krit> glyph-orientation-vertical: 0;
  <krit> }
  <heycam> krit, ok, that is interesting

Multi-line/block ellipsis
=========================

  <dbaron> https://lists.w3.org/Archives/Public/www-style/2015Jan/0357.html
  Florian: Not the first time we've discussed this.
  Florian: To refresh everyone, we have ellipsis.
  Florian: It only works in in the inline dimension. If a given line
           is overflowing, it gets ellipsized.
  Florian: Most people want something at the end of the last line of
           a block that's too long in the block direction.
  Florian: We actually have a resolution to add it to the spec,
           without specifying what's getting added.

  Florian: So I was looking into this...
  Florian: I have some ideas, but while working on this, I figured
           this was a problem that should be unified with something
           similar, and so I'll be talking more about fragmentation
           than ellipsis.
  Florian: When you say "I want ellipsis at the end of the last
           line", what does that mean? Last totally-fitting line?
           Does ink(shadow) count?
  Florian: Or do we just use fragmentation, which defines all of
           this?
  Florian: There's a property in the Regions spec called
           region-fragment.
  <astearns> http://dev.w3.org/csswg/css-regions/#the-region-fragment-property
  Florian: It has 'auto' or 'break'. If the last region of the
           region chain overflows, and it says "auto", it overflows
           like normal. If 'break', it acts like there's another
           region, but just drops the rest.

  fantasai: This sounds like another value for overflow-y.
  <fantasai> This is overflow-y: paged-hidden
  Florian: The Regions spec shows why that's not true; it's
           independent of overflow.
  astearns: overflow-x/y can have effects independently of
            region-fragment
  TabAtkins: Regardless, I think you're not invoking the property
             itself, just its concept?

  Florian: I think we can generalize this concept.
  Florian: [described the definition of the property again]
  fantasai: So you have overflow:scroll and hidden.
  fantasai: Same, but hidden just stops it rather than exposing the
            rest.
  fantasai: Similarly, this is like paged and "paged-hidden" - "page
            me, but don't expose the rest".

  dbaron: I agree with Florian.
  dbaron: When I was writing the Overflow spec, I found this awkward.
  dbaron: It was trying to put two different concepts in the
          Overflow property, one about visual overflow and one about
          pagination.
  dbaron: It was awkward that there were 'overflow' values (page and
          fragments) that were about how to paginate, so when you
          had those values, you had to arbitrarily pick what to do
          with the visual overflow that visible/hidden handled
          normally.
  fantasai: So that makes sense to me; maybe different properties
            for visual vs pagination overflow.
  fantasai: I'm okay with that.
  fantasai: As long as pagination and hiding pagination are in the
            same control.
  Florian: That's chapter 5 of my very long mail.

  Florian: So my new proposal is a 'fragmentation' property.
  Florian: With values auto/none/break/paged/clone
  Florian: Auto is "do the right thing in the middle of a region
           chain", etc
  <fantasai> break is region-break: break behavior
  <fantasai> paged is overflow: paged
  <fantasai> clone is overflow: fragment
  Florian: Should we explain regular pagination in terms of this?
  Florian: By having this property on the page box, having "auto"
           compute to "paged", which lets you turn off pagination on
           a page and let things overflow.
  Florian: Dunno if that's useful.

  Florian: Reason this ties into ellipsis is that we have an issue
           about block ellipsis, and another issue about "how can we
           write 'continue on page 3'", we can unify these.
  Florian: So we'd solve the "put ... at the end of a block" the
           same way as "put ... at the end of a region that
           continues elsewhere", and eventually "put (page 3) at the
           end of a region" when we have those tools.

  tantek: When I've seen "include the first 3 lines" behavior, it's
          usually on social networks with a "more" link.
  tantek: I don't know how to combine auto-ellipsizing that and
          adding a link that you can attach some other behavior to.
  Rossen: We discussed this in Seoul.
  Rossen: Talked about what to do with ellipsed behavior.
  Rossen: We added the "fade" ellipsis behavior, and there was talk
          about styling it, so it should be a pseudo-element.
  Rossen: So the ellipsed block is actually interactive. You can
          attach event handlers to the pseudo-element.

  Florian: Another possibility is adding a "fragment: into(<sel>)"
           that we could use later.
  fantasai: Bert had a pull model that I think makes more sense than
            into(<sel>).
  tantek: I think I'm okay with unifying.
  tantek: So we need a string, not just "ellipsis".
  TabAtkins: You can attach an event listener to the parent of the
             ::ellipsis pseudo, and do the "more" handling there.

  tantek: So one behavior is an expansion when you click "more".
  tantek: Another is "more" being a link to another page.
  tantek: Third is "continued on page 3", where it loads totally
          different content, maybe saying "continued from page 1".
  tantek: Another scrolls down to another part of the page.
  tantek: I'd like to at least capture those.
  <dbaron> And some websites use both, and you can't tell which
           you're going to get until after you click it.
  TabAtkins: First two can be done with JS now; doing it CSS
             requires reviving the Hyperlink module. Third can be
             done as Region expansions in the future.
  Florian: My basic point is that if we try to solve block ellipsis
           separately from fragmentation, we'll have to solve these
           problems twice.

  johanneswilm: As I understand it, if you can have an ::after
                pseudo element that you put the ellipsis in, you can
                use JS to figure out what page something shows up
                on, and set 'content' appropriately.
  tantek: It's definitely solvable in JS today. Just want to let
          there be less JS, or no JS.
  Rossen: If your container is actually constrained so there's only
          two lines visually, you say max-lines:3, the behavior is
          still bad.
  Florian: No, max-lines:3 just puts a break opportunity after the
           3rd line.
  Florian: Currently max-lines only applies to overflow:fragments;
           it should apply to any fragmentainer.
  TabAtkins: Yes, assuming we have these new fragment values.

  Florian: So, proposal is we remove region-fragment property,
           replace it with the 'fragmentation' property.
  dbaron: I'm okay for now, haven't looked into the details.
  tantek: I agree with the general scope of the proposal.

  RESOLVED: Replace region-fragment with 'fragmentation', written by
            Florian, determine where it belongs.

  fantasai: Why is max-lines only usable on fragmentainers? Should
            be on all block containers.
  [discussion over this]
  [???]
  [unminuted discussion about fragmentainers]
  [height, fragment or not, making breaks]

  Florian: So right now, if you say max-lines:3 on a <p> in the
           middle of a page, it'll break the page after the third
           line.
  Florian: Which is silly, so we need the <p> to be a fragmentainer.
  Florian: To be automatic, maybe max-lines:non-none causes
           fragmentation:auto to compute to 'break'.
  fantasai: 'break' is a non-obvious name.
  TabAtkins: Maybe 'discard'.

  Rossen: So max-lines is non-inherited.
  fantasai: So, what I understand is that the proposal is to take
            the values of 'overflow' that deal with fragmentation
            and make them into a separate property, and add a value
            that does fragmentation but hides the overflow instead
            of continuing it on another page/clone.
  Rossen: So what if you have <div style="max-lines:3;"><div>...
          </div></div>
  Florian: Well, regardless of that answer, max-lines should apply
           to any block.

  astearns: dbaron defined this well in the Overflow spec where he
            tries to take your case into account.
  astearns: We can resolve the issue over there.
  <astearns> http://dev.w3.org/csswg/css-overflow/#max-lines
  astearns: But the discussion is about fragmentation.

  Florian: So do we want to do regular pagination with this
           fragmentation property?
  fantasai: I was thinking paging was overflow:paged on the root
            element.
  fantasai: overflow:paged creates pages the same way that scrollbox
            creates a scrollable canvas in the viewport. Instead of
            scrolls, you get pages.
  fantasai: Each of those pages are style-able with an @page rule,
            regardless of whether the whole doc is paged, or a small
            section.
  Florian: So in some contexts, auto becomes paged, and maybe
           'break' becomes 'overflow:hidden' or whatever on the root
           element.

  RESOLVED: Split fragmentation values of 'overflow' into a separate
            property. Further develop this in the overflow module.

  <johanneswilm> Has it been defined what kinds of elements each of
                 those pages has?
  <johanneswilm> (header, body element, footnote area, page number
                 area, page float area?)
  <johanneswilm> Or can it be definable by the user?

  Florian: That property that gets separated out is the
           region-fragment property. So pull it out.

  RESOLVED: region-break gets folded into the new property, too.

  astearns: If this goes into Overflow, add Florian as an editor?
  dbaron: Yes.

  RESOLVED: Florian added as editor to Overflow.

  fantasai: Do we have a def of overflow-x/y?
  dbaron: Kinda, in Overflow.
  fantasai: I was gonna say that when we have that, we cut that as
            Overflow 3 and have everything new in Overflow 4.

  Florian: I think region is the only fragmentainer that has
           ::before/after, but now you can.
  astearns: We needed ::before/after in our processing model to see
            how they work in named flows.
  astearns: If we assume that ::before/after are always blocks in a
            fragmentainer (what we currently do), then we'd want to
            extend that.
  fantasai: What if the remaining space is negative?
  Rossen: Defined in the region spec.

  fantasai: Can they turn into run-ins?
  Florian: I'd like to.

  Florian: When you're doing ::after on fragmentainer, there are
           cases you want to only do ::after if you're fragmenting.
  Florian: So maybe have an ::ellipsis-like thing to help handle
           that.
  fantasai: Then we have the remaining issue about how to make it
            interactive.
  florian: That's a general pseudo-element issue.
  fantasai: Yes, but it's a core part of these use cases; not so
            much for other pseudos.

  heycam: How do you align the ::ellipsis? For the block one, does
          it appear as a block right below?
  Florian: The way I remember it is "you know how wide this thing
           is, so you can lay out your ::after".

  johanneswilm: I tried to do footnotes with regions, and
                ::before/after were problematic.
  johanneswilm: I couldn't have a footnote marker get left behind,
                etc.
  [johanneswilm and dauwhe got distracted by footnotes and went
       off-topic]

  dbaron: I initially wanted [it] that way...
  dbaron: We realized there was a problem that you design some style
          with overflow:fragments, style each fragment,
  dbaron: Then 'fragment 2' gets a page break in it.
  dbaron: You don't want your styles to be one off because your
          'fragment 3' styles get applied to the second half of what
          was originally 'fragment 2'.
  dbaron: Probably a way around that, but we're getting complicated.

  <br dur="til morning">
Received on Thursday, 12 March 2015 00:33:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC