W3C home > Mailing lists > Public > www-style@w3.org > September 2014

[CSSWG] Minutes Telecon 2014-09-24

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 24 Sep 2014 19:52:17 -0400
Message-ID: <CADhPm3vPboQHwPojxaGyEzx8WCw512Co_XWevNgVvT8brG_JCQ@mail.gmail.com>
To: www-style@w3.org
Joint meeting with dpub

  - The group was very interested in meeting with dpub.
  - dauwhe will suggest the Monday breakout time to the dpub group.
  - Rossen will also investigate a joint meeting with the user
      interface task force.

CSS Images 3

  - TabAtkins came to the group asking for approval to bring some
      items he had been working on in Images 4 up to Images 3 since
      he felt they were already stable items and therefore should be
      in the spec that's closer to REC.
  - RESOLVED: Allow nearest neighbor for image rendering in both
      directions but allow browsers to do prettier in the down
  - RESOLVED: Include image rendering in level 3.
  - RESOLVED: Close this issue (regarding guessing resolution from
      file size) with no change because we'll fix it later in
      harmony with HTML.
  - TabAtkins will send an e-mail to the list regarding the details
      of his plan for lifting restrictions on nesting with image set.
  - RESOLVED: Have image set in level 3.
  - RESOLVED: Move crossfade to level 3 of Images.

Sizing of floated ::first-letter

  - RESOLVED: Remove special case from ::first-letter

Overriding an important style

  - There was support for altering the property to conform with
      author expectations, however there was some concern about
      possible breakage.
  - We will revisit the issue after there has been time to write
      tests to confirm there's no compatibility issues.

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

  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Daniel Glazman
  Dael Jackson
  Chris Lilley
  Peter Linss
  Shinyu Murakami
  Edward O'Connor
  Anton Prowse
  Lian Quin
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Dirk Schulze
  Mike Sherov
  Greg Whitworth

  Bruno Abinader
  Adenilson Cavalcanti
  Simon Fraser
  Sylvain Galineau
  Mike Miller
  Lea Verou

  Scribe: dael

  plinss: Let's start
  plinss: Any additions to the agenda?
  plinss: I'll take that as a no.

Joint meeting with dpub

  dauwhe: I didn't know what the procedure is to set this up.
  plinss: Doesn't matter as long as we know.
  dauwhe: They're interested in the box tree stuff. dpub has a force
          on dom pagination or something like that

  dauwhe: They're at the end of the week and we're at the beginning.
  plinss: Are there times they would be available or would be better
          for us to meet?
  dauwhe: I'll ask them.

  plinss: Anyone in our group that wants to be there but has time
  <glazou> me
  Rossen: I think it would be good to see what they want to bring
  plinss: Should we invite them to our normal meeting or use our
          breakout time?
  <TabAtkins> I'm fine with taking a bit of normal time if necessary.
  dauwhe: I would say the breakout time is longer and that's a good
          way to use it.
  dauwhe: That's what I thought. Some people in dpub were worried
          that people wouldn't follow the schedule and use the
          breakout time for regular meeting, but I think this is a
          great use of the time.
  dbaron: I think the AC meeting is also in that time.
  plinss: I think that's Tuesday. Looks like Monday breakout is good
          to suggest.
  dauwhe: I'll start with that.

  Rossen: While we're on the topic, there's the user interface task
  Rossen: They currently are looking at defining editing behaviors.
          Based on our last F2F discussion I think there's an
          overlap between some of our intentions and what these guys
          want to do.
  Rossen: Talking to Ben Peters they might also want to attend a
          joint meeting. Same protocol?
  plinss: Sounds reasonable. Maybe you coordinate a time or put them
          in touch with me or glazou and we'll coordinate.

