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

[CSSWG] Minutes and Resolutions Paris F2F 2012-02-07 Tue Afternoon I: Webkit Prefixes Cont., css3-background, css3-images

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 12 Feb 2012 01:11:31 +0100
Message-ID: <4F3703B3.8000208@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Webkit Prefix Continued

Discussion of specific actions WG can take to ameliorate the situation.
Three approaches are available; chairs assert the WG can use all as needed:
   - Dropping prefixes before CR (via legacy clause in the prefixing policy
     documented at /TR/CSS)
   - Splitting specs to move stable features faster (as is being done
     with CSS3 Text)
   - Asking the chairs to assign high priority to those features (as
     with CSS2.1 leading up to its REC)

CSS3 Backgrounds and Borders

   - RESOLVED: Accept the proposed text for bidi splits and box-decoration-break
               (making it optionally applied to bidi splits)
   - RESOLVED: Accept the proposed text for corner transitions
   - RESOLVED: Default color of box-shadows is value of 'color'
   - RESOLVED: Accept proposed text defining a default object size for
               border images in order to determine slice positions
   - RESOLVED: Accept proposed values of 'Animatable' filed for all
               CSS3 Backgrounds and Borders properties
   - RESOLVED: Republish Backgrounds and Borders as LC in order to errata it
               as CR. Include an explanation of why we're publishing a LC --
               that it's still a CR-level draft, we just need to make errata
               'cuz the process doesn't allow for errata in CR.

CSS3 Images

   RESOLVED: Mark everything in Images 3 as at-risk except gradients.

====== Full minutes below ======

     Rossen Atanassov (Microsoft)
     Tab Atkins (Google)
     David Baron (Mozilla)
     Bert Bos (W3C)
     Tantek Çelik (Mozilla)
     John Daggett (Mozilla)
     Elika Etemad (Mozilla)
     Simon Fraser (Apple)
     Sylvain Galineau (Microsoft)
     Daniel Glazman (Disruptive Innovations)
     Vincent Hardy (Adobe)
     Koji Ishii (Invited Expert)
     Håkon Wium Lie (Opera)
     Chris Lilley (W3C)
     Peter Linss (Hewlett-Packard)
     Luke Macpherson (Google)
     Alex Mogilevsky (Microsoft)
     Anton Prowse (Invited Expert)
     Florian Rivoal (Opera)
     Alan Stearns (Adobe)
     Steve Zilles (Adobe)

     Jet Villegas (Mozilla Corporation)
     Tavmjong Bah (Inkscape)

<RRSAgent> logging to http://www.w3.org/2012/02/07-css-irc
Agenda: http://wiki.csswg.org/planning/paris-2012

