[CSSWG] Minutes and Resolutions 2010-06-09


   - Discussed status of CSS2.1 test suite and issues
   - Discussed vendor prefixes and allowing unprefixed implementations
     before CR
   - Discussed vendor prefixes and what to do when one vendor wants to
     implement the other's proprietary feature.
   - RESOLVED: Republish css3-background as LC to accept recent changes.

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

   David Baron
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Chris Lilley
   Peter Linss
   Alex Mogilevsky
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/06/09-CSS-irc
Scribe: dbaron


   Daniel: Extra agenda items?
   fantasai: LC of backgrounds and borders

CSS 2.1

   glazou: status of test suite?
   fantasai: Still trying to convert Hixie's tests.  Have about 150 left;
             working through CGI scripts (avoid needing CGI).
   fantasai: hopefully will be done today or tomorrow

   glazou: something deferred from last week?
   fantasai: the bidi issue.  We don't want a change, but the spec does
             need a clarification.
   fantasai:  We need to clarify that we're not overriding the behavior
              of the LINE SEPARATOR character.
   ChrisL: I took that issue last week and discussed with r12a and gave
           me things to look into further.
   fantasai: I've been discussing bidi at the bidi F2F last 2 days, and
             this was the conclusion.  We want <br> to force a bidi
             paragraph break because it's compatible with plaintext.
   fantasai: So we're not taking the change request to make it a line
             separator, but we do need to clarify that we're not
             overriding LINE SEPARATOR's behavior.
   ChrisL: Also, sample style sheet for HTML4 says br:before { content: "\a" }
   fantasai: people expect <br> to end a paragraph (due to IE?),
             suggestion was changing HTML to say <br> is a paragraph
             break rather than line separator. So CSS spec is correct.
   glazou: what other outstanding issues on radar?
   <oyvind> "changing HTML" - but we refer to 4 now?
   <oyvind> should it refer to whatever version is the newest instead?

   sylvaing: Haven't gotten to ???.  Really want to get it done, though.
             Requires some time to think.
   fantasai: still haven't looked at my 2.1 issues
   fantasai: will do after publishing test suite
   <bradk> I don't have any 2.1 issues assigned to me.
   dbaron: Still have 1; not sure when I'll get to it.
   glazou: There were some messages from tab and others with concrete
           proposals; suggest leaving to next week.

Vendor prefixes

   glazou: sylvain asked to divide topic in 2: (1) what's good/bad
           about current prefix policy (2) when should vendors
           submit things for standardization
   sylvaing: If a property is used all over the place, should it
             get standardized?  (-webkit-text-size-adjust)
   glazou: I saw another blog post complaining about vendor prefixes --
           authors having to use them for legacy browsers.
   glazou: We have to say something, even if we say we can't change it.
   glazou: First, when do we decide to remove a prefix?  Second, what
           to do with legacy browsers / vendor-prefix properties?
   glazou: I proposed WG should be responsible for when vendor prefix
           should be removed.
   ChrisL: Another suggestion... intermediate step.  Vendor prefixes
           should be for experimental/unproposed, then w3c prefix
           for in-process-of-standardization.
   * alexmog doesn't think standards body can reguate non-standard features
   ChrisL: We can't take off and add on prefixes easily around CR.
   ChrisL: There's always a risk that the prefixed property sticks.
   ChrisL: That in itself is an argument against vendor prefixes.
           (But on the other side...)
   glazou: border-radius is a good example.  Everyone has to write
           many properties.
   bradk: -moz-border-radius-* was different
   glazou: We have to live with legacy browsers.
   glazou: Could browser vendors make minor upgrade of legacy versions
           to remove prefix if possible?
   glazou: If Fx 3.7 ships without prefix, is it possible to ship minor
           release of Fx 3.6 also removing the prefix?
   alexmog: What you're saying is that when 3.6 was released it was not
            standard, and it became standard when 3.7 was released?
   glazou: ok, never mind

   glazou: Other problem:  time getting to CR can take years.
   glazou: Once people start using it we have to live with it.
   glazou, To be clear that property is stable enough to remove prefix
           before CR.  Would it solve problem?
   dbaron: I think it would be good to have a way to say we can remove
           prefixes for part of a draft without the whole thing going
           to CR.
   <ChrisL> I agree
   ?: I agree
   sylvain: Opera 10.5 for background properties they support longhand
            properties without prefix but not in shorthand, and reverse
            for border-image.
   sylvaing: Should be some contract about doing the whole thing.
   * fantasai agrees with sylvain
   dbaron: I removed prefixes on some background properties but didn't
           implement the shorthand because the shorthand wasn't
           published stable yet
   dbaron: I was unprefixing background props this week; didn't do all
           shorthand stuff because not stable yet; think that was the
           right choice.
   sylvaing: I think that would be confusing to authors, that the
             feature is only partially implemented in some browsers
   glazou: I don't think we intend to do that on a per-property basis.
   glazou: When a suggestion is made we can study what subset we want
           to unprefix.
   sylvaing: I agree with david's point about background shorthand;
             changing lately -> interesting result.
   sylvaing: But we should be clear on the granularity.
   glazou: I have a question for Chris from a process POV.  If we
           unprefix and the spec goes back to LC after CR and it takes
           much more time to move along REC track.
   glazou: Is that a bad signal to Consortium?
   ChrisL: From Process POV, process doesn't say anything about prefixes.
   ChrisL: For huge change we might rename property to avoid conflict.
   dbaron: We also have to worry about compat with properties not
           produced by this WG that were implemented without prefix.
           (e.g., overflow-x, etc.)
   SteveZ: One thing that's true about process is that there should be
           external review beyond WG before something is permanent.
   SteveZ: So you shouldn't do it without last call.
   SteveZ: role of CR was to ensure interop
   SteveZ: removing prefix before interop could be significant mistake
   SteveZ: ...
   SteveZ: Confusing to users if long and shorthand have different behavior.
   SteveZ: Not obvious to me that there's a simple process for doing this.
   SteveZ: Instead, can we do things that don't take so long, and not
           try to do so much, so the problem goes away?
   TabAtkins: That's the smaller spec approach.
   glazou: The smaller spec approach will never resolve dependencies
           between small specs.
   fantasai: The dependencies between specs should be handled by the
             specs depending on something older (2.1, previous CR).
   fantasai: In most cases tying together isn't really necessary.
   glazou: I'm hearing concerns but not really objections to idea of
           making part of spec advance faster or making a smaller
           spec to advance faster.
   fantasai: I have reservations about saying we can drop prefixes
             on one feature within a spec.
   dbaron: I prefer removing prefixes on one thing within a spec than
           splitting the specs.
   glazou: Splitting specs is a huge burden.
   glazou: This would be done only on consensus within WG.
   ?: ?
   Steve: I think what you're saying might be a reasonable experiment;
          I'd like a one-month announcement of intent to do that on
          www-style so people outside WG can comment.
   glazou: ok to me
   glazou: I suggest co-chairmen come up with written proposal for WG
           to discuss at August F2F to implement afterwards if approved.
   ChrisL, etc.: sounds ok
   ACTION: glazou to write proposal for process for marking sections of
           spec as implementable without prefixes for discussion at
           August 2010 F2F
   sylvain: ???
   sylvain: then it will work as the user expects

