[CSSWG] Minutes and Resolutions 2010-06-09

Summary:

 - discussed status of CSS 2.1 issues and test suite

 - briefly discussed CSS2.1 bidi issue (related to the distinction
   between line separator and paragraph separator?)

 - discussed vendor prefixes: when to drop prefixes

     ACTION: Daniel Glazman and Peter Linss to write proposal for
     process for marking sections of spec as implementable without
     prefixes for discussion at August 2010 F2F.

 - discussed vendor prefixes: when things should be submitted for
   standardization

 - discussed css3-background last call

     RESOLUTION: Publish last call of css3-background.

 - very briefly discussed css3-style-attr status

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

CSS Working Group Teleconference, 2010-06-09
Chair: Daniel Glazman
Scribe: David Baron
Attendees:
  Steve Zilles
  Brad Kemper
  David Baron
  Alex Mogilevsky
  Elika Etemad
  Peter Linss
  Chris Lilley
  Sylvain Galineau
  Daniel Glazman
  Tab Atkins
  Håkon Wium Lie
Regrets:
  Bert Bos
  Simon Fraser

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).
  ... 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.
  ... We need to clarify that we're not trying to override 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 a 2 day bidi F2F last 2 days,
  and this was the conclusion. We want X because it's compatible with
  plaintext.
  ... We're not taking the change request, 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

  glazou: what other outstanding issues on radar?

  <oyvind> "changing HTML" - but we refer to 4 now?

  sylvaing: Haven't gotten to ???. Really want to get it done, though.
  Requires some time to think.

  <oyvind> should it refer to whatever version is the newest instead?

  fantasai: still haven't looked at my 2.1 issues
  ... 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: when to drop 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.
  ... We have to say something, even if we say we can't change it.
  ... First, when do we decide to remove a prefix? Second, what to do
  with legacy browsers / vendor-prefix properties?
  ... 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.
  ... We can't take off and add on prefixes easily around CR.
  ... There's always a risk that the prefixed property sticks.
  ... 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.
  ... Could browser vendors make minor upgrade of legacy versions to
  remove prefix if possible?
  ... 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
  ... Other problem: time getting to CR can take years.
  ... Once people start using it we have to live with it.
  ... 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

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

  dbaron: I removed prefixes on some background properties but didn't
  implement the shorthand because the shorthand wasn't published 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 ???-property basis.
  ... 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.
  ... 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.
  ... Is that a bad signal to Consortium?

  ChrisL: From Process POV, process doesn't say anything about prefixes.
  ... 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.
  ... So you shouldn't do it without last call.
  ... role of CR was to ensure interop
  ... removing prefix before interop could be significant mistake
  ... ...
  ... Confusing to users if long and shorthand have different behavior.
  ... Not obvious to me that there's a simple process for doing this.
  ... 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).
  ... 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.
  ... 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
  ... 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

  <trackbot> Created ACTION-239 - write proposal for process for marking
  sections of spec as implementable without prefixes for discussion at
  August 2010 F2F [on Daniel Glazman - due 2010-06-16].

Vendor prefixes: when to submit for standardization
===================================================

  sylvain: ???
  ... then it will work as the user expects

  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.
  ... 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.
  ... I asked, haven't heard back.
  ... I think we goofed... the reaction was deserved. But I think we
  need a solution here.
  ... The long road means this thing being standardized.
  ... ...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- properties.

  sylvaing: Boris suggested some people at Mozilla also thought Moz
  should just parse it.
  ... Popularity of iPhone ...

  glazou: People who invented it should have submitted it to WG.
  ... 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

  glazou: Even when standard, prefixed properties all over Web.

  bradk: People wrote prefixed content for WebKit because they found it
  useful.
  ... 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.
  ... 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.
  ... So then it needs to go in a module. What if Apple then objects?

  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
  ... 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.
  ... 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.
  ... I think you should submit.
  ... Make sure to cc: AC rep of apple (dsinger)

Last call of css3 backgrounds and borders
=========================================

  fantasai: I'd like to publish LC of backgrounds & borders. If we don't
  have time now, would like discussion 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: Publish last call of css3-background

Style attribute spec
====================

  fantasai: Open issues for style attr spec raised by SVG
  ... which is what's blocking ??? now.

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Wednesday, 9 June 2010 17:42:05 UTC