WebKit Prefix Conversations
Scribe: fantasai

   <tantek> ASIDE: regarding using -webkit- prefix, clarification re: Lea Verou -
            she's advocated using *both* vendor prefixed properties (multiple
            vendors) and the unprefixed version after them. See her talk
            from Front-Trends 2010 for example. An actual example of -webkit-
            *only* prefix examples (thus implied advocacy) is Google's
            http://slides.html5rocks.com/ , e.g.
            http://slides.html5rocks.com/#css-columns has three -webkit- property
            declarations starting with -webkit-column-count

   plinss: Had various offline conversations.
   plinss: Tantek / roc talking about creating this list of properties they're
           considering for webkit prefixing
   plinss: Would like that list given to WG ASAP
   plinss: Rather than vendors making blog posts saying "this is what we're
           going to do", would rather vendors brought these lists to us so
           we can reset our priorities
   plinss: There is market interest in these properties. They are ready to
           be implemented, or already implemented, interoperably by multiple
           vendors. Therefore they meet the criteria to be standardized
   plinss: No reason they shouldn't be standardized immediately.
   plinss: If vendors feel there is sufficient market pressure that it's
           crucial to their business, that should be our highest priority.
   plinss: So I would like to get buy-in from the group that this is the
           right approach.
   plinss: Would like commitment from vendors considering this to talk to
           us, let us address this as quickly as possible.
   Florian: I'm convinced this is a good idea. Concerned it's not sufficient,
            but regardless we need to do it.
   plinss: I accept it may not be sufficient. I hope it is. But we should
           as a WG do what we can to alleviate this market pressure.
   plinss: Asking for commitment to get this list from vendors asap, and
           bring it first to WG not to vendor blogs
   glazou: [...] expand the evangelism community.
   glazou: let's try everything before going to the last resort
   glazou: I have two options for the article. Can call community at large.
   Florian: Idea is a call to the community at large to be responsible for
            how they use prefixes.
   Florian: vendors have tried that on their own, he's suggesting to do it

   plinss: I think if we have 2-3 vendors effectively agree on an
           implementation, whether it's because they like it or they're
           locked into it, that's sufficient for us to declare that it's
           enough for us to drop prefixes.
   plinss: Then we can call on all sites to drop prefixes.
   glazou: Want to move from de facto to de jure standards.

   tantek: Daniel, such an article might help. Need to point out 2 things.
   tantek: First, point out that -webkit- is hurting the web.
   tantek: 2 problems. First is UA-sniffing, only providing modern web
           content to webkit
   tantek: 2nd problem is that there are numerous features that work
           effectively interoperably across browsers
   tantek: That if those sites put multiple prefixes today, without any
           change from this group, they would work.
   glazou: Even if we're not sure that it will work, I think it is worth
           trying. I don't want us to take last resort option without trying.
   tantek: We'd rather sites provided full content to Mozilla and have it
           break, than provide dumb content to us. I think we're fixing
           things fast enough that we can respond to that. But it's the
           webkit-only coding that is harmful.
   glazou: Let's suppose it works a bit, and you see a trend of websites
           adding properties and not sniffing. Will that be sufficient
           for you to decide to wait?
   tantek: Will look at data on a case-by-case basis. If data changes,
           conclusions may change.

   plinss: Need to tackle this on all fronts.
   plinss: Need to evaluate list of properties, resolve to drop prefixes
           for those that are ready.
   tantek: I don't want to provide a list of properties, because I don't
           want anything that developers can depend on.
   fantasai: What about providing a list to the CSSWG list?
   tantek: Might change over time.
   Florian: Peter asked for the list to set priorities.
   Alan: Should emphasize that can use all prefixed versions right now,
         and without any changes by us, will work today.
   Alan: And we should be trying to drop prefixes on the things that work
         in that way.
   Tantek: We already have that focus in the WG. But things that are
           outstanding measures in the WG.
   plinss: The moment you have sufficient data about one property. If
           nothing else, send it to Daniel and I, so that we can make
           it #1 priority on the next telecon.
   plinss: My assertion is, just like we were driving 2.1 to REC, that
           was highest priority. I'm offering you and Opera and MS,
           that level of priority if you get to that point on any property.
   plinss: That will be the #1 focus of the group to drop that prefix.
   tantek: Ok. I'm willing to put that on css-wg list. Don't want to kick
           of some kind of flamewar on www-style. Minutes of discussion
           will of course be public.
   tantek: We may wind up posting list to wiki page, but we have better
           things to do than write blog posts about it.
   plinss: If we can help the situation by dropping the prefix, we will
           drop the prefix.
   <ChrisL> pointer to prefixing policy doc?
   <smfr> http://www.w3.org/TR/CSS/#experimental

   fantasai: Note that we do have a loophole in the vendor-prefixing
             policy that the WG can declare an experimental property to
             be implemented prefixless *for legacy reasons*. This was
             originally for things like text-overflow, but existing
             webkit-only content on the web also qualifies as a legacy
             content reason.
   fantasai: So if we have a spec that we cannot move fast enough to CR,
             we can use that loophole to drop prefixes immediately.
   smfr: I'd rather take the spec to CR.
   fantasai: How long will that take to finish?
   smfr: 1-3 months
   fantasai: Will that happen?
   smfr: We can make that happen.

   Tantek: How about we go to CR with open issues?
   fantasai: What's the point of that? The CR transition requires no open
             issues. If your problem is you want to drop prefixes with
             open issues, then drop prefixes before CR.
   jdaggett: You can defer issues, e.g. mark things undefined.
   Tantek: You'll get issues faster than you can evaluate them, just like 2.1
   fantasai: We haven't had that problem to the extent we had it with 2.1
             with our CSS3 modules
   fantasai: What do you want out of moving to CR?
   Tantek: Dropping prefixes
   fantasai: So let's drop prefixes and not change the definition of CR,
             what's the problem?
   Tantek: ...
   Tantek: I think it's more important to use CR as a marker for dropping
           prefixes than a marker for closing issues.
   Tantek: ...
   plinss: To make progress faster, as a group, we can drop prefixes before
           CR. And if there's a significant portion that is stable and has
           no issues, is ready to go to CR, we split the spec.
   plinss: And we are also willing to run through issues and solve or defer
           them quickly.
   plinss: We have three different avenues and we're willing to use them
           all as needed.
   Tantek: Sounds good.