CSS Images 3

  TabAtkins: As part of the F2F we said we'd re-publish since the CR
             is 2 years old.
  TabAtkins: The older text hasn't been touched, I've only been
             doing work on level 4.
  TabAtkins: I thought it was more reasonable to strip 4 down and
             use it in 3. It means there might be still some errors
             that have level 4 references.
  TabAtkins: If there's anything else we can catch those. I need
             sign off on a few features that have been implemented
             for a while and are stable enough for CR level draft. I
             need approval.

  TabAtkins: First item is image-function so it doesn't do URL
  TabAtkins: That shouldn't be controversial.
  TabAtkins: Second item is I've moved 3 functions, image-set
             function which is implemented by webkit and equivalent
             to picture. Cross-fade function for same reason.
  TabAtkins: Also image-rendering that controls interpreting pixel
             as you scale up or down. It's implemented in at least 2
             browsers so it's already stable.
  krit: Most of the properties you mentioned were in webkit before
        the fork in Images...
  TabAtkins: The two functions aren't in independent. Image-
             rendering is in Firefox and webkit.

  florian: Other than what you've listed explicitly, are all the
           changes from resolutions or are there things you thought
           were good ideas?
  TabAtkins: I believe all resolutions. The only other change I can
             think of is that image function auto-rotates when
             before it was an explicit special value, but that's
             from a resolution
  florian: The other changes are linked?
  TabAtkins: Yes. I'll go through and verify to make sure I haven't
             made further unintentional changes, but those are the
             ones I intended.

  dbaron: What's now in 4 that isn't pulled back?
  TabAtkins: Element function, and a few other bits.
  [TabAtkins looks at the spec]
  TabAtkins: Conical gradients.
  TabAtkins: That's it. Those two.
  dbaron: And bidi images.
  TabAtkins: Yes. Images 4 is now out of date because of the text
             changes in 3. I'll backport in a while. Or reset 4 to a
             delta spec until we're ready for it to be stable.

  MaRakow: I think in general it makes sense. I feel better about
           things that are in other browsers instead of the ones
           only in pre-fork webkit.
  ChrisL: So images 4 isn't in WD
  TabAtkins: Yes.
  ChrisL: So would we need another LC?
  TabAtkins: This would be a new process LC/CR
  ChrisL: Okay, so it doesn't matter.
  plinss: Is that true? If we're in CR we can't change to the new
  Bert: I think it would be great to publish a WD for 3 weeks and
        than go back to CR.
  ChrisL: The point of doing that would give a chance to go back. So
          as things coalesce it can get comments in CR.
  Bert: But CR means it's cemented and WD doesn't.
  ChrisL: But it used to. Now CR means we want comments.
  <ChrisL> I don't oppose dropping all the way back to WD but I
           don't think it is needed, we can go straight to LCCR
           which is the new proceed for "edited CR"

  florian: Given that there are a lot of changes, should we publish
           a CR that we haven't read?
  TabAtkins: You've read the level 4 draft.
  florian: We haven't read it as a CR.
  florian: Can we have actions to review it?
  TabAtkins: I'm fine with waiting for a few weeks and brining it up

  ChrisL: So, to be clear, people want it to be a WD again and I
          don't think we need to because LC/CR is meant to allow you
          to republish and disclose new features. I'll do whatever
          people want.
  TabAtkins: I'm fine with give the group 2 or 3 weeks of time and
             then asking for LC/CR publication
  ChrisL: Makes sense.
  plinss: I think that sounds reasonable. Am I remembering there was
          one phase where you can't switch to the new process?
  ChrisL: Old LC to CR, I think.
  <ChrisL> yes, old LC to new LCCVR (which seems odd)

  plinss: I'm hearing that everyone should review and come back in a
          few weeks.
  florian: We don't have consensus on the new functions.
  TabAtkins: Image-rendering. That's implemented by two browsers. It
             has auto or pixelated or crisp edges for scaling.
  krit: Is pixelated the same in both implementations?
  TabAtkins: Yes. dholbert just asked for a minor change that will
             simplify it, but yes.

  florian: Should we resolve on that suggested change while we're at
  TabAtkins: The change is previously the pixelated used the nearest
             neighbor when things are being scaled. Nearest neighbor
             doesn't have good effects when going down. It loses
             information instead of scaling.
  TabAtkins: Previously we said when scaling down use normal scaling.
             The objection was that it was difficult to pipe in if
             you're going up or down to the point you're doing the
             scaling. And scaling down doesn't loose too much
             information. We're mostly concerned about scaling up.
             He asked it to be changed to always nearest neighbor
             and doesn't care about direction.
  florian: If people have something better, can we have a MAY use
           different for scaling down?
  TabAtkins: Current is nearest neighbor or better.
  ChrisL: Currently we require bi-linear because we had
          implementations that did nearest neighbor and it was
          horrible. So we need to have a minimum level in the spec.
          If one says explicitly nearest and the other says do what
          you normally do. I'm sure we can have language that
  TabAtkins: We have auto set up so that it can go to the cheapest
             thing it can if it has limited resources.
  ChrisL: I'm worried the language will get abused.
  TabAtkins: People can make ugly browsers, but people will complain
             about it.

  florian: We do have a venue that's specifically for upscaling with
           nearest neighbor? It's meant for upscale, not when you
  florian: Do we have a use case for make it ugly when you scale
  TabAtkins: No.
  florian: So when you upscale you must and downscale you may.
  TabAtkins: The spec had previously said scaling up means at least
             in one dimension. Down is only if you're shrinking on
             all sides.
  florian: Is that reasonable with what we just said?
  krit: Nearest neighbor for down and up scaling?
  TabAtkins: I'm fine with adding weasel language.

  plinss: Is everyone happy with the change?
  <ChrisL> ok with the change, want to read exact weasel words
  TabAtkins: We accept my proposal to allow nearest neighbor in both
             directions but allow browsers to do prettier in the
             down directions.

  RESOLVED: Allow nearest neighbor in both directions but allow
            browsers to do prettier in the down directions.

  plinss: There's language in Images 3 [missed]. Did we ever publish
          a recommendation?
  TabAtkins: Yes, it was in SVG spec.
  plinss: So do we need to treat as deprecated, or should it be
  plinss: If it's specified in SVG that's fine.
  TabAtkins: So the large question of image rendering in level 3.
             Yea or objections?

  RESOLVED: Include image rendering in level 3

  TabAtkins: Next is image set. Browser uses magic to decide which
             one to load. This is identical to image source set.
             It's implemented in webkit and matchs HTML so I thought
             this was stable.
  florian: This matches the latest version of HTML?
  TabAtkins: The subset it addresses? This is more limited but I'd
             be happy the expand in 4.
  florian: This is a 3 way thing in in HTML.
  TabAtkins: The third part is something I'd like to explore later.
             There will be a way to do it in the future, but I don't
             want to tie it into the stable set and slow everything
  florian: So this is equivalent to the source set in HTML?
  TabAtkins: Yeah.

  TabAtkins: Any other opinions or objections?
  hober: I'm in favor.
  plinss: There's only one implementation?
  TabAtkins: Yes. Given that Firefox does source set, it may be easy
             to implement image set. It's easy to translate over.
  florian: This has been controversial. If people haven't agreed in
           HTML I'd object, but given that HTML did settle down I'm
  <ChrisL> agree with florian there.

  plinss: I'm concerned about how long this will keep us in CR.
  TabAtkins: We have 0 tests anyway.
  plinss: We are shy on tests.
  TabAtkins: I need to spend time on that. I plan to in the next
             couple months.

  MaRakow: There are 4 open issues. Will you port those over?
  TabAtkins: They're mostly resolved in Level 3 now, I think. Let me
  TabAtkins: There are two issues left in Level 3. First is common
             to HTML and I don't think we want to resolve on how to
             address this on CSS until HTML decides.
  TabAtkins: Resolution is approximate from file size, but not all
             file types are like that. Vector is infinite resolution
             but a small files size and image doesn't capture that
  hober: You can do vector without an image set.
  florian: What it doesn't do is giving hints to the browser which
           vector it's meant to be. The high res, the low res...
  TabAtkins: Vector also suffers from small image sizes. I think we
             should remove the issue, let HTML decide, and copy.
             Which might be nothing.
  TabAtkins: Right now vector images can be the largest resolution
             and that works for now.
  ChrisL: It's good as a first approximation. There's also need to
          have multiple vector images.
  TabAtkins: That's discriminating in a different way. Like pixel
             size which image-set doesn't solve. I'm saying this is
             complex and CSS shouldn't solve it. HTML and CSS should
             be consistent.

  MaRakow: Sounds like we should leave this is level 4 until
  TabAtkins: This isn't a large problem.
  florian: There's been a lot of discussion on this and people seem
           to be agreeing that what's in HTML is mostly right and
           good to go. The rest may be addressed in the future, but
           maybe not because no one cares enough. I don't think this
           is enough to block it and being consistent make sense.
  MaRakow: So can we say the issue is resolved or is it open and
           pending HTML?
  TabAtkins: We close for now because it's not a big deal. When it
             is resolved, we participate and make it consistent.
  florian: Can we make it into a note saying we know this feature
           doesn't address that use case?
  TabAtkins: Yes. That's something we've done before.
  florian: Say it's a use case we know this doesn't address and that
           will be addressed later.

  TabAtkins: So, any objections to closing this with no change
             because we'll fix it later in harmony with HTML?

  RESOLVED: Close this issue with no change because we'll fix it
            later in harmony with HTML

  TabAtkins: This one is a restriction that doesn't let image set
             nest. This is from when there was fallback concerns,
             but we removed the functionality from image and image
             set I switched to match HTML
  TabAtkins: Now that there isn't a need to worry about fallback, I
             think nesting is less complex and it's probably not a
             bad idea to lift the restriction so you can nest.

  plinss: That precludes future fallback solutions.
  florian: That looks subtle enough that I'd rather read it and
           think about it. You're probably right but I want time to
  plinss: I'm concerned that having the nesting may restrict our
          ways of doing fallback in the future.
  TabAtkins: I don't believe it will. I think we can add conditions
             as part of the fallback mechanism.

  plinss: What do you gain?
  TabAtkins: You have image set and have...
  TabAtkins: Oh. You don't. You don't gain anything. It's a matter
             of making it invalid to nest and we're not gaining
             anything from having the restriction.
  plinss: You're not gaining anything from the functionality.
  TabAtkins: No, it's useless to nest. I just want to remove the
             unneeded restriction.
  hober: I think we can add the limitation later. Authors don't do
         it, anyway.

  florian: If everyone is cool, I won't stand in the way, but I'd
           rather think on it.
  plinss: Let's come back to it.
  florian: Is there a summary in the spec?
  Action TabAtkins to e-mail the list about lifting restrictions on
         nesting image set
  * trackbot is creating a new ACTION.
  <trackbot> Created ACTION-652 - E-mail the list about lifting
             restrictions on nesting image set [on Tab Atkins Jr. -
             due 2014-10-01].

  TabAtkins: So the larger issue is keep image set in the spec; yea
             or object?
  TabAtkins: We're going to have a few weeks of review.
  florian: So the review is time to let me decide.
  hober: Yea.

  RESOLVED: Have image set in level 3

  TabAtkins: So the last item lets you blend images or blend colors.
  TabAtkins: It's used in blink/webkit to fill between animations.
             The syntax in the spec does differ from the current
             implemented syntax because we changed from the prefixed
             in order to be extensible to multiple images in the
  TabAtkins: In the future level we want crossfade to be able to
             blend 3 or more images. So I had to tweek the syntax.
  dbaron: Why doesn't crossfade take crossfade as an argument?
  TabAtkins: It does. It's messy.
  dbaron: It's the natural thing that falls out of transitions. So
          you end up with a nested case instead of a three function.
  TabAtkins: You might be right.
  TabAtkins: I'll give that more thought to see if we want to extend
             that. I need to talk to shane because I think there was
             something about additive animations.
  TabAtkins: So we may revert back.

  dbaron: This is also pulling the interpolation rules that depend
          on crossfade into images 3.
  dbaron: This almost sounds like abandoning images 3 and doing
          images 4
  TabAtkins: I recall an earlier F2F conversation about what it
             would mean to maintain a CR level 3 and WD level 4 and
             it would mean that whenever the level 4 items are ready
             to advance we would take those features and pull them
             into a republication of the lower level CR.
  dbaron: That depends on the definition of stable. These aren't
          ready to exit CR.
  TabAtkins: Yes. But by that criteria Image 3 should be kicked out
             of CR as well.
  <ChrisL> with zero tests its clear nothing is ready to exit CR
  dbaron: I guess I'm okay with it. It probably will mean it's hard
          to get it to REC.
  TabAtkins: That's possible. I don't think these are the first
             things that will drop out.

  florian: All this stuff you're adding, can it be marked at risk?
  ChrisL: In some ways I'd rather put it in and see if it has
          traction. If we want to move and it looks dodgy, we can
          change them to at risk
  florian: Is there any down side to at risk?
  ChrisL: There's a slight one because it's usually a flag saying
          we're going to pull this.
  TabAtkins: Previously it was to allow its removal to not be a
             normative change, but that's not needed anymore.
  florian: Okay. So ignore what I said.
  plinss: So we can delete the features and go right back to CR.
  florian: So with lack of LC do we need at risk?
  plinss: Let's not bikeshed the process.

  TabAtkins: So put the crossfade function in? There may be tweeks
             during review.
  TabAtkins: And putting it in for now doesn't mean we can't put it
             back into 4 later.

  RESOLVED: Move crossfade to level 3 of Images

Sizing of floated ::first-letter

  <florian> http://dev.w3.org/csswg/selectors-3/#application-in-css
  florian: In selectors 3 there's some language from CSS 2.1 that
           allows something to pick the letter height of the first
           letter. That was there because if you do it well you
           could make it look better.
  florian: Only Firefox is doing this so it's not interoperable. And
           we have another value coming in that's better at doing
           drop-cap. So I suggest we remove the special casing.

  florian: I wrote a few test cases that should show the difference.
  <florian> http://florian.rivoal.net/csswg/first-letter-tests/first-letter-001.html
  <florian> http://florian.rivoal.net/csswg/first-letter-tests/first-letter-002.html
  <florian> http://florian.rivoal.net/csswg/first-letter-tests/first-letter-003.html
  <florian> http://florian.rivoal.net/csswg/first-letter-tests/first-letter-001-ref.html
  florian: Only Firefox does anything different. I think
           gregwhitworth mentioned that there might be subtle
           differences elsewhere, but I don't think there's a case
           for allowing the difference other than drop-caps
  <gregwhitworth> agreed
  TabAtkins: I agree. I think initial-letter will do it better.
  Rossen: Sounds reasonable.
  florian: dbaron?
  dbaron: I'd like to see initial-letter be more stable, but I guess
          I'm okay.

  RESOLVED: Remove special case from ::first-letter

  florian: I'll submit the tests.
  florian: Do we submit from TTWF or is the old way fine?
  plinss: Old way is just fine.
  florian: What's preferred?
  plinss: Author's preference.

Overriding an important style

  mikesherov: Basically what we have is a situation where
              element.style.setProperty doesn't change the important.
              To do the way cascade works it doesn't take the
  mikesherov: There's no way to change from red important to black
              in one step. It's not interoperable and it fires two
              mutation observers. We tried to fix this in JQuery
              which cased a few more bugs.
  <ChrisL> Okay, so it is an atomic operation to change value and
           importance together.
  <mikesherov> http://bugs.jquery.com/ticket/14394
  <mikesherov> http://bugs.jquery.com/ticket/14836
  mikesherov: Because there isn't interoperability, though webkit,
              blink and IE are doing what the spec says, it might
              make sense to switch to what Firefox is doing
  glazou: I support this.

  <mikesherov> https://connect.microsoft.com/IE/feedback/details/831122/assigning-to-the-style-property-initialized-to-an-important-value-isnt-applied
  mikesherov: When we filled the bug (above) with Microsoft they
              pointed to the spec so I think they'd change it if we
              changed the spec and I'm hoping blink/webkit supports
  mikesherov: I'm not sure how many authors are relying on the
              current behavior.
  glazou: I don't think many authors are, but app authors hit it a
          lot and hate it.
  mikesherov: It's important for something like jQuery to be able to
              do this in one step.
  ChrisL: It makes sense for this to be an autonomous declaration.

  mikesherov: From the mailing list it seemed there was a resolution
              last August in the opposite direction. I'm not sure
              what the details of that decision were, but I'd like
              to see a change.
  plinss: Anyone remember or have minutes from that?
  dbaron: My memory is someone didn't want to change.
  plinss: Are they willing to change now?
  TabAtkins: I don't see reason why we'd object.

  plinss: So are folks okay with resolving?
  hober: I don't know either way. I don't know compatibility risk.
  Rossen: Same for us. We need to evaluate the compatibility and see
          if we'd need to change.
  <zcorpan> I think it's ok compat-wise. Last time I looked at it I
            only found scripts expecting the Firefox behavior
  mikesherov: I'm new. I don't understand about evaluating the
              compatibility risk.
  Rossen: We can try to run some queries to see how widely this
          pattern is used and once we find that we can see what the
          consequences would be for site breakage.
  florian: I don't know how you'd search. It's not an easy thing to
  Rossen: I'm not saying it will be. We can try and mine the data. I
          don't know how much success we'll have.
  mikesherov: Web developers believe that they can set it how they
              want to and since it's an inline style they think they
              can change it. Again, Firefox does the 'expected'
              behavior. I'm not sure how to research.
  florian: One thing would be, does Firefox have bugs filed against
           it on this issue?
  dbaron: I don't think it was an issue.

  plinss: Do people want time to research or can we resolve now?
  Rossen: I'd like a week.
  Action Rossen research changing the overwriting of an important
  * trackbot is creating a new ACTION.
  <trackbot> Created ACTION-653 - Research changing the overwriting
             of an important style [on Rossen Atanassov - due 2014-10

  plinss: Thanks everyone.
Received on Wednesday, 24 September 2014 23:52:45 UTC

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