Sharing Vendor Extensions

   glazou: If it's used all over the place, then it should be standardized.
   sylvaing: In that case, I think vendor is responsible for submitting
             a draft, etc.
   sylvaing: We've been shut down for parsing it, but I don't see
             anyone proposing it for standardization.
   glazou: Why don't you propose it yourself?
   sylvaing: I'd rather have Apple propose it.
   sylvaing: I asked several places, haven't heard back.
   sylvaing: I think we goofed... the reaction was deserved.  But I
             think we need a solution here.
   sylvaing: The long road means this thing being standardized.
   sylvaing: ...short of a new property with new name which I don't
             think is helpful.
   glazou: editors have to implement other-prefixed properties; my
           editor is based on Gecko but I implement -webkit and -o-
   sylvaing: Boris suggested some people at Mozilla also thought Moz
             should just parse it.
   sylvaing: Popularity of iPhone ...
   glazou: People who invented it should have submitted it to WG.
   glazou: We let browser implement other prefixes or we ask people to
           come to standardization table.
   bradk: We should strongly discourage browsers implement other prefixes.
   ?: ... but ok for editor
   ECHO ECHO ECHO [bad phone reception]
   glazou: Even when standard, prefixed properties all over Web.
   bradk: People wrote prefixed content for WebKit because they found it useful.
   bradk: If IE had prefixed version, people would add that.
   dbaron: only if IE had enough mobile market share.  Chicken & egg problem.
   TabAtkins: example of why monoculture in ... is bad
   sylvaing: People may see justice because MS is recipient, but it's
             still a problem.  I think needs to be specified.
   glazou: Easy to install new browser on desktop; not always the case
           on mobile.
   SteveZ: It's nice to encourage originator to submit, but you can't
           force them to.
   SteveZ: That puts you in the position of: if you think the property
           should be part of standard, someone else should reverse-engineer
           and submit.  Originator is still in the WG and can see it happen.
   glazou: My original suggestion: MS should submit to WG.
   SteveZ: So they do their best shot, and if wrong, the originator
           will fix in WG.
   sylvaing: So I'd request Apple submit description, if they don't,
             otherwise I'd submit reverse-engineered spec of it.
   sylvaing: So then it needs to go in a module.  What if Apple then objects?
   dbaron: I think worry about objection if it happens.
   glazou: MS Word implemented many -mso-prefixed properties, you never
           submitted them, many were useful.  It can't just be solved
           by the chairmen; needs to be agreed by vendors.
   sylvaing: We're talking about something out there with huge market shere.
   glazou: -mso- properties are out on lots of web pages
   glazou: Only way it can be solved is by agreement between vendors.
           Otherwise no solution.
   Steve: Sylvain, I think you're doing the right thing.  First try
          to get originator to submit.  If that fails, submit yourself.
          Formal objection doesn't block something, it just causes
          reconsideration and slower process.  Trust the process.
          You can be in the position of driving it.
   glazou: A formal objection only based on strategy/political reasons
           is probably not enough to block something.
   Sylvain: I'm trying to think how reasonable it would have been for
            -mso-* stuff.
   sylvaing: Anybody should be ready for request to document proprietary
             extension they came up with, or they should accept somebody
             else documenting and submitting it.
   sylvaing: I think this conflicts with previous discussion where
             we're trying to get prefixes under control.
   glazou: I don't think it's a problem for the second case.  First is
           more problematic.
   glazou: I think you should submit.
   glazou: Make sure to cc: AC rep of apple (dsinger)

Spec Publishing

   fantasai: I'd like to publish LC of backgrounds&borders.  If we don't
             have time ask now, would like scheduled this month.
   howcome: Is box shadow in?
   fantasai: yes
   howcome: let's do it
   fantasai: 3 weeks last call period
   <ChrisL> which wgs are invited to review it?
   RESOLUTION: LC of css3-background, 3 weeks review, ask SVGWG for comments

   fantasai: Open issues for style attr spec raised by SVG
   fantasai: Already responded, still waiting for their okay.
             Which is what's blocking CR now.

Meeting closed.

Received on Thursday, 10 June 2010 19:15:43 UTC