W3C home > Mailing lists > Public > www-style@w3.org > February 2017

[CSSWG] Minutes Telecon 2017-02-15 [css-timing] [css-text-decor] [css-speech] [css-grid] [css-cascade]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 15 Feb 2017 20:31:49 -0500
Message-ID: <CADhPm3vLM=ARwQatX9eTCdRBQk58tu8Z47yu4hPWXa4fghE6nw@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Request to publish FPWD of CSS Timing Functions

  - RESOLVED: Publish FPWD of CSS Timing Functions.
  - The short name will be css-timing.

A new property for text decorations to skip ink

  - RESOLVED: Use text-decoration-skip-ink with at least values of
              auto and none and have it cascade separate from
              shorthand. We will have some normative text describe
              how auto works, but we'll figure the details out in
              the future. Do this in L4.

Create a display property value for visually hiding an element while
    making it available for AT

  - RESOLVED: Republish CSS Speech CR.

Stretching image grid items in both dimensions

  - RESOLVED: The sentence beginning with "Items without an
              intrinsic ratio use," is what we as a WG wanted to use.
  - RESOLVED: Replaced elements with only one intrinsic size are
              sized as start in that dimension and stretch in the

Path to PR with CSS Cascade

  - RESOLVED: Drop scoped styles from current level of CSS Cascade.
  - There was a request to add tests to the Cascade test suite to
      help the spec get to PR.


Agenda: https://lists.w3.org/Archives/Public/www-style/2017Feb/0067.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  Dave Cramer
  Alex Critchfield
  Simon Fraser
  Tony Graham
  Koji Ishii
  Dael Jackson
  Philippe Le Hégaret
  Vladimir Levantovsky
  Chris Lilley
  Myles Maxfield
  Thierry Michel
  Michael Miller
  Rachel Nabors
  Simon Pieters
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth

  Brian Birtles
  Bert Bos
  Tantek Çelik
  Steve Zilles

Scribe: dael

A new property for text decorations to skip ink

  astearns: We have plenty of people on the call.
  <astearns> https://github.com/w3c/csswg-drafts/issues/962
  myles: Is koji on?
  myles: If he's not on we shouldn't discuss.
  Rossen: People trickling in.

