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

[CSSWG] Minutes New York F2F 2015-05-19 Part I: Writing Modes

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 29 May 2015 21:22:30 -0400
Message-ID: <CADhPm3vSWbVFG4roAnhs-9h57qH6G4MFYmz4qX1C3TPf6MxgLw@mail.gmail.com>
To: www-style@w3.org
Writing Modes

  - RESOLVED: No spec change for writing-mode on table cells
  - RESOLVED: No propagation of 'direction' from body to html,
              propagate dir attr with `html:not([dir]):has(>body:dir(
              rtl)) { direction: rtl; }, back out if web compat
  - RESOLVED: writing-mode and direction need to have the same
              propagation behavior, so writing-mode compat affects
              the previous resolution (which may be rescinded)
  - gregwhitworth and smfr will investigate web compat of not
      propagating writing-mode from body to html to try and come to
      a resolution on the discrepancy between the previous two
  - RESOLVED: Writing Modes spec adds an example of blocking
              inheritance into SVG; blocking is not automatic
  - RESOLVED: Clarify the spec to correctly explain how to implement
              sideways and how to not implement sideways-left
  - RESOLVED: Don't mark vertical-lr at risk
  - Auto-sizing block containers in orthogonal flows will be marked

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

  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Bo Campbell
  Tantek Çelik
  John Daggett (phone)
  Elika Etemad
  Daniel Glazman
  Koji Ishii (phone)
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Simon Fraser
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Doug Schepers
  Shane Stephens
  Lea Verou
  Jet Villegas
  Johannes Wilm
  Greg Whitworth
  Steve Zilles

  John Daggett
  Dael Jackson
  Simon Pieters
  Anton Prowse
  Hyojin Song
  Alan Stearns

  Agenda: https://wiki.csswg.org/planning/new-york-2015#agenda

  Scribe: SimonSapin

Writing Modes

Deferring Orthogonal Table Cells

  <presenter> https://lists.w3.org/Archives/Public/www-style/2015Apr/0387.html
  koji: First issue is proposal to defer orthogonal table cells
  fantasai: The idea is we don’t have interoperable implementations
            for writing modes applied to a table cell (you can apply
            to contents of a table cell).
  fantasai: The proposal is to defer to level 3.
  fantasai: I don’t think this makes sense, but problem is that we
            don’t have implementations e.g. for vertical table
            headers, so Koji suggests to defer.

  Rossen: Did you test IE?
  fantasai: Yes, we found bugs.
  fantasai: I don't think it makes sense to defer to next level.
  jet: Single cells?
  fantasai: Yes.
  fantasai: My position is we should keep it.
  Rossen: I agree.

  fantasai: Deferring means if you apply a writing mode to a table
            cell, some impls will apply, some will ignore.
  glazou: What does it mean in terms of spec? Behavior undefined?
  fantasai: We can do 3 things:
            1) leave the spec alone
            2) say it’s undefined
            3) say that for applying WM to a table cell, either you
               do X or pretend it doesn’t apply.
  dbaron: Writing modes inherits, right?
  fantasai: Yes.
  fantasai: We need to look at why it’s not implemented.
  <gregwhitworth> This works in IE/MS Edge: http://jsbin.com/videdumeme/2/edit

  SteveZ: Ignore the property?
  fantasai: That’s option 3
  fantasai: Undefined means weird things can happen.
  dbaron: It’s kinda weird to ignore an inherited property on just
          some elements.
  dbaron: On inner table elements like rows is use the WM of the
  koji: You already apply WM to the table’s contents.
  <koji> Spec currently says "All elements except table row groups,
         table column groups, table rows, and table columns"
  dbaron: Ignoring it means you do the same for a cell, which acts
          like it has the WM of the table,
  dbaron: but the anonymous block inside the cell uses the WM of the
  fantasai: If it's done correctly, that’s same results.
  dbaron: Except for logical properties.
  fantasai: True, but we don’t have those yet, so from the POV of the
            spec it doesn’t make a difference.

  dbaron: I don’t see how it would be extra work to make it apply at
          least on the anonymous block inside the table cell.
  koji: Some differences in table cells when applying borders.
  <koji> I think table cell has some differences in borders,
         colspan, etc.
  <koji> IE fails most of these tests as of today
  <fantasai> colspan!?
  <koji> Since WebKit and Blink does not apply to td/th
  <koji> Authors already work around by putting a div/span inside
         table cells
  dbaron: colsan and rowspan are still relative to the table’s WM I
  TabAtkins: Yes.
  TabAtkins: A colspan spans columns.

  dbaron: Who is pushing to change the spec?
  TabAtkins: Koji is
  <koji> me
  fantasai: My preferred solution would be file bugs against impls.
  gregwhitworth: Rossen: Agree.
  fantasai: Anyone have a different opinion?
  Chris: So your opinion is that the spec is clear?
  fantasai: On that topic, yes.
  glazou: What does this mean to go to REC?
  fantasai: Bugs need to be fixed before REC.
  glazou: Are browsers interested in fixing this?
  jet: We’re implementing now.

  glazou: Should it be at-risk?
  Chris: There is no downside to marking at-risk.
  Florian: You also can mark at-risk + say "we can drop from must to
  SteveZ: In that case, fantasai wants a fallback which in my mind
          means to ignore the property.
  fantasai: So `td, th { writing-mode: inherit !important}` in the
            UA stylesheet?
  fantasai: Effectively.
  Chirs: With a comment: do it properly or not at all.
  <koji> If not supported, it should be the same as when applied to
         <tr>, no?

  jet: Sounds like implementers want to leave it in
  fantasai: You (IE) want the spec to stay and you’ll fix your bugs?
  Rossen: Can you be more specific?
  fantasai: So if we write test cases where you fail, you’ll fix it?
  Rossen: That’s how it works.
  fantasai: I think it should stay, but it’s up to the WG.

  glazou: Let's do a straw poll.
  glazou: Two options: should stay in the spec, or not
  Florian: and marked at risk
  <Florian> Stay in the spec, mark at risk, with clarification that
            at risk means may drop from must to should
  <fantasai> 1. No change to spec
  <fantasai> 2. Say it is undefined
  <fantasai> it = what happens when writing-mode is applied to a
             table cell
  <fantasai> 3. Mark as at-risk and specify what happens if it's not
  1: 8 hands raised
  2: none
  3: 6 hands
  * fantasai notes that Microsoft, Blink, and Mozilla reps were all
             for 1

  Florian: What’s the downside of 3? It's the same as 1 plus
  dbaron: Plus extra work.
  fantasai: You need to specify both "should" and the alternative.
  <koji> I can try to define the alternative
  glazou: 1 wins. Anyone objects?
  <koji> ok

  RESOLVED: No spec change for writing-mode on table cells

Propagation of the direction property from <body>

  fantasai: We're not really getting information on why would
            anybody would do that.
  gregwhitworth: It's faster to make the switch and see how much
                 stuff breaks.
  fantasai: Proposal: propagate the dir attr value from body to html,
  fantasai: rather than the direction property.

  <koji> does the proposal include writing-mode?

  fantasai: The advantage is that the direction property has lots of
            side-effects on the root: scrolling direction, scrolling
            origin, alignment of things in the root, cascading…
  fantasai: It's lots easier and less buggy if none of these things
            had to be special-cased for body.
  fantasai: You only pay attention to direction on the root.
  fantasai: It's less buggy impls, the main question is can we pull
            that off in web content.
  fantasai: There's some data, but it's hard to tell what’s going on.
  fantasai: One survey says the direction property is used in like
            88% of web pages, which is ridiculous.
  fantasai: Maybe it’s in some library.
  fantasai: One of the browsers should release a nightly build and
            see if that works.
  fantasai: Lots of simplification in layout engines, consistency,
            less bugs.
  fantasai: I'm worried about e.g. logical properties.

  dbaron: The proposal is that dir attr on body sets the direction
          property on html?
  fantasai: Yes.
  fantasai: It’s only one line with a child selector.
  SimonSapin: You mean :has()?
  fantasai: Yeah.
  dbaron: You also have to handle dir=auto.
  dbaron: Is there a difference with dir=auto on html vs body?
  fantasai: Yes: on html, also looks at the title.
  dbaron: And maybe style and script elements?
  fantasai: Yeah, probably you don’t want to set dir=auto on the
            html element.
  dbaron: I don’t know about interop. Gecko’s behavior is a bit
          random, 5 things that should be propagated but only some
          do. No good sense of compat risk or how reliable other
          impls are.
  fantasai: Testing showed lots of bugs.

  fantasai: Do we want someone implementing this, or more data, or
            not do this?
  SimonSapin: I'm in favor of the proposal.
  Bert: I would like to get rid of propagation from body as much as
        possible, e.g. background was an anomaly.
  fantasai: Probably this is the best we can do.

  fantasai: 2 variations up to HTML WG: 1. propagate the resolved
            direction (accounts for auto on body, not particularly
            necessary) 2. just propagate dir=rtl
  <fantasai> html:has(>body[dir=rtl]) { direction: rtl }
  <fantasai> html:has(>body:dir(rtl)) { direction: rtl; }
  <fantasai> (insert a :not([dir]) after the html there)
  <fantasai> I don't think it matters which one we take, both are
             fine for web-compat, and using dir=auto on <body> is
  dbaron: Don’t think the current HTML WG is suited to make this
  fantasai: I mean the people who work on these things.
  dbaron: That’s us.
  dbaron: Probably more sensible to handle dir=auto on body.
  dbaron: Makes more sense than on html.

  fantasai: other opinions?
  <koji> writing-mode?
  <fantasai> koji, I think we have to handle that as a separate issue
  <koji> ok, good then
  fantasai: Works for me.

  glazou: We need to resolve or move on. Good to go?
  TabAtkins: Yeah.
  gregwhitworth: Good to go but we need other impls to follow.
  dbaron: Someone just wrote a patch, waiting for review. Don’t know
          if it does what this says.
  gregwhitworth: Can we resolve on doing this unless web compat is
  fantasai: Yes.
  fantasai: Proposed resolution: no propagation of 'direction' from
            body to html, propagate dir attr with that rule above,
            back out if web compat problems.
  fantasai: Sounds good?
  glazou: No objection?
  <koji> yes, good

  RESOLVED: No propagation of 'direction' from body to html,
            propagate dir attr with `html:not([dir]):has(>body:dir(
            rtl)) { direction: rtl; }, back out if web compat

