W3C home > Mailing lists > Public > www-style@w3.org > March 2016

[CSSWG] Minutes Sydney F2F 2016-02-01 Part I: Web Compat Challanges

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 13 Mar 2016 08:37:33 -0400
Message-ID: <CADhPm3tWBJBJ-iDn9nDVUg87PFXG_6u0-d4qjqUfXWPr72cFuQ@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

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
      These are handled on a case-by-case basis, and considerations
        - 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
        - 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
          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
      - 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
      - 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.


Agenda: https://wiki.csswg.org/planning/sydney-2016

  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

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

  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:

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

  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

  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
  <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
  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
  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>"
  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
  dbaron: It's not for degrees, it's for the argument to transform
  Florian: Apparently we can also agree in gradients accept 0 or an
  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
  <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
  <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
  Florian: The argument for "it's a natural thing to do"
  tantek: dbaron, what would be impact of adding 0 to other
  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
            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> 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
  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

  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

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


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
  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
  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
  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
  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
  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
  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
  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
  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
  glazou: W3C doesn't write standards, Members write standards.
  glazou: Let's do that all together, please.

  <tantek> The specific example
           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-
  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
  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
  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
  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
Received on Sunday, 13 March 2016 12:38:31 UTC

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