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

[CSSWG] Minutes Telecon 2015-07-01

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 2 Jul 2015 06:30:22 -0400
Message-ID: <CADhPm3t6TJbUN4HrJ+bVGieHFbmEO8gRoWcsoT5orEQm=q5TeQ@mail.gmail.com>
To: www-style@w3.org

  - Gecko now also has plans to ship some of css-logical-properties.
  - Mozilla clarified the pieces they'll be shipping.

fixed z-index interop issue

  - RESOLVED: Make position: fixed a full stacking context
  - Rossen will write the text change in place it in the Positioning
      spec. Bert will then take the same text and add it as an
      errata to CSS 2.

Aggregating CSS modules

  - The ability to create a big document listing all the modules is
      on the bikeshed issues list and therefore will happen at some

Language specific support for hyphenation and justification

  - Everyone agreed that there was a use case for this and that
      there are definitely times where you may want to style
      differently depending on if you can hyphenate text.
  - There were concerns about the performance implications of
      checking for hyphenation support, but most group members
      believed there would be no significant change in performance.
  - It was concluded that, though there are use cases, it wasn't a
      high enough priority for implementation. Florian will keep the
      text in case the priorities change in the future.


  - There were two primary issues raised for underlines in
      1. Do we allow auto to combine with left|right
      2. If left | right is specified alone, is the behavior in
          horizontal text under or auto
  - The proposed syntax seemed okay to everyone, but is dependent on
      the final solution to the above questions.
  - No consensus was reached and discussion will continue on the
      mailing list.

Splitting CSS-speech

  - There was some doubt as to if there would be any interest in
      CSS-speech, even if it is cut down to just speak and speak-as
      in the first draft.
  - glazou will be reaching out to get more context to if it's even
      possible to break out speak and speak-as.

Display WD

  - RESOLVED: New WD for Display

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

  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Bo Campbell
  Tantek Çelik
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Koji Ishii
  Dael Jackson
  Chris Lilley
  Peter Linss
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Anton Stearns
  Lea Verou
  Greg Whitworth

  Sonja Bonic
  Tony Graham
  Brad Kemper
  Michael Miller

  scribe: dael


  glazou: Let's try to start
  glazou: There were a few additions. I saw a message from Florian
          about the backlog and one from Koji.
  SimonSapin: I had one. Gecko is intending to ship
              css-logical-properties which isn't a WD yet, it's full
              of issues.
  glazou: And you'll ship the full of issues?
  SimonSapin: I'm not sure exactly what.
  Florian: Unprefixed?
  <SimonSapin> https://groups.google.com/d/msg/mozilla.dev.platform/zQgw_4WeBkc/oyVZ5-k1D6cJ
  fantasai: If any issues are on www-style with Mozilla's proposed
            resolution somewhere it's good to have that. Otherwise
            I'll get around to connecting everything later.

  glazou: Was that a question or an announcement?
  SimonSapin: I wanted to bring to the group's attention. I don't
              know if it's a problem to ship early.
  dbaron: The pieces we're planning on shipping aren't the pieces
          with the problems. We're not shipping the shorthand on
          logical. I think we're shipping margin-padding, border-*
          and one other, I think.
  glazou: Behind a flag?
  dbaron: No. Only longhands.
  dbaron: It's been behind a flag for a year.

  Florian: If you want to ship, why not help finish the spec first
           to be sure things won't break. I think that's what we
           generally said we'd be doing.
  dbaron: Fundamentally because we're the last browser to ship this,
          i.e. vertical text support, and shipping it depends on
          logical properties for us.
  dbaron: And we'd really like to get it shipped.
  glazou: We're not going to do this right discussion right now.
          Thanks for the announcement. I suggest discussing the
          future of the spec on the ML.
  glazou: Anything else before we really start?

  <dbaron> the logical props we have are margin-*, border-*,
           padding-*, top/right/bottom/left, (min-/max-/)width/height
  * fantasai will try to set aside some time to finish up the fpwd,
             has a couple things higher in the queue