Propagation of writing-mode

  <koji> can we also resolve for writing-mode?
  <koji> ...or at least discus?
  dbaron: If this works, it makes sense not to propagate
  dbaron: if not, keep them together,
  fantasai: Seems ok.
  <koji> But propagating dir attribute implies propagating direction
         property, no?
  <fantasai> No, it's different.
  <koji> I prefer propagating writing-mode,
  <koji> as that's what IE/WebKit/Blink does today AFAIU.
  <koji> If those two are linked, I'm not ok with the proposal for

  dbaron: If we want WM to propagate at the CSS level we should undo
          that resolution and propagate direction at the CSS level
          as well,
  dbaron: though maybe in terms of effect, not necessarily in terms
          of computed values,
  dbaron: ... on the root.
  fantasai: We have to figure out what to do for writing-mode. If it
            has to propagate, direction does too.
  fantasai: IE WebKit Blink all propagate.

  fantasai: The issue would be, can we turn it off?
  <koji> Quite possible to break lots of EPUB
  Rossen: In our case, vertical/rtl doesn’t make a difference.
  Rossen: I’m gonna be opposed to different handling.
  fantasai: Agreed.
  fantasai: You currently propagate writing-mode from body to html,
            would you be able to turn that off?
  Rossen: We can, if everybody else does it at the same time.
  fantasai: Other impls are WebKit and Blink.
  TabAtkins: I have no idea.

  gregwhitworth: Maybe a good starting point is understand the
                 compat issue.
  fantasai: It is more […], we have more options to solve with
            direction, because of the dir attr, but writing-modes is
            only CSS.
  fantasai: Sounds like Microsoft is willing if Blink and WebKit
            also ship without propagation. What is the state of the
            content you need to deal with?
  fantasai: Concern that there are pages out there that set writing-
            modes on body and expect the whole thing to be vertical
  <koji> I don't have data, but estimates it breaks several EPUB
  gregwhitworth: Do we wanna unresolve?
  fantasai: We can resolve that direction and writing-mode need to
            have the same propagation behavior.
  gregwhitworth: I can give sites that are using writing-mode on
                 body, be would be good if webkit/blink can also

  RESOLVED: writing-mode and direction need to have the same
            propagation behavior, so writing-mode compat affects the
            previous resolution

  fantasai: Action item for that?
  gregwhitworth: I’ll take it, but good if everybody else looks
                 into it.
  gregwhitworth: ebooks and stuff.

  ACTION gregwhitworth Investigate web compat of not propagating
         writing-mode from body to html.
  <trackbot> Created ACTION-687

  ACTION smfr Investigate web compat of not propagating writing-mode
         from body to html
  <trackbot> Created ACTION-688

  <koji> I'll try to look into too
  * fantasai notes that result of ebooks layout might not be
             affected if 7.3.2 is implemented fully ^_^
  fantasai: 7.3.2 is automatic use of multicol. Since ebooks don’t
            scroll, the default column size is the full size of the
            viewport. Long horizontal document with vertical
            columns … ends up with the same result.
  fantasai: Only problem with scrollable web page, scrolling origin
            is in the wrong place.
  fantasai: If you set w-m on body and it doesn’t propagate, you
            only notice it in scrolling.
  fantasai: You don’t implement auto multicol, it does make a
  fantasai: If you have one long thing and only print the first
            chunk of it,
  fantasai: might be that we can not propagate if we handle auto
            multicol in orthogonal flows.


  fantasai: Issue is that writing-mode property will inherit into
            embedded SVG.
  fantasai: In some cases you want that, if decorating text,
  fantasai: in most cases, that’ll break your coordinate space.
  fantasai: Do we block inheritance of writing-mode in SVG?
  ChrisL: There are lots of cases when inheritance is unwanted.
  ChrisL: MathML doesn’t do vertical text, SVG tries.
  fantasai: You render MathML sideways, it ignores writing-mode.
  <koji> yeah, but the problem of writing-mode is coordinate system
         is always physical
  Rossen: If you have foreign objects with HTML inside, you might
          want to propagate.
  dbaron: It seems like if pasting SVG into HTML, there’s a ton of
          things that inherit. Fonts, … If you want your SVG to be
          isolated, not be part of the context, you should be using
          object or img or iframe.
  fantasai: We can block with `all: initial`.
  TabAtkins: Except direction, because it shouldn’t have been a CSS
  TabAtkins: And unicode-bidi.
  fantasai: We want that to happen at the HTML layer.

  fantasai: Direction is not the problem here. If you’re pasting
            graphics with text, chances are it’s in the same
  shepazu: It's confusing either way. Some people will expect either
           behavior. As long as there is a way to achieve both. Have
           a way to block all these things at the SVG layer.
  shepazu: It’s gonna be confusing for somebody no matter which way
           we go.
  ChrisL: Mention it in the SVG integration spec?

  fantasai: The way to do it is to set `all: initial` and maybe
            `direction: initial`. Is that the default? Or does the
            default inherit through?
  fantasai: 2 things is that `all: initial` would block inheritance,
            `all: unset` would get it back.
  shepazu: Once you see a graphic you don’t expect it to change
           based on context. So you want the default to not
  TabAtkins: You’re dropping literal markup.
  shepazu: I still think it’s more intuitive to opt into propagation.
  fantasai: You also run into bugs when the author didn’t look at
            that particular graphics when translated… or change some
            font property.
  fantasai: It's more obvious if the text is off.
  shepazu: We don’t know how they’re bringing that markup. Are they
           using D3?
  shepazu: They could do it in a blog. Blocking is more intuitive,
           and make it clear how to unblock.

  fantasai: Proposed resolution: CSSWG recommends to SVGWG to block
            inheritance of CSS properties using `all: initial` at
            the SVG/HTML boundary.
  dbaron: There's a compat risk; this is used.
  glazou: Yes.
  Florian: It would be fine 10 years ago, but SVG is used now with
           inheritance; we’re changing behavior.
  glazou: SVG editor in Bluegriffon. You can select the whole
          document and make it bold. It just works.
  glazou: This would change behavior in a way that may not be
  ChrisL: The problem is two situations where people expect opposite
          things. Not clear which should be the default.
  shepazu: We’re mostly talking about text.
  TabAtkins: Color matters. `fill: currentColor`
  TabAtkins: It can be done now, we’d be breaking graphics if we
             change it to black.

  jet: Should the SVG WG be doing this?
  fantasai: The spec should explain how to do the other behavior.

  Rossen: I’m with dbaron. Web compat is gonna be a challenge. If
          you want to do this, it should be opt-in.
  Florian: It should be on the svg element.
  Rossen: It's too big of a knob.
  ChrisL: The all property is already a big knob.
  Florian: SVG is just an image, or it’s part of the document.
           Having that switch, that can still be overridden.

  plinss: The other problem when people want isolation of style. Why
          special mechanism just for SVG?
  ChrisL: Lea suggested the seamless attribute to do the opposite.
  leaverou: That was more a joke.
  ChrisL: When you want to inherit into <object>

  fantasai: So inherit, and use `all: initial` if your image is
            screwed up.
  fantasai: We need notes on both specs, especially for
            `writing-mode: unset`.
  fantasai: SVG spec in embedding should talk about this.
  shepazu: Somebody’s gonna be surprised either way.
  fantasai: If we have existing content, we can't change default

  RESOLVED: Writing Modes spec adds an example of blocking
            inheritance into SVG
  [SVG spec should also add examples of blocking inheritance with
   all: initial ]

  <break duration=15m>

  Scribe: gregwhitworth


  fantasai: We have three keywords.
  fantasai: Depending on the block direction sideways will get you
            the direction of the non-cjk language,
  fantasai: as though the block was rotated.
  fantasai: [shows diagram of sideways props]
  fantasai: sideways-right is the same as sideways in vertical-rl
            (Chinese, Japanese, etc.), but looks backwards to us
            (and correct in Mongolian) in vertical-lr
  fantasai: sideways-left is the opposite orientation
  fantasai: sideways automatically switches between the two, based
            on what's correct for non-vertical writing systems
  fantasai: You just want to set writing-mode on the root element
            and have it work.
  fantasai: The issue we have is implementors have not implemented
  fantasai: Because of this if you set vertical-lr together with
            sideways, webkit will give you the sideways-right

  florian: Isn't the bottom right to embed Arabic in English?
  fantasai: Yes, you're right, there are use cases for this.
  fantasai: Also there is an obscure script that uses this as well.

  fantasai: We have implementors saying sideways-right is good, and
            sideways, but not sideways-left.
  fantasai: This is not right, this is a conflict, you can't
            implement sideways and not implement sideways-left.

  florian: Given what you want for Mongolian, do we need sideways?
  fantasai: It's trivial to implement once you have sideways-left,
            and it helps with side captions being correct
            automatically for non-East-Asian writing systems.
  florian: Fair enough.

  fantasai: Either implement both sideways-left, or drop vertical-lr
            support, or update the spec.
  fantasai: We could mark vertical-lr at risk.
  fantasai: We can change the meaning of sideways.
  fantasai: Those are the things that we can do for the spec.
  florian: The naming we have now favors English.
  florian: Maybe we should focus the short keyword on doing the
           right thing for Asian languages since writing-modes is
           for fixing these issues.

  simon: What is the difficulty with sideways-left? And don't you
         have the same issues with sideways-right and RTL?
  fantasai: No, the issue is with the coordinate system being
  fantasai: All other values, the baseline shift goes towards the
  fantasai: In sideways-left, the baseline shift goes towards the
  fantasai: And you may have both of them in a line, so you will
            have a coordinate system for your linebox that shifts to
            the right, and then inside of this you may have to flip
            this for a range of text.

  dbaron: Gecko implements sideways-right, but not sideways or
  dbaron: Another complication that sideways-left introduces is how
          floats will work, technically float: left and float: right
          can be swapped within a block formatting context.
  dbaron: The spec needs to be switched to floats that are on the
          right/left of the bfc, etc.
  dbaron: Once you introduce sideways-left you may have a bfc where
          they swap.
  <dbaron> (that's issue 5 in the spec)

  Bert: Why is this different than Japanese?
  fantasai: Because it works differently and the float will go where
            it should go like normal, just in vertical.
  florian: That way float: left would be float: top?
  ratan: That is how our implementation currently works, it's
         generic to the bfc

  <dbaron> http://dev.w3.org/csswg/css-writing-modes/#logical-to-physical
           is a useful table

  fantasai: We have this issue where Webkit is not per spec.
  fantasai: I believe this is the same for Blink as well.
  fantasai: There's three options:
  fantasai: 1) Change meaning of sideways to sideways-right
  fantasai: 2) Webkit/Blink drops support for sideways keyword
  fantasai: 3) Webkit/Blink drops support for vertical-lr
  fantasai: 4) Webkit/Blink implements sideways correctly

  florian: Do we actually have a choice or are there compat concerns?
  fantasai: Not really, there won't be a lot of compat risk.
  fantasai: The case when you would hit this, is foreign text in a
            Mongolian document where you used 'sideways' to render it.
            That's the only case where this would break compat.
  fantasai: I want to know what Webkit/Blink think about the options
  tabatkins: ¯\_(ツ)_/¯
  <koji> As a personal I prefer 1.
  florian: Number 1 makes the most sense to me.

  Bert: Are these values to be used in CJK texts?
  fantasai: Yes.
  fantasai: Say you're embedding a word "O'Connor" in CJK text.
  fantaai:  In mixed mode it would look wrong because the letters
            would be sideways, but the apostrophe would be upright.
  fantasai: You would set [lang-en] {sidways-x} for the name so that
            it display correctly as a sideways run.
  florian: For CJK sideways and sideways-right are actually the same.

  smfr: I'm looking at some webkit test cases and sideways and
        sideways-right differ in glyphs used.
  fantasai: Well then that's wrong, the spec is clear that sideways
            equates to sideways-right.
  florian: So your sideways, is a kind of mixed not a kind of
           sideways, so drop it?
  smfr: But we did this for Japanese books.
  fantasai: From the testing it looks like we landed on two...
  tantek: Has webkit ever dropped the support for a keyword?
  tantek: I don't think that we should resolve on it if it's never

  <fantasai> koji, do you have a testcase for webkit 'sideways'?
  <koji> It used to work as an alias to sideways-right AFAIK
  <fantasai> It doesn't seem to atm
  <fantasai> smfr's testcase works same as mixed
  <fantasai> koji, webkit also says they can change names when
             dropping prefix
  <fantasai> koji, So, is there still an issue?
  <koji> I'm not really following...so which option WG prefers?
  <fantasai> koji, WG testing shows 'text-orientation: sideways' is
             not supported by WebKit
  <fantasai> So, it seems option 2 is ok.
  <koji> It used to, at least for a few years, and Bilnk does today
  fantasai: I need a testcase
  <Bert> Neither writing-mode nor text-orientation is in Safari's
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22-webkit-writing-mode%3A%20vertical-lr%3B%20-webkit-text-orientation%3A%20sideways%22%3ETEXT%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B8%E3%80%81%E3%82%B9%E3%82%AF%E3%83%AD%E3%83%BC%E3%83%AB%E3%81%8C
  <fantasai> Koji, looks like no support
  <fantasai> Note that all properties are prefixed
  <fantasai> -webkit-
  <koji> I see, because you use vertical-lr
  <koji> WebKit supports sideways correctly if vertical-rl
  <koji> looks like
  <koji> vertical-lr + sideways = mixed in WebKit, but
  <koji> vertical-lr + sideways = sideways-right
  <koji> So WebKit does have problems for CJK, not a problem for

  fantasai: We have two different behaviors for the sideways keyword
            in vertical-lr mode:
  fantasai: Blink implements it as sideways-right,
  fantasai: Webkit implements it as mixed,
  florian: Since they're prefixed the same there should be no compat
  fantasai: Yeah.
  dbaron: We're not currently shipping our pref for text-orientation.
  <koji> Mongolian needs sideways-right anyway, so I guess option 1
         works better than option 1?
  smfr: We did this for Japanese, so that's probably just a bug.

  <fantasai> koji, does content depend on unprefixed
             'text-orientation: sideways'?
  <koji> fantasai: don't have data

  fantasai: I feel like we're leaning towards option 1 or 4.
  fantasai: There seems like a decent likelihood that we won't have
            sideways-left for a while, so I think it's at risk of
            being dropped, what happens to sideways in that case as
            we may have web compat.
  florian: Again, it's only in prefixed properties for compat.
  florian: Also, it's mainly in books, etc. so less likelihood of
           automatic prefixers.
  florian: Maybe we should drop them now,
  dbaron: Another option is to keep sideways-left/right and put
          vertical-lr at risk.
  fantasai: Seems less likely to drop vertical-lr.
  smfr: I don't think I'd prefer that.

  tantek: What is the usecase for 2 vs 3 keywords?
  fantasai: [shows the different examples again]
  fantasai: It's captions on tables or image, and you want to put
            the block ordering in English.
  fantasai: The other options are for CJK languages, it doesn't make
            sense for English.
  tantek: So for horizontal text written vertically that's the main
          use case for sideways?
  florian: Yes.
  <koji> tantek: sideways-left is for English, but sideways-right is
         used in CJK and Mongolian too
  <koji> and most of the use cases can be achieved by
  <koji> So I'm not positive to bring in the complexity
         sideways-left has

  SteveZ: It's not easy as you say, what if you want it different on
          the left than on the right of the document?
  fantasai: You would change the writing-mode only.
  fantasai: The use cases for sideways-left are not that strong,
  fantasai: but to have sideways, you have to have both
            sideways-right and sideways-left.
  tantek: They're not strong, but there are use cases?
  fantasai: Yes, in books, with tabs in the corner that are rotated,
  tantek: Are there any use cases for non-90 degree angles?
  fantasai: Not currently.

  fantasai: On a related note, we may want to change the keywords to
            sideways-rl and sideways-lr to match writing-mode
  florian: I don't think that is better.
  florian: Typically when embedding a foreign language in Japanese
           you normally do sideways-right.
  fantasai: But there are examples of both.
  tantek: What is the easiest one for authors to remember, if it
          doesn't actually map to vertical-lr then we probably
          shouldn't change it.

  dbaron: Let's pick an option before moving onto the naming.
  fantasai: [crosses off number 3]
  smfr: When we unprefix, we could change the behavior.
  fantasai: I think you could change it now, because people aren't
            really depending on sideways-right in vertical-lr mode.
  fantasai: [explains options again]

  smfr: Just spec what people want and we'll change our
  Working Group says to keep 4: Implement sideways correctly,
  smfr: File those bugs and we'll go fix them.

  RESOLVED: Clarify the spec to correctly explain how to implement
  RESOLVED: And how to not implement sideways
  RESOLVED: Don't mark vertical-lr at risk

  koji: Anymore issues?
  <koji> Are there time for issue 10?

auto-multicol and orthogonal flows

  fantasai: Issue 10.
  fantasai: Let's say you have a vertical block and start writing,
            and the block gets longer and longer.
  fantasai: Because we only paginate in one direction, when you
            print it chops off the overflow to the side.
  fantasai: However, if you support multicol, when you print the
            spec requires that overflow gets broken into columns
            that then flow in the paging direction.
  fantasai: This is good because you have no data loss and this will
            allow ebooks to still work as well.

  ChrisL: You said this as though it was magic, but does the
          stylesheet have this, or does the UA do this?
  fantasai: The spec currently says that this needs to happen if you
            overflow, so you would need to put it into multicolumn.
  Rossen: We had this behavior in IE6/7 when you have vertical
          inside of horizontal, our printing would do what you are
  Rossen: We didn't emulate this in later versions, it wasn't
          technically too difficult to do but in my opinion if we
          need to have this it would be easier to do the magic
          behavior that ChrisL stated,
  Rossen: where when we're paginating, that would allow us to keep
          the layout.
  fantasai: I'm not recommending this for just printing.

  SteveZ: Isn't this where you would want to do overflow: fragment?
  tabatkins: Sure, multicol was just the way to get the behavior.
  fantasai: You don't want copies of the container with it's
  fantasai: This is just for autosizing.
  SteveZ: I would still need to set a height.

  dbaron: This seems way too magical.
  dbaron: I would prefer to do it in simple ways that they can know
          how to set it up.
  florian: On the other hand if you're testing on your screen and
           don't hit this, that causes problems.
  smfr: There are other ways to cause these issues.

  plinss: I would like to see a general solution to clipping content
          to overflow.
  Bert: It's not overflowing, the height is auto - you have infinite
        space in the block direction.
  fantasai: You don't want to set the height to vh, because you'll
            cause overflow in the block direction as well
  SteveZ: Then I agree this is way too magical.
  Rossen: Also this is really rare.
  fantasai: The author doesn't print their website ever, it's the
  fantasai: That's why we set to shrink wrap to the viewport height,
  fantasai: and that causes things to wrap and end up overflowing.

  SteveZ: I agree that multicol is good solution, but I would prefer
          to use overflow: fragment.
  plinss: I like the effect, and what you're trying to do with it,
          but I don't like the magic and trying to explain
          pagination using multicol.
  fantasai: We normally just tile sideways overflow, if we print it
            at all, but here you don't want to tile it as you'll cut
            stuff in half.
  plinss: I just wish we had a better way of explaining pagination.
  plinss: It feels like overflow: fragmentation is the right way to
          take this, but we need to mature that space.
  fantasai: Multicol and fragment are very similar, but multicol
            will provide you with the backgrounds and borders you
  plinss: I want a better general explanation of this.
  <dauwhe> +1 to plinss

  florian: We've been using multicol as a type of exotic layout, but
           in this case it is very fundamental in common layouts.
  florian: The type of behavior it gets you is quite fundamental.
  plinss: Again, the behavior is the correct one, but I don't want
          it just using multicol under the hood. I want a general
          set of primitives that explains pagination that people can
  fantasai: This is only triggered in an orthogonal flow.
  Rossen: The spec encourages to set height.
  SteveZ: I would like to have it work on all heights.

  fantasai: [draws diagrams showing calculations of heights of cols
            in an orthogonal flow]
  SteveZ: If I print that and I've set the orthogonal flow to 1vh.
  fantasai: You can't because you can't split the line box.
  fantasai: We don't have the capability of having variable width
  ChrisL: This is the type of thing that authors can't control.
  fantasai: They can set the properties themselves and control this,
            this is only for situations where everything is auto.

  dbaron: This is making me think things are getting more and more
          complex, for example I'm considering not investing on grid
          as it keeps evolving.
  dbaron: I'm starting to regret working on writing-modes, as I want
          to be able to ship stuff that are valuable.
  tabatkins: This is not getting more complex, we're just starting
             to actually document everything instead of just saying
  tabatkins: This is a common thing that people hit.
  florian: Yes, mixed modes are very common in Japanese.
  tabatkins: I understand your frustration.
  fantasai: The spec even says what to do if you don't have support
            for multicol.
  rossen: In the current Japanese printed world, where you're saying
          most of them have mixed writing modes, I've never seen them.
  SteveZ: The most likely place you'll see this is in English text
          quoting Japanese text.
  SteveZ: The real problem I think is between the switch of captions.
  Rossen: Again, these are small chunks, not long long flows of text.

  smfr: Are we trying to do this in L3, or can we defer this until
  fantasai: I think that's ok, but we may run into a few edge cases
            with this.
  rossen: I've discussed this case so many times and yet I've never
          seen it, it's always something small.

  <Bert> (Image from a ftf in 2012:
http://www.w3.org/Talks/2012/0509-CSS-ftf/all.htm#challenge5 )
  fantasai: [draws a sample Japanese magazine layout]
  fantasai: [talks about how the publishers adjust the layout and
            content to make it work just right]
  fantasai: We don't see what happens when you mess with the layout
            or change the screen size.
  fantasai: We should decide on what to do,
  fantasai: We should make it so that it doesn't clip the content.
  rossen: Is anyone asking for this? If this was a very big painful
          point the entire Japanese publishing would let us know.
  fantasai: Sure we can defer this, but we should solve this problem.
  rossen: I'm not saying that. We're about to add a bunch of magic
          that won't be trivial to implement and cause interop
          issues on something that we aren't commonly told is an
          actual issue.

  fantasai: [shows another use case]
  SteveZ: I think vh is the wrong thing to use for the line length,
          I think it would be better to use Xchars in the default
  rossen: I'll add to this, when I implemented orthogonal flows in
          IE8, when you have a mixed flow and let's say the body has
          a margin of 100vh you will automatically have a scrollbar
          even if you don't overflow.
  rossen: Again, I've never heard from people about this problem
  fantasai: I think that ultimately the author should select the
            correct column height.
  SteveZ: No one can read that, though.
  SteveZ: My memory, and I can't remember where from, is between
          14-16 ems for Japanese.
  fantasai: As a spec author I'm not going to pick an arbitrary set
            of numbers for font sizes.
  tabatkins: She's trying to just provide the same capability for
             vertical text as horizontal text.
  plinss: The more I think about this, the more I think this is the
          right solution for orthogonal flows especially when you
          have N levels deep. All my other reservations stand on
          their own, but on this one I think this is the best
          solution for this.

  rossen: What happens if it's a scroller, would you still do
  rossen: I have a a div from overflow: visible to overflow: scroll.
  florian: It would make sense to remove the multicol.
  rossen: Well that's more fairy dust and magic.
  fantasai: This will only trigger if you have height:auto and thus
            can grow in that infinite direction; a scroller will
            have a set height, so won't trigger this.
  plinss: What is stopping the line from being one long line,
          something has to be causing it to wrap.
  fantasai: You don't want to have any line of text that is longer
            than your viewport. Otherwise you have to scroll back
            and forth to read the text.
  tabatkins: That's the behavior if you don't support multicol or
             you have line breaks (pointing at css3 multicol

  SteveZ: I still think there are enough unanswered questions that
          it should be deferred.
  florian: There is value in shipping this, if not shipping anything
           at all.
  SteveZ: But you're not providing anything valuable.
  fantasai: In the case of fixed height, we're trying to avoid
            overflowing, which is the whole point of this.
  SteveZ: All you're doing is coming up with a height for the first
          block if no height is set.
  Bert: You can turn it into a fixed height and multicol.
  glazou: This discussion is going no where, let's wrap up.
  fantasai: I think everyone can agree to add this to the at risk
            list in the spec, we can agree with that.
  rossen: Yep.
  fantasai: We'll see where we are.
  fantasai: If stuff ships and we don't have this, then we'll defer

  <koji> Thank you all and sorry for making lunch late.
  <gregwhitworth> koji: no problem, thank you for staying up late!!!
Received on Saturday, 30 May 2015 01:23:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:11 UTC