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

[CSSWG] Minutes and Resolutions Paris F2F Monday Morning 2012-02-06: Administrivia, Vendor Prefixes, Property/Value Alias OM

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 07 Feb 2012 09:41:00 +0100
Message-ID: <4F30E39C.9030405@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Administrative
--------------

   - RESOLVED: San Diego meeting, August 13-15, hosted by HP

   - Discussed ways of handling traffic on www-style. Chairs to play
     a greater role in shutting down useless threads, as identified by
     members. Tantek and fantasai to write etiquette guidelines / FAQ.

   - RESOLVED: Move to Mercurial for specs, work on docs / setup.

Vendor Prefixes
---------------

   Discussed problem of WebKit monopoly on mobile and the consequent
   pressure for other engines to implement -webkit- properties. See
   also Tantek's questions at
       https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#questions_and_methodology

Aliasing
--------

   Aliases are used both for vendor prefixed / unprefixed property pairs
   as well as for the word-wrap/overflow-wrap property and for the page-break-*
   properties (which are aliased to break-*). We discussed what, exactly,
   aliasing means:

   RESOLVED: When a browser supports multiple syntaxes of a single property,
             they're treated as aliases in the cascade, such that last
             wins. In the OM, *all* variants show up, with equivalent
             values, regardless of which version was specified or which
             won.
   RESOLVED: The last resolution applies to WG-approved aliases. It MAY
             be used by browsers for handling prefixed versions as well.
   RESOLVED: When value aliases are supported, return the version that
             the author provided.
   RESOLVED: In media query feature strings, also return the version
             that the author provided.

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

Present:
   Rossen Atanassov (Microsoft)
   Tab Atkins (Google)
   David Baron (Mozilla)
   Bert Bos (W3C)
   Tantek Çelik (Mozilla)
   John Daggett (Mozilla)
   fantasai Etemad (Mozilla)
   Simon Fraser (Apple)
   Sylvain Galineau (Microsoft)
   Daniel Glazman (Disruptive Innovations)
   Vincent Hardy (Adobe)
   Koji Ishii (Invited Expert)
   Håkon Wium Lie (Opera)
   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)

Agenda
======
ScribeNick: dbaron

   Daniel: How much time for regions?
   Vincent: 2+ hours would be good
   Daniel: I suggest we break around 12:00 or 12:30 to avoid crowds.
   Daniel: means we have roughly 2.5 hours for this morning
   Daniel: Maybe start with review of documents that want to publish
           LC, CR, etc.
   fantasai: Most of those have issues.
   jdaggett: There's some coalescing of the agenda that could be done
             (by modules).
   jdaggett: Maybe talk about logistics, San Diego meeting, etc.

Upcoming Meetings
=================

   Vincent: So for Hamburg, I sent an email.  There's an event in
            Hamburg at the time of the meeting: the port anniversary.
   Vincent: The city apparently gets pretty busy.  It starts on Friday,
            the last day of the F2F.
   Vincent: Originally when I talked to people in Hamburg they said it
            wasn't a problem; now they said we need to make reservations.
   Vincent: We've blocked rooms in some hotels until end of the week;
            people should make reservations.
   Vincent: We need to renew the hotel room block week by week.
   (discussion of trains)
   Daniel: So we stay firm on Hamburg?  OK for everyone?  Book soon.
   jdaggett: Håkon offered to host in Oslo, too. Should we consider that?
   ?: Would need to coord with SVG
   Daniel: ok, let's keep Hamburg
   Vincent: The Adobe rates for hotels should be better than the ones on
            the meeting page.
   Vincent: Just the worry that other hotels will fill up.

   Topic: August meeting
   jdaggett: Wiki now says week of 13-17
   jdaggett: We didn't lock down which dates
   peterl: I can host at HP or somewhere downtown.  (?)
   SteveZ: middle 3 have least impact on weekend
   Håkon: I'd prefer close to weekend.
   jdaggett: Prefer 13-15
   Daniel: Better to stay over a Saturday night, otherwise plane fares
           triple.
   Daniel: Probably having weekend before the meeting best.
   Florian: Earlier the better for me... week ...
   Håkon: Ideally the next week for me.
   SteveZ: next week fine for me too
   Daniel: The week after (20-22) could be better for airlines if you
           fly Europe to US because it's the end of the holidays...
   jdaggett: Week after would be tricky for me.
   RESOLVED: San Diego meeting, August 13-15, hosted by HP
   Next meeting after that is TPAC, Lyon

www-style
=========

   Daniel: There was a thread on www-style to split the mailing list to
           multiple lists.  I strongly object.
   Daniel: It would double or triple the work the co-chairmen have to
           review items for agendas.
   Daniel: The new mailing list will double or triple the threads and
           new people will never know where to post something.
   jdaggett: Could an advocate for splitting the list explain their
             position?
   fantasai: I'm worried about the level of traffic.
   <something about traffic growing to fill vacuum>
   Tantek: I agree with what Daniel said.  I'd go further and say w3c
           has too many mailing lists.
   Tantek: If anything, we should be looking at collapsing.
   Tantek: I see no reason for fx list to exist; it should be rolled
           into www-style ASAP.
   Tantek: I think forking of mailing lists and then growing to be too
           big has been happening the entire time I've been at W3C.
   Sylvain: Is the number of lists a problem?
   Tantek: Yes, because of the effect Daniel speaks about.
   Florian: Each single list grows to be the maximum amount one person
            can read.
   Tantek: Splitting lists doesn't lead to less traffic.
   SteveZ: It's difficult to split because topics last for some period
           of time and then tends to die out.
   Bert: Agree there's too much traffic.  Nearest after this is WebApps.
         www-style is 40% more than WebApps and double the next.
   Florian: Yes, there's a lot of traffic; but splitting won't help.
   Daniel: We invited the public -- this is part of the bad side of that.
           Second, we could probably stop better a few useless threads.
   Daniel: Peter and I cannot monitor everything.
   Daniel: If you ping us during the week to ask us to please step in
           and stop it, we can do that.
   Daniel: That's happened a few times, and we can try doing it more.
   Tantek: That's good -- it puts the responsibility on all of us to
           help reduce useless threads.
   Florian: There are some where it's easy to say it should be stopped,
            and some not, because they are on topic, just not making
            progress.
   Simon: And people need to fix the subject line when the topic of the
          thread changes.
   Tantek: Do we have a www-style FAQ for new people on the list?
   Daniel: We tried that back in 1997 or beginning of 1998; it was
           painful to send the FAQ every 2 weeks or month.
   Tantek: I think we could try again.
   fantasai: Let's (Tantek & I) try to write an FAQ and connect it to the
             archive page and send it out once and see if it helps.
   Bert: It's technically possible to send when someone subscribes.
   Tantek: Sending to the list is better because everyone knows everyone
           else has received it.
   Daniel: Can we get rid of people as a last resort?
   Bert: We can unsubscribe somebody from a list or we can ban somebody
         from all mailing lists.
   Anton: I think the signal to noise ratio is still pretty good.
   Anton: And people need to put [spec] at the start -- we can filter on
          that.
   Tantek: That could be material for the FAQ.
   (fast discussion between Tantek and fantasai about retitling threads,
    authority to tell people to stop or to change the topic)
   Tantek: Issue is 2 people quickly replying back to each other.
   fantasai: Tantek & I will write up something and then post it once or
             twice, not regularly. We'll have Bert link it from the
             archive page.
   ACTION fantasai with Tantek to write a FAQ for www-style
   <trackbot> Created ACTION-418
   Daniel: Don't send to www-style immediately so WG can review it first.

W3C Mercurial for Dummies status
================================

   dbaron: I wrote some parts, I think others wrote more parts
   jdaggett: Have we made a decision to go to Mercurial?
   Tantek: No, this is one of the dependencies.
   jdaggett: I think one of the key items is getting history from CVS
             to Mercurial.
   fantasai: We'd do that, but first we'd need to decide to switch to it.
   dbaron: It is possible.
   Håkon: It's a lot of work to make the switch; what's the benefit?
   Håkon: It's small projects.
   <smfr> cvs -> mercurial: http://mercurial.selenic.com/wiki/RepositoryConversion
   Tantek: I tried to look at the document and ran into numerous problems
           in the installing mercurial step -- added problems to the wiki
           page. Stopped there.
   Tantek: The quality of document is not up to par with the CVS document.
   <smfr> http://wiki.csswg.org/tools/hg

Scribe: fantasai
   dbaron: I don't know if anyone alleged the document was complete yet
   dbaron: I'll also note the CVS doc contains all the problems you run
           into because you ran into them and put them there.
   dbaron: You can't build up that kind of documentation without that
           experience.
   dbaron: Peter wrote the Installing for Macs section
   questions of what problem is being solved
   fantasai: We're starting to fork specs a lot, and CVS doesn' let us
             do that with history
   dbaron: are we planning one repo per spec or one repo for all specs?
   tantek: I think that's a separate topic
   dbaron: The setup is doable. Question of whether to use it is important
   tantek: I don't want to switch to a system where people don't document
           their problems.
   dbaron: Mercurial is a one-line install on Linux
   tantek: We shouldn't be discussing cvs vs mercurial, we should switch
           to git
   fantasai: Doesn't make sense to switch to git when our test suite is
             in Mercurial.
   plinss: Hg vs. Git, I don't see a significant advantage of git over
           Hg, and the rest of W3C uses Hg. I don't think there's a
           benefit for us to be different.
   jdaggett: Ok, seems to me there's enough other variables for moving
             to Mercurial, and we just need to get it set up.
   jdaggett: I think what Rossen said is key: having a simple setup on
             Windows
   glazou: If you want to make it easy on Windows, you just get the
           Mozilla build tools, and it's one click.
   dbaron: The Hg installer on Windows is just as easy

   jdaggett: There's a secondary issue, which is, a lot of our specs
             are still using Bert's tools.
   jdaggett: It's not set up to run locally, which to me is a problem.
   jdaggett: I see comments, I have to get Bert to add a biblio entry
   Bert: you can add that yourself
   Bert: I put it as a CGI script so people don't have to install things
         locally, but we can do that
   jdaggett: I think one of the things we have to do is move some of
             that infrastructure to whatever we're switching to
   jdaggett: So that I just have a Makefile that will make in my directory
   jdaggett: The problem is the bibliography is still in the old CVS
             database
   Bert: hmm, that could be tricky to move...
   jdaggett: Should make it easy for people to do it locally, and then
             for you, you have an extra step to get it updated on the
             server
   jdaggett: There are details in the script that need updating. E.g.
             script doesn't know how to generate descriptor tables for
             @rules
   Bert: yeah, sure, I can do something about descriptors
   jdaggett: If the build script is in the same system as the specs and
             can run locally, then other people can also help improve
             the build scripts
   smfr: How much work is it to enable Make to run offline?
   dbaron: I had it working a few years ago, but then upgraded and
           doesn't work anymore
   jdaggett: Uses tools
   smfr: Would like to be able to just check out Hg repo and be able
         to run Make
   Bert: Might be easy on linux/Mac, unsure about Windows
   dbaron: Didn't somebody reimplement Bert's script?
   smfr: can't effectively work offline if we can't build offline

   smfr: i don't think we should block on the document
   glazou: That was what we decided
   tantek: plan was to work on the document, nothing happened
   fantasai: document was worked on. Just nobody ran into your problems,
             so those problems weren't documented.
   Tantek: Nobody ran into problems?
   Nope.
   Tantek: Maybe I should switch to QA.
   plinss: Might help to link directly to Mercurial installer instead
           of MacPorts
   jdaggett: I think we've resolved that we will switch to Mercurial,
             and we will work through the problems people have.
   Tantek: What about working offline?
   jdaggett: It's a separate issue.
   plinss: I think we can set the direction
   jdaggett: The issue I brought up, even if we don't go to Hg, still
             exists
   glazou: The proposal is to move to Hg and fix the documents later
   RESOLVED: Move to Mercurial, work on docs.

   fantasai: I think we need to work on some details about the move.
   fantasai: (inaudible) pull and rebase (inaudible)
   plinss: I don't want to have 3-4 different Hg docs on our wiki.
   plinss: Not have separate docs for specs and testing
   glazou: Break now. Vendor prefixes later.

Vendor Prefixes
===============

   glazou: Title is: Why and How to Implement Other Vendors' Prefixes
   tantek: This is a specific subtopic of vendor prefixes
   tantek: The problem statement right now, and this is a problem for
           Mozilla and any other non-WebKit browser
   tantek: Sites have webkit-specific content, and serve backup content to
           everyone else. Specifically for mobile content.
   tantek: Non-WebKit browsers face prisoners dilemma
   tantek: similar to quirks in 2003 or so
   tantek: At this point we're trying to figure out which and how many webkit
           prefix properties to actually implement support for in Mozilla
   plinss: Zero.
   tantek: Currently we have zero. Zero is no longer an option for us.
   Florian, Sylvain: Zero is not an option for us anymore either.
   tantek: We're doing an analysis of what properties we need to consider. I
           want to minimize this.

   glazou: A long time ago, Mozilla had an Evangelism team that would call up
           the website owners and ask them to change.
   Florian: Opera has a large and active one, but it does not scale.
   Florian: I found on the rough analysis of top 1000 websites, several percent
            use webkit prefixes without a fallback for others.
   Florian: Regardless of how we ended up here, if we don't support webkit
            prefixes, we are locking ourselves out of parts of the mobile web.
   sylvaing: -webkit-text-size-adjust was implemented in IE. So we pulled it
             out and asked that it be submitted for standardization. But it
             wasn't. *looks at smfr*

   tantek: We don't consider this a long-term situation. The goal is to open
           up the webkit-specific part of the web to others, same as implementing
           parts of IE-specific web.
   tantek: We do have some experience in not screwing this up.
   tantek: But it has come time to discuss this publicly. I have put our data
           and findings on public wiki pages.
   tantek: I'm bringing to this group b/c affects more than just Mozilla.
   tantek: If we come up with a solution together, we can hopefully minimize
           the problem.
   plinss: You said this is a short-terms solution. Quirks mode was supposed
           to be a short-term solution.
   tantek: No it wasn't.
   plinss: Yes it was.
   plinss: I implemented it before you did.
   plinss: The intention was to solve a short-term problem. It was supposed to
           be gone in a few years. We're stuck with it.
   plinss: If we open this Pandora's box, we're going to be stuck with it.
   plinss: If people implement other vendor prefixes, then everyone will
           implement others prefixes and we'll be stuck with it forever.
   Florian: We are currently losing market share because of not implementing
            -webkit- properties.
   glazou: Do you have a -o- version?
   glazou: I can write an add-on that converts the style sheet.
   dbaron: What's the difference between that and implementing it in the engine?
   Tab: Given the discussion is about webkit being a monoculture on Mobile, if
        webkit decides to remove a prefix then it's okay for everyone to remove
        prefixes also.
   Florian: Some prefixes will not be dropped by webkit
   glazou: None will be dropped.

   tantek: So this is not saying implement -webkit- across the board.
   tantek: This is consider implementing some -webkit- properties, and be very
           deliberate about which ones and why.
   tantek: We need to do analysis about how many sites we can fix and how much.
   tantek: I don't see authors being recommended to use webkit, b/c works mozilla
           as well. Goal is to get some sites working on Mozilla.
   tantek: When I was implementing Quirks mode in MacIE.  I didn't think it
           would be short-term at all.
   tantek: There were ~90 places where used switched.
   tantek: Over time, I was able to cut some.
   tantek: By the time Tasman got parked got to ~80
   tantek: Probably would never go to zero, due to box-sizing, etc.
   tantek: but some of those problems *were* short term.
   tantek: wanted to offer that as a data point.

   Alan: When you do analysis of site using webkit prefixes, do you go back and
         see whether implementing the prefix will fix that 10%?
   Alan: Or are there other complications where they're doing browser-sniffing
         or otherwise wouldn't work even if you implement these prefixes?
   Alan: I'm wondering about the efficacy of implementing webkit prefixes.
   tantek: None. We will also need to send a webkit-tricking UA string.
   tantek: Just like WebKit sent "like Gecko" in its UA string, we have to do
           the same thing again
   glazou: Two implementations will not fully match, but you will treat -o- and
           -webkit- as the same.
   Florian, Sylvain: Evangelism has failed.
   glazou: Have you tried pinging the WASP about that? Other activists of web
           standards?
   sylvaing: If MS can't scale to handle this, you think WASP can?
   tantek: Opposite is happening right now. Web standards activists are teaching
           people to use -webkit-
   tantek: People like Lea Verou.
   tantek: Their demos are filled with -webkit-. You will see presentations
           from all the web standards advocates advocating people to use
           -webkit- prefixes.
   glazou: Tab, how do you feel about that? Is there anything you can do?
   Tab: There's enough legacy content that there are some properties that we
        can't drop the prefixes.
   Tab: Given that's a reality for us, totally sympathetic that it's a problem
        for everyone else.
   Tab: These are used on production sites.

   smfr: Two categories of problem.
   smfr: We have things like Transforms, which are being standardized and
         implemented by other browsers.
   smfr: There's others like text-size-adjust, which is only proprietary on
         iPhone
   smfr: Not sure about standardizing things like that.
   smfr: Some of this is due to iPhone's success
   ...
   Florian: If something is intended for internal use, then it is proprietary.
   Florian: But once it's encouraged out on the Open Web, it cannot be
            proprietary anymore.
   Florian: The cat is out of the box.
   Florian: ... If you submit a spec about things like this, we're back into
            the other case.
   Florian: ...
   Florian: If we don't get specs for these, the problem is harder. But I
            think we should get specs for these.
   tantek: Once it gets served over the open Web, it is no longer proprietary.
   sylvaing: A lot of authors assume that any -webkit- property is in the
             standards process.
   ...
   jdaggett: Maybe use a different prefix?
   tantek: Once it's on the open Web, it's not proprietary
   jdaggett: -apple-, or -iphone-
   alexmog: Once Apple ships -webkit-, it's frozen.
   <tantek> it can be considered experimental, but claiming it is
            proprietary-only is inaccurate
   smfr: It's not necessarily frozen, might be changed.
   alexmog: We will never drop -ms-, or change -ms- behavior.
   ...
   Florian: It doesn't solve the problem.
   Florian: Whether it's -webkit-border-radius or -draft25-border-radius,
   Florain: You will get content depending on that.
   alexmog: Doesn't change the problem, but you can think about it differently.

   tantek: I have a couple of questions.
   tantek: Bringing to WG because I believe we can solve problem better together
           than individually.
   tantek: I'm going with assumption that none of us want to just implement
           all -webkit- properties.
   Tab: I don't even want to implement all -webkit- properties.
   <tantek> https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#questions_and_methodology
   tantek: What are the thresholds, even approximate, for implementing
           -webkit- properites (or none)?
   glazou: Unbelieveable we are having this discussion.
   Florian: Our job is to solve interoperability. We want to discuss it here,
            because that's our job.
   tantek: Help us minimize the damage.
   dbaron: Part of what Tantek is saying is that we want to look very carefully
           at the evidence to see whether we need to do this.
   dbaron: Can we get the draft to a point where we can unprefix?
   dbaron: E.g. 2D transforms, based on Aryeh's tests, are interoperable enough
           to drop prefixes right now.
   dbaron: Maybe revisit our decision to merge 2D and 3D transforms, and take
           draft to CR in a couple months.
   Florian: Might not be enough to solve the problem.
   dbaron: What Tantek is saying is that we're not going to look at this as a
           single problem.
   dbaron: The more we can unprefix, perhaps the less we have this problem.
   tantek: One possible proposal is to only parse other vendors' prefixes in
           conjunction with parsing unprefixed.
   tantek: e.g. with -webkit-transform. We wouldn't parse that until we also
           parse transform.
   tantek: Thereby giving authors option to just use unprefixed, hopefully
           biasing new authors to using that instead.
   tantek: That is one example of methodology that we want to apply to limit
           the damage of this.
   tantek: If you can think of other examples of ways of thinking about this,
           to provide ways of moving forward.
   tantek: We are absolutely open to other ideas.

   glazou: Simon said that Apple WebKit implemented -webkit-text-size adjust
           for better experience on mobile.
   glazou: I suppose this aims at mobile.
   tantek, florian: yes.
   glazou: This is replacing standardization by turning one implementation
           into a de facto standard.
   glazou: Instead of creating a de jure standard here.
   glazou: The right thing to do would be for Apple to submit text-size-adjust
           for standardization here.
   dbaron: I don't see why Apple has to write the spec if they're not writing
           the spec.
   dbaron: We dealt with this with IE6. Bunch of stuff we had to copy IE6 into
           the spec and implement that.
   Tab: IE6 monoculture of desktop. WebKit monoculture of mobile. It's the same
        problem.
   smfr: I can take a list of properties we need back and see if we can bring
         it back for standardization
   glazou: In a reasonable timeframe?
   smfr: Yes.
   dbaron: Off the top of my head, the only thing not in this WG that's a major
           issue is text-size-adjust
   Florian: -webkit-appearance
   ?: That's in UI. But was dropped
   fantasai: Maybe we need appearance: auto | none. (None of the other values
             are useful.)
   <tantek> https://bugzilla.mozilla.org/show_bug.cgi?id=708406
   tantek: Have to do crawls by switching UA strings. But here's our data.

   sylvaing: The -webkit-tap-highlight-color is very highly requested
   fantasai: I think that's a case that's not very critical. Nice to have,
             but not having it won't break anything. We should solve the
             problem it's solving, but don't think we need to implement
             exactly that.
   ...
   tantek: I think if you're working on open standards, you should propose
           your features before you implement them and discuss that here.
   smfr: We can't do that.
   sylvaing: We can't do that either.
   tantek: We're going to push you to do that sooner and sooner.
   jdaggett: If you're proposing something that's going to be put on a Web
             page, how is that proprietary?

   Alan: Do you agree with fantasai that tap-highlight-color isn't needed?
   Alan: Not asking about threshold. fantasai saying that it's not necessary
         functionality.
   dbaron: I agree.
   dbaron: Like Tantek said, i think we should look at each item carefully.
   dbaron: The problem we're trying to solve is that users don't want to use
           a browser because it doesn't support certain functionality.
   dbaron: Users don't really care about tap-highlight-color.
   dbaron: Users care about whether they can read the web page and can get
           to its functionality.

   tantek: Don't expect to come to a conclusion in this discussion right now.
           But wanted to raise the issue and raise the questions that will
           help us get to a better place.
   Alan: Right now the only consider is percentage of usage.
   Alan: If there are other considerations, like users don't care, that should
         be in your page.
   Florian: Looking at usage because it can be measured. Whether it breaks the
            website, much harder to measure.
   fantasai: I think we can make some subjective judgements on that.

   Florian: Properties is not the only thing, e.g. gradients.
   Florian: device-pixel-ratio is another problem.
   tantek: Here's my challenge to non-Webkit vendors.
   tantek: Please document what properties you're thinking of implementing,
           and why. The why to me is more important.
   tantek: Because that is how we will derive methodology to minimize the
           properties we implement.
   tantek: I really want to minimize this.

   glazou: I think it's very unfortunate timing, esp. now that we're trying
           to use prefixes for JS APIs.
   glazou: You are solving a problem not with the right way.
   Florian: give us a better way
   glazou: You're saying that because you're saying the other ways did not
           succeed.
   Florian: We have 15-20 people in devrel, one of their primary jobs is that.
   Florian: It doesn't scale.
   tantek: Number of mobile websites providing webkit content first is growing
           faster than we can contact them.
   ...
   glazou: We're not just here to do things. We're here to do things the right
           way. We want things to be stable on the Web for 50 years.
   glazou: The technology, yes, it has to be readable.
   glazou: I don't think this is the right way. And this is the first time in
           this WG that we are proposing to do things that are not the right way.
   sylvaing: Many don't consider the right way to be good.
   glazou: You don't have to teach me about pragmatism.
   sylvaing: We have authors who actively write tools to avoid the right way.
   tantek: Want to close the discussion with a request for questions and
           methodology
   tantek: Request Opera and Microsoft to publish your methodology and what
           properties you're thinking of implementing.
   tantek: That way we can minimize the damage.
   plinss: As soon as we do this, vendor prefixes have failed.
   tantek: I don't think we need to throw out the baby with the bathwater.
   plinss: I think the fact that Mozilla is discussing this publicly is harmful.
   plinss: Nevermind actually doing this.
   Florian: So what should we do?
   dbaron: So what should we do, disband the WG?
   plinss: yes
   plinss: If we go down this path we have broken standardization.
   ...
   plinss: Let's back up a second.
   plinss: I think Alan raised the best point in this discussion. Your solution
           doesn't work unless you spoof as someone else.
   sylvaing: No, we did tests with text-size-adjust, just implementing it was
             enough.
   Tab: The biggest thing we're talking about is things like transforms. IP is
        already released.
   glazou: transforms almost interop, hope you will drop prefixes
   Tab: If they're thinking of implementing it, then we're probably not able
       to drop prefixes.
   Tab: We try to drop prefixes, but some things are too heavily used.

   Steve: I haven't heard anything new in the last 1/2 hour that I can detect.
   Steve: I would summarize that there's a practical problem out there, that
          should be trying to drive features to as quick standardization as
          possible.
   Steve: As a way of moving in that direction, attempting to implement an
         existing prefix is getting a spec out of it.
   Steve: If we cooperate on documenting what the prefix is, would help us
          drive towards standardization.
   glazou: I'm going to take problem from another point of view, from market pov.
   glazou: WebKit has a monster advantage out of this situation. Why would
           they help on standardization?
   glazou: I'm dead serious. Are you going to help them gain market share by
           standardization?
   smfr: We're members of this WG, and accepted the IP implications of that
         for transforms and stuff.
   glazou: But you submitted that directly. But not text-size-adjust.
   smfr: AFAIK we don't have a reason not to help standardization
         text-size-adjust.
   smfr: Think it slipped between the cracks; not enough impetus to standardize
         it.

   Alan: Mozilla and Opera have researched what are important for them to
         implement.
   Alan: The problem for you for this moment, locks in the problem for the
         rest of time.
   Alan: One alternative is that we can do this analysis, see here are the
         ones that it would help us to implement as a prefix, and treat
         those as house fires.
   Alan: These are things we need to standardize on *now*.
   Alan: Make it something that the WG finalizes within the next 3 months.
   Alan: Go out and say, here is the unprefixed properties. Get the word out.
   Alan: You fix the problem in a better way.
   Alan: Lose out a percentage on websites that won't get updated.
   Alan: But you stop the problem there.
   Florian: We have everything to gain by reducing the number of times there
            is a non-standard property used by a large number of websites.
   Florian: Yes we should minimize such situations.
   Florian: That will help in the future. But won't fix body of content
            already out there.
   Alan: Regardless of whether you implement those prefixes, this WG needs
         to prioritize the work accordingly.
   Florian: Strongly agree. Yet I think it is not enough.

   plinss: Thing we need to spend some energy minimizing the escape of
           prefixes into the wild
   plinss: Fact that production sites use them, it's okay if it makes it
           slightly prettier, but if not supporting breaks the site, then
           that's a problem.
   Alan: Devrel can't seem to get on top of that. Only thing this WG can
         do is not put them in releases.
   plinss: Should discuss putting experimental properties only in experimental
           builds.
   howcome: Should maybe put out a call to web authors to stop this.
   jdaggett: I think strategy of just pretending to be -webkit-, without any
             attempt ...
   jdaggett: You need to make public statements like "Here is an example of
             a presenter presenting -webkit- things as if they are a standard,
             and they are not."
   jdaggett: Need multiple people here to do that.
   howcome: Including Apple.
   ...
   Steve: Philosophical point. Standardization, when you control the consumers
          and the generators, is much easier.
   Steve: In good old days of telephones, ppl who made telephones and ppl
          who installed telephones were relatively small set. Could get
          interoperable standards and it worked.
   Steve: We are operating in an environment where we can't control users of
          our standards. We can influence them, that's point being made; but
          too many of them doing too little reading that we can impact them.
   Steve: This is just life.
   fantasai: Having standards advocates advocate prefixes is making the problem
             worse, cutting that off would improve the situation.

   tantek: Florian's point that we're competing against Flash and mobile apps
           is important.
   tantek: Telling web developers to stop using webkit properties would mean
           they stop writing web apps.
   tantek: I think it's great that Apple wants to innovate as fast as they
           can. I would prefer they propose to the WG, if not before
           implementation, then when implementing. If not then, at least
           when shipping. If not then with a few months, Simon?
   tantek: I don't want Apple to slow down in innovation and implementing
           new things. That helps the Web grow and innovate.
   plinss: Your point about if people can't write webkit properties they'll
           write a web app --
   plinss: I would rather they write an iphone app than they write a web app
           that only works on webkit.
   plinss: There's no advantage to the Web to have someone write a
           platform-specific website.
   tantek disagrees.
   Anton: I think it'll be very dangerous to make it obvious that we can
          implement each others prefixes without making it very clear what
          vendor prefixes are and how they're supposed to work.
   Anton: Need the WG to agree and explain what problem they're trying to
          solve with prefixes.
   Anton: I think it is harmful to concentrate on this one problem and not
          concentrate on the global problem. Send a very mixed message to
          authors.
   plinss: You're telling authors to just use webkit prefixes, we'll make
           it work.
   Tantek: No, we're only implementing a small minimized number of these.
   fantasai: But if you don't make that clear, and communicate that, it'll
             be interpreted as "if enough websites use it they will
             implement it".
   fantasai: Anton's point is that you need to send that message, and not
             just in the CSSWG minutes.
   glazou: If the user requests another -webkit- property, they will implement
           it. It's a Pandora's box.
   sylvaing: Listening to the conversation, sounds like this proposal is a
             big injury to the Web, that prefixes are a [...].
   sylvaing: I've sat in conferences where Eric Meyer show how to use prefixes
             and then put unprefixed version for "future proofing"
   sylvaing: Nobody gets it.
   sylvaing: We have people trying to evade the system. Problem is large.
   sylvaing: Prefixing works on theory in paper, and out in the real world
             everybody hates it.
   glazou: There's at least one way it didn't fail.
   glazou: If you use -moz- prefix, you have to test it in Mozilla
   glazou: If you use -webkit- you know it will only work in WebKit.
   sylvaing: The advice being given now is to include the unprefixed version.
             The system works in theory, in practice it doesn't work.
   tantek: My experience with authors is that they Hate using prefixes.
   tantek: If anything, they are annoyed with the CSSWG for taking so long
           to get specs to the point where they can be unprefixed.
   tantek: They complain that CSSWG takes too long.
   tantek: Second reason is they are evangelized to use prefixed stuff, e.g.
           -webkit-
   sylvaing: The people who think prefixing is a good feature, majority of
             them are in this room.
   glazou: Even if we only take 3 months from FPWD to unprefixed, it's too
           slow compared to shipping an implementation, which is then used
           immediately.
   Tab: We can break some people. But not everyone.
   glazou: Transforms emerged not long ago. Web is full of them.
   glazou: It took 3 months to have real life examples of ppl using transforms.
   Tab: I thought 2D transforms have been around for a while.
   Steve: Are we getting somewhere?
   tantek: I tried to close once with request with more questions.
   glazou: Seems that the 3 browser vendors here have already decided.
   dbaron: I think one of the underlying problems here...
   dbaron: The IETF has a motto "rough consensus and running code"
   dbaron: I haven't deal with them much. But I think one of the problems I
           sense in this group
   dbaron: is that it's just as easy to hold up a specification that has no
           implementations as it is to hold up a spec that's got 4
           implementations and everyone pushing to use it.
   dbaron: There should be a bias based on what the real state of something is.
   dbaron: What the state of implementations is.
   dbaron: When we've got something like 2D transforms thats implemented in
           4 major browsers and it's blocked.
   dbaron: Should be harder to put process blocks on that spec.
   dbaron: We have a test suite now, but we've agreed to abandon the spec.
   alexmog: I think implementations should use -rfc3300- prefix
   alexmog: have a draft that defines what that means, experiment with it
   alexmog: if it fails, it fails, if it succeeds, it's defined what it is
   sylvaing: ?
   alexmog: Not different from today, but don't have the moral problem of
            implementing another vendor's prefix

   Steve: First, RFCs are specifically withdrawn after 6 months. Spec
          disappears by definition.
   dbaron: That's a draft. Not RFC.
   Steve: We're not talking about specs. For the user to use things, there
         has to be documentation for the user.
   Steve: The problem is asking for documentation sufficiently well-specified
          for interop
   sylvaing: Both us and Apple document our things on our site, but not enough
             for standardization
   Steve: Suggest that group establish a goal that members who introduce
          experimental properties submit a description to the WG
   Steve: Maybe it just goes into a file somewhere, until someone wants to
          follow up
   Steve: But at least it becomes available to the WG, which Tantek was
         requesting.

   Florian: Said that there's no progress in this conversation.
   Florian: Some people are saying don't do this. But all the vendors need
            to do this.
   Florian: Blocking the conversation here just means don't do this in this room.
   Florian: The idea is to discuss the how.
   plinss: We haven't spent any time discussing how not to do this.
   Florian: I think we did enough on why.
   plinss: Only if the what else has failed should we go onto how.
   plinss: You have tried and failed individually. Not as a group.
   dbaron: a year ago we tried to discuss dropping prefixes before CR, and
           failed at that.
   fantasai: No, you added additional requirement of having the test suite.
   plinss: If you have a list of properties you have to implement to survive,
           then let's get that list, get consensus on it, and then agree to
           standardize them as-is implemented in WebKit.
   Florian: That only stops the bleeding.
   plinss: If we do this without a plan to stop the bleeding, it's only going
           to get worse.
   Anton: And will cause confusion.
   plinss: To go back to Quirks mode. The original intention -- it was
           intended for NS4, btw, not IE6 -- the problem was too many sites
           to fix, we have to support them.
   plinss: But we wanted to support only the old sites, and new sites should
           be written to standard
   plinss: People are still writing sites today that depend on quirks mode
           in order to function.
   plinss: People 20 years from now will be writing sites that support
           webkit prefxes.
   dbaron: There's a major piece of Web standards community, not well
           represented in this room, but better represented in HTML and WHATWG
   dbaron: They think quirks mode was a mistake. That we should have just
           lived with that behavior.
   plinss: I accept that as a philosophy, but that was impossible.
   plinss: NS4 did not treat HTML as a structured document.
   dbaron: I think quirks mode very quickly diverged from its original intent
   dbaron: Because 2 years after IE had 95%+ market share
   dbaron: It became about being compatible with IE, not NS4.
   plinss: If we launch this vendor-prefixed quirks mode, it's going to get
           out of hand. Whatever our desire to minimize our impact, it's
           going to get worse than what we expect.
   Florian: Not spread to everything
   plinss: Going to get worse than you expect
   dbaron: Email headers with X-. Supposed to be experimental. But the world
           still works.

   tantek: While I understand the analogy with Quirks mode, I disagree
   tantek: We can search for and get data on prefixed property use
   tantek: You can write a linter that points out your webkit properties.
   tantek: quirks mode you can start relying on accidentally
   tantek: I don't think this is as bad as quirks mode.
   tantek: Quirks mode biased being lazy.
   tantek: The policy we have for prefixes biases the right thing, which is
           no prefix.
   tantek: It takes work to use a prefix, whereas it didn't take work to
           use Quirks mode.
   tantek: I can see the similarities but in practice I think they're very
           different.
   plinss: My assertion is that it's still going to be worse than you think.
   plinss: People will write tools and inject things, etc.
   plinss: Authors are going to have this happen to them, because of tools.
   sylvaing: Once those -webkit- properties work in other browsers, are people
             going to check which ones work? Or are they just going to assume
             that all -webkit- properties work?
   tantek: It is up to us to make sure that the unprefixed properties are the
           most reliable.
   tantek: And that's how we end up driving off the -webkit-
   tantek: Being neat only drives authors so far. They want reliability. If
           we can deliver that with unprefixed
   plinss: We need to get in people's minds that if you use prefixed, we will
           drop support for it at some point.
   plinss: We should assert leverage to get MS and Webkit to change their mind.
   plinss: Prefix has half-life. It will live for so many years, then go away,
           by definition. That will help this problem.
   plinss: If we can get something like that stuck in the ground, then my
           objection drops dramatically. Because we've cut the bleeding.

   glazou: I heard earlier that prefixes are bug not a feature.
   glazou: Prefixes for web authors, they don't think it's a bug. They think
           it's a burden. It's not the same thing.
   glazou: It's a burden b/c they don't know how long they have to maintain them.
   glazou: If prefixes were only implemented for 3 years, that would help.
   tantek: mozilla has a policy of dropping prefixes when we implement unprefixed
   tantek: Web authors can know just by Mozilla, that prefixes are uncertain.
   tantek: IE10 broke many things. I would not be surprised if MS will drop
           prefixes at some point.
   <sylvaing> note that IE10 dropped legacy features from *standard mode*
   <sylvaing> Trident still includes legacy features for older docmodes;
              the latter are necessary for intranets for instance

   fantasai: We would not be having this conversation if mobile did not exist,
             correct?
   agreement
   fantasai: What if -webkit- was implemented only for mobile? That would add
             the unreliability factor that Tantek was asking for, because it
             would not work on desktop. And that would bias authors to using
             unprefixed, which is what we want.

