[CSSWG] Minutes and Resolutions Paris F2F 2012-02-07 Tue Afternoon I: Webkit Prefixes Cont., css3-background, css3-images from fantasai on 2012-02-12 (www-style@w3.org from February 2012)

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

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 ======

Present:
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)

Observers:
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
http://www.slideshare.net/LeaVerou/css3-a-practical-introduction-ft2010-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
together.

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
border-width).
"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'
border.
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>hello<%2Fspan><%2Fspan>
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>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>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
matters.)
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
years.
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
simple-but-nobody-cares?
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