W3C home > Mailing lists > Public > www-style@w3.org > April 2011

[CSSWG] Minutes and Resolutions 2011-04-13

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 13 Apr 2011 12:11:24 -0700
Message-ID: <4DA5F55C.3000009@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:
   - RESOLVED: June F2F move to Kyoto, Japan
   - RESOLVED: Accept the new CSSWG site design from Divya Manian
   - RESOLVED: EPUB should use prefixed versions of properties that aren't
               yet in CR. No recommendations on what the prefixed property
               means.

====== Full minutes ======

Present:
   Tab Atkins
   David Baron
   Bert Bos
   Cathy Chan
   John Daggett
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Vincent Hardy
   Koji Ishii
   John Jansen
   Brad Kemper
   Håkon Wium Lie
   Peter Linss
   Alex Mogilevsky
   Edward O'Connor (hober on IRC)
   Alan Stearns
   Daniel Weck
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2011/04/13-css-irc
* Ms2ger congratulates the CSSWG on releasing CSS2.1
* plinss thank you
* hober will have to drop off the call in 30 minutes, but will remain on IRC
Scribe: TabAtkins

Administrative
--------------

   plinss: Any last-minute additions?
   kojiishi: Can I talk about epub response?
   plinss: Sure.

CSS2.1
------

   plinss: There's nothing to discuss about 2.1 this week!
   arronei: Hey, we moved to PR.
   plinss: Yes, the PR transition call went very well.
   glazou: We'll probably make a tshirt for the occasion.
   <Bert> (Excellent work by Peter on PR telcon, especially explaining
           the tests!)

CSSWG Website
-------------

   plinss: Elika wanted to talk about the website.
   <fantasai> http://csswg.inkedblade.net/staging/redesign/index-divya.html
   <fantasai> New website design from Divya Manian
   <fantasai> Based on structure from old design by Jason Cranford Teague
              and myself
   <fantasai> Do we want to adopt this design?
   <Bert> I'd like to use the design, but it will take some work, because
          it was made for different mark-up.
   <smfr> there's a missing image after "News"
   <fantasai> I fixed the markup
   <Bert> I saw Elika already did some adaptation.
   <Zakim> + +1.415.832.aaii
   glazou: My concern is still the legibility of the blue links in the blue
           header.
   glazou: Other than that I think it's wonderful.
   bradk: Same concern from me.
   <jdaggett> yeah, the dark blue links have poor legibility
   <fantasai> easy to fix, just suggest a color code :)
   <nimbupani> oh hai.
   glazou: Are we listing the modules somewhere, or is that under "current work"?
   <fantasai> Overview and Current Work both list modules
   Bert: The structure isn't changing, just the markup/style.
   <nimbupani> we could use aliceblue for the dark banner
   <fantasai> It only uses <time> element, which is ignorable
   <bradk> I sent a mockup suggestion picture, fantasai. Did you get it?
   <bradk> for the blue on blue issue
   <glazou> BUT IS IT NATIVE HTML5 ????
   plinss: So, consensus on adopting this for the site?
   <nimbupani> :)
   * Bert lol
   RESOLVED: Accept the new site design.

June F2F
--------

   plinss: Next topic, f2f.
   <kojiishi> http://wiki.csswg.org/planning/japan-2011-venues
   kojiishi: I have a few candidates at this link.
   kojiishi: The only good candidate is the Kyoto Research Park.
   kojiishi: Fujisawa-san from the SVGWG seems to be fine to do it there too.
   jdaggett: That sounds good to me.
   kojiishi: The kyoto reserach park currently has some conditions for the
             place.
   kojiishi: The place has internet, but not wifi - we can bring a router.
   kojiishi: Lunch delivery is available but there are other lunch options
             close by.
   szilles: 5 mins walking distance from kyoto station, or the subway station?
   <sylvaing> not sure that was clear as the sound is bad on my end;
              Microsoft Japan can sponsor lunches and dinner if necessary.
              Google being the original host, it's up to them though
   kojiishi: from the subway station - 1 stop from kyoto
   plinss: This is where SVG will meet the following week?
   kojiishi: Yeah, and they're considering having a joint meeting.
   TabAtkins: Not sure what the progress is on that yet.
   sylvaing: SVG is planning June 6-9, so starting on Monday.
   jdaggett: I think they were maybe talking about coming on Saturday.
   * fantasai doesn't mind staying extra to Monday
   TabAtkins: Google can still do dinner, but I'll have to check about lunches.
   jdaggett: Who's coordinating the router?
   kojiishi: ??? (I missed the name.)
   jdaggett: So you'll coordinate with him?
   kojiishi: Yes.
   <kojiishi> http://buffalo.jp/products/catalog/network/wzr-hp-ag300h/
   <mihara> NTT will bring the router and projector.
   kojiishi: So are we all fine with kyoto research park, or are we sticking
             with tokyo?
   jdaggett: I think we should resolve on kyoto research park.
   <dbaron> KRP sounds good
   [several] seems fine
   plinss: Any issues with relocating the other workshop to Tokyo?
   kojiishi: That's fine - we already have the place in KRP reserved on june 1st.
   sylvaing: So wednesday for the workshop, and thu-fri-sat for the meeting,
             + sat for joint svg meeting.
   RESOLVED: Relocate f2f to Kyoto.