fixed z-index interop issue

  gregwhitworth: Is dbaron there?
  dbaron: Yes.
  gregwhitworth: We've been pushing this off a bit. Blink, Webkit
                 and Edge basically give anything with z-index its
                 own layer but the spec says it should work like
                 abspos and not get a new layer. We want to change
                 the spec so that it represents the reality of the
                 other browsers. Marco has been seeing issue in
  gregwhitworth: I want to get your input and see if you're against
  smfr: You mean position: fixed getting a stacking context?
  gregwhitworth: position: fixed, not z-index, thank you.

  dbaron: I think I'm okay with it.
  Rossen: It's worth mentioning that I had...when we pushed this
          early in Edge development phases I added this behind a
          flag to see if anyone complains. We didn't hear any but we
          do know of a number of pages that will be broken when the
          opposite is broken,; when fixed position don't create
  Rossen: The interesting bit of information is during Sydney F2F
          someone from Chrome, I think Rick Byers, said they want to
          revert and support a partial context on z-index. I'm okay
          either way, with our implementation both are possible, but
          I'd prefer to lock on one of those.
  Rossen: If anyone from Chrome can comment that would be great.
  TabAtkins: I can ask, but I think it's that our recent
             improvements make it possible to go back to partial. I
             don't think there's anything wrong with full stacking
  smfr: I'd prefer we maintain a full stacking. Our painting can't
        deal with interweaving.
  Rossen: So if we decide to support partial, you won't be able to
          for technical reasons.
  smfr: We've been shipping with fixed for 2 years so going back
        would be a compat risk for us.

  smfr: So it sounds like we're back to the question as to if Gecko
        will make position: fixed create a stacking context.
  dbaron: I think it's fine given that it's for compat.

  Florian: As an author I think this is sufficiently confusing and
           having the semi-stacking makes it worse. If we can avoid
           that, it's better.
  gregwhitworth: So can we resolve on this? I don't know if we put
                 it in 2.2 or what, but can we call for resolution?
  glazou: If everyone agrees to implement it the same thing we can

  Rossen: I missed it, my connection dropped. Did we resolved to
          make position: fixed a full stacking context, always?
  Florian: We seemed to be about to.
  gregwhitworth: It seems there's no disagreement. dbaron is saying
                 it's okay. If no one is against it I say we resolve.

  Rossen: The only reason I brought it up is there was the
          implementation consideration from Chrome and I don't want
          to have the same conversation in 6 months with the
          opposite argument.
  TabAtkins: There's nothing technical making stacking context hard.
             There's something technical with making partial hard,
             but full isn't a technical issue. I think we'll be fine.
  Rossen: Sounds great. So we can resolve on it and that's it.

  glazou: Objections?
  smfr: Clarification: If a position: fixed element has a
        transformed ancestor and it doesn't behave in a fixed way,
        does this apply?
  smfr: I want to clarify if it's the position: fixed itself or
        having the containing block be the view port.
  TabAtkins: I think it's just position: fixed.
  smfr: Okay, that's fine.
  Rossen: That sounds really good. Tying it down is better than
          looking up ancestry.

  RESOLVED: Make position: fixed a full stacking context

  gregwhitworth: So how does this make it into the spec?
  Rossen: I can add it to Position level 3.
  fantasai: It needs to go into level 2. We should action Bert to
  <Bert> (Is it just a clarification?)
  antonp: Isn't this already in level 2?
  Rossen: I'm not sure why you think that's the case, but it's not
  fantasai: In 2.1 position: fixed is considered a stuck category of
  antonp: I think I'm thinking of something else. I think I'm wrong.
          I'll write to the list if I correct myself, but I think
          I'm wrong.

  Bert: For CSS 2 does it need a change?
  Rossen: I think there's agreement you have to have a note in
          CSS 2.2. That was fantasai's argument and I don't have an
          opinion. I will add the requirement to CSS 3 positioning.
  fantasai: It needs to go into both.

  ACTION Rossen add position: fixed as s full stacking context to
  <trackbot> Created ACTION-698

  Bert: I can look at Rossen's text and create an errata
  Rossen: It'll be one sentence and we can use it in both.

  ACTION Bert to take Rossen's text and export it to level 2
  <trackbot> Created ACTION-699

  <rbyers> Rossen: IIRC it was vollick who said he felt guilty about
           us insisting on a full stacking context for
           position:fixed now that our implementation no longer
           requires it.  I.e. we recognized a fundamental flaw in
           WebKit/blink compositing architecture (that causes
           correctness issues elsewhere) and are close to finally
           eliminating it.

Aggregating CSS modules

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0160.html
  glazou: We started the discussion, but I'm not sure we went far.
  astearns: I started it to prod plinss and TabAtkins.
  TabAtkins: We keep being lazy about creating the index of all
             things in CSS. Altering bikeshed so that it can make a
             huge document is something I haven't done. I've been
             doing bikeshed issues for a bit and I might get there.
  Rossen: SVG has been asking for the same thing. They've been
          waiting for this so they can switch to bikeshed.
  TabAtkins: It'll be on my list. I think I have it as an issue.

Language specific support for hyphenation and justification

  Florian: This is something I was wondering about. We have
           @supports, but it doesn't quite work for hyphenation
           because when the browser impl hyphenation it doesn't do
           it for all the languages in the world.
  Florian: If you think something is ugly without hyphenation, you
           need to know if it supports hyphenation on the language
           you're using for the element, to decide if you want to
           use narrow columns or justification for example.
  Florian: I'm not saying that's always enough to give nice
           hyphenation, but it's a datapoint that's useful. I was
           thinking we might want to introduce either a special
           syntax in @supports or a pseudo class that you can tag
           onto any element.
  Florian: Based on the language the element uses, if it's one the
           browser can hyphenate then the class matches and you
           use that to style.

  Florian: A second part is if you want to turn on justification but
           only if the browser can do it nicely, which might mean
           hyphens for some languages, but not all. Trying to detect
           it sounds useful, but it's hard to tell what 'nice' means.
  Florian: I think they hyphenation case is less fuzzy. 'If it's
           supported' is non-ambiguous.
  TabAtkins: I agree that multiple ambiguous hints aren't something
             we want. The hyphenation is unambiguous. It sounds
             reasonable and I see the use case.
  * fantasai is unsure this is that important to solve atm
  * fantasai is therefore unsure it's worth the work/complexity to

  Florian: The difference between the syntaxes is if you're using
           @supports you can inside that have any number of rules
           and combine. What's nicer with a pseudo class, in
           @supports you have to ask about one language specifically.
  Florian: That makes me lean toward the pseudo class. You have
           multiple declarations, just on a rule block.
  TabAtkins: This is classically a MQ type thing. That seems to be
             more natural, but I have to think on it.

  astearns: I'm not entirely sure that's enough justification for
            this new feature. If a UA doesn't support a language for
            hyphenation, maybe that's a bug. As UA gets more
            sophisticated the need diminishes.
  Florian: I doubt we'll reach a point where all UA support hyphens
           for all languages. It's too large a set, almost infinite.
  astearns: So you're talking about a stylesheet for near infinite
  Florian: If you're creating something where you expect a lang tag
           and you want to go with a different layout depending on
           what's supported, we should be able to do that. There
           won't be a browser that knows all local languages.
  <dbaron> https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens#Notes_on_supported_languages_2

  Rossen: I'm a bit hesitant for a feature like this. When we were
          adding conditional language abilities for windows apps, we
          had similar problems where content written for RTL
          languages or hosted in RTL it needed to adapt properly so
          on/off buttons are right. Hyphenation in that respect, I
          don't see as an outlier in language-specific behavior.
  Rossen: It's also a minor use case. Making such a huge exception
          for a minor feature is a stretch.
  Rossen: The fallback here isn't really that bad. The third thing I
          wanted to point out, we have a service that we use which
          is shared across many components. Simply booting the
          service is quite costly so doing it per element is crazy.
  glazou: Doing this on a per element basis, as soon as you have the
          info for a given language you can cache. You don't
          hyphenate differently between elements. As soon as the
          info is acquired you have it for the whole session.
  Rossen: Does that go for mixed language?
  glazou: This is related to my question. Florian mentioned the
          pseudo class, but does it take an argument?
  Florian: It matches the language of the element. No argument.
  glazou: I don't see the problem. In 99.9% of cases the language
          will be the same.
  Florian: And if you have a bunch of languages this isn't more
           costly. If we didn't have it you would apply hyphens and
           have to turn on the engine anyway.
  glazou: I understand the performance concern, but we should stick
          to the usefulness of the feature. There's an issue there.

  Florian: I don't think it's majorly useful, but the same is true
           of hyphenation. Hyphenation itself is more difficult to
           use if you can't know if you have it. You can't use
           @supports, so you're stuck right now.
  Florian: Narrow columns without hyphenation can be ugly so it's
  TabAtkins: There are layout types you only want with hyphenation.
  Florian: And you only want this if you have a language that
           doesn't need hyphenation or if you can have hyphenation.
           We can have the browser tag if it doesn't need it.

  glazou: So the official French typographic rules, which we've used
          in the past, I've seen some prose about not using
          hyphenation in that case. But the use case exists.
  Florian: You mean not using justification if there's not
  glazou: Yes.
  Rossen: Can you find a reference to that?
  glazou: Yes, it's at home, but I will.
  glazou: I'm not so sure the cost of implementation for this is
          expensive, I think it's straight forward. It could solve a
          case in some languages for layout. I feel, personally,
          that we should investigate.
  glazou: What do others think?

  Rossen: From implementor's POV this will be low on the stack. I
          can see the completeness argument from Florian. If there
          are use cases that can hit somewhere...but cost to benefit
          is off.
  fantasai: I agree with Rossen.
  glazou: Other implementors?
  <dbaron> I don't have a strong opinion either way.
  TabAtkins: I'm not able to speak on this now.
  smfr: I'm not aware we've had any requests on this so I think it's
        low priority.

  glazou: Florian would you keep some prose under the radar for now?
  Florian: Yes, I can see how it's not high priority, even though
           it's not wrong. I'll keep the text.


  <glazou> https://lists.w3.org/Archives/Public/www-style/2015May/0153.html
  fantasai: Currently we have an auto value and an under value and a
            right value.
  fantasai: If we look at the spec [link]...
  <fantasai> http://dev.w3.org/csswg/css-text-decor-3/#text-underline-position-property
  fantasai: You can combine under with left or right so you can have
            different behavior from vertical and left and right. The
            feedback we got was that we want to have...there's a
            suggestion the UA stylesheet should have a rule that
            sets the underline to the correct side for Chinese and
  fantasai: That's in the spec as a recommendation. But because you
            can only combine right with under it causes a problem.
            The suggestion is to let auto and under both be combined
            with left or right.
  <dbaron> Japanese and Korean on right, Chinese on left, no?
  fantasai: dbaron is correct

  <Bert> (Maybe there is way to generalize this: provide alternative
         styles based on whether each of them can deliver a certain
         quality, where "quality" can be an aggregate or a set of
         detailed typographic measurements...)

  koji: I'm not clear about what the semantics is.
  koji: I'm unclear about how to interpret another value.
  fantasai: That is another issue. If left or right is specified
            without the other keyword, what do we do?
  koji: Or if under is specified, is it left or right?
  fantasai: It's just going to be left.
  Rossen: And under start won't work?
  fantasai: It has less to do with start and end of block and more
            with text orientation. For example, Mongolian, the
            underline will be on the right side, even if it's the
            end side.
  fantasai: It's the end side on CJK. under if you specify it by
            itself, it means it goes on that side of the text. left
            and right give a direction, either the left or right

  Rossen: In that case, I'm okay with auto. It's magic enough for
          people to get it from the get go. It's better off to be
          left as magic.
  glazou: Other opinions?
  glazou: Any disagreement? Objection?
  koji: I'm okay with the syntax, but from the original proposal I
        can't read what they're expectation is for some of the
        values. I want to confirm that they think it means.

  fantasai: There's two issues. [types]
  <fantasai> 1. Do we allow auto to combine with left|right
  <fantasai> 2. If left | right is specified alone, is the behavior
             in horizontal text under or auto
  fantasai: I'm guessing it should be auto since that's the initial
  koji: Does that imply when under is specified left or right is
  fantasai: Under has a meaning that isn't left or right, it means
            it's on the underside which depends on the text
  fantasai: Most cases it will be left, but in sideways-left it
            would be right.
  koji: Japanese is right.
  fantasai: Yes.

  Rossen: When is left and right used when auto does it when it's
  fantasai: It doesn't.
  koji: auto applies only for horizontal, I think is what she's
  fantasai: We discussed having auto adjust based on the language
            and we decided not to have it change based on the
  fantasai: Let's all look at the word alphabetic in the spec.
  fantasai: There's a p and the line crosses the tail. That side of
            the text is the underside. If we rotate the text 90
            counterclockwise, the underline is on the right side.
            clockwise it's on the left.
  fantasai: Auto puts the underline on the side of the text that's
            the bottom after you rotate the text. Since Japanese and
            Korean have their typesetting rule place it on the right
            side of the text, we added a UA rule that says for those
            two languages change the value so that in vertical text
            it is on the right side.
  koji: We allow auto to adjust between CJK and non-CJK for
        horizontal. I also requested not to have UA stylesheets
        request what you want. Like that you said in the mailing

  glazou: Among the two people discussing, I'm not seeing consensus.
          I don't know what to do with your discussion now.
  koji: I think we can resolve syntax now. We can continue the
        semantics discussion on the ML.
  glazou: fantasai?
  fantasai: I think that that's fine.
  Rossen: Is the ML discussion happening?

  fantasai: One thing that's confusing is if we change the meaning
            of auto to switch sides, not just adjust the position.
            It doesn't flip to the other side of the text, it's
            always on the under side of the text. If we change auto
            to also place on the over side it doesn't make sense to
            combine it anymore.
  koji: I asked for clarification yesterday on the list. Maybe it's
        worth waiting a bit more to see if the discussion continues.
  glazou: Okay. Done deal.

  koji: We can resolve the syntax change.
  fantasai: I think if we're changing the semantics of auto, we may
            want to rethink the syntax.
  koji: Okay.

