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

[CSSWG] Minutes Sydney F2F 2015-02-10 Part VI: New Publication Process, Upcoming Meeting Dates and Locations, CSS Ruby

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Mar 2015 17:53:43 -0400
Message-ID: <CADhPm3umoPSVom=sPT=PNoTCPk=-p8ugxRtKt7v-c7s9TeykhQ@mail.gmail.com>
To: www-style@w3.org
New Publication Process

  - ChrisL introduced the new tool for publication, Echidna, and
      said that the beta version should be available for people to
      look at shortly.

Upcoming Meeting Dates and Locations

  - New York on 18-20 May was reconfirmed.
  - RESOLVED: Mozilla does August meeting in Paris.
  - RESOLVED: Provisionally accept Aug 25-27 (Tue-Thu) as the
              meeting dates.
  - RESOLVED: Pencil in week of Feb 1st for 2016 meeting.

CSS Ruby

  - fantasai will clarify the vertical layout section.
  - Reverse-propagating style to the parent appeared to be the least
      bad way to address whitespace between ruby boxes
  - RESOLVED: Use locale-specific :lang() rules instead of something
              like webkit-ruby-size for bopomofo ruby sizing
  - RESOLVED: ruby-position simplified to over|under|inter-character
  - RESOLVED: Either option 1 (Change initial value to center. Reset
              it for Japanese to be space-around in the UA
              stylesheet) or 3 (Have a value that does custom
              justifications - auto - which justifies between Han
              and Kana, and not between bopomofo) for ruby-position,
              at editor's discretion, WG preference to 1 if no legacy
              problems exist.


  Scribe: TabAtkins

New Publication System

  ChrisL: Existing publication system is a piece of shit.
  ChrisL: It takes html => tidy => xhtml => php => composter:
          produces error messages as a primary function.
  ChrisL: Then when it's free of error messages, ask someone else to
          do the same exact thing and disagree with you.
  ChrisL: This is not a good model.
  ChrisL: Replacing it with echidna.
  ChrisL: The source tool is in github so you can look at it, change
          it, etc.
  ChrisL: Been in alpha, about to go into public beta (tomorrow,
          hopefully, or today in Australia, who knows)
  ChrisL: Been testing it today with CSS3-UI.
  ChrisL: But that spec is cursed. Breaks everything.

  ChrisL: Benefits:
  ChrisL: Publish any day. All 7 days.
  ChrisL: Can publish multiple times per day; last per day will be
  ChrisL: Downsides: First beta won't do CR, only WD.
  ChrisL: It won't do cross-WG publications yet.
  ChrisL: Those'll be worked on.
  ChrisL: But no FXTF stuff yet.
  ChrisL: No human in the way to complain about your stylesheet.
  astearns: "last per day will be retained"?
  ChrisL: If you publish and notice a problem, you can just fix it
          and nobody will know.
  ChrisL: But with more than 24 hours, you're screwed.
  ChrisL: Cutoff is midnight Boston Time

  heycam: Does anyone get the right to push the button?
  fantasai: Everyone but Tab.
  ChrisL: Anyone can. There's a token system? I don't understand it
  ChrisL: afaik there's nothing preventing chairs from giving it to
          the editors.

  heycam: Any documentation?
  ChrisL: Yes, somewhat.
  ChrisL: I'll find it.
  <dbaron> https://github.com/w3c/echidna
  <dbaron> https://github.com/w3c/echidna/wiki

  krit: If something goes wrong, will someone fix it?
  ChrisL: Yeah, it's an official systeam product, they'll fix it.
  SimonSapin: Does that mean we can have max-width:50em on our
  ChrisL: Don't know. As long as the checker doesn't complain, you
          can probably get away with it.
  ChrisL: Currently something we have to take out when we publish is
          the tests script.
  ChrisL: W3C is now allowing those scripts, and not under the
          directory it's published in.

  ChrisL: I scared the system by first asking for a W3C mathjax
          install. When they said no, I pointed out we have 60+
          individual mathjax versions all bitrotting, and they
  ChrisL: Bert is maintaining mathjax, Peter will maintain the
          results script, and I'll talk to Lea about prism.js.
  ChrisL: So over time there'll be several approved scripts people
          can just use.

  krit: Can we get a `bikeshed publish` command?
  ChrisL: Sure, probably.
  tantek: When will we see the first draft?
  ChrisL: Maybe tomorrow.
  tantek: How long until we can publish CRs, joint work, etc.
  ChrisL: A few months.
  astearns: Since FPWDs trigger review too, does that mean they
            can't do it yet either?
  ChrisL: Dunno. Probably.

  <ChrisL> some documentation
  <ChrisL> in case anyone wondered, our cuddly new publication
           system is named after this:

Upcoming meeting dates and locations

  glazou: Next meeting is confirmed in New York, 18-20 May.
  <astearns> https://wiki.csswg.org/planning/new-york-2015

  glazou: We still have to discuss end of August.
  TabAtkins: People tell me Zurich is a hellhole in August.
  dbaron: And it's gotten very expensive lately.
  TabAtkins: Right. So what about Paris?
  dbaron: Note that everyone leaves Paris in August.
  TabAtkins: So cheap hotels?
  dbaron: Also some restaurants will be closed.
  <liam> no, because people from other countries flood in, just as
         the French go to Italy and the Italians all go to Greece :)
  TabAtkins: So it sounds like Paris is the best idea.
  [general assent]

  plinss: Let's nail down dates. Currently Aug 24-28 blocked out.
  dino: What about Houdini?
  Rossen: 1-2 days. We'll work it out on the ML.

  TabAtkins: So, suggestion from Tantek is that Firefox hosts Paris
             August instead, and Google just does Sydney again next
  <tantek> TabAtkins, well, it was more of a floated idea to
  <tantek> TabAtkins, dual motion

  RESOLVED: Mozilla does August meeting in Paris.

  <dbaron> SimonSapin, re: the room in Paris, both double-check with
           Shannon *and* book the room in the calendar
  <SimonSapin> dbaron, will do

  TabAtkins: Dates!
  Florian: Suggest 24-26
  SteveZ: Possible conflict on 24, maybe do 25-27
  heycam: Next scheduled SVG meeting is June in Sweden.
  heycam: Don't think we're meeting between then and TPAC.

  RESOLVED: Provisionally accept Aug 25-27 (Tue-Thu) as the meeting

  tantek: Tentatively block out next Feb meeting as first week of

  RESOLVED: Pencil in week of Feb 1st for 2016 meeting.

  <tantek> with Google hosting in Sydney

  SimonSapin: Feb 1st is FOSDEM.
  glazou: I can't do after Feb 20
  <tantek> getting away from Valentine's Day is a plus
  ChrisL: That'll conflict with my 20th wedding anniversary.
  dbaron: This year, the week before this week was a more expensive
          for flights, because of Australia flight patterns, though
          that went away closer in.

  <TabAtkins> ADJOURNED
  <Rossen> br { @extends .break; action: resume; }

CSS Ruby
  Scribe: shane