Request to publish FPWD of CSS Timing Functions

  <astearns> https://lists.w3.org/Archives/Public/www-style/2017Feb/0044.html
  astearns: That is something we had decided to do, but birtles is
            now ready to prep FPWD. Does anyone have any comment?
  <ChrisL> +1 to publication
  ??: Yes, please
  <fantasai> I think it would be good to also get corresponding
             updates to Animations and Transitions onto /TR
  <fantasai> Otherwise in favor
  <fantasai> Last Transitions draft is from 2013
  <fantasai> Last Animations draft is from 2013
  <fantasai> These are wayyy out of date :(
  <Rossen> fantasai, yup...

  Rossen: That's the timing functionality that was taken out of web
  astearns: That and frames.
  Rossen: Let's do it.

  astearns: Objections?
  smfr: Does this effect transitions and animations in that it
        removes text?
  ChrisL: I don't think so.
  TabAtkins: In a later publication we should probably remove them,
             but it doesn't have an immediate effect.
  astearns: And according to birtles it's just frames and he talks
            about new timings functions, not so much what's in
            transitions and animations.
  astearns: Again, objections?

  RESOLVED: Publish FPWD of CSS Timing Functions

  astearns: Should short name be css-timing or css-timing-functions
  lots: Timing, please
  astearns: Great. Short name is css-timing
  Florian: When doing FPWD and we resolve on a different short name
           than the ED what's the procedure for renaming in the
           short name?
  astearns: If it was just on draft server the short name was
            provisional. It's only fixed on FPWD.
  Florian: But there are incoming links.
  TabAtkins: We have redirecting if needed in the htaccess file.
  <fantasai> Florian, yes, inform plinss
  <fantasai> We used to have a .htaccess file
  <fantasai> We don't anymore
  <fantasai> TabAtkins, ^^^^^
  <fantasai> plinss is maintaining redirects in a different system
  TabAtkins: css-timing hasn't been reffed much but we can set it up.
  astearns: [reads fantasai]
  TabAtkins: Well, we still have a system.
  Florian: Okay, thank you!
  <fantasai> TabAtkins, yes, but it doesn't work by editing a file
             in the csswg-drafts repo...
  <fantasai> wish it did

A new property for text decorations to skip ink

  <astearns> https://github.com/w3c/csswg-drafts/issues/962
  koji: This is about the resolution to add text-decoration skip ink
        to L3.
  koji: This is a proposal. 2 discussion points. 1 is property name.
        Is text-decoration-skip-ink appropriate? Since we don't do
        text underline-skip would be better.
  koji: Other is about values. fantasai said auto|yes|no
  <fantasai> pretty sure she didn't say yes | no as keywords to
             use ...
  * fantasai agrees with the principle of what they do
  koji: If this is fine what auto should be is a discussion point.
  astearns: Let's go one at a time. Can we resolve on changing the

  Florian: Related is if it should be part of the L4 shorthand. If
           it is it should start with the same thing. If it's not we
           can be more creative.
  <fantasai> Should not be part of shorthand
  <fantasai> It should cascade independently
  koji: I'd prefer not to make short hand because this is styling
        decoration underlines.
  Rossen: I'm trying to understand...this proposed behavior is
          supposed to describe what webkit currently does for text
          decoration underline?
  myles: For skip ink yes
  Rossen: And you (myles) do this auto for text decoration underline?
  myles: I don't remember exactly.
  Rossen: Let's assume you're doing it at least for underline. Is it
          done unconditionally? There's no additional optional
  myles: Conditionally where you can turn it off. The initial value
         was changed to ink so users can use a value of off.
  Florian: But if it's on it's always on? auto or yes?
  myles: We do auto because we have special CJK behaviors were we
         turn on/off at a glyph level.
  Rossen: That sounds good.
  Rossen: Thank you.
  Rossen: Both skip and auto make sense in how you desc them.
  <fantasai> text-decoration-ink: skip | no-skip ?

  koji: Ink has same behavior in beta(?).
  myles: I don't have many preferences. I just have that the auto
         keyword to do what I described should not go away.
  koji: I agree. We're interested in opt out and opt in.
  Florian: Do we need all three or auto and don't skip?
  myles: Currently webkit it's impossible to skip on CJK.
  Rossen: But you can opt out of the auto with the non-skipping
  myles: Yes, you can opt out
  Florian: So you have 2 values. Do we want 2 or 3?
  myles: The reason we decided to never skip on CJK is because it
         looks terrible more or less always. But my preference isn't
  Rossen: We shouldn't make bad decisions easy.
  Florian: Adding a value later isn't hard
  astearns: We can do auto and no for now. If a need appears later
            to force it we can consider it them
  <Rossen> +1
  myles: I think that's a good idea.

  Florian: I think that helps with naming. In that case having
           text-decoration-skip: auto makes sense because it knows
           not to do line-through.
  Florian: That also depends on koji's point about no short hand. I
           didn't understand why.
  koji: I think you had an example that most of the other properties
        apply to a specific element but skip-ink applies to root
  Florian: mmm...okay
  astearns: And fantasai put in irc that they should cascade
            separately. I'm not sure the reason.

  astearns: I'm not hearing a strong desire to change the name to
  astearns: I think we should keep the name as text-decoration-skip.
  Florian: Even if not part of the short hand?
  fantasai: Behavior is a lot more like text underline position.
            You'll want to set it at a higher level for how you want
            to behave for the document. Turning on and off for the
            underline is separate. Thus they shouldn't be conflated.
  Florian: Then they shouldn't have same prefix.
  fantasai: Yeah, in general we try that but something is closely
            related will share a prefix and not be in the shorthand.
  astearns: I would prefer the same prefix so you don't have to
            remember a different word. And it's easy to remember
            difference because people will be using it differently.
  koji: We have text-emphasis where it's not in the short hand. I
        think if this should be in the short hand can be separate.
  Florian: It's intuitive enough.

  Florian: Can I suggest off instead of no?
  myles: None?
  Florian: That's fine too.

  Rossen: Can we summarize?
  Rossen: I've heard it's text-decoration-skip: auto|none
  <Florian> text-decoration-skip-ink: none | auto
  astearns: I think it's text-decoration-skip-ink
  koji: yes
  <fantasai> I'm provisionally OK with this. Need to think about
             integration with other text-decoration-skip values.
  <myles> ✅
  astearns: proposal: text-decoration-skip-ink: none | auto with
            auto as the default.
  Rossen: Reason to not remove ink?
  Florian: There's a level 4 that skips in other places. Ink is a
           sub case that's in level 3.
  Rossen: So...I see.
  <astearns> https://www.w3.org/TR/css-text-decor-3/#text-decoration-skip-property

  Florian: Should we define what auto does?
  myles: No. :)
  Florian: There has been discussion on github that auto shifts the
           baseline. I don't think it should do that.
  koji: That was a misunderstanding.
  myles: If we don't define auto UA can tweak.
  Florian: I'd rather UA not to use skipping for positioning.
  <fantasai> agreed
  Rossen: Aside from bikeshedding I think these are good things to
          agree on.

  astearns: Is text-decoration-skip-ink with values as none|auto
            with auto default...is anyone opposed?
  fantasai: It's okay to me. I'd like to think about how it
            integrates with other skipping, but it's fine for now.
            We should note that it's not in the shorthand.
  astearns: Yes, and I believe how it works with the rest is for the
            next level.
  dbaron: So that's saying that impl are expected to turn it on by
          default upon impl.
  dbaron: We're saying that there will be no way to opt into more
          skipping than default.
  Rossen: As of now, yes.
  astearns: For this level. We're doing the minimum to finish this
            level of text decoration. We'll add more later.
  dbaron: Okay.
  <dbaron> It feels a little odd to introduce it as a change in
           behavior rather than opting in to the different behavior
  Florian: As part of peopling auto to UI does that make it
           non-testable? Because then auto could be same as none.
  astearns: I would prefer having some suggestions that it SHOULD
            skip ink in roman but not Arabic.
  astearns: I'm not sure that the impl notes should be normative.
  Florian: If we don't we can go to rec with no impl.
  Florian: That doesn't sound helpful.
  myles: If there are non-normative or normative notes they
         shouldn't list every language. Maybe a couple of examples
         are valuable. Saying which language should and shouldn't
         shouldn't be in spec. I should say script, not language.
  dbaron: On the other hand then you're asking impl to figure it
          out. So 4 teams do it.
  myles: The teams can talk.
  astearns: I'm not sure any team has an exhaustive list.
  Florian: We can have a base case and exceptions.
  myles: We can say it's expected to skip in Latin and others are up
         to UA.
  Florian: Yes. Can that be a must?

  astearns: Objection to having a normative must on skipping ink in
            Latin cases?
  ChrisL: It's not an objection, but it comes across that this is
          the language we care about. I know that's not the
          intention but it sounds a bit awkward. I don't have a
          better suggestion.
  <fantasai> +1 to ChrisL
  ChrisL: I just have a slight concern. We could ask i18n for help.
  fantasai: It would make more sense to go the other way and say
            skip ink for everything except cases where you know you
            shouldn't. This is mostly on or mostly off. If we want
            to make an exception for if there's a case where you
            think it looks bad you can not do it. But it should
            clearly say if you don't know what to do you should
            define what to do
  dbaron: Saying do it is awkward for something that will be the
  dbaron: If it were an option dev turn on that's fine. But given
          that the default is skip ink we need to gather a list
          where it would look bad.
  <dbaron> Like, say, is skip-ink desirable for Kannada?
  <dbaron> or Malayalam?
  <fantasai> dbaron: I think it is desired for South Asian and
             Southeast Asian scripts. The ones I've investigated use
  <dbaron> fantasai, those in particular have different sorts of
           descenders, which is why they seem interesting (and
           different from many North Indian scripts)
  <fantasai> dbaron, http://scripts.sil.org/cms/sites/nrsi/media/LannaThai.png

  fantasai: I would prefer on and off and if you want to do it
            language dependent you can do it that way.
  Florian: It's glyph based.
  myles: We found it looks terrible in too many cases with untagged
  Rossen: The huge benefit is when it comes online and it just
          works. When I've seen it on Apple it was cool to see it.
          No authors had to do anything. I agree we need to do
          better homework for when to turn it off by default. I
          don't think we need to decide it this moment.
  Rossen: We'll continue working on this feature. I think we can
          wrap up by agreeing to adopt the properties and values and
          then continue tech details of auto's definition.
  Florian: In general I agree. I want to add a nuance. I'm okay with
           doing homework later. I don't want to call it done in L3
           without an explanation.

  astearns: Things are going in circle. I think we should close for
            now. I do believe we can resolve we're using
            text-decoration-skip-ink with at least values of auto
            and none and it cascade separately from shorthand. We
            will have some normative text describing how auto works,
            but we'll figure the details out in the future.
  astearns: Objections to leaving it there?
  fantasai: The spec is in CR. The goal for me has been to wrap up
            issues and do a stable CR. Maybe it should go next draft.
  astearns: That's possible.
  astearns: Would there be objections to moving this to next level?
  Rossen: Once we accept we can move it back in to L3
  Florian: I'm okay with L3 or L4. It just needs to be with its
           defined normative behavior.
  <fantasai> +1 to Florian

  astearns: Proposed resolution: everything before in L4
  astearns: Objections?
  koji: Webkit has a separate behavior we had the ability to opt out
        and this removes the ability.
  astearns: I think this is process. We're defining it, it's just in
            a next module level so we can get to the current impl
            interop things done.
  Florian: L4 isn't an ED yet
  astearns: I'm hearing no objections
  <fantasai> I really object to having "no skipping" and "maybe
             skipping, not sure if we want this to be mostly
             skipping or mostly not skipping"
  <fantasai> If it's "no skipping" and "skip unless it's really
             bad"... I could deal with that.

  RESOLVED: Use text-decoration-skip-ink with at least values of
            auto and none and have it cascade separate from
            shorthand. We will have some normative text describe how
            auto works, but we'll figure the details out in the
            future. Do this in L4.

Create a display property value for visually hiding an element while
    making it available for AT

  <astearns> https://github.com/w3c/csswg-drafts/issues/560
  fantasai: I think we decided not to do anything. This was really
            if we wanted to do anything with speak or speak-as.
            There may be further discussion on this draft, but I
            don't see solid proposals. Maybe republish CSS Speech.
  astearns: Anyone have something more to add?
  astearns: Shall we resolve to close the issue?
  fantasai: I would say do we want to republish CSS Speech CR.
  astearns: With what changes?
  fantasai: We renamed some values and def they're effected by
  <fantasai> We did that last month
  astearns: Objections?

  RESOLVED: Republish CSS Speech CR

  ChrisL: New features, or just text? Do I do the non-technical?
  fantasai: It's non-technical
  ChrisL: DoC?
  fantasai: I can update in 5 minutes; there were only 2 issues.
  ChrisL: And a changes section?
  fantasai: Yep.
  ChrisL: Thanks.

Stretching image grid items in both dimensions

  <astearns> https://github.com/w3c/csswg-drafts/issues/523
  fantasai: The discussion we had in Seattle...Mats said it was
            unclear if we're distinguishing by if it's replaced or
            has an aspect ratio. TabAtkins and I thought it should
            be based on if they have an aspect ratio. Images that
            don't generally take their size from the container
  fantasai: We need to answer what happens to an image that has no
            aspect ratio & no size.
  fantasai: An SVG with no viewbox, width, or height
  fantasai: Other question is what if it just has width.
  Rossen: For SVG these things are defined in integration spec. The
          internal sizing algo for all the permutations. I don't
          think there's anything new that will be added for SVG.
  Rossen: You can word it so SVG is treated as non aspect ratio
          image and it won't effect sizing in SVG. It's just a
          choice of which to we apply in SVG.
  fantasai: Only thing that really makes sense if for it to take the
            size of the fixed size grid container. That's what we do
            in blocks when we can.
  Rossen: I think this is reasonable.

  Rossen: From text POV if we tried to make a distinction between
          what applies with and without intrinsic ratio this isn't
          the place. If we want the spec to call out this applies to
          when it has an intrinsic size and this is when it does and
          leave out the definition for another spec.
  fantasai: Right. We don't say when, but we define different
            behavior for when it has one and when it doesn't.
  Rossen: From what I understand Mats pushed back this isn't well
          defined in grid?
  fantasai: We had defined it and Mats pushed back it didn't match
            what was resolved in his understanding that all replaced
            elements have one behavior which is the shrink to fit.
  Rossen: I think if we change the wording to refer to replaced
          elements with an intrinsic ratio it solves both issues.
  Rossen: Does that sound right?
  fantasai: I need to look at the wording.
  astearns: As much as I'm following, we need a resolution that our
            previous resolution only applies to replaced elements...
  Rossen: The other way. It currently applies to all replaced
  <fantasai> https://github.com/w3c/csswg-drafts/issues/523#issuecomment-275869984
  fantasai: Here's the comment ^
  fantasai: [reads]
  dbaron: Yep.
  dbaron: I think Mats' point is he wants the WG to resolve
          something that matches what people put in the issue. Since
          there have been previous edits where edits and the
          resolution diverge. He's sensitive that edits and
          resolutions can diverge and he's pointing those out.
  Rossen: Yes. That's a valid point. Having a tighter definition of
          which replaced elements will be good.

  fantasai: There's two questions we need to resolve [reads]
  <fantasai> The two questions we need to resolve are
  fantasai: First should get stretched.

  astearns: Before we get to the questions don't we need to resolve
            that we meant the previous resolution to only apply to
            those with an aspect ratio.
  astearns: What is the THIS that only applies to things with an
            aspect ratio?
  Rossen: Instead of stretch we respect the intrinsic ratio. [looks
          for exact previous resolution wording]
  <fantasai> Items without an intrinsic ratio use, in both axes, the
             width calculation rules for non-replaced block boxes as
             defined in CSS2.1 § 10.3.3. (Meaning, auto values in
             either axis are effectively sized to fill the remaining
             space.) However, the box alignment properties have
             special effects: when align-self/justify-self is
             neither normal nor stretch, an auto size for the grid
             item in that axis is treated as fit-content instead of
             as the stretch-fit size. Se[CUT]
  <fantasai> Items with an intrinsic ratio follow the same rules,
             except that in the case of a normal alignment value, an
             auto size for the grid item is sized as for align-self:
             start (consistent with the width calculation rules for
             block-level replaced elements in CSS2.1 § 10.3.4).
  fantasai: Current spec text^
  Rossen: The resolution says we're keeping the current behavior
  astearns: What's the change to satisfy Mats?
  TabAtkins: We talked about replaced elements when we meant those
             with aspect ratio. Resolving that. Then some questions
             falling out from that.
  Rossen: Reading from fantasai text we're talking about [reads]
          This is talking about intrinsic ratio.
  fantasai: That's not what was in the minutes so Mats wants
  astearns: Proposed resolution is that the sentence pasted above is
            what was intended from the Seattle resolution and we
            resolve on that text.
  astearns: Objections?

  RESOLVED: The sentence beginning with "Items without an intrinsic
            ratio use," is what we as a WG wanted to use.

  astearns: Okay, the questions.
  fantasai: We didn't really talk about the first case. It makes
            sense to me that the axis with an intrinsic size should
            follow the second clause. In the dimension without a
            size it behaves as stretch.
  astearns: So that first sentence would be that items without an
            intrinsic size in the axis....
  Rossen: I'd rather say items with defined size in only one
          dimension, that dimension is start and the other is
  fantasai: I'm happy to word smith, but if we conclude on the
  Rossen: Proposed: replaced elements with only one intrinsic size
          are sized as start in that dimension and stretch in the
  ChrisL: I think that makes sense.
  astearns: Replaced elements with one intrinsic size and no aspect
  fantasai: Yes.
  astearns: Objections to Rossen proposal?

  RESOLVED: Replaced elements with only one intrinsic size are sized
            as start in that dimension and stretch in the other.

  astearns: We'll let the editors get that into the spec text.
  Rossen: fantasai you doing this?
  fantasai: I'll do the edits.