<br type=lunch>

<glazou> for those who know him, Tristan Nitot from Mozilla Europe says hi
* sgalineau doesn't know Tristan, but knows of Tristan....
<fantasai> jdaggett, what were the text issues that you raised?
            (other than @text-transform)
* fantasai only knows about the issues in
            http://www.w3.org/Style/CSS/Tracker/products/10
ScribeNick: TabAtkins
<jdaggett> fantasai: i'm on drugs, issues were in writing-modes
<jdaggett> fantasai: but text-transform will take a bit of time i think
<fantasai> jdaggett, my plan is to cut anything that has issues that
            can't be solved between now and march 1st
<jdaggett> fantasai: in text?  writing modes?
<fantasai> jdaggett, text
<fantasai> jdaggett, unfortunately white space processing is not
            optional, so I have to fix all the issues in it anyway :)
<jdaggett> fantasai: so you're shooting for LPWD at end of march?
<fantasai> jdaggett, shooting for the beginning of march, hopefully
            make it by the end :)


Aliasing Details
================
ScribeNick: TabAtkins

   florian: When a browser supports several variants of the same property
            (either prefixed and unprefixed, or multiple prefixed), what
            does it look like through the OM?
   florian: If we favor interop here, we should decide what it says.
   florian: But David argues that we shouldn't favor interop here - the
            fragility helps discourage prefix usage.
   [some discussion over one impl strategy]
   florian: Another strategy is to always favor your impl, as it can
            let someone target your impl well.
   sylvaing: What do browsers do today?
   florian: We don't have a problem with it yet.
   dbaron: Gecko never implements different semantics for two things.
   dbaron: The only time we've had two things in gecko is with prefixed
           and unprefixed.
   dbaron: When we did that, -moz- was treated as an alias for unprefixed.
   dbaron: If you asked for the -moz- in the OM, you'd get back the
           unprefixed.
   dbaron: If you got the list of properties, you'd get the unprefixed
           as well.
   dbaron: It was meant to steer people toward the unprefixed.
   dbaron: Webkit supports multiple prefixes with different semantics.
   alexmog: In general, only cascading should matter. If a dev puts it
            there, it means that they want it.
   alexmog: If you have two prefixes, you should favor your own.
   TabAtkins: What about -webkit- and -epub-?
   alexmog: You should favor the -webkit-.
   sylvaing: Why is it different from prefixed and unprefixed?
   alexmog: I need to be able to target specific impls.
   sylvaing: So if -webkit- is supported by Opera and it's the last one,
             what happens?
   florian: If you set up a hierarchy (your prefix is stronger than
            other prefix, unprefixed is most important), what happens
            if you have different specificity/important?
   sylvaing: We had that with 'opacity' and 'filter'.

   florian: Back to David's original point, do we *want* to synchronize,
            or is it a feature that we're all different?
   plinss: I question whether we need to standardize on something
           vendor-specific.
   florian: The problem is that authors should have a reliable way,
            when reading stylesheets from JS, knowing which one will
            work.
   florian: Does putting the unprefixed last guarantee that it'll be
            the one that's chosen (when selected), or might some
            prefixes win anyway?
   plinss: In general, I don't like adding feature to help people work
           around vendor bugs.
   plinss: I think it's fair that vendors put in special-case code.
   florian: I would be happy if the WG said that, when prefixes are
            used, they alias and are chosen in turn by the normal
            cascade.
   florian: Also, do multiple versions of a property all survive to
            the OM?
   Rossen: If they're aliases, they should all point to the same thing.
           If they're not, they should point to different things.
   TabAtkins: [explains WebKit's behavior - generally, they're aliases
               in the stylesheet, but separate in the OM]

   florian: I remember what was said.
   florian: If you use multiple versions in the stylesheet, then all
            are preserved in the specified value, but only the "winning"
            one lives in the computed style.
   TabAtkins: But Gecko always returns the unprefixed version in the
              computed style - they don't remember the source.

   fantasai: We have some unprefixed aliasing too - overflow-wrap
             and word-wrap are (unprefixed) aliases.
   dbaron: I don't think we should have aliases in the spec.
   florian: I think it's reasonable, even if it's just an optional alias.
            We should still define how the cascade and OM work for them.
   florian: I propose that it gets converted to the "most standard" one,
            and it appears as that in all cases in the OM.
   fantasai: We also have page-break-* and break-*.
   fantasai: I need to put that into a spec.  So we need a resolution
             for this.
   sylvaing: I'd like to see some testcases, if someone needs to change.
   sylvaing: In the case of filter/opacity, it depends on document mode.
   [something about the specifics of IE modes]
   plinss: When it comes to aliases, has anyone implemented those yet?
   howcome: I think we support break-*, and page-break-*. I don't think
            we do column-break-*
   howcome: I'm not sure what we do with the OM.
   szilles: For "most standard", if I have -webkit- and -epub-, which
            is most standard?
   tantek: I think that Moz always converts to unprefixed in the OM.
   [several moz people]: No, that's not what happens.

   plinss: Maybe that's a good approach, though.  Just *never* show
           prefixed in the OM.
   TabAtkins: That seems reasonable to me.
   glazou: And what about when serialized?
   plinss: Serialization is different.
   glazou: If it doesn't show up in the OM at all (when an unprefixed
           doesn't exist yet), that will break editors.
   tantek: We set a precedent for prefixing in the DOM, too.
   tantek: We probably want to keep things prefixed in the OM, then,
           so we can justify other web apis prefixing.
   <sgalineau> if one supports -prefix-foo and foo and the stylesheet
               only sets -prefix-foo, does getComputedStyle() expose
               it as prefixFoo or foo ?
   florian: The simplest thing we can do is that, at the cascading level,
            the last one wins.
   florian: In the OM, the one that's used is returned.
   dbaron: I don't see any need to remember prefixes in Gecko.
   macpherson: I think the most consistent is to reflect the used
               version.
   macpherson: If we change the spec after implementation, you'll
               need to return the value in the old form as a prefix.
   dbaron: Part of the Gecko strategy to discourage prefixes is that,
           the *instant* the unprefixed is supported, the OM no longer
           supports th eprefix.
   dbaron: We may support it still in the stylesheet for a bit, as
           necessary.
   plinss: Our policy should be to keep prefixes fragile.
   TabAtkins: Yes.
   plinss: If you use prefixes, here be dragons, and we won't help
           you keep it working.

   jdaggett: While members are cool with that, their companies have
             marketing departments that may not agree.
   macpherson: I think you can handle that by just dropping when we
               can, not by *forcing* prefixes to break automatically.
   sylvaing: We shouldn't punish success.
   florian: So should we preserve the prefix or not?
   dbaron: We haven't had content breaking because of dropping the
           prefix in the OM.
   smfr: We probably would have content break in WebKit if we did that.

   florian: As an editor, Daniel, do you prefer what the stylesheet
            originally said, or what is used?
   glazou: From a CSS editing program, I'd prefer getting back
           *everything*.  But at least, what the author said.
   glazou: If an editor changes properties between input and output,
           we'd just get complaints from users.
   florian: By now I know what I want to ipmlement, so I wonder if
            we should consider discussing until we agree on what to
            implement, or if we should learn to love the breakage.
   florian: The cascade wins (the one that comes last). When you
            query through the OM, you only see the one that won
            (with or without prefix, depending on which one won).
   florian: So internally you remember which name was used, but you
            otherwise treat them as aliases.

   glazou: Say that Opera supports a -webkit- property, and -webkit-
           drops its prefix.
   glazou: Before you drop the prefix too, if -webkit- is used last,
           you'll output the -webkit- rule in the OM, even though it
           will no longer work in WebKit.
   florian: Yes.  That's internally consistent.
   glazou: But you have inconsistencies for a little while.
   glazou: My preference would go to supporting the last one in
           implementation order, not cascading.
   florian: When a page is authored toward a particular prefix in
            script, that'll break the page.

   alexmog: I can explain what we might think of doing.
   alexmog: We preserve all the properties that are set.
   alexmog: So if you write out a file, we'll write out everything.
   alexmog: If you query through the OM, we only preserve one of the
            values after cascading.
   alexmog: If hypothetically we have -ms- and -webkit- and unprefixed,
            all will return the appropriate syntax, but from only the
            winning value.
   florian: If the -webkit- won the cascade, do you see it as -webkit-,
            or as something else, or as all of them?
   alexmog: So if we support multiple names for a property, we'll
            return the winning declaration as *all* of them (perhaps
            with adjusted syntax, as necessary).
   alexmog: So we probably won't want to remember who won.
   szilles: What do you do if the values changed between property
            versions?
   alexmog: We'll adjust the output to match the syntax of the given
            version.
   Rossen: I don't think that's right.
   Rossen: Today we only have aliases.
   alexmog: We remember literal attribute and property values.
   [some discussion about the exact behavior of MS]
   florian: But if you ask for a list of the properties on an element,
            do you get all of them, or just the winning?
   sylvaing: Yes, even if you only specify one of them in the stylesheet.

   plinss: We won't ever get every single value - fully unsupported
           properties won't show up.
   [something about how Blue Gryphon works]
   florian: So the suggestion is that, if you specify only -moz-
            (in Firefox), then in the OM you'll see both unprefixed
            and moz-prefixed.
   florian: Is that okay?
   glazou: Maybe.
   glazou: [explains why it may be difficult, but not impossible]
   plinss: You just need to have a table, based on the version of Gecko
           you're using, saying which properties are unprefixed.
   TabAtkins: That behavior sounds fine to me.
   dbaron: [explains exactly what Gecko does - it's identical to the
            proposed behavior, except that the CSS2Properties interface
            (like el.style.boxShadow) only shows one version at a time ]
   glazou: [clarifies his understanding, and asks about prefixed values
           as well]
   RESOLVED: When a browser supports multiple versions of a property,
             they're treated as aliases in the cascade, such that last
             wins. In the OM, *all* variants show up, with equivalent
             values, regardless of which version was specified or which
             won.
   plinss: For aliases, this should be clearly specced.
   plinss: Distinct from prefixed stuff.
   florian: Is this somewhere centralized in CSSOM, or do we specify
            it every time we have an alias.
   RESOLVED: The last resolution applies to WG-approved aliases. It
             MAY be used by browsers for prefixed versions as well.

   florian: Now, for prefixed values.
   florian: I say just return the one you got.
   plinss: Agreed.
   TabAtkins: Agreed.
   Florian: What about individual media query features?
   TabAtkins: I think they feel a little more like values, so I'd
              preserve them as the author wrote.
   florian: Does anyone who cares object?
   fantasai: Deferring to dbaron.
   plinss: The point for properties is so we don't have to remember
           which version it came from.
   florian: But for values we reasonably often can't cover all the
            possibilities between versions.
   RESOLVED: When value aliases are supported, return the version that
             the author provided.
   RESOLVED: In media query feature strings, also return the version
             that the author provided.
Received on Tuesday, 7 February 2012 08:44:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT