W3C home > Mailing lists > Public > www-style@w3.org > November 2013

[CSSWG] Minutes TPAC F2F 2013-11-12 Tues I: Box Generation and Elements as Regions, CSS Writing Modes and Tr Fallback

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 21 Nov 2013 18:29:46 -0500
Message-ID: <CADhPm3sMOo7vqRhZ4kBRQStHfzeN7BHTmRbXiKA+=uzHRnTe-g@mail.gmail.com>
To: www-style@w3.org
Box Generation and Elements as Regions

  - RESOLVED: Closing issue in bug 15733.

CSS Writing Modes, Tr Fallback

  - Koji discussed the ongoing issue about how Tr should fallback,
         rotated or upright.
  - Another solution was also raised to leave the fallback behavior
         undefined or must not.
  - RESOLVED: Accepting option A, "If the vert alt glyph is not
         present in the font, UA may, but is not expected to, substitute
         the glyph," with term "MAY WISH TO" and referencing RFC6919.
  - RESOLVED: Take CSS Writing Modes to Last Call.


  Rossen Anatassov
  Tab Atkins (IRC Only)
  David Baron
  Bert Bos
  Elika Etemad
  Sylvain Galineau
  Daniel Glazman (IRC Only)
  Rebecca Hauck
  Israel Hilerio
  Koji Ishii
  Dean Jackson
  Taichi Kawabata
  Jirka Kosek
  Chris Lilley
  Peter Linss
  Larry McLister
  Simon Pieters
  Simon Sapin
  Dirk Schultze
  Leif Arne Storset
  Alan Stearns
  Lea Verou
  Jet Villegas
  Kazutaka Yamamoto
  Steve Zilles

Agenda: http://wiki.csswg.org/planning/tpac-2013#agenda

