- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 07 Feb 2012 09:41:00 +0100
- To: "www-style@w3.org" <www-style@w3.org>
Administrative
--------------
- RESOLVED: San Diego meeting, August 13-15, hosted by HP
- Discussed ways of handling traffic on www-style. Chairs to play
a greater role in shutting down useless threads, as identified by
members. Tantek and fantasai to write etiquette guidelines / FAQ.
- RESOLVED: Move to Mercurial for specs, work on docs / setup.
Vendor Prefixes
---------------
Discussed problem of WebKit monopoly on mobile and the consequent
pressure for other engines to implement -webkit- properties. See
also Tantek's questions at
https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#questions_and_methodology
Aliasing
--------
Aliases are used both for vendor prefixed / unprefixed property pairs
as well as for the word-wrap/overflow-wrap property and for the page-break-*
properties (which are aliased to break-*). We discussed what, exactly,
aliasing means:
RESOLVED: When a browser supports multiple syntaxes of a single property,
they're treated as aliases in the cascade, such that last
wins. In the OM, *all* variants show up, with equivalent
values, regardless of which version was specified or which
won.
RESOLVED: The last resolution applies to WG-approved aliases. It MAY
be used by browsers for handling prefixed versions as well.
RESOLVED: When value aliases are supported, return the version that
the author provided.
RESOLVED: In media query feature strings, also return the version
that the author provided.
====== Full minutes below ======
Present:
Rossen Atanassov (Microsoft)
Tab Atkins (Google)
David Baron (Mozilla)
Bert Bos (W3C)
Tantek Çelik (Mozilla)
John Daggett (Mozilla)
fantasai Etemad (Mozilla)
Simon Fraser (Apple)
Sylvain Galineau (Microsoft)
Daniel Glazman (Disruptive Innovations)
Vincent Hardy (Adobe)
Koji Ishii (Invited Expert)
Håkon Wium Lie (Opera)
Peter Linss (Hewlett-Packard)
Luke Macpherson (Google)
Alex Mogilevsky (Microsoft)
Anton Prowse (Invited Expert)
Florian Rivoal (Opera)
Alan Stearns (Adobe)
Steve Zilles (Adobe)
Observers:
Jet Villegas (Mozilla Corporation)
Tavmjong Bah (Inkscape)
Agenda
======
ScribeNick: dbaron
Daniel: How much time for regions?
Vincent: 2+ hours would be good
Daniel: I suggest we break around 12:00 or 12:30 to avoid crowds.
Daniel: means we have roughly 2.5 hours for this morning
Daniel: Maybe start with review of documents that want to publish
LC, CR, etc.
fantasai: Most of those have issues.
jdaggett: There's some coalescing of the agenda that could be done
(by modules).
jdaggett: Maybe talk about logistics, San Diego meeting, etc.
Upcoming Meetings
=================
Vincent: So for Hamburg, I sent an email. There's an event in
Hamburg at the time of the meeting: the port anniversary.
Vincent: The city apparently gets pretty busy. It starts on Friday,
the last day of the F2F.
Vincent: Originally when I talked to people in Hamburg they said it
wasn't a problem; now they said we need to make reservations.
Vincent: We've blocked rooms in some hotels until end of the week;
people should make reservations.
Vincent: We need to renew the hotel room block week by week.
(discussion of trains)
Daniel: So we stay firm on Hamburg? OK for everyone? Book soon.
jdaggett: Håkon offered to host in Oslo, too. Should we consider that?
?: Would need to coord with SVG
Daniel: ok, let's keep Hamburg
Vincent: The Adobe rates for hotels should be better than the ones on
the meeting page.
Vincent: Just the worry that other hotels will fill up.
Topic: August meeting
jdaggett: Wiki now says week of 13-17
jdaggett: We didn't lock down which dates
peterl: I can host at HP or somewhere downtown. (?)
SteveZ: middle 3 have least impact on weekend
Håkon: I'd prefer close to weekend.
jdaggett: Prefer 13-15
Daniel: Better to stay over a Saturday night, otherwise plane fares
triple.
Daniel: Probably having weekend before the meeting best.
Florian: Earlier the better for me... week ...
Håkon: Ideally the next week for me.
SteveZ: next week fine for me too
Daniel: The week after (20-22) could be better for airlines if you
fly Europe to US because it's the end of the holidays...
jdaggett: Week after would be tricky for me.
RESOLVED: San Diego meeting, August 13-15, hosted by HP
Next meeting after that is TPAC, Lyon
www-style
=========
Daniel: There was a thread on www-style to split the mailing list to
multiple lists. I strongly object.
Daniel: It would double or triple the work the co-chairmen have to
review items for agendas.
Daniel: The new mailing list will double or triple the threads and
new people will never know where to post something.
jdaggett: Could an advocate for splitting the list explain their
position?
fantasai: I'm worried about the level of traffic.
<something about traffic growing to fill vacuum>
Tantek: I agree with what Daniel said. I'd go further and say w3c
has too many mailing lists.
Tantek: If anything, we should be looking at collapsing.
Tantek: I see no reason for fx list to exist; it should be rolled
into www-style ASAP.
Tantek: I think forking of mailing lists and then growing to be too
big has been happening the entire time I've been at W3C.
Sylvain: Is the number of lists a problem?
Tantek: Yes, because of the effect Daniel speaks about.
Florian: Each single list grows to be the maximum amount one person
can read.
Tantek: Splitting lists doesn't lead to less traffic.
SteveZ: It's difficult to split because topics last for some period
of time and then tends to die out.
Bert: Agree there's too much traffic. Nearest after this is WebApps.
www-style is 40% more than WebApps and double the next.
Florian: Yes, there's a lot of traffic; but splitting won't help.
Daniel: We invited the public -- this is part of the bad side of that.
Second, we could probably stop better a few useless threads.
Daniel: Peter and I cannot monitor everything.
Daniel: If you ping us during the week to ask us to please step in
and stop it, we can do that.
Daniel: That's happened a few times, and we can try doing it more.
Tantek: That's good -- it puts the responsibility on all of us to
help reduce useless threads.
Florian: There are some where it's easy to say it should be stopped,
and some not, because they are on topic, just not making
progress.
Simon: And people need to fix the subject line when the topic of the
thread changes.
Tantek: Do we have a www-style FAQ for new people on the list?
Daniel: We tried that back in 1997 or beginning of 1998; it was
painful to send the FAQ every 2 weeks or month.
Tantek: I think we could try again.
fantasai: Let's (Tantek & I) try to write an FAQ and connect it to the
archive page and send it out once and see if it helps.
Bert: It's technically possible to send when someone subscribes.
Tantek: Sending to the list is better because everyone knows everyone
else has received it.
Daniel: Can we get rid of people as a last resort?
Bert: We can unsubscribe somebody from a list or we can ban somebody
from all mailing lists.
Anton: I think the signal to noise ratio is still pretty good.
Anton: And people need to put [spec] at the start -- we can filter on
that.
Tantek: That could be material for the FAQ.
(fast discussion between Tantek and fantasai about retitling threads,
authority to tell people to stop or to change the topic)
Tantek: Issue is 2 people quickly replying back to each other.
fantasai: Tantek & I will write up something and then post it once or
twice, not regularly. We'll have Bert link it from the
archive page.
ACTION fantasai with Tantek to write a FAQ for www-style
<trackbot> Created ACTION-418
Daniel: Don't send to www-style immediately so WG can review it first.
W3C Mercurial for Dummies status
================================
dbaron: I wrote some parts, I think others wrote more parts
jdaggett: Have we made a decision to go to Mercurial?
Tantek: No, this is one of the dependencies.
jdaggett: I think one of the key items is getting history from CVS
to Mercurial.
fantasai: We'd do that, but first we'd need to decide to switch to it.
dbaron: It is possible.
Håkon: It's a lot of work to make the switch; what's the benefit?
Håkon: It's small projects.
<smfr> cvs -> mercurial: http://mercurial.selenic.com/wiki/RepositoryConversion
Tantek: I tried to look at the document and ran into numerous problems
in the installing mercurial step -- added problems to the wiki
page. Stopped there.
Tantek: The quality of document is not up to par with the CVS document.
<smfr> http://wiki.csswg.org/tools/hg
Scribe: fantasai
dbaron: I don't know if anyone alleged the document was complete yet
dbaron: I'll also note the CVS doc contains all the problems you run
into because you ran into them and put them there.
dbaron: You can't build up that kind of documentation without that
experience.
dbaron: Peter wrote the Installing for Macs section
questions of what problem is being solved
fantasai: We're starting to fork specs a lot, and CVS doesn' let us
do that with history
dbaron: are we planning one repo per spec or one repo for all specs?
tantek: I think that's a separate topic
dbaron: The setup is doable. Question of whether to use it is important
tantek: I don't want to switch to a system where people don't document
their problems.
dbaron: Mercurial is a one-line install on Linux
tantek: We shouldn't be discussing cvs vs mercurial, we should switch
to git
fantasai: Doesn't make sense to switch to git when our test suite is
in Mercurial.
plinss: Hg vs. Git, I don't see a significant advantage of git over
Hg, and the rest of W3C uses Hg. I don't think there's a
benefit for us to be different.
jdaggett: Ok, seems to me there's enough other variables for moving
to Mercurial, and we just need to get it set up.
jdaggett: I think what Rossen said is key: having a simple setup on
Windows
glazou: If you want to make it easy on Windows, you just get the
Mozilla build tools, and it's one click.
dbaron: The Hg installer on Windows is just as easy
jdaggett: There's a secondary issue, which is, a lot of our specs
are still using Bert's tools.
jdaggett: It's not set up to run locally, which to me is a problem.
jdaggett: I see comments, I have to get Bert to add a biblio entry
Bert: you can add that yourself
Bert: I put it as a CGI script so people don't have to install things
locally, but we can do that
jdaggett: I think one of the things we have to do is move some of
that infrastructure to whatever we're switching to
jdaggett: So that I just have a Makefile that will make in my directory
jdaggett: The problem is the bibliography is still in the old CVS
database
Bert: hmm, that could be tricky to move...
jdaggett: Should make it easy for people to do it locally, and then
for you, you have an extra step to get it updated on the
server
jdaggett: There are details in the script that need updating. E.g.
script doesn't know how to generate descriptor tables for
@rules
Bert: yeah, sure, I can do something about descriptors
jdaggett: If the build script is in the same system as the specs and
can run locally, then other people can also help improve
the build scripts
smfr: How much work is it to enable Make to run offline?
dbaron: I had it working a few years ago, but then upgraded and
doesn't work anymore
jdaggett: Uses tools
smfr: Would like to be able to just check out Hg repo and be able
to run Make
Bert: Might be easy on linux/Mac, unsure about Windows
dbaron: Didn't somebody reimplement Bert's script?
smfr: can't effectively work offline if we can't build offline
smfr: i don't think we should block on the document
glazou: That was what we decided
tantek: plan was to work on the document, nothing happened
fantasai: document was worked on. Just nobody ran into your problems,
so those problems weren't documented.
Tantek: Nobody ran into problems?
Nope.
Tantek: Maybe I should switch to QA.
plinss: Might help to link directly to Mercurial installer instead
of MacPorts
jdaggett: I think we've resolved that we will switch to Mercurial,
and we will work through the problems people have.
Tantek: What about working offline?
jdaggett: It's a separate issue.
plinss: I think we can set the direction
jdaggett: The issue I brought up, even if we don't go to Hg, still
exists
glazou: The proposal is to move to Hg and fix the documents later
RESOLVED: Move to Mercurial, work on docs.
fantasai: I think we need to work on some details about the move.
fantasai: (inaudible) pull and rebase (inaudible)
plinss: I don't want to have 3-4 different Hg docs on our wiki.
plinss: Not have separate docs for specs and testing
glazou: Break now. Vendor prefixes later.
Vendor Prefixes
===============
glazou: Title is: Why and How to Implement Other Vendors' Prefixes
tantek: This is a specific subtopic of vendor prefixes
tantek: The problem statement right now, and this is a problem for
Mozilla and any other non-WebKit browser
tantek: Sites have webkit-specific content, and serve backup content to
everyone else. Specifically for mobile content.
tantek: Non-WebKit browsers face prisoners dilemma
tantek: similar to quirks in 2003 or so
tantek: At this point we're trying to figure out which and how many webkit
prefix properties to actually implement support for in Mozilla
plinss: Zero.
tantek: Currently we have zero. Zero is no longer an option for us.
Florian, Sylvain: Zero is not an option for us anymore either.
tantek: We're doing an analysis of what properties we need to consider. I
want to minimize this.
glazou: A long time ago, Mozilla had an Evangelism team that would call up
the website owners and ask them to change.
Florian: Opera has a large and active one, but it does not scale.
Florian: I found on the rough analysis of top 1000 websites, several percent
use webkit prefixes without a fallback for others.
Florian: Regardless of how we ended up here, if we don't support webkit
prefixes, we are locking ourselves out of parts of the mobile web.
sylvaing: -webkit-text-size-adjust was implemented in IE. So we pulled it
out and asked that it be submitted for standardization. But it
wasn't. *looks at smfr*
tantek: We don't consider this a long-term situation. The goal is to open
up the webkit-specific part of the web to others, same as implementing
parts of IE-specific web.
tantek: We do have some experience in not screwing this up.
tantek: But it has come time to discuss this publicly. I have put our data
and findings on public wiki pages.
tantek: I'm bringing to this group b/c affects more than just Mozilla.
tantek: If we come up with a solution together, we can hopefully minimize
the problem.
plinss: You said this is a short-terms solution. Quirks mode was supposed
to be a short-term solution.
tantek: No it wasn't.
plinss: Yes it was.
plinss: I implemented it before you did.
plinss: The intention was to solve a short-term problem. It was supposed to
be gone in a few years. We're stuck with it.
plinss: If we open this Pandora's box, we're going to be stuck with it.
plinss: If people implement other vendor prefixes, then everyone will
implement others prefixes and we'll be stuck with it forever.
Florian: We are currently losing market share because of not implementing
-webkit- properties.
glazou: Do you have a -o- version?
glazou: I can write an add-on that converts the style sheet.
dbaron: What's the difference between that and implementing it in the engine?
Tab: Given the discussion is about webkit being a monoculture on Mobile, if
webkit decides to remove a prefix then it's okay for everyone to remove
prefixes also.
Florian: Some prefixes will not be dropped by webkit
glazou: None will be dropped.
tantek: So this is not saying implement -webkit- across the board.
tantek: This is consider implementing some -webkit- properties, and be very
deliberate about which ones and why.
tantek: We need to do analysis about how many sites we can fix and how much.
tantek: I don't see authors being recommended to use webkit, b/c works mozilla
as well. Goal is to get some sites working on Mozilla.
tantek: When I was implementing Quirks mode in MacIE. I didn't think it
would be short-term at all.
tantek: There were ~90 places where used switched.
tantek: Over time, I was able to cut some.
tantek: By the time Tasman got parked got to ~80
tantek: Probably would never go to zero, due to box-sizing, etc.
tantek: but some of those problems *were* short term.
tantek: wanted to offer that as a data point.
Alan: When you do analysis of site using webkit prefixes, do you go back and
see whether implementing the prefix will fix that 10%?
Alan: Or are there other complications where they're doing browser-sniffing
or otherwise wouldn't work even if you implement these prefixes?
Alan: I'm wondering about the efficacy of implementing webkit prefixes.
tantek: None. We will also need to send a webkit-tricking UA string.
tantek: Just like WebKit sent "like Gecko" in its UA string, we have to do
the same thing again
glazou: Two implementations will not fully match, but you will treat -o- and
-webkit- as the same.
Florian, Sylvain: Evangelism has failed.
glazou: Have you tried pinging the WASP about that? Other activists of web
standards?
sylvaing: If MS can't scale to handle this, you think WASP can?
tantek: Opposite is happening right now. Web standards activists are teaching
people to use -webkit-
tantek: People like Lea Verou.
tantek: Their demos are filled with -webkit-. You will see presentations
from all the web standards advocates advocating people to use
-webkit- prefixes.
glazou: Tab, how do you feel about that? Is there anything you can do?
Tab: There's enough legacy content that there are some properties that we
can't drop the prefixes.
Tab: Given that's a reality for us, totally sympathetic that it's a problem
for everyone else.
Tab: These are used on production sites.
smfr: Two categories of problem.
smfr: We have things like Transforms, which are being standardized and
implemented by other browsers.
smfr: There's others like text-size-adjust, which is only proprietary on
iPhone
smfr: Not sure about standardizing things like that.
smfr: Some of this is due to iPhone's success
...
Florian: If something is intended for internal use, then it is proprietary.
Florian: But once it's encouraged out on the Open Web, it cannot be
proprietary anymore.
Florian: The cat is out of the box.
Florian: ... If you submit a spec about things like this, we're back into
the other case.
Florian: ...
Florian: If we don't get specs for these, the problem is harder. But I
think we should get specs for these.
tantek: Once it gets served over the open Web, it is no longer proprietary.
sylvaing: A lot of authors assume that any -webkit- property is in the
standards process.
...
jdaggett: Maybe use a different prefix?
tantek: Once it's on the open Web, it's not proprietary
jdaggett: -apple-, or -iphone-
alexmog: Once Apple ships -webkit-, it's frozen.
<tantek> it can be considered experimental, but claiming it is
proprietary-only is inaccurate
smfr: It's not necessarily frozen, might be changed.
alexmog: We will never drop -ms-, or change -ms- behavior.
...
Florian: It doesn't solve the problem.
Florian: Whether it's -webkit-border-radius or -draft25-border-radius,
Florain: You will get content depending on that.
alexmog: Doesn't change the problem, but you can think about it differently.
tantek: I have a couple of questions.
tantek: Bringing to WG because I believe we can solve problem better together
than individually.
tantek: I'm going with assumption that none of us want to just implement
all -webkit- properties.
Tab: I don't even want to implement all -webkit- properties.
<tantek> https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#questions_and_methodology
tantek: What are the thresholds, even approximate, for implementing
-webkit- properites (or none)?
glazou: Unbelieveable we are having this discussion.
Florian: Our job is to solve interoperability. We want to discuss it here,
because that's our job.
tantek: Help us minimize the damage.
dbaron: Part of what Tantek is saying is that we want to look very carefully
at the evidence to see whether we need to do this.
dbaron: Can we get the draft to a point where we can unprefix?
dbaron: E.g. 2D transforms, based on Aryeh's tests, are interoperable enough
to drop prefixes right now.
dbaron: Maybe revisit our decision to merge 2D and 3D transforms, and take
draft to CR in a couple months.
Florian: Might not be enough to solve the problem.
dbaron: What Tantek is saying is that we're not going to look at this as a
single problem.
dbaron: The more we can unprefix, perhaps the less we have this problem.
tantek: One possible proposal is to only parse other vendors' prefixes in
conjunction with parsing unprefixed.
tantek: e.g. with -webkit-transform. We wouldn't parse that until we also
parse transform.
tantek: Thereby giving authors option to just use unprefixed, hopefully
biasing new authors to using that instead.
tantek: That is one example of methodology that we want to apply to limit
the damage of this.
tantek: If you can think of other examples of ways of thinking about this,
to provide ways of moving forward.
tantek: We are absolutely open to other ideas.
glazou: Simon said that Apple WebKit implemented -webkit-text-size adjust
for better experience on mobile.
glazou: I suppose this aims at mobile.
tantek, florian: yes.
glazou: This is replacing standardization by turning one implementation
into a de facto standard.
glazou: Instead of creating a de jure standard here.
glazou: The right thing to do would be for Apple to submit text-size-adjust
for standardization here.
dbaron: I don't see why Apple has to write the spec if they're not writing
the spec.
dbaron: We dealt with this with IE6. Bunch of stuff we had to copy IE6 into
the spec and implement that.
Tab: IE6 monoculture of desktop. WebKit monoculture of mobile. It's the same
problem.
smfr: I can take a list of properties we need back and see if we can bring
it back for standardization
glazou: In a reasonable timeframe?
smfr: Yes.
dbaron: Off the top of my head, the only thing not in this WG that's a major
issue is text-size-adjust
Florian: -webkit-appearance
?: That's in UI. But was dropped
fantasai: Maybe we need appearance: auto | none. (None of the other values
are useful.)
<tantek> https://bugzilla.mozilla.org/show_bug.cgi?id=708406
tantek: Have to do crawls by switching UA strings. But here's our data.
sylvaing: The -webkit-tap-highlight-color is very highly requested
fantasai: I think that's a case that's not very critical. Nice to have,
but not having it won't break anything. We should solve the
problem it's solving, but don't think we need to implement
exactly that.
...
tantek: I think if you're working on open standards, you should propose
your features before you implement them and discuss that here.
smfr: We can't do that.
sylvaing: We can't do that either.
tantek: We're going to push you to do that sooner and sooner.
jdaggett: If you're proposing something that's going to be put on a Web
page, how is that proprietary?
Alan: Do you agree with fantasai that tap-highlight-color isn't needed?
Alan: Not asking about threshold. fantasai saying that it's not necessary
functionality.
dbaron: I agree.
dbaron: Like Tantek said, i think we should look at each item carefully.
dbaron: The problem we're trying to solve is that users don't want to use
a browser because it doesn't support certain functionality.
dbaron: Users don't really care about tap-highlight-color.
dbaron: Users care about whether they can read the web page and can get
to its functionality.
tantek: Don't expect to come to a conclusion in this discussion right now.
But wanted to raise the issue and raise the questions that will
help us get to a better place.
Alan: Right now the only consider is percentage of usage.
Alan: If there are other considerations, like users don't care, that should
be in your page.
Florian: Looking at usage because it can be measured. Whether it breaks the
website, much harder to measure.
fantasai: I think we can make some subjective judgements on that.
Florian: Properties is not the only thing, e.g. gradients.
Florian: device-pixel-ratio is another problem.
tantek: Here's my challenge to non-Webkit vendors.
tantek: Please document what properties you're thinking of implementing,
and why. The why to me is more important.
tantek: Because that is how we will derive methodology to minimize the
properties we implement.
tantek: I really want to minimize this.
glazou: I think it's very unfortunate timing, esp. now that we're trying
to use prefixes for JS APIs.
glazou: You are solving a problem not with the right way.
Florian: give us a better way
glazou: You're saying that because you're saying the other ways did not
succeed.
Florian: We have 15-20 people in devrel, one of their primary jobs is that.
Florian: It doesn't scale.
tantek: Number of mobile websites providing webkit content first is growing
faster than we can contact them.
...
glazou: We're not just here to do things. We're here to do things the right
way. We want things to be stable on the Web for 50 years.
glazou: The technology, yes, it has to be readable.
glazou: I don't think this is the right way. And this is the first time in
this WG that we are proposing to do things that are not the right way.
sylvaing: Many don't consider the right way to be good.
glazou: You don't have to teach me about pragmatism.
sylvaing: We have authors who actively write tools to avoid the right way.
tantek: Want to close the discussion with a request for questions and
methodology
tantek: Request Opera and Microsoft to publish your methodology and what
properties you're thinking of implementing.
tantek: That way we can minimize the damage.
plinss: As soon as we do this, vendor prefixes have failed.
tantek: I don't think we need to throw out the baby with the bathwater.
plinss: I think the fact that Mozilla is discussing this publicly is harmful.
plinss: Nevermind actually doing this.
Florian: So what should we do?
dbaron: So what should we do, disband the WG?
plinss: yes
plinss: If we go down this path we have broken standardization.
...
plinss: Let's back up a second.
plinss: I think Alan raised the best point in this discussion. Your solution
doesn't work unless you spoof as someone else.
sylvaing: No, we did tests with text-size-adjust, just implementing it was
enough.
Tab: The biggest thing we're talking about is things like transforms. IP is
already released.
glazou: transforms almost interop, hope you will drop prefixes
Tab: If they're thinking of implementing it, then we're probably not able
to drop prefixes.
Tab: We try to drop prefixes, but some things are too heavily used.
Steve: I haven't heard anything new in the last 1/2 hour that I can detect.
Steve: I would summarize that there's a practical problem out there, that
should be trying to drive features to as quick standardization as
possible.
Steve: As a way of moving in that direction, attempting to implement an
existing prefix is getting a spec out of it.
Steve: If we cooperate on documenting what the prefix is, would help us
drive towards standardization.
glazou: I'm going to take problem from another point of view, from market pov.
glazou: WebKit has a monster advantage out of this situation. Why would
they help on standardization?
glazou: I'm dead serious. Are you going to help them gain market share by
standardization?
smfr: We're members of this WG, and accepted the IP implications of that
for transforms and stuff.
glazou: But you submitted that directly. But not text-size-adjust.
smfr: AFAIK we don't have a reason not to help standardization
text-size-adjust.
smfr: Think it slipped between the cracks; not enough impetus to standardize
it.
Alan: Mozilla and Opera have researched what are important for them to
implement.
Alan: The problem for you for this moment, locks in the problem for the
rest of time.
Alan: One alternative is that we can do this analysis, see here are the
ones that it would help us to implement as a prefix, and treat
those as house fires.
Alan: These are things we need to standardize on *now*.
Alan: Make it something that the WG finalizes within the next 3 months.
Alan: Go out and say, here is the unprefixed properties. Get the word out.
Alan: You fix the problem in a better way.
Alan: Lose out a percentage on websites that won't get updated.
Alan: But you stop the problem there.
Florian: We have everything to gain by reducing the number of times there
is a non-standard property used by a large number of websites.
Florian: Yes we should minimize such situations.
Florian: That will help in the future. But won't fix body of content
already out there.
Alan: Regardless of whether you implement those prefixes, this WG needs
to prioritize the work accordingly.
Florian: Strongly agree. Yet I think it is not enough.
plinss: Thing we need to spend some energy minimizing the escape of
prefixes into the wild
plinss: Fact that production sites use them, it's okay if it makes it
slightly prettier, but if not supporting breaks the site, then
that's a problem.
Alan: Devrel can't seem to get on top of that. Only thing this WG can
do is not put them in releases.
plinss: Should discuss putting experimental properties only in experimental
builds.
howcome: Should maybe put out a call to web authors to stop this.
jdaggett: I think strategy of just pretending to be -webkit-, without any
attempt ...
jdaggett: You need to make public statements like "Here is an example of
a presenter presenting -webkit- things as if they are a standard,
and they are not."
jdaggett: Need multiple people here to do that.
howcome: Including Apple.
...
Steve: Philosophical point. Standardization, when you control the consumers
and the generators, is much easier.
Steve: In good old days of telephones, ppl who made telephones and ppl
who installed telephones were relatively small set. Could get
interoperable standards and it worked.
Steve: We are operating in an environment where we can't control users of
our standards. We can influence them, that's point being made; but
too many of them doing too little reading that we can impact them.
Steve: This is just life.
fantasai: Having standards advocates advocate prefixes is making the problem
worse, cutting that off would improve the situation.
tantek: Florian's point that we're competing against Flash and mobile apps
is important.
tantek: Telling web developers to stop using webkit properties would mean
they stop writing web apps.
tantek: I think it's great that Apple wants to innovate as fast as they
can. I would prefer they propose to the WG, if not before
implementation, then when implementing. If not then, at least
when shipping. If not then with a few months, Simon?
tantek: I don't want Apple to slow down in innovation and implementing
new things. That helps the Web grow and innovate.
plinss: Your point about if people can't write webkit properties they'll
write a web app --
plinss: I would rather they write an iphone app than they write a web app
that only works on webkit.
plinss: There's no advantage to the Web to have someone write a
platform-specific website.
tantek disagrees.
Anton: I think it'll be very dangerous to make it obvious that we can
implement each others prefixes without making it very clear what
vendor prefixes are and how they're supposed to work.
Anton: Need the WG to agree and explain what problem they're trying to
solve with prefixes.
Anton: I think it is harmful to concentrate on this one problem and not
concentrate on the global problem. Send a very mixed message to
authors.
plinss: You're telling authors to just use webkit prefixes, we'll make
it work.
Tantek: No, we're only implementing a small minimized number of these.
fantasai: But if you don't make that clear, and communicate that, it'll
be interpreted as "if enough websites use it they will
implement it".
fantasai: Anton's point is that you need to send that message, and not
just in the CSSWG minutes.
glazou: If the user requests another -webkit- property, they will implement
it. It's a Pandora's box.
sylvaing: Listening to the conversation, sounds like this proposal is a
big injury to the Web, that prefixes are a [...].
sylvaing: I've sat in conferences where Eric Meyer show how to use prefixes
and then put unprefixed version for "future proofing"
sylvaing: Nobody gets it.
sylvaing: We have people trying to evade the system. Problem is large.
sylvaing: Prefixing works on theory in paper, and out in the real world
everybody hates it.
glazou: There's at least one way it didn't fail.
glazou: If you use -moz- prefix, you have to test it in Mozilla
glazou: If you use -webkit- you know it will only work in WebKit.
sylvaing: The advice being given now is to include the unprefixed version.
The system works in theory, in practice it doesn't work.
tantek: My experience with authors is that they Hate using prefixes.
tantek: If anything, they are annoyed with the CSSWG for taking so long
to get specs to the point where they can be unprefixed.
tantek: They complain that CSSWG takes too long.
tantek: Second reason is they are evangelized to use prefixed stuff, e.g.
-webkit-
sylvaing: The people who think prefixing is a good feature, majority of
them are in this room.
glazou: Even if we only take 3 months from FPWD to unprefixed, it's too
slow compared to shipping an implementation, which is then used
immediately.
Tab: We can break some people. But not everyone.
glazou: Transforms emerged not long ago. Web is full of them.
glazou: It took 3 months to have real life examples of ppl using transforms.
Tab: I thought 2D transforms have been around for a while.
Steve: Are we getting somewhere?
tantek: I tried to close once with request with more questions.
glazou: Seems that the 3 browser vendors here have already decided.
dbaron: I think one of the underlying problems here...
dbaron: The IETF has a motto "rough consensus and running code"
dbaron: I haven't deal with them much. But I think one of the problems I
sense in this group
dbaron: is that it's just as easy to hold up a specification that has no
implementations as it is to hold up a spec that's got 4
implementations and everyone pushing to use it.
dbaron: There should be a bias based on what the real state of something is.
dbaron: What the state of implementations is.
dbaron: When we've got something like 2D transforms thats implemented in
4 major browsers and it's blocked.
dbaron: Should be harder to put process blocks on that spec.
dbaron: We have a test suite now, but we've agreed to abandon the spec.
alexmog: I think implementations should use -rfc3300- prefix
alexmog: have a draft that defines what that means, experiment with it
alexmog: if it fails, it fails, if it succeeds, it's defined what it is
sylvaing: ?
alexmog: Not different from today, but don't have the moral problem of
implementing another vendor's prefix
Steve: First, RFCs are specifically withdrawn after 6 months. Spec
disappears by definition.
dbaron: That's a draft. Not RFC.
Steve: We're not talking about specs. For the user to use things, there
has to be documentation for the user.
Steve: The problem is asking for documentation sufficiently well-specified
for interop
sylvaing: Both us and Apple document our things on our site, but not enough
for standardization
Steve: Suggest that group establish a goal that members who introduce
experimental properties submit a description to the WG
Steve: Maybe it just goes into a file somewhere, until someone wants to
follow up
Steve: But at least it becomes available to the WG, which Tantek was
requesting.
Florian: Said that there's no progress in this conversation.
Florian: Some people are saying don't do this. But all the vendors need
to do this.
Florian: Blocking the conversation here just means don't do this in this room.
Florian: The idea is to discuss the how.
plinss: We haven't spent any time discussing how not to do this.
Florian: I think we did enough on why.
plinss: Only if the what else has failed should we go onto how.
plinss: You have tried and failed individually. Not as a group.
dbaron: a year ago we tried to discuss dropping prefixes before CR, and
failed at that.
fantasai: No, you added additional requirement of having the test suite.
plinss: If you have a list of properties you have to implement to survive,
then let's get that list, get consensus on it, and then agree to
standardize them as-is implemented in WebKit.
Florian: That only stops the bleeding.
plinss: If we do this without a plan to stop the bleeding, it's only going
to get worse.
Anton: And will cause confusion.
plinss: To go back to Quirks mode. The original intention -- it was
intended for NS4, btw, not IE6 -- the problem was too many sites
to fix, we have to support them.
plinss: But we wanted to support only the old sites, and new sites should
be written to standard
plinss: People are still writing sites today that depend on quirks mode
in order to function.
plinss: People 20 years from now will be writing sites that support
webkit prefxes.
dbaron: There's a major piece of Web standards community, not well
represented in this room, but better represented in HTML and WHATWG
dbaron: They think quirks mode was a mistake. That we should have just
lived with that behavior.
plinss: I accept that as a philosophy, but that was impossible.
plinss: NS4 did not treat HTML as a structured document.
dbaron: I think quirks mode very quickly diverged from its original intent
dbaron: Because 2 years after IE had 95%+ market share
dbaron: It became about being compatible with IE, not NS4.
plinss: If we launch this vendor-prefixed quirks mode, it's going to get
out of hand. Whatever our desire to minimize our impact, it's
going to get worse than what we expect.
Florian: Not spread to everything
plinss: Going to get worse than you expect
dbaron: Email headers with X-. Supposed to be experimental. But the world
still works.
tantek: While I understand the analogy with Quirks mode, I disagree
tantek: We can search for and get data on prefixed property use
tantek: You can write a linter that points out your webkit properties.
tantek: quirks mode you can start relying on accidentally
tantek: I don't think this is as bad as quirks mode.
tantek: Quirks mode biased being lazy.
tantek: The policy we have for prefixes biases the right thing, which is
no prefix.
tantek: It takes work to use a prefix, whereas it didn't take work to
use Quirks mode.
tantek: I can see the similarities but in practice I think they're very
different.
plinss: My assertion is that it's still going to be worse than you think.
plinss: People will write tools and inject things, etc.
plinss: Authors are going to have this happen to them, because of tools.
sylvaing: Once those -webkit- properties work in other browsers, are people
going to check which ones work? Or are they just going to assume
that all -webkit- properties work?
tantek: It is up to us to make sure that the unprefixed properties are the
most reliable.
tantek: And that's how we end up driving off the -webkit-
tantek: Being neat only drives authors so far. They want reliability. If
we can deliver that with unprefixed
plinss: We need to get in people's minds that if you use prefixed, we will
drop support for it at some point.
plinss: We should assert leverage to get MS and Webkit to change their mind.
plinss: Prefix has half-life. It will live for so many years, then go away,
by definition. That will help this problem.
plinss: If we can get something like that stuck in the ground, then my
objection drops dramatically. Because we've cut the bleeding.
glazou: I heard earlier that prefixes are bug not a feature.
glazou: Prefixes for web authors, they don't think it's a bug. They think
it's a burden. It's not the same thing.
glazou: It's a burden b/c they don't know how long they have to maintain them.
glazou: If prefixes were only implemented for 3 years, that would help.
tantek: mozilla has a policy of dropping prefixes when we implement unprefixed
tantek: Web authors can know just by Mozilla, that prefixes are uncertain.
tantek: IE10 broke many things. I would not be surprised if MS will drop
prefixes at some point.
<sylvaing> note that IE10 dropped legacy features from *standard mode*
<sylvaing> Trident still includes legacy features for older docmodes;
the latter are necessary for intranets for instance
fantasai: We would not be having this conversation if mobile did not exist,
correct?
agreement
fantasai: What if -webkit- was implemented only for mobile? That would add
the unreliability factor that Tantek was asking for, because it
would not work on desktop. And that would bias authors to using
unprefixed, which is what we want.
<br type=lunch>
<glazou> for those who know him, Tristan Nitot from Mozilla Europe says hi
* sgalineau doesn't know Tristan, but knows of Tristan....
<fantasai> jdaggett, what were the text issues that you raised?
(other than @text-transform)
* fantasai only knows about the issues in
http://www.w3.org/Style/CSS/Tracker/products/10
ScribeNick: TabAtkins
<jdaggett> fantasai: i'm on drugs, issues were in writing-modes
<jdaggett> fantasai: but text-transform will take a bit of time i think
<fantasai> jdaggett, my plan is to cut anything that has issues that
can't be solved between now and march 1st
<jdaggett> fantasai: in text? writing modes?
<fantasai> jdaggett, text
<fantasai> jdaggett, unfortunately white space processing is not
optional, so I have to fix all the issues in it anyway :)
<jdaggett> fantasai: so you're shooting for LPWD at end of march?
<fantasai> jdaggett, shooting for the beginning of march, hopefully
make it by the end :)
Aliasing Details
================
ScribeNick: TabAtkins
florian: When a browser supports several variants of the same property
(either prefixed and unprefixed, or multiple prefixed), what
does it look like through the OM?
florian: If we favor interop here, we should decide what it says.
florian: But David argues that we shouldn't favor interop here - the
fragility helps discourage prefix usage.
[some discussion over one impl strategy]
florian: Another strategy is to always favor your impl, as it can
let someone target your impl well.
sylvaing: What do browsers do today?
florian: We don't have a problem with it yet.
dbaron: Gecko never implements different semantics for two things.
dbaron: The only time we've had two things in gecko is with prefixed
and unprefixed.
dbaron: When we did that, -moz- was treated as an alias for unprefixed.
dbaron: If you asked for the -moz- in the OM, you'd get back the
unprefixed.
dbaron: If you got the list of properties, you'd get the unprefixed
as well.
dbaron: It was meant to steer people toward the unprefixed.
dbaron: Webkit supports multiple prefixes with different semantics.
alexmog: In general, only cascading should matter. If a dev puts it
there, it means that they want it.
alexmog: If you have two prefixes, you should favor your own.
TabAtkins: What about -webkit- and -epub-?
alexmog: You should favor the -webkit-.
sylvaing: Why is it different from prefixed and unprefixed?
alexmog: I need to be able to target specific impls.
sylvaing: So if -webkit- is supported by Opera and it's the last one,
what happens?
florian: If you set up a hierarchy (your prefix is stronger than
other prefix, unprefixed is most important), what happens
if you have different specificity/important?
sylvaing: We had that with 'opacity' and 'filter'.
florian: Back to David's original point, do we *want* to synchronize,
or is it a feature that we're all different?
plinss: I question whether we need to standardize on something
vendor-specific.
florian: The problem is that authors should have a reliable way,
when reading stylesheets from JS, knowing which one will
work.
florian: Does putting the unprefixed last guarantee that it'll be
the one that's chosen (when selected), or might some
prefixes win anyway?
plinss: In general, I don't like adding feature to help people work
around vendor bugs.
plinss: I think it's fair that vendors put in special-case code.
florian: I would be happy if the WG said that, when prefixes are
used, they alias and are chosen in turn by the normal
cascade.
florian: Also, do multiple versions of a property all survive to
the OM?
Rossen: If they're aliases, they should all point to the same thing.
If they're not, they should point to different things.
TabAtkins: [explains WebKit's behavior - generally, they're aliases
in the stylesheet, but separate in the OM]
florian: I remember what was said.
florian: If you use multiple versions in the stylesheet, then all
are preserved in the specified value, but only the "winning"
one lives in the computed style.
TabAtkins: But Gecko always returns the unprefixed version in the
computed style - they don't remember the source.
fantasai: We have some unprefixed aliasing too - overflow-wrap
and word-wrap are (unprefixed) aliases.
dbaron: I don't think we should have aliases in the spec.
florian: I think it's reasonable, even if it's just an optional alias.
We should still define how the cascade and OM work for them.
florian: I propose that it gets converted to the "most standard" one,
and it appears as that in all cases in the OM.
fantasai: We also have page-break-* and break-*.
fantasai: I need to put that into a spec. So we need a resolution
for this.
sylvaing: I'd like to see some testcases, if someone needs to change.
sylvaing: In the case of filter/opacity, it depends on document mode.
[something about the specifics of IE modes]
plinss: When it comes to aliases, has anyone implemented those yet?
howcome: I think we support break-*, and page-break-*. I don't think
we do column-break-*
howcome: I'm not sure what we do with the OM.
szilles: For "most standard", if I have -webkit- and -epub-, which
is most standard?
tantek: I think that Moz always converts to unprefixed in the OM.
[several moz people]: No, that's not what happens.
plinss: Maybe that's a good approach, though. Just *never* show
prefixed in the OM.
TabAtkins: That seems reasonable to me.
glazou: And what about when serialized?
plinss: Serialization is different.
glazou: If it doesn't show up in the OM at all (when an unprefixed
doesn't exist yet), that will break editors.
tantek: We set a precedent for prefixing in the DOM, too.
tantek: We probably want to keep things prefixed in the OM, then,
so we can justify other web apis prefixing.
<sgalineau> if one supports -prefix-foo and foo and the stylesheet
only sets -prefix-foo, does getComputedStyle() expose
it as prefixFoo or foo ?
florian: The simplest thing we can do is that, at the cascading level,
the last one wins.
florian: In the OM, the one that's used is returned.
dbaron: I don't see any need to remember prefixes in Gecko.
macpherson: I think the most consistent is to reflect the used
version.
macpherson: If we change the spec after implementation, you'll
need to return the value in the old form as a prefix.
dbaron: Part of the Gecko strategy to discourage prefixes is that,
the *instant* the unprefixed is supported, the OM no longer
supports th eprefix.
dbaron: We may support it still in the stylesheet for a bit, as
necessary.
plinss: Our policy should be to keep prefixes fragile.
TabAtkins: Yes.
plinss: If you use prefixes, here be dragons, and we won't help
you keep it working.
jdaggett: While members are cool with that, their companies have
marketing departments that may not agree.
macpherson: I think you can handle that by just dropping when we
can, not by *forcing* prefixes to break automatically.
sylvaing: We shouldn't punish success.
florian: So should we preserve the prefix or not?
dbaron: We haven't had content breaking because of dropping the
prefix in the OM.
smfr: We probably would have content break in WebKit if we did that.
florian: As an editor, Daniel, do you prefer what the stylesheet
originally said, or what is used?
glazou: From a CSS editing program, I'd prefer getting back
*everything*. But at least, what the author said.
glazou: If an editor changes properties between input and output,
we'd just get complaints from users.
florian: By now I know what I want to ipmlement, so I wonder if
we should consider discussing until we agree on what to
implement, or if we should learn to love the breakage.
florian: The cascade wins (the one that comes last). When you
query through the OM, you only see the one that won
(with or without prefix, depending on which one won).
florian: So internally you remember which name was used, but you
otherwise treat them as aliases.
glazou: Say that Opera supports a -webkit- property, and -webkit-
drops its prefix.
glazou: Before you drop the prefix too, if -webkit- is used last,
you'll output the -webkit- rule in the OM, even though it
will no longer work in WebKit.
florian: Yes. That's internally consistent.
glazou: But you have inconsistencies for a little while.
glazou: My preference would go to supporting the last one in
implementation order, not cascading.
florian: When a page is authored toward a particular prefix in
script, that'll break the page.
alexmog: I can explain what we might think of doing.
alexmog: We preserve all the properties that are set.
alexmog: So if you write out a file, we'll write out everything.
alexmog: If you query through the OM, we only preserve one of the
values after cascading.
alexmog: If hypothetically we have -ms- and -webkit- and unprefixed,
all will return the appropriate syntax, but from only the
winning value.
florian: If the -webkit- won the cascade, do you see it as -webkit-,
or as something else, or as all of them?
alexmog: So if we support multiple names for a property, we'll
return the winning declaration as *all* of them (perhaps
with adjusted syntax, as necessary).
alexmog: So we probably won't want to remember who won.
szilles: What do you do if the values changed between property
versions?
alexmog: We'll adjust the output to match the syntax of the given
version.
Rossen: I don't think that's right.
Rossen: Today we only have aliases.
alexmog: We remember literal attribute and property values.
[some discussion about the exact behavior of MS]
florian: But if you ask for a list of the properties on an element,
do you get all of them, or just the winning?
sylvaing: Yes, even if you only specify one of them in the stylesheet.
plinss: We won't ever get every single value - fully unsupported
properties won't show up.
[something about how Blue Gryphon works]
florian: So the suggestion is that, if you specify only -moz-
(in Firefox), then in the OM you'll see both unprefixed
and moz-prefixed.
florian: Is that okay?
glazou: Maybe.
glazou: [explains why it may be difficult, but not impossible]
plinss: You just need to have a table, based on the version of Gecko
you're using, saying which properties are unprefixed.
TabAtkins: That behavior sounds fine to me.
dbaron: [explains exactly what Gecko does - it's identical to the
proposed behavior, except that the CSS2Properties interface
(like el.style.boxShadow) only shows one version at a time ]
glazou: [clarifies his understanding, and asks about prefixed values
as well]
RESOLVED: When a browser supports multiple versions of a property,
they're treated as aliases in the cascade, such that last
wins. In the OM, *all* variants show up, with equivalent
values, regardless of which version was specified or which
won.
plinss: For aliases, this should be clearly specced.
plinss: Distinct from prefixed stuff.
florian: Is this somewhere centralized in CSSOM, or do we specify
it every time we have an alias.
RESOLVED: The last resolution applies to WG-approved aliases. It
MAY be used by browsers for prefixed versions as well.
florian: Now, for prefixed values.
florian: I say just return the one you got.
plinss: Agreed.
TabAtkins: Agreed.
Florian: What about individual media query features?
TabAtkins: I think they feel a little more like values, so I'd
preserve them as the author wrote.
florian: Does anyone who cares object?
fantasai: Deferring to dbaron.
plinss: The point for properties is so we don't have to remember
which version it came from.
florian: But for values we reasonably often can't cover all the
possibilities between versions.
RESOLVED: When value aliases are supported, return the version that
the author provided.
RESOLVED: In media query feature strings, also return the version
that the author provided.
Received on Tuesday, 7 February 2012 08:44:11 UTC