- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 13 Apr 2011 12:11:24 -0700
- 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 UTC