- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 10 Jun 2010 12:15:06 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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 ======
Present:
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
Administrative
--------------
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-
properties.
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