Splitting CSS-speech

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0347.html
  fantasai: I was thinking speak and speak-as are something we would
            encourage general authors to us since it lets them
            control is some text is visible to speech. There's
            examples such as websites will position stuff off to the
            weeds so that it's there for speech but you don't want
            it for visual people. speak could override that so you
            do display: none and speak: normal and it overrides it.
  fantasai: That seems like it would be generally useful and be
            implementable without much interaction with the speech
            rendering. It seems like that might be useful for
            general authors, while styling the voice-rate and other
            things in CSS speech, they're interesting, but it's
            unlikely authors will take advantage of them in a useful

  <tantek> Big question here is who are the implementers that have
           any interest at all?
  <tantek> Without indication of even a hint of implementer interest
           I'd say it's too low a priority to bother with group time
  <tantek> Even *interest* nevermind code.
  <bkardell_> what agent supports css-speech?
  smfr: I think tantek is making a useful point that there's such
        little impl it might not be worth talking about.
  fantasai: I don't think there's interest in the rest of
            css-speech, but I think speak and speak-as will be
  <tantek> If even a single implementer speakers up indicating
           interest in impl, then let's re-assess
  fantasai: And might be interesting to implementers, if they were
            not buried in the rest of speech
  <bkardell> it seems to me leonie watson recently told me she
             couldn't find any if that is worth anything

  glazou: I'm not sure we're the best place to know about special
          application tools. I suggest pinging Daniel Weck. He was
          the author and will know about where it's used.
  glazou: I'd like him contacted before we move on.
  <bkardell> glazou: I can bring it up in a11y task force if that is
  <tantek> Otherwise not worth the time. But agreed with glazou - ok
           to ask around.
  bcampbell: I'd be interested in understanding this further and
             getting opinions from screen reader users.

  glazou: fantasai do you want me to take an action to contact?
  fantasai: I'm mostly interested in what the browsers are doing
            right now. It seems it would be useful for a11y.

  ACTION glazou contact Daniel Weck to see if there's any evolution
         on speak and speak-as so we can see if we can extract it.
  <trackbot> Created ACTION-700

  <tantek> Documentation of those use cases would be a good start.
  <tantek> That fantasai mentioned
  <fantasai> tantek, look on the web for text-indent:
  <tantek> fantasai, big neg text-indent is a hack for all kinds of
           crap.  SEO nonsense etc.
  <fantasai> tantek: ok, on a page that isn't doing SEO crap :)
  <tantek> Lol

Display WD

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jun/0346.html
  glazou: There was issues and a publication request.
  TabAtkins: We only have two minutes left.
  fantasai: I suggest we publish and deal with issues later.
  glazou: Objections?
  <ChrisL> yes!
  <ChrisL> +1 to publish

  RESOLVED: New WD for Display

  glazou: Thanks everyone. Sorry if the first day of webex wasn't
Received on Thursday, 2 July 2015 10:31:25 UTC

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