Line Height Rules

  dbaron: There was discussion on the mailing list - agreed on line
          height rules. But it's not in the spec yet.
  fantasai: It seemed like that made sense.
  fantasai: I will try to write it up and grasp it fully.
  dbaron: With some of the prose for figuring out what this means in
          terms of vertical placement/sizing I couldn't figure it
  xidorn: There's an open bug about how height in ruby base
          container can be determined.
  dbaron: Prose in spec about how this can be determined. OK for
          ruby text container but ruby base container should act
          like an inline as much as possible.
  fantasai: I think ruby base container in terms of how it effects
            line layout should be like an inline, but in terms of
            how it effects the spacing of ruby annotations on either
            size need to take into account border padding and margin.
  dbaron: I'm ok with that.

  dbaron: Part that's weird is sizing of the content box is not like
          an inline.
  fantasai: Right. Sizing of content box should include margin boxes
            of all of the bases.
  dbaron: Is that because you don't like how inlines work?
  fantasai: I don't like that margins don't effect layout for those.
  fantasai: If you put borders on ruby bases, having that not effect
            position of ruby text seems wrong.
  fantasai: How does the author get it right then? line height?
  dbaron: Fine with it to move the ruby text.
  fantasai: The simplest way to keep things from colliding is to
            have the ruby base container contain all of the ruby
            base boxes and text container (?) contain ruby text and
            stack them with no gaps.
  dbaron: If you don't want line height to effect ruby position that
          makes sense.
  SteveZ: But ruby has to effect line height.
  dbaron: I'm OK with that.

  xidorn: Does vertical align property effect ruby text?
  fantasai: Yes.
  xidorn: But how?
  fantasai: I don't remember scoping. Ruby text at same annotation
            level with align with each other.
  dbaron: So basically ruby text container acts like a line for
          purposes of alignment.
  SteveZ: So what connects lines?
  SteveZ: Will I get strange behavior if I put non-ruby stuff
          between two things?
  SteveZ: e.g. underlines don't jump around. Concerned that Ruby
          might act different. I don't know what should happen

  fantasai: <draws on board>
  SteveZ: What if one of the letters was bigger?
  fantasai: <more drawing>
  fantasai: Basically you do the sizing of the characters, then the
            base box wraps around that, then the text sits on top so
            it's always aligned.
  SteveZ: Why isn't the ruby text box a line box the whole line

  xidorn: Another concern is the line height of the anonymous ruby
          text container. In the current model it should inherit
          from its parent. But I don't think it is desirable.
  fantasai: I think you're right. We shouldn't be using properties
            of the ruby text container for layout. We should be
            using the ruby text, then wrapping the container around
            the result.
  dbaron: Be careful about difference between line box and inline
          box. Inline box has a line height but line box wraps
          around a bunch of inline boxes and takes height from them.

  dbaron: I think what you're saying makes sense. More complicated
          but OK. Put in spec please?
  fantasai: What's not in the spec?
  dbaron: Vertical alignment.
  fantasai: I'll just check.
  fantasai: I need to fix that then.
  dbaron: That's the biggest set of issues I was worried about.
  dbaron: I would like to see spec edits resulting from discussion
          with xidorn and koji though.

Whitespace Between Ruby Text

  fantasai: There's a couple of hard issues.
  fantasai: Handling whitespace between ruby text. Problem is that
            if you've got ruby text that you've marked up but
            there's whitespace in-between. Want the whitespace to
            stay there but I size the ruby text elements to 50% of
            base text. But then whitespace ends up being really tall
            and really wide and the wrong size.
  Florian: That's not something we can fix.
  fantasai: Yes, HTML people don't like autogenerating tags.
  fantasai: That's the issue I haven't really figured out how to

  dbaron: Is it possible to say that the whitespace goes away but
          that there are other spacing rules for ruby text?
  dbaron: For example, what script they're in, whether script has a
          certain property.
  dbaron: Such as newlines go away in Chinese.
  SteveZ: Does that mean you want to put another character than
          whitespace in?
  fantasai: I think you could reasonably argue that those rules
            could get rid of the whitespace but there are other
            cases where you don't want it to.
  fantasai: The issue is that we want font set on the outer box but
            instead it's set on the inner boxes
            [because the outer box isn't marked up]

  Florian: Can we reverse-propagate style to the parent?
  dbaron: We've never done it before.

  astearns: Any other reason we'd want to style the text container?
  fantasai: Possibly?
  fantasai: We do forbid you from making ruby text and ruby base
            containers visible.
  fantasai: This is because some implementors will want an
            internalized structure that's different from the CSS
  fantasai: Styling those boxes isn't an important use case.
  fantasai: It should be fine to have different internal model.
  fantasai: So boxes aren't directly detectable, can only inherit
            properties through them.

  astearns: Can you say line height of container is max line height
            of children?
  SteveZ: That doesn't work. Really want to set it to font size of
  SteveZ: Only concerned about whitespace between?
  fantasai: Yeah, everything else is wrapped.
  Rossen: Is this really a common use case?
  fantasai: It isn't an error condition but it isn't common.
  SteveZ: Classic one is where you have double ruby (english + ??).
          English one would need the spaces.
  SteveZ: Would be common in English ruby.

  fantasai: I'm not sure what the rules are in pinyin.
  Florian: Some syllables need to be separated by an apostrophe if
           there isn't a space. Otherwise it's stylistic.
  Florian: If the only purpose of propagating up is to propagate
           back down again that seems like the least bad idea.
  fantasai: Agreed. I'll use that for now. If anyone thinks of
            something better can change it.

Locale-Specific :lang Rules

  fantasai: Next issue. Webkit has a special keyword for
            ruby-font-size. Inter-character generates smaller font
            than above or below.
  fantasai: Resolved as locale-specific rule in stylesheet for ruby.
  Florian: Is by language not by script. Close enough?
  fantasai: Can do it by :lang(). Can set font size explicitly if a
            problem. This is just for default size.
  Florian: OK

  RESOLVED: Use locale-specific :lang rules instead of something
            like webkit-ruby-size.

Ruby-Position Property

  <Florian> http://upload.wikimedia.org/wikipedia/commons/c/c7/Hunmin_jeong-eum.jpg
  fantasai: Next issue. Ruby-position property had 2 keywords for
            position in horizontal text and for vertical text.
  fantasai: Suggestion was to simplify to a single keyword for both
            (over, under, inter-character)
  dino: We have after, before, inter-character
  fantasai: That's definitely wrong.

  fantasai: If we have single keywords, then over implies right,
            under implies left, and inter-character implies right
            for vertical text.
  Florian: This example shows inter-character for vertical text.
  fantasai: Can extend back to two keywords if necessary.
  fantasai: But this is the common case.
  fantasai: Can we resolve to do this?

  Scribe: TabAtkins

  SteveZ: My understanding of the problem of translating above/below
          to vertical is that traditionally Japanese does right (
          above) but some Chinese cases go left.
  fantasai: That's why we had two values, but Xidorn says we don't
            need them.
  xidorn: I don't see any left cases.
  xidorn: You don't have any pictures of left.
  xidorn: I don't know what use-cases you've found.
  fantasai: This is stuff I inherited from the previous editor.
            I don't know the use case myself.

  fantasai: The difference between over/under and before/after is:
  fantasai: If you have block-flow of vertical text laying out right
            to left, before is right, after is left. If the blocks
            stack left to right, vice versa.
  fantasai: But over/under depend on what way text is rotated, not
            block-flow direction.
  fantasai: So proposal is to knock it it down to over|under|
            inter-character, and we can add more in the future if

  dbaron: What was the two-value syntax?
  <xidorn> [over|under|inter-character] || [left|right]
  fantasai: Would let you specify left|right as well, so one's for
            horizontal and one's for vertical writing.
  Florian: The current proposal combines them.

  RESOLVED: ruby-position simplified to over|under|inter-character


  fantasai: Next is default value of ruby-align
  fantasai: Two values are center and space-around.
  fantasai: space-around is a justification value.
  fantasai: It add space at the justification opportunities.
  fantasai: So Latin text would stay together, but Chinese would be
            able to split between each character.
  fantasai: So we set the initial value to space-around.
  fantasai: Problem is that bopomofo can be justified, but bopomofo
            ruby should be centered by default (due to language
            users preference).
  fantasai: 1) Change initial value to center. Reset it for Japanese
               to be space-around in the UA stylesheet.
  fantasai: 2) Keep it as space-around, reset it for Chinese to
  fantasai: 3) Have a value that does custom justifications - auto -
            which justifies between Han and Kana, and not between

  fantasai: Spec is currently 2.
  fantasai: But multi-word ruby you may not want to justify spaces,
            so maybe 1 or 3 is better.
  fantasai: It seems only Han/Kana should be justifying.
  TabAtkins: 1 seems simple then.
  SteveZ: 3 is the classic way we do it, but it requires magic.
  fantasai: I don't think 3 is too magic, but 1 is definitely
  fantasai: Main concern with 1 is "do we have a concern with legacy
            untagged content?"
  SteveZ: 3 is script-based.
  SteveZ: Why is 1 better?
  fantasai: Simpler. 1 is just a 1-line fix to your UA stylesheet; 3
            is effectively a new justification algorithm.
  TabAtkins: Can we just do 1 unless we see evidence of breakage in
             the wild?
  fantasai: Dunno what Koji wants. Let's do 1 unless Koji dissents.

  RESOLVED: Either option 1 or 3 for ruby-position, at editor's

Received on Wednesday, 18 March 2015 21:54:12 UTC

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