EPUB CSS Profile
----------------

   <kojiishi> http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#sec-css-profile
   kojiishi: epub is curious if we're recommending that they use a prefix
             for properties that aren't in CR state.
   smfr: From an impl perspective, *not* using prefixes is potentially
         dangerous. A browser may want to use the same rendering engine
         for both epub and webpages.  If there are differences between
         an unprefixed epub property and a final unprefixed CSS property,
         this would cause a problem.
   kojiishi: epub is willing to respond to changes in working drafts.
   <kojiishi> http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#sec-css
   kojiishi: In section 3, there's a note...
   kojiishi: ...about how this is still a work in progress and may change
             in incompatible ways.
   * sylvaing has a nagging suspicion smfr's scenario is not totally
              hypothetical...
   smfr: Right, so that says that if an epub user uses an unprefixed property,
         the page may break when the reader is implemented.
   smfr: It also means that the unprefixed property is exposed to arbitrary
         web content too.
   kojiishi: epubs have a version number, so you can key off that for the
             differing behavior if necessary.
   TabAtkins_: Versioning has never worked on the web, unfortunately.
   <fantasai> If you use prefixes, you are versioning anyway.
   <fantasai> Just a different trigger for versioning
   <fantasai> Having to support two different behaviors is a problem,
              prefix or not.
   smfr: It would mean we have to support two version of the same thing,
         which we don't do right now.  This becomes a huge implementation
         burden as time goes on.
   kojiishi: Isn't the criteria the same, though? epub readers would have
             to support both prefixed and unprefixed properties.
   smfr: We already have the situation where we'll have to support prefixed
        properties indefinitely.  That's easier than having to handle two
        version of the property with different syntax/meaning.
   plinss: I agree in general with the arguments for having a prefix.
   smfr: Something with an epub prefix may have different behaviors between
         epub UAs.
   fantasai: If epub spec tracks what we're doing, what behavior is being
              associated with the prefixed property?  Behavior now, behavior
              a month from now, ...?
   fantasai: There's no clear description of what the behavior would be,
             so it just forks the spec.
   smfr: It'll be whatever they expect.
   smfr: They'll author in whatever UA they have around.
   fantasai: It's not analogous - the author can have multiple UAs which
             have different behaviors under the same "-epub-" prefix.
   fantasai: Prefixing doesn't solve the versioning problem here.
   * TabAtkins is slightly lost in the minutes. @_@
   fantasai: Any impl that wants to read epub will have to read epub syntax.
             even if they have the same behavior between the two. That's just
             forking the syntax.
   fantasai: I think we should just subset the properties we think are stable
             and finish the spec.
   fantasai: There's not much in the way of epub content out there when they
             release the spec. And the implementations will not be very
             consistent with each other or the spec. As content and
             implementations gradually lock with each other, we can hopefully
             lock down the spec, too.

   jdaggett: The problem here is that authors will be using properties that
             aren't in CR.
   jdaggett: If we use unprefixed properties, we're assuming that no
             differences in behavior will occur.
   fantasai: let's suppose that moz decides to support epub content in 2 years.
   fantasai: They'll have to parse all the epub properties, but they won't
             want two codepaths.
   fantasai: So they won't be forking behavior based on the prefix anyway.
   fantasai: And for the most part, I think they can get away with this.
   jdaggett: After a while, epub can publish a revised spec that includes
             unprefixed props once the specs are stable.
   smfr: Authors should use both vendor and unprefixed properties, like
         they do right now.
   plinss: Assuming it hasn't changed.
   fantasai: I don't understand how that's different from using unprefixed
             properties.
   smfr: We won't be exposing the unprefixed property to the web at large.
   TabAtkins: So the compat problems are the same, but the overall web can't
              play with it and make it worse, just epub.
   jdaggett: So the problem is that epub is trying to lock down things that
             aren't finished yet in the spec.
   fantasai: Given the explanations, recommending that authors use both -epub-
             and unprefixed makes sense to me.

   bradk: That still has compat problems, though.
   sylvaing: A prefix lets you at least reference one version of a property.
   TabAtkins: Generally, we're not going to want multiple versions of a
              property.  We want only one codepath.
   plinss argues for diferent codepaths
   fantasai: Some implementations may be okay with different codepaths,
             but others aren't.
   plinss: I think we should have epub reference a specific version, and
           guarantee that epub readers implement that specific version.
   fantasai: webkit won't want to specifically implement different versions
             of vertical text, for example.
   fantasai: Epub has decided that they want to track the spec, not freeze
             on a particular version. Except Apple, the EPUB implementors
             are in *their* working group, not ours. They've already
             considered the situation and come to that decision.
   plinss: That's fine.  I think we should recommend they do the opposite.
   TabAtkins: I disagree. If we want to treat epub as part of the web, it's
              bad to have them snapshot, and it's a bad precedent for other
              new web-type technologies.
   <fantasai> +1 to Tab
   <jdaggett> the bad precedent is basing new technologies on *WD* versions
              of specs
   <tabatkins> I agree, jdaggett, but it's an unfortunate consequence of the
               fact that we are *just now* addressing the typographic
               conventions of a significant percentage of the world.
   plinss: I think epub should fix on a revision, and set it with a version
           on themselves.
   <jdaggett> "addressing the typographic conventions of a significant
              percentage of the world" == vertical text?

   plinss: How often is epub revving?
   fantasai: I don't know.
   <kojiishi> http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#sec-overview-versioning

   dbaron: I don't think they should snapshot if they want to track.
   dbaron: Then we're just encouraging epub and web content to diverge.
   dbaron: If the impls converge slowly enough that they don't have tons
           of interop before we reach CR, we're okay.
   dbaron: If they create testcases and drive conformance to a snapshot,
           then that drives interop faster in a direction that forks CSS.
   <fantasai> +1 to dbaron
   plinss: Things about the properties will change.  They shouldn't be
           basing their impl on non-CR stuff.
   fantasai: I think we should keep it fuzzy until we either decide that
             there's no need to fork, or a fork is imminent.
   plinss: It would be ideal if nobody forked the spec.
   <Ms2ger> It would be ideal if these specs were in CR
   fantasai: The solution you're advocating is more likely to lead to a fork.
   plinss: yes, but we aren't forking, they are.
   fantasai: By advocating they fork the spec, we are responsible for the fork.
   plinss: I'm saying that if epub wants to add a property that's not yet
           part of CSS, they should own the property themselves, so that
           when CSS defines the property it can be unprefixed across everyone.
   fantasai: Then we have multiple implementations that have to support
             multiple behaviors, when it might not even be necessary.
   sylvaing: We already do that, like webkit's stuff.
   fantasai: And they want to avoid doing it more.
   smfr: We are okay with maintaining multiple versions of simple things
         like gradients, but not core layout primitives like vertical text.
   smfr: We never want forked behavior for unprefixed properties.
   plinss: I think I'm hearing consensus that they should prefix their
           properties.
   [several]: yes
   plinss: What I'm hearing dissent on is what the prefixed version means.
   plinss: They're their own working group. We can make recommendations.
           If they decide not to prefix, they don't prefix and the only
           thing we can do is get mad about it.

   <Bert> (Best might be to encourage them to make a version 3.0 without
          vertical, send their engineers to CSS to work on vertical, and
          make 3.1 half a year later.)
   <fantasai> (Bert, that won't help anyone. What are their engineers going
              to do to help?)
   <fantasai> (We have to write the spec. It's unlikely that they can do
              that for us.)
   <Bert> (Elika, help you with tests and impl. reports?)
   <fantasai> (Yes, that would be great :)

   plinss: Anything else on this topic?
   jdaggett: Any resolution here?
   plinss: No formal resolution yet.  We're just in agreement that they
           should prefix properties that aren't in CR.
   jdaggett: Is that our formal recommendation.
   bradk: We could provide them with examples of spec that have changed
          drastically between WD and CR.
   fantasai: They know that already.
   RESOLVED: Epub should use prefixed versions of properties that aren't
             yet in CR. No recommendations on what the prefixed property
             means.

Meeting closed.
Received on Wednesday, 13 April 2011 19:12:14 GMT

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