Backgrounds and Borders
Scribe: TabAtkins

   <fantasai> http://www.w3.org/Style/CSS/Tracker/products/11
   fantasai: Bert and I have been going through the B&B issues.
   fantasai: There are a couple open ones, with proposed resolutions, but
             we need the WG to evaluate them.

   fantasai: First is bidi reordering and the application of box-decoration:break
   <fantasai> http://dev.w3.org/csswg/css3-background/#the-box-decoration-break
   fantasai: After the discussion with dbaron, I edited in text that says
             UAs *may* apply box-decoration to control rendering at
             bidi-imposed breaks.
   <fantasai> "UAs may also apply ‘box-decoration-break’ to control rendering
              at bidi-imposed breaks, i.e. when bidi reordering causes an
              inline to split into non-contiguous fragments. Otherwise such
              breaks are always handled as ‘slice’. "
   fantasai: Otherwise, such breaks are handled as slice.
   fantasai: Are people happy with this?
   TabAtkins: Is there a particular reason to keep it optional right now?
   dbaron: We don't have a strict definition of where bidi breaks happen.
   dbaron: And we probably, in reality, want to split breaks into two groups,
           one of which pays attention to the property, and the other which
           always slices.
   fantasai: This is a weird edge case, so this lets the UA do whatever makes
             sense right now.
   fantasai: The default behavior is 'slice' (the easy case), so the suggested
             solution is to optionally apply 'box-decoration-break' when
             specified if the UA has a good way to do it.
   dbaron: Is it conformant to do a split between the two?
   fantasai: I don't think it's conformant with this wording.
   dbaron: I think it's the most sensible behavior, at least given by the way
           we consider these breaks to exist.
   fantasai: That's why we have the term "contiguous" in the definition.
   dbaron: I want tests in the test suite for this.
   fantasai: Ok.
   [no further objections]
   RESOLVED: Accept the proposed text for bidi splits and box-break

   fantasai: Next issue is the corner transitions in border-radius
   <fantasai> http://dev.w3.org/csswg/css3-background/#corner-transitions
   fantasai: The spec as I brought up before is *completely* wrong. But we
             don't have a good definition for the right behavior, so the
             idea right now is to make it officially undefined for now.
        "Color and style transitions must be contained within the
        segment of the border that intersects the smallest rectangle
        that contains both border radii as well as the center of the
        inner curve (which may be a point representing the corner of
        the padding edge, if the border radii are smaller than the
        "If one of these borders is zero-width, then the other border
        takes up the entire transitional area. Otherwise, the center of
        color and style transitions between adjoining borders must be
        proportional to the ratio of the border widths such that a
        function of its location is continuous with respect to this
        ratio. However it is not defined what these transitions look
        like or how “proportional” maps to a point on the curve.
   fantasai: This way, the spec is at least not *wrong*, and we can
             figure out the correct behavior in level 4.
   fantasai: [explains the above text]
   plinss: Didn't we discuss this at TPAC?
   fantasai: We did, and concluded we needed to investigate a lot more
             before we could correctly specify it.
   fantasai: This way, we're defining the important bits that people rely on.
   fantasai: Like that a zero-width border won't contribute any visible color.
   fantasai: And that larger borders are proportional in some way.
   sylvaing: What's the important bit, precisely, and who depends on it?
   fantasai: One example is a box with only a border on top that curves
             around.  The sides will usually just be currentColor, and
             authors don't expect that to show up.
   tantek: I think we could instead hook that to border-style.  If the
           side is border-style:none, don't show any of that side's color.
           But if it's solid, even if it's 0px, when you do a gradient it
           should fade to that.
   Bert: I think that's what Konqueror does.
   fantasai: So you want to replace 'zero-width' with 'none or hidden'.
   dbaron: I think that removes the continuity argument.
   Bert: Not sure.  We need more research, or to leave it open.
   tantek: I'm okay with leaving it open, I just wanted to present it as
           a use-case.
   fantasai: So if you wanted to use a double or dashed border...
   tantek: Borders historically have been places where we allow impls to
           give better results, rather than locking them into the lowest
           common denominator.
   fantasai: So we still want to define, at least in the 'none' case,
             that the entire visible border is the color of the non-'none'
   fantasai: But that makes dbaron unhappy.
   dbaron: I don't think the color at the corner is ever what's desirable.
   fantasai: So how should we resolve this?
   dbaron, smfr: I'm happy leaving the proposed text as it is.
   plinss: Can we resolve to accept the text in the editor's draft?
   [no objection]
   RESOLVED: Accept the ED text for border-transitions.

   <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/214
   fantasai: Next issue, define the default shadow color.
   <fantasai> Options mentioned so far:
   <fantasai> 1. black
   <fantasai> 2. rgba(0,0,0,0.5)
   <fantasai> 3. currentColor
   <fantasai> 4. currentColor except it doesn't compute until after inheritance
   <fantasai> 5. make <color> required
   dbaron: Are we discussing box-shadow, or text-shadow as well?  And
           what do the specs currently say?
   fantasai: Both, and they should be consistent.  They both say "UA-defined"
             right now.
   dbaron: Gecko seems to use currentColor for both shadows, almost.
   dbaron: I think, though, that on text-shadow, if the text decorations
           are a different color form the text, the default shadow *on the
           decorations* will match the decoration color.
   fantasai: Ok, so 6 options (for text-shadow; doesn't make a difference
             for box-shadow)
   plinss: Any opinions?
   <dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span 
style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"color%3A orange%3B text-shadow%3A 20px 
   dbaron: Above data url confirms Gecko's text-shadow handling.
   smfr: I think WebKit defaults to transparent.
   fantasai: We could still make it required.
   dbaron: I'm not comfortable with a syntax change at this point.
   dbaron: Opera doesn't shadow decorations at all.
   Tab: When we do equivalent of fill on text, filling text with images,
       what will text-shadow do then?
   Florian: Will it behave like stained glass or not?
   smfr: I think black as a default color would be easier to understand.
   Tab: Given we have random answers right now, we could pick anything.
   <dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span 
style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"text-decoration:line-through;color%3A orange%3B 
text-shadow%3A 20px 20px">hello<%2Fspan><%2Fspan>
   [people run tests on various UAs]
   sylvaing: IE10 shadows text and decorations both with the currentColor.
   [discussing defaulting to black]
   Bert: we have an implementation: Konqueror defaults to black
   <dbaron> http://www.w3.org/TR/1998/REC-CSS2-19980512/text.html#text-shadow-props
            says to use the current color
   [everyone checks what the default for box-shadow is in UAs]
   <dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span 
style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"text-decoration:line-through;color%3A orange%3B 
text-shadow%3A 20px 20px;box-shadow: 40px 40px">hello<%2Fspan><%2Fspan>
   Proposed to make box-shadow default to the value of the 'color' property
     on the element being shadowed. Computed value doesn't have a color if
     it's not specified.
   RESOLVED: box-shadow as above

   fantasai: We fixed some definitions surrounding border-image and SVG.
             We need review to ensure they're correct.
   fantasai: [explains the text in the spec]
   <fantasai> http://dev.w3.org/csswg/css3-background/#the-border-image-source
   <fantasai> "If the image must be sized to determine the slices (for example,
              for SVG images with no intrinsic size), then it is sized as for
              an auto-sized background, using the border image area as the
              default object size in place of the background positioning area."
   fantasai: If the image has an intrinsic size, you don't need to size it to
             cut it.
   ChrisL: It won't tile in the sense that you have only one copy of the image.
   dbaron: It seems there may be a solution where you just end up with one
           copy of the image.
   dbaron: Except you're doing sizing before doing slicing to fill the border.
   [some discussion]
   dbaron: I guess it's fine.
   <dbaron> (I still don't really know what it means, but I don't think it
   RESOLVED: Accept the ED text for border-image-slice.

   fantasai: next issue is animations.
   <Bert> ISSUE-215?
   <trackbot> ISSUE-215 -- Animatability of box-shadow: none to box-shadow: <shadow>
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/215
   fantasai: We added the Animatable field to the spec.
   fantasai: It should match transitions in general.
   fantasai: One different area is the box-shadow property.
   fantasai: We currently say "animatable: yes, but not between inset and outset".
             We'll deal with that kind later.
   <ChrisL> specifying animatability on all properties is good
   fantasai: And we say that transition to/from an absent shadow is between
             "0 0 transparent".
   fantasai: So you can transition between box-shadow:none and box-shadow:<something>

   tantek: Is there a reference to what we mean by "animatable"?
   fantasai: yeah, the transitions spec.
   tantek: So that's a normative dependency?
   Bert: Not quite.
   dbaron: The idea is that specs that happen before Transitions, Transitions
           defines how they work.  Ones published afterwards, the spec defines
           how they work.
   dbaron: We're maybe racing with Transitions with this spec, but it's not a
           big deal.
   ChrisL: But every spec will end up with animation information?
   dbaron: Yes, when they next update.
   <ChrisL> ok, good
   tantek: For specs that are ahead in progress of Transitions, we should have
           Transitions contain that information.
   dbaron: I don't agree.
   fantasai: Unless someone has a *really good reason* why this is a process
             problem, we shouldn't worry about it.  It's better to be consistent
             and have all the specs work the same way.
   plinss: At TPAC we discussed transitioning between inset/outset shadows.
   TabAtkins: I don't think we have a good answer for it yet.
   fantasai: We'll address it in level 4.
   plinss: Okay.
   fantasai: That's all the issues, so Bert and I need to compile the list
             of changes.
   smfr: Issue - If going from 'none' to an inset shadow, need to support the 'none' being treated as "0 0 transparent inset".
   ACTION fantasai: if animating from none to inset shadow, need none to
                    behave as '0 0 transparent inset'
   <trackbot> Created ACTION-434
   <dbaron> (or for a list being shorter)
   <dbaron> (and none really gets treated as a 0-length list)
   RESOLVED: Accept ED text for all animatable properties.

   fantasai: So Bert and I will make the edits and compile the list of changes,
             then present before the next telecon.
   fantasai: So question, can we republish CR with the changes, or do we need
             to go back to LC.
   szilles: Did you do anything that would invalidate an existing impl?
   fantasai: Yes, we made the default shadow color more precise.
   ChrisL: You can do the minimum 3-week LC, and say you're not accepting
           any new features, but are only looking for feedback on the list
           of recent changes.
   tantek: Can we just go to LC directly?
   tantek: Or CR directly?
   [process discussion]
   plinss: We could potentially do a testsuite and go from LC straight to PR.
   fantasai: Last time we tried that with Selectors, it sat in LC for several
   tantek: I think that sending it back to LC communicates that it's unstable,
           which is wrong.  That part of W3C process is broken.
   fantasai: I agree with Tantek that the process is broken, and we need a
             way to errata a CR in-place.
   fantasai: But here, we have two options.  Go through LC, make it quick,
             and get back to CR.  Second is to make box-shadow default color
             undefined and stay in CR.
   [angry discussion about process]
   RESOLVED: Republish Backgrounds and Borders as LC in order to errata it
             as CR. Include an explanation of why we're publishing a LC --
             that it's still a CR-level draft, we just need to make errata
             'cuz the process doesn't allow for errata in CR.
   <astearns> the errata list should probably highlight the single issue
              that made LC required

Image Values

   fantasai: If anyone has any issues about LC, please raise them.
   sylvaing: I have a question about gradients.  Does anyone know how long
             they'll keep their prefixes around?
   sylvaing: It looks like FF has changed to accept the new grammar.
   dbaron: We attempted to make an additive change so we would support more
           of the new syntax values, but not remove support for anything yet.
   dbaron: I don't plan to remove things fro mthe -moz-gradient; I plan to
           remove that stuff when we unprefix.
   dbaron: We'll probably keep the prefix around for a bit, considering how
           used it is.
   florian: We'll probably drop our prefix the moment we go to unprefixed.
   smfr: We implemented gradients before the angle change, which means we
         can't update without breaking stuff.
   smfr: So we probably won't be able to drop prefixes for a long time.
   smfr: We can definitely do unprefixed correctly, though.

   Tab: smfr suggests moving element() to L4
   Tab: right now only Mozilla implements. If nobody else has plans, perhaps
        better to shift to L4?
   dbaron: How many implementations do we have of the other stuff?
   Tab: The other stuff is relatively simple
   dbaron: Why are we removing the hard-but-popular instead of the
   fantasai: If the spec is stable, then we should take it to CR and mark
             it at-risk.
   fantasai: If the spec is unstable, then we should hold it back.
   TabAtkins: Simon, would you be okay if we kept element() as at-risk as
              we go into CR?
   smfr: Yes.

   dbaron: Are enough things marked as at-risk?
   dbaron: Do we have two impls of object-position and image-resolution?
           And the rest of object-fit?
   fantasai: We have two impls of image-resolution.
   florian: We have code for object-* in our tree, but I don't know the status.
   plinss: What about a testsuite?
   sylvaing: We have some gradients test.  We'll contribute them.
   TabAtkins: I plan to make testsuite my next priority.

   fantasai: There's an issue from the community about the gradient syntax.
   Florian: We've debated this to death already.  What we have is a compromise,
            and it satisfies more people than any other compromise we've had.
   fantasai: For linear-gradient, it was a coin toss.
   fantasai: and it made the updated syntax less compatible with what's out
             there already
   dbaron: I suggest we mark everything but gradients as at-risk.  I don't
           want any of the other features to hold up gradients.
   [several]: That's fine.
   RESOLVED: Mark everything in Images 3 as at-risk except gradients.
Received on Sunday, 12 February 2012 00:12:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:15 UTC