- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 13 Mar 2016 08:37:33 -0400
- 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.
=========================================
Introductions and Agenda Setting
--------------------------------
- This discussion to set the agenda held no technical details.
Web Compat Challenges
---------------------
- tantek presented several types of web compat challenges the
working group faces.
- The first type is problems like 0 vs 0deg in CSS gradients,
where there is a common dependency on the web that breaks spec
compat.
These are handled on a case-by-case basis, and considerations
include:
- Some cases can be seen as an opportunity to make behavior
more author-friendly, if it's clear that this is
author-expected behavior.
(0 vs. 0deg seems to be such a case)
- The amount of pages that are affected should be taken
into account in decision making - though there was a
difference of opinion as to how much breakage is
acceptable.
- The reason for the original decision should be reviewed
before any changes are made.
- Implementers seem willing to make more severely-breaking
changes if the benefit to the platform is significant.
- In regards to gradients, this was narrowed down to three
options on which there was a straw poll:
1. Don't change gradients. Keep angle-parsing quirk to
transforms
2. Allow 0 || <angle> for gradients as well as transform
functions, but not in properties in general
3. Allow 0 to parse as <<angle>> everywhere (including not
in functional notations)
- RESOLVED: Angles can drop unit when value is 0
- The next type of challenge is when there are changes made for
web compat purposes, but they're not reported to the working
group.
- Though business decisions needs to be made, there was a
request for an e-mail to the working group informing them
of a deviation, even if no effort is made to follow up,
because this way at least the problem is being tracked.
- It was also suggested that the working group be more
receptive to this kind of e-mail.
- The third challenge was how do we get member sites to stop
depending on CSS vendor prefixes. The example for this issue
was the bug browsers had to introduce to keep Gmail working.
- The discussion started by trying to figure out how to put
more pressure on member organizations for problems like
this, however with many member organizations being very
large, their CSSWG representatives often don't have power
to make the changes.
- The conversation changed to how to give more agency to those
in the working group to encourage change in their
organizations.
- A step to move forward in some -webkit- cases is to update
at least the behavior to match the spec; this reduces
the implementation burden for vendor-prefixed properties.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2016
Present:
Rossen Atanassov, Microsoft
Takao Baba, BPS
L. David Baron, Mozilla
Brian Birtles, Mozilla Japan
Bert Bos, W3C
Bogdan Brinza, Microsoft
Rick Byers, Google
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre (via telephone)
Emil A Eklund, Google
Elika Etemad, Invited Expert
Simon Fraser, Apple
Daniel Glazman, Disruptive Innovations (via telephone)
Jihye Hong, LG Electronics
Joone Hur, Intel
Dean Jackson, Apple
Brian Kardell, jQuery Foundation (via telephone)
Brad Kemper, Invited Expert
Ian Kilpatrick, Google
Peter Linss, Hewlett-Packard
Cameron McCormack, Mozilla
Edward O'Connor, Apple
Simon Pieters, Opera
Xidorn Quan, Mozilla
Francois Remy, Microsoft
Florian Rivoal, Vivliostyle
Andrey Rybka, Bloomburg
Hiroshi Sakakibara, BPS
Simon Sapin, Mozilla (via telephone)
Hyojin Song, LG Electronics
Elliott Sprehn, Google
Alan Stearns, Adobe
Shane Stephens, Google
Ojan Vafai, Google
Jet Villegas, Mozilla
Philip Walton, Google
Levi Weintraub, Google
Greg Whitworth, Microsoft
Steve Zilles, Adobe Systems
Regrets:
Tab Atkins, Google
Dongwoo Joshua Im, Samsung Electronics Co.
Dael Jackson, Invited Expert
Chris Lilley, W3C
Scribe: fantasai (with tantek scribing when fantasai spoke)
Introductions and Agenda Setting
================================
[This discussion to set the agenda held no technical details.]
Web Compat Challenges
=====================
Problems like 0 vs 0deg in CSS gradients
----------------------------------------
tantek: I've gathered together a set of web compat challenges that
we're dealing with.
tantek: First web compat challenge we have, specific example to
illuminate problem.
tantek: And hopefully come up with ways to address in general,
rather than one-off case-by-case.
<Florian> https://bugzilla.mozilla.org/show_bug.cgi?id=1234357
<Florian> https://code.google.com/p/chromium/issues/detail?id=569703
tantek: Specific problem we ran into was 0 vs 0deg in CSS gradients.
tantek: All other browser engines allow zero, even though invalid
per spec.
tantek: They treat it as 0deg.
tantek: At this point content on the Web that depends on this,
tantek: nothing to do with prefixes.
tantek: When situation like this, how do we decide? Fix browsers,
fix spec?
<zcorpan> httparchive research i just did for this -
https://code.google.com/p/chromium/issues/detail?id=569703#c10
tantek: Wanted to see others reaction on this.
fantasai: I think what we do depends on severity of problem and
insanity of bug. In some cases might be reasonable and
tolerable, in some cases might be a good idea, in some
cases might be insane and nobody wants it.
glazou: We have some history about length and zero values,
glazou: With 0 vs 0px.
glazou: I think real question is, is this used in the wild?
glazou: How many web authors relying on it? Is it harmless to
allow in the spec?
glazou: These are right questions to ask.
[dino spits out some numbers]
zcorpan: http archive has 260 stylesheets from 247 pages
?: 47000 pages in the archive
?: so .050%
zcorpan: Seems slightly too much for this particular case.
<rbyers> http://www.chromium.org/blink#new-features
rbyers: On Blink, we have a process that we try to use.
rbyers: Try to make a change that's good for web, vs compatibility
risk.
rbyers: We can say how bad it is, using data here.
rbyers: This is pretty bad.
rbyers: But then ask here about how important it is.
rbyers: If it's important, sometimes weigh to breaking the web.
Florian: Looking at gradient compat stories, what I found is that
breaking a gradient can make a site completely unusable.
Florian: When background is given with no fallback color, can't
read the text.
<glazou> In other words, 0.05% is not significant and it's safe to
force the unit ; but that's also a religious choice
<shane> glazou - I think the point is that 0.05% *is* significant
and you'd want a really good reason to break that many
people?
zcorpan: Point about flexibility in grammars.
(earlier rbyers pointed out that Tab said parsing 0 as 0deg limits
grammar flexibility)
zcorpan: We can only have this workaround for specific features
where its needed, e.g. linear gradient. In that case
wouldn't affect grammars in general.
<rbyers> httparchive hits:
https://docs.google.com/spreadsheets/d/170E-EyADapdzl1dap92PDmZ9Vpm3VfxkwvZJRadDpcg/edit#gid=0
glazou: 2 things.
glazou: 1st one, is 0.05% is pretty insignificant. I don't think
it's to worry about.
glazou: Other thing is religious choice.
glazou: We don't deal with Fahrenheit.
glazou: From author's perspective, 0 is 0 and you don't need a unit.
glazou: Did consider in the past.
glazou: Same argument for 0 vs 0px.
glazou: Should we make the same choice today?
glazou: Isn't 0 the same as 0deg?
glazou: Whatever are the technical discussions and choices behind
it.
* fantasai points out that 0 and 0% are significantly different;
they have dramatically different behavior in some cases
glazou: Whatever choice we make today, are authors going to fall
into unitless trap again?
glazou: Will browsers be forced to implement unitless 0 again?
tantek: I think a lot of cases looking at stats for compat is
important.
tantek: Also once in awhile run into cases like this, where
authors do something that feel natural.
tantek: This can be an opportunity to improve the spec to be more
author-friendly.
<glazou> +1 to what tantek just said
tantek: If so, this may be worth fixing.
tantek: Let's limit author frustration if we can.
<Florian> +1
tantek: I'm a bit more sympathetic in this particular case towards
treating 0 as 0deg.
rbyers: Wanted to respond to .05% page loads being insignificant...
rbyers: Gone back and forth on .03 as limit.
rbyers: We've had businesses come to us and say "you just ruined
my business."
rbyers: .05% is 50,000 page loads a day. It's still a lot
<glazou> rbyers, with that argument, we kept prefixed properties
forever
plinss: I'm hearing a lot of arguments in favor of making 0 0deg
plinss: Nothing I disagree with.
plinss: But I remember we did this for a reason. I don't remember
what it was.
plinss: Let's not make this change without understanding the
reason for making this reason.
fantasai: This is not a recent change; it was built in to the CSS2
spec, it's how angles were defined. We kept those parsing
rules in CSS3 Values and Units. (This is before Tab's
time.)
fantasai: Main reason was probably parsing ambiguity. Right now
lengths are only units you can drop units. For example,
you can't write 0% as just 0. Like percentages, angles
are a different type of unit.
fantasai: Then ambiguity of whether 0 is a length or an angle. If
you also make it so you can drop 'deg', you can't
convert between 0deg and 0 lengths; if you can tell from
context you can guess, but we'll no longer be able to
tell difference between angles and lengths.
fantasai: Doesn't matter what unit, every length unit at zero is
equivalent. So doesn't matter the unit. But 0deg vs 0
length are two very different things.
<bradk> Tab said: This was never supposed to be valid. >_< We
should limit the spread of this incorrect pollution,
because CSS isn't going to change to make this valid in
general - it makes it harder to write unambiguous grammars
if any old dimension can be dropped when the value is zero.
<tantek> that's a quote from
https://code.google.com/p/chromium/issues/detail?id=569703#c4
<tantek> fantasai: we don't have any properties where this is an
issue now
smfr: In Webkit code, subtlety.
smfr: We're not parsing 0 as 0deg.
smfr: We're failing to parse the 0, and defaulting to initial
value of zero.
dbaron: For us the 0 makes us drop the whole gradient.
smfr: I'm confused about this and why our code doesn't do this, too
<shane> could we just require units inside calc expressions?
...
dbaron: Animation and Transition shorthands are a bit problematic,
dbaron: with regards to times.
dbaron: Developers often run into problem of some implementations
parsing 0 as 0sec.
dbaron: Those shorthands are a *huge* mess if unitless zeros can
be times or angles.
dbaron: The animation shorthand has 2 time and a number and ...
dino: Naming being ambiguous with timing function.
dbaron: That's a separate ambiguity.
dbaron: We may well end up having to change those too for compat,
unless other implementations are willing to fix.
Florian: If we move in general for unitless zero, then it
constrains our grammars.
Florian: It is natural for authors to use unitless zero.
Florian: So they're confused.
jet: We'd been talking wrt unitless zero.
jet: But we also have a problem with other unitless numbers. e.g.
behave different for 45.
smfr: That should cause us to drop the gradient.
[jet shows smfr a testcase]
philipwalton: People said that web devs use unitless zeros.
philipwalton: Sometimes it's not the web developer's fault.
Sometimes it's the minifier.
tantek: Is anyone seriously proposing using unitless zero
*everywhere*?
glazou: One thing, from author's perspective I think that allowing
unitless zeroes almost everywhere makes sense.
glazou: and it would be our task to define how any ambiguity makes
declaration unparseable.
glazou: If there's any ambiguity, then you drop the whole thing.
glazou: That would be more reasonable to do.
zcorpan: Another thing to consider here is quirks mode, where
unitless zero can be color or length.
zcorpan: The grammar ambiguity gets worse in quirks mode.
<glazou> good point
<tantek> like background
<zcorpan> https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk
<zcorpan> Actually background shorthand doesn't support the quirk
<zcorpan> (actually the color quirk is only for a few longhands so
it seems it's not actually an issue)
fantasai: Hard to remember order of values in shorthands.
fantasai: We already require %s to have a % at the end.
fantasai: e.g. if you say height 0% it will turn to auto.
fantasai: There's behavior differences already between 0 and 0%.
fantasai: The suffix on the 0 matters.
<franremy> +1 fantasai
<franremy> same for 1px vs 1fr
tantek: Sounds like we don't have consensus on allowing zero
anywhere.
tantek: There are several cases where that breaks things or makes
them worse for the authors.
tantek: So perhaps for purpose of this discussion, limit for
gradient issue.
[tantek proposes straw poll]
zcorpan: I think 0 was needed for rotate/transform/skew.
dbaron: Transform functions take as an argument "0 || <angle>"
explicitly.
tantek: Anywhere we accept angles, should we accept 0 as 0deg?
zcorpan: Do we have a list of properties?
Florian: I think from what we're hearing in the room, we can
resolve for gradients.
Florian: But not for everything.
Florian: dbaron said we already agreed to zero in a specific
context.
dbaron: It's not for degrees, it's for the argument to transform
function.
Florian: Apparently we can also agree in gradients accept 0 or an
angle.
Florian: I haven't heard anybody opposing this.
<bradk> transform: polar(0deg, 10px)
Florian: For broader discussion.
Florian: I'm not sure that discussion is easily wrapped up.
Florian: Anyone oppose zero in gradients?
tantek: Okay, so we could either do gradients as "0||<angle>"
* bradk not opposed in gradient
<dbaron> Gecko accepts angles in CSS for transform functions,
image-orientation, linear-gradient, radial gradient,
hue-rotate() filter
tantek: It leaves question to authors where some angles can be 0
and others cannot.
tantek: I'd like to re-raise that question, where else are there
angles where putting 0 would cause problems?
<SimonSapin> "0 | <angle>" in gradients seems harmless, as far as
I can tell
dbaron: [lists properties that take angles]
<glazou> blink also has 'rotate' and "motion-rotation'
franremy: Just wanted to mention that SVG transforms actually take
all degrees without a unit.
franremy: You can put rotate: 45 and it will just work.
franremy: Same property on HTML elements requires degree, whereas
SVG sides doesn't require.
<fantasai> franremy, can you clarify if that is CSS syntax or
attributes
<franremy> https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/transform
<franremy> transform="translate(30) rotate(45 50 50)"
heycam: I don't think we should take what SVG accepts in its
attributes as precedent for CSS syntax.
smfr: We have a difference in behavior in quirks vs standard.
smfr: we always allow unitless 0 for angles lengths and times
Rossen: Same thing in Edge.
smfr: It seems we always allow unitless zero for lengths, angles,
and times.
smfr: In gradients we sometimes parse 0 as color in quirks mode.
smfr: Make sure testing standards mode.
zcorpan: I think we should strive for interop in quirks mode.
zcorpan: So if you can drop that quirk in WebKit, that would be
nice.
<smfr> just filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=29413
rbyers: Just wanted to point out looks like transforms spec
doesn't technically allow the zero, but has examples where
0 is used
Rossen: In other words we are encouraging authors to use that by
example.
Florian: The argument for "it's a natural thing to do"
tantek: dbaron, what would be impact of adding 0 to other
properties?
dbaron: I don't think it would be a big deal.
dbaron: Unless something ambiguous in gradient syntax.
Florian: If some properties no browser accept zero in some cases,
then we might have opposite problem of authors expecting
it to not work.
<baba> Is '0.0' used as zero-length in current spec?
<zcorpan> 0.0 is the same here
<baba> Thank you zcorpan!
[smfr clarifies that this magic is only for gradient parsing]
fantasai: 3 options here:
1. Don't change gradients. Keep angle-parsing quirk to
transforms
2. Allow 0||<angle> for gradients, but not in properties
in general
3. Allow 0 to parse as <<angle>> everywhere (including
not in functional notations)
fantasai: Unless someone has something to add, suggest straw
polling on that.
plinss: Clarify on option 3, does that preclude cases where it is
ambiguities in shorthands?
<glazou> +1
plinss: Either need a rule to clarify in shorthand, or say
shorthand must require unit.
tantek: Shorthand must resolve how to assign values.
shane: We have rules for this.
dbaron: Those are pretty awful, though, and we accepted because we
had to.
<zcorpan> (unitless color ambiguity is apparently a problem in
webkit still)
Rossen: Forced on implementers, not by choice.
<SimonSapin> list-style: none none
Florian: Write everything that you agree with, star your favorite.
[argument over voting methods]
<franremy> fantasai: should we add ==> 4. Accept unitless angles
(for any value) <== ?
<fantasai> franremy, that's #3
<SimonSapin> franremy, that’s and I think should stay a
SVG-specific quirk
<fantasai> SimonSapin, franremy, ohyeah, I misread. Agree with
SimonSapin
<SimonSapin> what does * mean?
<fantasai> SimonSapin, favorite
<Florian> SimonSapin: * means preferred
[Straw Poll
fantasai 1, 2
Florian 3* 2
SteveZ abstain
glazou 3
dbaron 3 2
franremy 3,1*
tantek 3,2
shane 3*
zcorpan 3,2
Bert 1, 2, 3*
rbyers 3, 2
astearns 3, 2, distant 1
andrey-r abstain
bradk 3,2
bkardell_ abstain
smfr 3, 2
esprehn 3, 2
plinss 3 2
gregwhitworth 3
SimonSapin abstain
philipwalton abstain
dino 3*, 2
hober three, *two
Rossen #3, #2
Florian 三 二
vollick 3, 2
BogdanBrinza 3, 2
skk 3 ---> 2
smfr *3, 2
birtles abstain
jet abstain]
Rossen: Seems like 3 is most popular
tantek: fantasai, can you live with 3?
fantasai: Yeah.
tantek: No objections to 3?
RESOLVED: Angles can drop unit when value is 0
tantek: Impacts lots of specs
<SimonSapin> doesn’t it only impact Values & Units?
<SimonSapin> directly.
fantasai: No, only values and units.
ACTION fantasai: update V&U to accept unitless angles
trackbot Created ACTION-746
Web compat changes without informing the working group
------------------------------------------------------
tantek: Increasing order of difficulty!
Florian: Easy questions always take longer.
tantek: We discovered this problem (the 0 vs 0deg difference)
because Mozilla was one exception.
tantek: Hadn't heard about it from anyone else.
tantek: Clearly other browsers either ship like this by default,
whether accident or not,
tantek: Or get this behavior because they forked from such a
browser,
tantek: *or* they implemented because they fixed due to web compat
**and didn't bother to inform anyone else in the WG**.
tantek: You guys clearly implemented this to work with web content
out there.
tantek: But didn't report it to the WG.
tantek: What happened there?
tantek: If you had to violate the spec due to web compat, you're
supposed to let the WG know.
<smfr> wonders about the test suite coverage?
BogdanBrinza: For Microsoft it was a problem with scale.
BogdanBrinza: In last year or so we fixed over 5000 interop issues.
BogdanBrinza: Quirks to match other browsers.
BogdanBrinza: In most cases we try to work with other browsers.
BogdanBrinza: But have many teams. But not everyone has bandwidth.
BogdanBrinza: Agree with you that should discuss.
<SimonSapin> Even a raw dump of details on these 5000 issues would
be nice
* fantasai agrees with SimonSapin
Rossen: In most of the cases, we actually, our internal procedure
is to reach out to the list and other implementers and
figure out what is going on,
Rossen: especially for harder ones.
Rossen: One actual reason we have next topic, Tables, on agenda,
is exactly because of interop.
Rossen: We want to chase alignment among implementations.
Rossen: I want to reinforce what BogdanBrinza said.
Rossen: Scale problem when in a fix sprint.
Rossen: We have to go approve many issues.
Rossen: And that's obviously not something that happens that often.
Rossen: For us it was abrupt switch between IE/Trident and Edge.
Rossen: There were very different goals in Edge.
Rossen: We had bigger freedom to change things.
Rossen: Took opportunity to sprint rather than walk in the park.
Rossen: So yes, what you're saying resonates with us, and it's the
right way to do it.
Rossen: We use mailing list to discuss most.
fantasai: Most? 5000 issues, only < 10 reported?
fantasai: You violating the spec in 5000 cases and only reported
< 10?
Rossen: Browsers violate spec in many cases, only know if there's
a test case or content ...
dbaron: I think what Rossen was saying that most of those issues
were just bugs where they fixed the bugs.
Rossen: We match what others are implementing, whether or not it
matches the spec.
fantasai: If you're fixing a bug and haven't bothered to check
what the spec behavior is, that's a problem. If you're
violating the spec intentionally for web compat and
can't bother to send an email to www-style, that's a
problem in your process.
fantasai: If that's not in your process that's a problem for us
and we can't fix the spec.
zcorpan: A more pragmatic way to let the world know what you're
doing is to release your internal tests.
zcorpan: People can run those tests against other browsers and
find the differences.
zcorpan: And can convert tests to web platform tests so everyone
can run them.
<zcorpan> Rossen, BogdanBrinza; my idea about releasing tests is
like what opera did with presto-testo, i.e. dump in a
github repo without cleanup other than removing stuff
you don't want to release for some reason
<zcorpan> Rossen, BogdanBrinza; and use a license that is
compatible with someone else converting the test to
web-platform-test
Florian: I will issue same challenge to Mozilla, wrt Servo.
Florian: Servo does implement once in awhile.
Florian: But given it's a from-scratch implementation, I'm pretty
sure it's running into weird things often and not
reporting them.
Florian: So as fantasai said, same idea of actually reading the
spec and reporting to www-style.
<SimonSapin> (Re Servo, I think several of us on the team insist
we do report issue when decide to diverge from specs.
But we haven’t done a lot of interop work yet, so we
haven’t found a lot of these issues yet.)
tantek: So I think to be clear, the request is not saying that you
need to run a discussion. But send a heads-up.
tantek: Everyone has different business constraints.
tantek: But it seems reasonable to at least request an "FYI, we
found this web compat problem, we're shipping this change"
that kind of notice
tantek: The flip side of that is that we as a WG need to be
receptive to that kind of feedback.
tantek: I think we have enough experience to know that this is a
real problem for every implementer.
tantek: I'd rather hear the data and not have a discussion, than
not hear the data at all.
gregwhitworth: I'd say that we definitely try to... the majority
of them I actually pulled back on documenting as
many as I could.
gregwhitworth: We'd discuss, end up in this one wormhole.
gregwhitworth: That quickly wastes time even though.
dbaron: How are we going to conclude this discussion?
tantek: In the past, we've had a much stronger climate for yelling
at implementers for violating spec, but try to be more
receptive for filing bugs against specs.
tantek: At least in this room, can say we talked about in person,
but shouldn't turn into perma-thread.
tantek: Saying, "fyi, ship this thing beyond what spec things",
take that as input rather than upset at breaking the spec.
tantek: Should make that cultural change.
<Florian> +1 tantek
smfr: I looked at test suite repository, and there are 9 tests for
all of CSS Images.
smfr: We've all done a bad job of providing test cases.
dbaron: There are a bunch of tests in the mozilla import directory
<dbaron> also tests in vendor-imports/mozilla/mozilla-central-
reftests/images3 although they're all for
object-fit/position
tantek: If there's anything MS would like to see from WG to be
more supported in sending this information to the WG...
BogdanBrinza: I might've set the wrong tone here. I don't think we
are deliberately not reporting spec violation we
identified.
BogdanBrinza: Might've fixed things that were spec violations and
didn't identify it.
BogdanBrinza: Not a problem with WG. Conversations with WG have
been helpful.
BogdanBrinza: But checking bugs, we fixed 4000 bugs for web compat.
BogdanBrinza: History for specs/w3c/CSSWG/ things like that, a
very small number of bugs correlate with what we
reached out to.
BogdanBrinza: Others mostly edge issues.
BogdanBrinza: Not sure why we talk about this anymore.
tantek: I'd like to ask chairs that we take a break then, before
next discussion.
[break]
How do we get member sites to stop depending on CSS vendor prefixes?
--------------------------------------------------------------------
Rossen: *gavelgavel*
Rossen: Continuing topic...
[technical problems]
tantek: In the third topic on web compat this morning.
tantek: Question is, how do we get Member sites, in particular, to
stop depending on vendor prefixes and other browser-specific
bugs.
tantek: The specific bug, since we picked on Microsoft last time,
is Google -- bugs in Gmail
tantek: Depending on either prefix properties, and not using
standard versions.
tantek: Or relying on bugs in their browser.
tantek: Here we have Edge copying a bug from Blink, because they
didn't really have a choice.
tantek: Members have sites on the Web. Gmail is one example.
tantek: How can we fix these problems, at least on Member sites?
rbyers: The question has a fundamental misunderstanding, we don't
have much access to the Gmail people.
rbyers: Sometimes web developers just don't want to fix the bug,
because it's not worth it to them.
rbyers: We can't change that.
rbyers: We can do outreach.
rbyers: And we can make decisions in the browser.
rbyers: In some cases we have a stupid bug in Chrome, and we have
Google properties and others depending on.
rbyers: Talk to them, and then risk seems good, we just break them.
rbyers: That's our only fallback.
rbyers: There's no side channel, due to member of CSSWG.
fantasai: Google's motto is don't be evil, designing your websites
to only work in your browser is evil.
fantasai: The people at the top of Google should care.
fantasai: If there was a way to say here are all the places in
your web code that you're doing evil things,
fantasai: and then get that list to some VP higher up,
fantasai: because right now individual Gmail properties are doing
their own thing,
fantasai: but if you for example focus on performance, why can't
you do that for compat?
rbyers: When I dig into these cases, it often boils down to not
some dev being ignorant, but our failure as a standards
group to not properly spec things and our failure as
browser vendors to make things interoperable.
rbyers: We need to invest in interop, testing, etc.
rbyers: When you look at some really rich sites, they didn't have
an alternative.
fantasai: In this case there was a reasonable alternative though.
There is an easy standard way to fix it but they're not
doing it.
Florian: So the "don't be evil" is one way of framing it.
Florian: But when framing as "just like other website", it's not
true.
Florian: Google isn't just another website.
Florian: It's pretty major, and also it has its own Chrome
browser, which building for itself is kind of an
antitrust problem.
<dino> I was just going to say that I agree with rbyers.
glazou: I think we're making a confusion here about the role of
the CSSWG
glazou: Our role is not to be evangelizing the whole world
including the members.
glazou: The browser vendors have evangelists for that, and the
motto that is used for politics "...all press is good
press."
glazou: I suggest as an answer to evangelists to do their job, and
they can use the press when needed.
glazou: Bar press will be enough to trigger a change
glazou: With regards to Gmail, I think Google's business is based
on collecting data from everyone.
glazou: And everyone means everyone in every platform everywhere,
so if one of their major properties is broken in other
browsers, it's a big problem for them and they're going to
fix it.
esprehn: This is starting to become a legal matter... gotta stop.
esprehn: Microsoft and Google have many tens of thousands of
employees.
esprehn: The members here have no power,
tantek: That's why brought it to WG, looking for suggestions on
how to improve the situation.
tantek: I agree legal stuff is not something to discuss here.
tantek: But I think your analogy to Windows is incorrect.
tantek: If you said Outlook.com, might agree.
tantek: I think fantasai's point, that you have a chain of command
that you can walk up,
tantek: that's a difference that you can effect change in your own
company in a different way to someone from outside.
tantek: Another problem is that your bug databases are internal,
so we can't apply any outside pressure.
tantek: Another possibility is that when we find these kinds of
bugs,
tantek: we file them at W3C.
tantek: Have it be something we can openly track, as something
that is causing problems for the Open Web.
<glazou> yes tantek, and that's the max we can do ; the rest is in
evangelists' hands
tantek: Making that bug list more open, makes it easier for us to
apply more pressure.
<dino> i think rbyers original point was not "Sometimes web
developers just don't want to fix the bug, because it's not
worth it to them.". They *do* want to fix the bugs, they
just don't have time. Like all developers.
rbyers: I think argument applies in other direction as well
rbyers: Chrome exists to make the Open Web great.
rbyers: Google being a collection of small independent teams means
that Chrome does things in the interest of the Web that
are not in the interest of Gmail.
rbyers: I think there's a risk of compat ...
rbyers: Just because bug on our site, doesn't mean it's elsewhere.
fantasai: Google's properties are often the tipping point for
bugwards fixes at Microsoft and Mozilla.
tantek: This problem is specific to us. There is a class of
problems where it's a member site that we're having to
make fixes in the browser for.
rbyers: We should have a higher tolerance for breaking a single
site.
tantek: So you're saying that Chrome would break Gmail?
rbyers: Yes.
tantek: I think that's a really strong show of good will
<glazou> extremely
tantek: So let's acknowledge that.
tantek: Let's turn the question back around.
tantek: How can we help you make those kinds of breaking changes?
tantek: When we run into this kind of problem, having to introduce
hacks into our browsers to fix Google bugs, what can we
give you to make that breaking change?
rbyers: Show us why we should fix the bug, instead of keeping it
and ignoring your spec.
rbyers: Why is the spec better?
<rbyers> To clarify exactly what I said: we strive to balance
what's best for the health of the open web and what's
best for our users. What company owns the specific sites
that are broken by a change is irrelevant. But that
doesn't mean we'd cause undue user pain for the sake of
making spec authors / WGs happy.
glazou: Reminds me of arguments I heard 20 yrs ago.
glazou: I'm not sure I'm that sympathetic to this kind of argument.
glazou: Breaking the web to introduce things you think are good
for the Web, I thought this is the task of the W3C, not of
Google.
glazou: If you want to break the web, do it with us, don't do it
yourself, don't do it alone
glazou: If you do that, you are breaking interoperability for
awhile.
glazou: This affects users of other browsers.
glazou: If we don't break it together, this place the CSSWG and
other WGs and other committees, are for evolution but
also...?
glazou: W3C doesn't write standards, Members write standards.
glazou: Let's do that all together, please.
<tantek> The specific example
https://code.google.com/p/chromium/issues/detail?id=559258#c14
is about requiring -webkit-border-image
(and not including unprefixed border-image)
tantek: Wrt "show us why we should fix the bug, instead of
ignoring the spec"
tantek: Specific instance is both Gmail and Gcal require a
prefixed version of border-image.
tantek: The question here is, do you think it's okay to force
other browsers to implement -webkit- prefixes?
rbyers: So first of all, nobody is forcing to do anything.
Everyone makes their own choices.
rbyers: Do I think other browsers should implement -webkit-? sure.
We implemented IE6 hacks.
rbyers: I think Edge has done a great job of doing this, balancing
fixes with maintaining architectural integrity.
rbyers: Pushing back on Chrome to fix their problems.
tantek: Okay, let's record that you would prefer that rather than
fixing Gmail, other browsers should implement -webkit-
prefixes.
rbyers: If it's a case that -webkit-border-image and border-image
are the same, and the benefit is not having an alias, then
let's just add the alias.
fantasai: There's a behavior difference as well.
fantasai: It's fairly easy to fix, but here is one.
Florian: This isn't new.
Florian: Last time we discussed adding -webkit- prefixes Google
was completely sympathetic, because couldn't remove it.
fantasai: It's about the effect of the border-image affecting
layout.
fantasai: In the prefixed version, it affects layout,
fantasai: In the standard version, if you hadn't loaded the image
yet, or link is broken, the layout would remain stable--
consistent with a loaded image.
fantasai: You could fix the way that behaves by changing the
border declaration that you have,
fantasai: so that the border-image and width match.
rbyers: Bug in this case, I can look for it.
rbyers: Maybe we can fix things gradually by, e.g. turning
-webkit-border-image into an alias to border-image without
the differences.
tantek: If the prefixed version requires more implementation,
reverse engineering etc., then we will likely pushback.
rbyers: We have examples where this worked well.
fantasai: If it's just an alias, that's more palatable.
rbyers: At last BlinkOn, we discussed making compat better for the
Web.
rbyers: Came up with pragmatic solutions.
rbyers: Sometimes have simple APIs to add to give a better
transition path.
rbyers: How to make very easy to for devs to migrate.
rbyers: Chrome use of webkit prefix is also a lie, we inherited it
from WebKit.
Rossen: Sounds like we're done.
tantek: Hopefully should minimize necessity of replicating bugs.
tantek: We can try moving forward with that with case by case basis.
rbyers: Chrome has open process for this stuff, Intent to
ship/deprecate/remove.
rbyers: Happens on blink-dev
rbyers: Look for "intent" in subject line
rbyers: There's nothing that happens as part of that process that
isn't accessible to you.
fantasai: The main problem here isn't Chrome, it's other teams at
Google and trying to get them to pay attention.
<rbyers> Here are slides and video for the interop discussion I
mentioned:
https://docs.google.com/presentation/d/1pOZ8ppcxEsJ6N8KfnfrI0EXwPEvHwg3BHyxzXXw8lRE/edit
Received on Sunday, 13 March 2016 12:38:31 UTC