Box generation and elements as regions
  ScribeNick: dbaron

  [projector and microphone configuration]
  [astearns shows http://www.theguardian.com/world?view=mobile]

  astearns: I wanted to describe a few things we're doing with regions.
  astearns: We're pushing for using regions and named flows in
            responsive UI designs.
  astearns: I'm showing a site from the guardian, not using regions at
            all. It has a navigation bar at top, with a menu that comes
            out. It's assuming for a landscape tablet display. As you
            narrow the display, the navigation elements move to the
  astearns: The script is putting items that don't fit in the width and
             moves elements around in the DOM.
  astearns: The script is a little buggy and janky.
  astearns: It's really easy to do by defining navigation elements as
            belonging to a named flow, two regions: nav bar, and menu.
  astearns: That's much more performant, and doesn't need script.
  astearns: A similar thing, the example at
  astearns: You don't want these buttons to show up on mobile, so at a
            certain width all the buttons get collected into a named
            flow and put into a slide-out.
  astearns: Again, no script, just a media query that turns on the named
  astearns: I just wanted to introduce these ideas to the group.
  astearns: In this case it's a region chain of regions all with a
            particular height (viewport height) so the content is
            interspersed with images:

  astearns: I've been posting to www-style about how named flows work
            with overflow:fragments in an attempt to convince people
            that the issue in regions about box generation should be
            closed because every box generation mechanism we have
            defined or proposed for CSS is something regions can
            participate in.
  astearns: The original issue was put into the specification because
            people wanted to see what the page template proposal that we
            had only talked about would look like.
  astearns: I produced the page template proposal where we can target
            CSS-generated boxes with region chains.
  astearns: I assume we're going to do something similar in future work
            with this group. Regions works well with that.
  astearns: Introduced before and after elements, and introduced
            overflow:fragments which dbaron ran with and produced an
            interesting spec; but again, regions works well with
  astearns: You can take two overflow:fragments elements in your
            document, link them with named flow, and have content
            flowing through elements without adding region elements to
            markup at all.
  astearns: So the question was, do we need a box generation mechanism
            for regions, and I've maintained all along that we don't,
            and we'll use every box generation mechanism we have for

  astearns: So unless anybody has an objection I'd like to close that
            one particular issue.
  dbaron: I'm ok with closing 15733.
  fantasai: 16858 stays open.
  astearns: Yeah.

  RESOLVED: closing issue in bug 15733

  astearns: I don't know that it's going to be fruitful to talk about
            elements today. I've been posting to the list; it's on
            dbaron's todo list to look at those messages.
  astearns: If anyone wanted to discuss what we've been talking about on
            the list about using named flows and region chains as lower
            level mechanism for describing fragmentation and pagination
            and things, we can but I'm also happy continuing discussion
            on list.
  astearns: Anybody want to talk about that right now?
  astearns: If not, we can move on to next agenda item.

CSS Writing modes, Tr fallback

  Plinss: Maybe we can close this one today?
  [Koji projects http://www.unicode.org/reports/tr50/]

  Koji: The issue is Tr fallback in writing-modes.
  Koji: Some background on the discussion:
  Koji: UTR50 describes 4 values (shows Table 1). One of them is Tr. T
        means transform, not only about upright or rotated, but usually
        requires different type of transformation.
  Koji: Tr means if font doesn't provide alternative glyphs it should
        fall back to rotated.
  Koji: Tr has 2 purposes (1) for backwards compat -- but all existing
        fonts have alternative glyphs.
  Koji: (2) example is is U+3030 WAVY DASH - not only about rotation but
        also includes flipping.
  <fantasai> For backwards compat -- you can see, these characters are
             not transformed, just rotated, but since all fonts contain
             transformed glyhs that perform the rotation, want to use
             those glyphs.
  Koji: The recommendation is a preference for flipping in font system,
        but preference to fall back to rotated fonts.

  Koji: In CSS writing modes, we had same definition for Tr at one point
  Koji: 1.5 years ago John (Daggett) proposed that implementation cost
        of Tr fallback is high, and the number of characters affected is
        about 10-20 characters.
  Koji: Given the definition -- if font provides all alternative glyphs
        for these 20 codepoints, these issues will go away.
  Koji: John said that even though UTR50 defines fallback, given
        implementation cost, he wants CSS to define fallback to upright.
  * sgalineau does not believe jdaggett described the cost as sky-high
              or 'impossible'. His argument was that it was unnecessary.

  Koji: After that we had 2 different feedbacks from developers, saying
        implementation is easy, and they want their UA to display those
        characters correctly, even with existing fonts.
  Koji: So we have a situation where 2 developers want fallback to
        rotated and 1 to upright.
  Koji: fantasai and I discussed it and considered 5-10 characters as
        subtle difference.
  Koji: We agreed to define UA may fall back to upright or sideways,
        which is what we have in spec right now.

  Koji: In September John raised a concern that 2 options can cause
        confusion to authors, and fallback to rotated is wrong or the
        cost is high.
  Koji: So John wants CSS to define "must upright."
  Koji: So sylvain agreed with that; glenn disagrees and wants rotated
        or both options.
  Koji: James Clark is ???, fantasai and Rossen are opposed to it.
  Koji: Eric said he agrees with John 2 weeks ago.
  Koji: I talked with Eric last week during UTC; he still wants upright,
        but ok for WG to resolve.
  <sgalineau> For Adobe, Eric Muller believes the best option is to
              mandate no fallback
  Koji: I think that's pretty much situation up to today.
  Koji: This issue is last issue remaining for LC of css-writing-modes.

  SteveZ: 2 comments:
  SteveZ: (1) You said TR50 said "should fallback" but what said is "can
          fallback", though that's a nit-pick.
  SteveZ: (2) Second point, what Eric was concerned about was telling
          whether font had the appropriate characters. He's concerned
          about looking at font data because with font subsetting you
          may get false information about what the font is doing if
          you're getting a subset. So he was concerned about building
          that particular piece.
  SteveZ: (3) John's point was that whenever we have optional sorts of
          things, it means implementations diverge and users get
  Koji: My comments on those three:
  Koji: (1) As you said it's "can".
  Koji: And, as Eric said, this UTR50 is informative, so it's not
        forcing everything.
  Koji: (2) So I understand that not only it has some other issues like
        John pointed out, may break dlig.
  Koji: The argument is that can be fixed by designing fonts correctly
        or designing embedding correctly.
  Koji: So there are challenges,
  Koji: But that's not something really not possible.
  Koji: (3) There may be a ??? on UTR50,
  Koji: But the original goal of UTR50 was to provide consistent
  Koji: During the development phase we figured it's not possible with
        existing fonts,
  Koji: So our goal was to give best consistency, and complete
        consistency if UTR50 compatible font is used,
  Koji: And there are 10 characters we are discussing for Tr,
  Koji: And 20 or more that will be inconsistent anyway.
  Koji: I'm working with Japanese publishers and AntennaHouse about how
        authors have to be careful when authoring to be careful
        orientation is consistent across existing fonts.
  Koji: I agree that allowing both options can diverge and add more
        burden to authors, but it's not something we can really avoid.
  Koji: Given the cost; development cost varies depending on
  Koji: Given that we can't reach consensus I think allowing both is
        best option.

  SteveZ: I'm concerned about something you said: fixing a rare case and
          fixing it at the cost of putting burden on anyone who develops
          font subsetting.
  SteveZ: Font subsetting seems likely to be very popular for East Asian
          fonts. Adding cost to that to fix this problem seems wrong way
          to go.
  fantasai: I don't see what this has to do with subsetting.
  SteveZ: Probably not in this case... either character is there or not
  Koji: Let me explain: Tr defines render as upright, but if no vertical
        alternate, fallback to rotated.
  Koji: Font subsetting could only subset one glyph without the vertical
  Koji: In that case, using the subsetted font, UA cannot determine if
        codepoint has a vertical alternate glyph or not.
  SteveZ: Yes, that sounds correct.

  Koji: The case for PDF, but is for epub or html where user can
        override writing modes for usability/accessibility, regardless
        of this issue, font subsetting should include both horizontal
        and vertical alternate glyphs into the subsetted fonts. If they
        do that they also solve this problem.
  Koji: It's true that it requires an additional step, but it's not only
        to solve this problem.
  Koji: Does that answer your questions?
  SteveZ: I certainly understand what you're saying; the requirement for
          not subsetting with only one of directional things is not
          coming from this but coming from that user style sheets could
          override, so you need that capability anyway.
  Koji: This is about 10 characters. In John's original proposal those
        10 characters will be rendered incorrectly for some existing
  Koji: John and Eric think that's ok because they're rarely used
        characters ...
  Sylvain: No, they think fonts will get fixed.
  Koji: I know there are technical differences... if it's about subtle
        differences why do we care so much?

  SteveZ: I understand last way, but it applies equally way to any
  Koji: Thus I ask for it to be either behavior. John wants to demand
        single behavior, I want to know why.
  Jet: The cost to every other codepoint that's not those 10,
  Jet: Extra conditional in code -- vs benefit to rendering those
       characters incorrectly.

  Sylvain: I posted a link to Eric Muller's post. Eric thinks no
          fallback is the better decision.
  Sylvain: That's consistent with feedback I got from other experts.
  Sylvain: I think the issue about cost was not about absolute cost, but
           about cost relative to how often it's needed, since
           expectation is that fonts will be fixed.
  Sylvain: In general, in standards providing optional behavior is a
           source of incompatibility.
  Sylvain: I think that makes sense.
  Koji: It costs more for one option for one architecture but opposite
        cost for other architectures.
  Koji: So if we mandate one we have to pick one.
  Sylvain: That's the point of mandating.
  Koji: It costs more for some browsers and less for others.
  Sylvain: I don't think having no fallback can cost more than fallback.
  Koji: I disagree.
  Koji: 1.5 years ago the discussion, one said cost is sky high, another
        developer said cost is low, another developer said cost is
  Sylvain: You write complex fallback code that you have to test for
           something that will happen extremely rarely. That's not sky
           high in terms of total amount; it's relative to the benefit.
  Sylvain: Mandating no fallback will lead fonts to update. (?)
  Sylvain: So that code will never be used.

  Plinss: Does the practice of subsetting potentially break that
  Plinss: If alternates end up not part of the subset, not guaranteed to
          have them.
  <SimonSapin> If we assume fonts will get fixed, can we also assume
               subsetting tools will get fixed?

  SteveZ: Koji's point was that subsetting for CSS requires both glyphs
          to be there because you don't know what will be there until
          things arrive. You can always do it wrong, but then people
          will get bad results and people will stop using your system.

  Rossen: What if we, instead of disallowing it, discourage it?
  Rossen: We can say that behavior is not expected, but if there's an
          implementation that really wants to do it, it's at least not
  Rossen: Authors reading spec should not expect it to be supported, but
          they are not restricted to forbid behavior.

  fantasai: I think another thing to consider would be font formats
            other than OpenType.
  fantasai: In OpenType a number of these characters are transformed by
            convention, but this might not be true in another font
            format might have different expectations.
  fantasai: So even if we want to mandate this for OpenType I don't
            think it would make sense to mandate for all font formats.
  fantasai: Also it doesn't make sense ... ??? if handled at font engine
            level rather than text layout level.

  SteveZ: Rossen, if I understood you: "If the data for the rotated form
          is not present, this specification does not define what should
          be done"?
  fantasai: That works for me.
  Rossen: That's more of the undefined case.
  SteveZ: I think advantage of undefined, it still leaves the forcing
          function of getting the fonts updated, because you don't know
          what's going to happen.
  Rossen: Would anyone not be able to live with undefined?
  r12a: Would it be a question of leaving it undefined like that, or
        undefined plus recommend that you follow UTR50?
  fantasai: The wording I'd suggest is that it's undefined whether the
            UA is allowed to synthesize some kind of substitute glyph.
  dbaron: So no longer Rossen's "undefined but discouraged" proposal?
  <dbaron>: I'd prefer undefined but discouraged over simply undefined.

  SteveZ: Where are we?
  Rossen: I think between disallowed and undefined?
  Rossen: As I understand, John wants disallowed.
  <sgalineau> fwiw feedback on fallback implementation cost I have
              heard: cheap to hack it, more expensive to do it right.
              Too expensive for the number of cases that will exercise

  <fantasai> "UA may but is not expected to synthesize the substitute
  Rossen: If we say UAs are not expected to support rotated sideways
          glyph, but not required not to, then that should be a way of
          saying basically: don't expect it to work, but implementations
          might do it.
  ChrisL: Or in other words would be saying "you may fall back but not
          required to" just like UTR50 says.
  SteveZ: That's why I'd prefer it's simply undefined, since otherwise
          you're back out of undefined.

  [various people mumbling]

  Bert: That's the wrong way round, I'd say.
  Rosssen: Current spec says UA may, but not required to fall back to.
  Rossen: The current statement is close.
  Bert: The current statement suggests that what UTR50 says is that
        rotating better than not.
  Bert: The want implementations to rotate but we still like them to do
  Bert: I think wording should be clear that we still want them to.
  dbaron: I think many people here disagree that we want them to.
  dbaron: People think we're better off expecting font to have correct
          data in it, instead of adding features to work around bugs in
          a font.
  <sgalineau> +1 to dbaron
  Bert: That assumes it's a bug in the font, maybe it's not.
  <fantasai> I think for OpenType it would be considered a bug in the
             font, but for other font formats might not be...

  Plinss: In general I'm ok with any of these proposals.
  Plinss: I'm concerned that I don't want us to say "you must not do
          this" because if you have a font engine that does this then
          the UA has to undo what the font engine is doing.
  Plinss: Just saying it's undefined because it is defined in UTR50,
  Plinss: If we're explicitly undefining it then we're just sanctioning
          what UTR50 says.
  <fantasai> +1 to Peter
  <fantasai> wrt undoing font engine
  Plinss: So if we have an explicit preference we'd ???
  Plinss: I have concerns if we're willfully violating another spec, if
          it says "can do it" and we say "must not do it."
  <Rossen_> "the UA is not expected to fallback..."

  fantasai: Can we straw poll on wording "may, but is not expected to"?
  Plinss: Should we reference April 1 update to RFC2119?
  fantasai: ?
  Rossen: What if we say UA is not expected to do fallback?
  fantasai: We have to say allowed disallowed or optional.
  fantasai: We have to say, normatively, what is it.
  fantasai: Saying something is expected or not expected is not really

  SteveZ: Seems to me we have 3 possibilities:
  SteveZ: (1) John's "must not."
  SteveZ: (2) undefined.
  SteveZ: (3) should use the font, but failing that can do fallback per
  SteveZ: I think those are only 3 on the floor. Appears to me at this
          point that the easiest to eliminate is (1).
  SteveZ: That leaves us with 2 different ways of saying can fallback,
          either by not saying anything or by saying you can.
  SteveZ: I'd propose a straw poll that would eliminate the first
  SteveZ: And then we can see if there's a significant difference
          between other two.
  SteveZ: Seems easier to eliminate (1) from straw poll.

  fantasai: There's 2 wordings on floor:
  <fantasai> "If the vert alt glyph is not present in the font, UA may
             but is not expected to substitute the glyph"
  <fantasai> vs
  <fantasai> "If the vert alt glyph is not present in the font, behavior
             is undefined"
  <fantasai> ??

  SteveZ: I think fantasai's second option captures what we should get
  fantasai: The first one is my proposal, because I don't like leaving
            things blanket undefined.

  r12a: What happened about the straw poll to eliminate (1)?
  r12a: Can we resolve to eliminate option 1?

  A) "If the vert alt glyph is not present in the font, UA may but is
     not expected to substitute the glyph"
  B) "If the vert alt glyph is not present in the font, behavior is

  fantasai: I don't like (B) because it allows the UA to do absolutely
            anything it wants.

  A) "If the vert alt glyph is not present in the font, UA may, but is
     not expected to, substitute the glyph"
  B) "If the vert alt glyph is not present in the font, behavior is
  astearns: A
  rhauck: A
  dirk: Abstain
  Bert: Of these two, prefer A,
  zcorpan: Abstain
  kazutaka: A
  yamamoto: A
  Koji: A
  Rossen: A
  Israel: A
  jet: A
  chrisL: A
  Lea: A
  Sylvain: A
  3 A's
  Dean: Abstain
  fantasai: A
  dbaron: A
  hober: mu
  SteveZ: A
  Kennyluck: A
  Leif: Abstain
  Peter: A
  TabAtkins: abstain

  Bert: My question is, are we really doing what Unicode want us to do?
  Bert: Was it really a neutral choice to be doing it or not, or do we
  fantasai: Descriptions in unicode spec are informative saying what
            categories mean, not dictating a behavior.
  Bert: If they didn't want implementations to rotate, why did we write
        it there?
  Bert: I think we're saying opposite of UTR50.
  Plinss: UTR50 says can, we're saying may but not expected to.

  r12a: Is substitute the right word, or is rotate?
  fantasai: Synthesize the substitute glyph
  fantasai: wording's a little bit off

  Peter: I think "MAY WISH TO" from RFC6919
  Peter: I think we should use "MAY WISH TO" and reference RFC6919.

  RESOLVED: Accepting option A, with term "MAY WISH TO" and
              referencing RFC6919.
  <ChrisL> http://tools.ietf.org/html/rfc6919
  * sgalineau can't wait for the RFC6919 reference in the new charter
  <SimonSapin> "This phrase is frequently used to avoid further delay in
                approval of a document."

  Peter: Is the spec ready to advance?
  fantasai: I expect this to be the first of at least two last calls.
  <SimonSapin> seems appropriate
  Peter: Anything to rename?

  RESOLVED: Take CSS Writing Modes to Last Call.

  Peter: break until 11am.

  <fantasai> I think there's an open issue on possibly renaming
             text-combine-horizontal to something better/easier-to-type

Received on Thursday, 21 November 2013 23:30:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC