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

[CSSWG] Minutes Telecon 2015-10-21 [css-round-display] [css-writing-modes] [css-text-3] [css-will-change] [css-variables] [css-cascade]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 22 Oct 2015 07:01:06 -0400
Message-ID: <CADhPm3v+zPHL2tLLNPpazgJ0T0ovXJCVuABfNcZrct1g-TRxow@mail.gmail.com>
To: www-style@w3.org

  - Anyone with items to discuss at TPAC is asked to please put them
      on the agenda ASAP.
  - The Japanese Industry meet-up is still short on details, but
      Florian is speaking with them tomorrow, so hopefully they are

Polar Orientation Property

  - Jihye brought her proposal for a polar orientation property to
      the working group for their feedback.
  - The group felt that the effects of the property could be
      achieved by the rotate property either as it stands or with
      additional keywords aimed at handling polar cases easier.
  - Florian also expressed a concern that the proposed behaviors in
      polar orientation may not be enough to solve common use cases
      and requested an issue be added that there may need to be more

Writing Modes

  - RESOLVED: Publish CR for Writing Modes.

word-break: break-all

  - Everyone agreed that the spec text for word-break: break-all
      needed re-working, though there wasn't a clear decision on the
      right direction.
  - Koji and fantasai will come up with a proposed change to the
      spec check referencing UAX14 and see what the group thinks of

TR Stylesheet for W3C

  - The working group is in favor of any changes to the default TR
      stylesheet that brings it closer to the stylesheet that the
      CSS working group is already using.

Status of Unpublished Specs

  - The Will Change and Variables specs have received resolutions
      for publication, but have not actually been published.
      - Bert will look into where these specs are in the pipeline.
  - There are also specs with last publication date of more than 6
      months ago.
      - This issue will be discussed at TPAC.

Cascade 4

  - RESOLVED: Publish Cascade 4 as CR


Agenda: https://lists.w3.org/Archives/Public/www-style/2015Oct/0173.html

  David Baron
  Bert Bos
  Adenilson Cavalcanti
  Tantek Çelik
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Jihye Hong
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Myles Maxfield
  Michael Miller
  Edward O'Connor
  Simon Pieters
  Anton Prowse
  Florian Rivoal
  Hyojin Song
  Alan Stearns
  Greg Whitworth

  Dave Cramer
  Chris Lilley
  Peter Linss
  Lea Verou
  Johannes Wilm

  scribe: dael


  glazou: Let's get started. This is the last call before TPAC
  glazou: First thing as usual, digressions.

  <glazou> https://wiki.csswg.org/planning/tpac-2015
  glazou: TPAC agenda items. The list is pretty light as of a few
          hours ago. I added a few, but it would be good if you
          could add your requests to that page.
  glazou: Do that ASAP so the chairs can have a good sense of how
          much we have to discuss and some sort of prioritization.

  Florian: The paperwork is in progress, so this isn't technically
           true, but I'm switching to represent Vivliostyle. I also
           have a valid consulting contract with Bloomberg. But I'm
           no longer an invited expert, I'm Vivliostyle.

  glazou: Anything to add to the agenda? We only have 3 items.

Polar Orientation Property

  <jihyerish> https://lists.w3.org/Archives/Public/www-style/2015Oct/0177.html
  jihyerish: Hi, I'm Jihye from LG Electronics. Above is the mailing
             list message about polar orientation.
  jihyerish: I proposed the property which could decide the
             element's degree of rotation in a polar coordinate
             system. It's named polar orientation and makes the
             element rotate in that axis. It takes the values
             center | counter-center| <angle>.
  jihyerish: It works when it is positioned with polar distance and
             polar angle property. When center is the given value,
             the element rotates by polar angle value. If the anchor
             is the center point of the element, a straight line
             passing through the anchor point would meet the center
             point of the containing block.
  jihyerish: Counter-center makes it rotate by the polar angle value
             plus 180deg.
  jihyerish: Also, <angle> is used for polar orientation value type.
             When the element has an angle value it has constraint
             rotation transformation by specified angle. You can see
             the results of the property by the example linked below.
  <jihyerish> http://anawhj.github.io/jRound/demo/polar/rotate.html
  jihyerish: You can see the sample of polar orientation in polyfill.
             There are two circular layouts. In the left they are
             without polar orientation. The right side is
             implemented with polar orientation. All elements in the
             circular shape have same polar distance. An element
             with polar angle <90deg as center value. counter-center
             is given to polar orientation when the polar angle
             value is >90 and <270.
  jihyerish: As you can see from the elements positioned at polar
             angle 90 and 270, they rotate by a constant value of
             0deg, no matter which polar angle value.

  jihyerish: This is the explanation of polar-orientation. What do
             you think about this property? Are there more things to
  fantasai: This is, except for center center, is this the same as a
            rotate property?
  jihyerish: Yes, this property means the element rotates by Z axis
  <dbaron> https://drafts.csswg.org/css-transforms-2/#propdef-rotate
  fantasai: So rather than have a separate property that only works
            when you're polar positioning, I think it makes more
            sense if we need special keywords like polar-center, we
            should add those to a rotate property which I think is
            planned to be added. The angle values behave the same
            way and we shouldn't have two properties that do the
            same thing.
  Florian: I had the same thought. If we keep it on a separate
           property we should remove the explicit angle because
           that's redundant with rotation. Center and counter-center
           are not.

  <dbaron> What was the intended initial value of polar-orientation?
  <bradk> Transform: rotate(auto) ?
  <fantasai> transform: rotate(polar-angle)
  <astearns> it looks like you can do it all with rotation, you just
             need to do the math
  <fantasai> transform: rotate(counter-polar-angle)
  <fantasai> transform: rotate(calc(180deg + polar-angle))
  <astearns> rotate: polar-upright
  <bradk> Upright = no rotation?

  glazou: I have a question. Is there anything you can do with polar
          orientation that you cannot do with rotation?
  jihyerish: There is nothing we can do not using rotate, but when
             you use polar orientation the user can specify the
             rotation transformation more easily than using rotate
             value when aligning elements in rounded display, I
  Florian: It saves you from doing math. If you want to keep the
           polar angle and orientation in sync. If you have center
           and counter-center it self-adjusts.
  glazou: Yeah.

  Florian: Which brings me to another point. As shown in the
           example, it doesn't completely adjust automatically. On
           the right you have a different value for the numbers on
           the top, numbers on the bottom, and 4 and 10. Which means
           you have to manually keep track of what is where. If you
           have to do that I don't think the property is meeting the
           goal. If you can set one thing to polar-orientation I
           think you've met your goal. But if you have to set each
           element you might as well use rotation.
  Florian: Maybe we're missing a value or two, like an auto that
           just handles the facing center. If the list of values
           explodes, maybe it's not practical.

  glazou: It seems there's consensus on the call and IRC that this
          as a new property isn't a good idea, but a new value for
          rotation is maybe the best thing.

  smfr: One question is does it effect layout?
  Florian: On the example everything is rounded. But if you stop
           rounding and have corners, if you rotate that changes
           what the polar distance has to be to avoid overflow. If
           we're doing 100% with the value that makes it not
           overflow then...
  dbaron: Isn't polar positioning like abspos where it doesn't
          effect layout outside?
  jihyerish: Yes.
  Florian: When you stack to one side the 100% value, like left 0 in
           abspos, it puts you against the edge. If you rotate that
           changes where you put it if you want to avoid overflow.
           Am I making sense?
  jihyerish: Yes.
  Florian: So I think not being in rotate and being a separate
           property makes sense for that.
  fantasai: You'd want to have them evenly positioned outwards by
            the centers because otherwise it looks uneven. You want
            the centers even, not the furthest edge. So I'm not sure
            I buy that.
  Florian: Distribution, yes.
  Florian: But I don't know. I'm not sure.
  <bradk> On the list, there was a better way to avoid overflow,
          which would make it not an issue here.

  fantasai: I would say this is a case for using rotate and if we
            want to add keywords to rotate to make this easier, I
            don't see a problem. But two properties that control the
            same thing is always a problem. If we want layout
            effecting transforms that's separate.
  Florian: This is separate. The way this would effect layout is
           changing how percentages resolve in polar distance.
           That's not the usual way of talking about layout
           effecting transforms.
  fantasai: I'll go with the if we need layout effecting transforms,
            we make them, and not having this minor thing that does

  jihyerish: Then you think the polar orientation is not useful
             enough to be a new property?
  fantasai: It's not about usefulness, it's about having something
            solving one specific case and having a general property
            that solves the same case. We shouldn't have this
            special switch that does the same thing. If we need
            additional keywords to make calculations easier, we can
            do that. it's not good to have two properties control
            same effect.
  jihyerish: Okay, I got it.

  Florian: One other thing I'd like as an issue is maybe we need
           more keywords. Specifically keywords that automatically
           switch between center and counter-center depending on
           which half of the circle you're on. I don't know how many
           variants, but I'd like an issue that says we need some
  jihyerish: I'll make that as an issue and think about it.

  glazou: Anything else on this while you're on the call?
  jihyerish: It's done.
  glazou: Thank you very much.