Path to PR with CSS Cascade

  <astearns> https://lists.w3.org/Archives/Public/www-style/2017Feb/0067.html
  astearns: Main thing is drops scoped styles.
  TabAtkins: Which is due to support. FF might impl, but no one else
             is planning on them.
  dbaron: We are keeping our impl for now.
  fantasai: It is also defined in cascade L4.
  astearns: If we drop from level 3 would we also from L4?
  fantasai: We can decide on that once we're blocked on PR. Do we
            have 2 implementations of revert keyword?
  fantasai: That's the main new thing on L4.
  * fantasai notes current level is kind of vague, given both are in
  astearns: Objections to dropping scoped styles from current level
            of css cascade?

  RESOLVED: Drop scoped styles from current level of css cascade.

  fantasai: We need action items for getting impl test into the repo.
  fantasai: If no one wants to import tests they can point to where
            the tests are so someone else can import.
  fantasai: If we don't have tests we can't go to PR.
  astearns: Anyone willing to take an action item?
  TabAtkins: I can find the ones for us.

  ACTION TabAtkins to find cascade tests

  astearns: I guess we'll see if the blink tests are sufficient. I'd
            like more participation since we don't do enough
            compiling of test suites. I'd rather volunteers.
  fantasai: What I can do is I can grab and import the Mozilla tests
            and they have 2 copies.
  dbaron: I'm having trouble finding tests. The only tests I know we
          have are mochitests.
  dbaron: You can't import those.
  fantasai: If you can drop in the URLs we can look to try and
  fantasai: Then it's more solvable of a problem.
  astearns: We're over time. Thanks everyone for calling in.

  <Florian> I'd like to take this opportunity to remind people to
            watch the csswg-test Pull Request queue. There's quite a
            bit of tests there sitting and waiting.
  <Rossen> +1 to Florian<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
        <td style="width: 55px; padding-top: 13px;"><a
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
		<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
target="_blank" style="color: #4453ea;">www.avast.com</a>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
Received on Thursday, 16 February 2017 01:32:55 UTC

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