Writing Modes

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015OctDec/0039.html
  koji: The mail is from fantasai, but we think all the open issues
        are resolved and edits are done.
  koji: fantasai solved the last issue in SVG WG telecon. We want to
        publish an updated Writing Modes CR.
  Florian: Sounds good to me. We had a bunch of issues, we fixed them.
  Florian: Small note, your bikeshed icon is red, so you should fix
  koji: You're right. I sent an e-mail to TabAtkins, but have to

  glazou: I'm in favor of CR.
  glazou: Other opinions?
  <Florian> +1
  <Bert> +1 to CR
  glazou: Objections?

  RESOLVED: Publish CR for Writing Modes

  koji: Thank you.
  fantasai: Cool.

word-break: break-all

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Oct/0124.html
  koji: This is about word-break: break-all. This value was
        originally proposed by Microsoft to allow Korean typographic
  koji: fantasai and I thought allowing breaks only between letters
        works good. Blink included that and feedback from dev is it
        was widely used in CJK and people want to break between
  koji: I tested and Firefox and Webkit breaks anywhere. IE doesn't
        break before closing parenthesis and the like. I'm in favor
        of following IE behavior.

  Florian: So, as was said in the mailing list, the fact that IE
           doesn't break before opening and closing parenthesis is
           handled by the spec. Maybe that we use 'letter' in the
           spec it doesn't allow breaking in the middle of a run of
           punctuation, like ***. I think we should allow breaking
           in the middle if it's not already allowed.
  koji: The difficulty is what you pointed out. Since we don't
        define line breaking rules exactly, our choice when we wrote
        it was allowing only between letters can avoid breaking
        before closing parenthesis.
  fantasai: We an easily update the spec by, instead of saying
            'letters', saying characters with unicode line breaking
            collapse of AI, AL, H2, H3, HL, ID.
  fantasai: The unicode line break spec seems to handle a lot of
            these. The * is handled. I think they went through and
            put everything under other characters as break between.
            Other classes would continue to behave as they do
  fantasai: [missed]
  <fantasai> http://unicode.org/reports/tr14/#Table1
  <fantasai> Proposal to switch restriction from "allow breaks
             between letters" to "allow breaks between characters
             from Numeric Context / Other Characters"
  <fantasai> (roughly, might need to tweak for IS class)
  <fantasai> (and RI class)
  Florian: I can't verify that your list is correct, but the intent
           is right and I trust you on the list.

  koji: We have two choices. Add more line breaking places or say
        places you shouldn't break.
  Florian: I think shouldn't is handled via line-break: auto. We may
           want to add a note to that value saying something like
           restrictions should vary depending on language and are
           important on some languages which don't use spaces as
           separators. It's allowed by spec, but that might not be
           clear enough.
  Florian: For, me it's just a clarification. We have that the UA
           should determine where it's not allowed. If the UA didn't
           take into account requirements, that's their fault. We
           shouldn't define where it's forbidden...it varies by
           language and even in a single language there's variation.
           But reminding the UA they need to care is useful.
  koji: I'm not strongly against...line-break is switching between
        levels, but it doesn't define basic levels. Second, I don't
        think it's so controversial, breaking before a closing
        period. it's not language specific. My understanding of
        line-break: auto is break as much as possible unless it's
        really bad.

  <dbaron> maybe we should have this discussion next week when we
           have better audio?
  <tantek> agreed with dbaron
  <tantek> also, debating line-breaking would be assisted by visual
  <tantek> in-person

  fantasai: I think what we should do is look at the line breaking
            classes and tailor them for word break. There's two
            classes, ones by line-break and ones by word-break. I
            think the only one in between is the small kana. The one
            in the spec dealing with just letters is incorrect, but
            UAX14 does that correctly. I think that will effectively
            solve the problem.
  koji: Okay.
  Florian: I think we can give it a shot. I'm still a bit hesitant.
  koji: Maybe fantasai and I work on the direction and come up with
        proposed text.
  Florian: Let's do that and see where it takes us.
  koji: I think I'm okay with this.

TR Stylesheet for W3C

  glazou: If there's nothing else, we exhausted the agenda. Anything
  fantasai: Yeah.
  fantasai: There was, there's a message on the survey about redoing
            the TR stylesheets. I haven't gotten any response from
            the WG.
  <fantasai> https://www.w3.org/wiki/SpecProd/Restyle/Survey
  fantasai: Are the chairs against having us answer, or is that
            something we should do?
  glazou: I'm leaving it to the new chairs. I didn't have a chance
          to look at it.
  fantasai: The deadline for the survey was a month and a half ago.
            I need to have the stylesheet done by TPAC for it to do
            anything, so it's a bit tough that we left it to when I
            need feedback.

  glazou: From a personal prospective, I trust you to do the right
          thing. Personally I don't think we need to spend
          conference call or mailing list time. Is there any
          objection or is anyone willing to review the stylesheet so
          we can come up with a WG decision?
  Florian: I trust fantasai
  fantasai: I'll do the best I can, but if you can tell me things
            that need to be fixed that's also helpful.
  glazou: No one objects. Let's record that it's a go ahead to
          fantasai and we'll ping you later if there's something. Is
          that okay for you fantasai?
  fantasai: I'd like the WG to answer the questions about what they
            do and don't like on the TR stylesheets. I'm sure people
            have opinions and I can't account for them.

  Bert: Question for fantasai. If I remember correctly the survey,
        the things you proposed are things we already do in our
  fantasai: Yeah. I do have more leeway since I'm doing it for the
            entire W3C. If there's things we don't do because it's
            too different from W3C, we have the opportunity to
            change it.
  fantasai: What are things we can do with CSS without changing the
            markup that we'd want W3C wide.
  fantasai: I will be merging in the CSSWG stylesheet, but since I'm
            changing the entire stylesheet site-wide, things that
            would make us inconsistent are now on the table.
  <gregwhitworth> I personally love the CSSWG specs, the centering
                  of the text, a lot of white space, good contrast
                  and spacing.
  Florian: I don't have a objection or desire for changing things
           beyond what we do. I don't have a request for a change
           beyond what the WG is using. I'll review something if you
  fantasai: It's fine if the WG has zero input, but it would have
            been nice to know that a while ago. If there's nothing
            to be said that's fine with me.
  fantasai: If no one has any opinions on styling, we can say CSSWG
            has no feedback.
  Florian: Our feedback is we prefer what we use over what's on TR
           and we support moves in that direction. Feedback beyond
           that we don't have.
  <fantasai> sgtm
  Florian: Does my last sentence on IRC sound good as a WG position,
           or is it just me?
  <gregwhitworth> I agree
  <koji> agree
  glazou: I tend to agree with that.
  <Bert> (I don't want the maximum line length, you know that
         already; but otherwise fine.)
  <fantasai> Yeah, that's a controversial one. I've got a handful of
             people who don't want it and a bunch who do

  glazou: I guess we won't push further on that since we can't hear
          fantasai. Let's do that and move one.

Status of Unpublished Specs

  glazou: There's still 12 minutes left
  <fantasai> glazou, status of css-variables?
  <fantasai> and will-change?
  <fantasai> Also, http://www.w3.org/TR/css-cascade-4/ to CR
  glazou: Status of css-variables and will-change.
  glazou: There was an implementation in Webkit a few days ago, but
          I guess this is part of a large topic. That is....for a
          lot of our documents the TR document is older than 6
          months or the ED is older. We have a lot of documents that
          need to republish or give a clearer status.

  fantasai: I'm concerned with these two.
  glazou: Even if you're concerned with these specs only, it's a
          wider issue. A lot of documents are ready for a new
          publication and we need to discuss what to do with all of
  glazou: I'm guessing you want publication for those two?
  fantasai: I don't. I want to know who is holding the ball. Why is
            it not published as CR because it has been many, many
            months. We have outstanding resolutions to publish these.
            They were supposed to transition and they're not there.
  Bert: It must be ChrisL or me. I don't remember which.
  Florian: Or would it be TabAtkins?

  <tantek> can we document how long it is taking from resolution to
           publish CR to actual publication as CR?
  <tantek> I would like to report this information to the AB
  <tantek> seems like there are too many humans in the loop
  <fantasai> css-variables is approaching 1 year
  <tantek> and I want to cut this process down
  <fantasai> and the problem there is people forgetting they need to
             do stuff
  <tantek> month+ between resolution CR -> TR CR is unacceptable
  <tantek> and an embarrassment to W3C
  <tantek> let me help fix this
  <tantek> help me help you
  <tantek> specifically the resolution -> TR time gap
  <fantasai> tantek, they were held up on edits from Tab at some
             point, and then I don't know whether they're held up on
             him now or W3C staff

  glazou: This is something we'll solve F2F at TPAC. There's a
          moratorium anyway, so what we decide won't get the
          documents published in the next few days.
  glazou: There's nothing more we can do now.
  glazou: I agree tantek, but stuff happens from time to time. Some
          documents went under the radar for 8-10 years. It's bad
          for everyone.
  <tantek> under the radar is a different problem

  glazou: Anything else for today?

  <TabAtkins> No, I got all my edits in, and pinged Chris about them.
  <fantasai> TabAtkins: will-change and variables both?
  <TabAtkins> Yeah
  <Bert> Yes. I'll see which documents are in the queue and check
         with Chris.
  <fantasai> Thanks, Bert.
  <fantasai> I suspect it's just fallen off his radar

Cascade 4

  fantasai: Cascade 4 to CR? There were no comments.
  glazou: Okay. Comments from people? What do you think?
  <tantek> +1
  <astearns> +1
  tantek: If there's no outstanding issues, make it CR.
  glazou: Objections?
  Florian: I agree

  RESOLVED: Publish Cascade 4 as CR

  <fantasai> Bert, can you help Chris with the transition? (see above)


  glazou: Nothing else?
  glazou: I wish you all a safe trip to Japan.
  <tantek> see you all Tuesday morning
  <tantek> I will be missing the first day (Monday)

  glazou: This is my last call so you won't hear me too often.
  <gregwhitworth> THANKS FOR ALL OF YOUR HELP glazou and plinss

  glazou: Let's meet on Monday and for those going to attend the
          Japanese Industry on Sunday, I'll see you there. We're
          missing a few details on that. I got an e-mail on that
          since there's no sign of life from the organizer. I'll try
          and reach them before noon Sunday it will mean the meetup
          is canceled or there's no info.
  Florian: I'm meeting with organizers tomorrow, so I don't think
           this will be canceled. I'll push for more details.
  glazou: They need to send a message to this WG, all the chairs
          (glazou, plinss, astearns, and rossen), and Marie-Claire
          because she wants to share the info and cannot.
  glazou: Safe trip everyone and I'll see you on Monday.
  <Florian> thanks
Received on Thursday, 22 October 2015 11:02:06 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:54 UTC