- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 6 Aug 2014 20:56:26 -0400
- To: www-style@w3.org
New CR Process
--------------
- Everyone was tasked with reading the new process for CR
documents in order for the group to be able to discuss how to
handle current CR documents in light of the new process.
Fonts
-----
- RESOLVED: John Daggett is reinstated as Font spec editor
Animation Issues
----------------
- Defer to next week
CSS Color Classes
------------------
- Many members of the group expressed a desire to have a more
unified color class instead of the separation in TabAtkins'
proposal; something closer to what leaverou is trying to
create.
- There was also concern expressed for how the proposal handled
CYMK colors.
- Tabatkins requested that people type up their proposes and/or
thoughts in e-mails so that he can respond in long form with
his reasoning for separation.
Brand Color
-----------
- gregwhitworth will post examples to the mailing list in order to
further conversation.
Transform as a shorthand
------------------------
- There was some of skepticism about the value of the proposal,
but most people wanted more time to consider it.
- Some others expressed a desire to focus attention on review of
transforms level 1 before considering this proposal.
- TabAtkins will create a document that looks more like a spec
proposal in order to aid conversation which will likely
continue at the F2F in September.
Ruby
----
- After a bit of clarification, these items were deferred to the
mailing list.
September F2F
-------------
- Everyone was reminded to register because if they don't, they
won't have network access.
===== FULL MINUTES BELOW ======
Present:
Glenn Adams
Tab Atkins
David Baron
Bert Bos
Adenilson Cavalcanti
Alex Critchfield
Dave Cramer
Bruno de Oliveira Abinader
Elika Etemad
Simon Fraser
Daniel Glazman
Dael Jackson
Peter Linss
Edward O'Connor
Matt Rakow
Florian Rivoal
Lea Verou
Simon Sapin
Dirk Schulze
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Rossen Atanassov
Chris Lilley
Michael Miller
Simon Pieters
Anton Prowse
ScribeNick: dael
New CR Process
--------------
glazou: Let's start, guys.
glazou: As usual, extra items on the agenda? I have two to add.
florian: I have a brief comment. Just wanted to comment about the
upcoming F2F wiki. There isn't much about agenda or
participation details.
glazou: We should start putting items there, agreed.
glazou: My two things: first is the new process. It's live and we
have to decide the new CR exit criteria. What do we do
with existing specs in CR? Do we republish under the new
process?
<glazou> https://www.w3.org/wiki/ProcessTransition2014
glazou: The document is the above URL. That's the transition
document. It has a section about the main changes. I
suggest everyone reads.
glazou: Have people had a chance to read this?
fantasai: I have. I read it a while ago.
glazou: Others?
<adenilson> nope.
<TabAtkins> read it
Several: nope.
glazou: Let's put an action on everyone to read for next week.
Action everyone read the new process doc.
* trackbot is creating a new ACTION.
<trackbot> Error finding 'everyone'. You can review and register
nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
<krit> topic for F2F?
glazou: This is possibly for the F2F, but with the action for
reading it now there's no excuse not to have it read by
Sept.
fantasai: I think we should transition to the new process as we
publish specs. If we republish a CR we should do it into
the new process.
<krit> agree with fantasai
<TabAtkins> I agree with fantasai too.
glazou: I'd like everyone to read the new process.
Fonts
-----
glazou: Second item is about jdaggett. He's rejoining as you saw,
but won't be at the F2F. He'd like to become editor of
Fonts again and requested agreement from the group. I
don't think it's a problem.
<Bert> +1
<krit> +1 for John
<fantasai> yay!
<SimonSapin> +1
<SteveZ> +1 for John being editor
TabAtkins: I say yes because otherwise I'd have to take over.
glazou: Any objections?
<florian> +1
<adenilson> +1.
<leaverou> +1
RESOLVED: John Daggett is reinstated as Font spec editor
Animation Issues
----------------
dbaron: I think we can save that for next week.
dbaron: sylvain was going to start a thread, and said he would do
so tomorrow.
glazou: No problem.
CSS Color Classes
------------------
TabAtkins: I haven't read minutes from last week. Did we discuss
last week?
[silence]
TabAtkins: So no. In that case, leaverou hasn't posted the counter
proposal, so I say we keep the first section until
later, I'll continue pinging her. I know she's busy.
TabAtkins: We can doing the naming of RGB Color Class. As I said,
the name RGBColor is taken by a DOM level 2 style
interface, one of those terrible ones. I don't think it
matters in the slightest.
TabAtkins: I'd be surprised to find one in one million pages using
this. I'd be surprised to find one. I think it's fine
for us to steal the name as browsers never implemented
it or in Blink's case halfway implemented.
<dbaron> I've seen some pages using the class, but I don't
remember seeing them use the name.
TabAtkins: We can rename it to something else and have a note in
the spec saying we're stealing this name.
<krit> Is there a use counter in Blink for it?
TabAtkins: There is no use counter in blink for it, but I am 100%
confident in the results. If you think it's needed we
can measure, but I think it'll be below the noise
threshold
TabAtkins: I don't believe we report below one in a million.
glazou: Do we really need RGB Color and HSL Color? Can we have
Color?
leaverou: That was what the counter was going to be. The main
problem is...It was going to be having RGB in the same
color class instead of separate classes, but there's a
name collision.
leaverou: There is an issue that TabAtkins and I discussed on IRC
after the last call. If we don’t have single letter
properties, the collisions are much fewer. However,
there is still one. If we ever add HSV, there will be a
collision on the saturation property, since HSV’s
saturation is very different from HSL saturation.
leaverou: That's one of the reasons I don't have a counter is
because I don't have a solution.
glazou: I'm trying to think as a web designer. A color is a color
and you're expressing in different units. I don't see the
point of separating.
TabAtkins: So we need an extra type whose sole purpose is to
differentiate between HSL and HSV?
fantasai: I don't think a type is right, I think you need separate
functions with separate names.
fantasai: You may just have HSLSaturation/HSVSaturation.
TabAtkins: That's worse. It's verbose and inconsistent. Nothing
else will be tagged. I think it's redundant to have RGB
Red.
<SimonSapin> color.rgb.r?
<dbaron> SimonSapin: We could have color.rgb.r so there's an
intermediate object
* dbaron wonders if we're doing HSV, HWB, or both?
<leaverou> dbaron: we currently have HWB in the ED, but it's
possible HSV will be added in the future
glazou: I suggested it for cleanness of proposal and because it
solved naming issue with DOM.
<Bert> (That was also my main question on reading the proposal:
why 4 classes instead of just 1?)
TabAtkins: I don't think the name is important. I have other
reasons why I don't want to merge. I'd prefer to give
them in an e-mail because they're long, but name
collision is one reason I think it's the way to go, but
there's at least two other important reasons.
TabAtkins: I'd rather wait until there's a serious proposal.
SimonSapin: I typed a proposal on IRC.
<leaverou> SimonSapin: +1
TabAtkins: Can someone raise this in the mailing ist so I can
raise objections in long form text?
<leaverou> agreed this will be better discussed in the ML
<glazou> +1
Florian : For everything that happens in RGB space, the CYMK part
bothers me because for every other coordinate system
it's the same, but it's not that with CYMK
TabAtkins: I think you'd have to make it so that each class
represents different syntax for each color space. CMYK
and RGB.
Florian: I'm not sure I'm comfortable with having a conversion
between RGB and CYMK
TabAtkins: We have that problem with device-CMYK. Right now if the
browser has knowledge of conversion it uses that, else
wise it uses naive.
<leaverou> fwiw, I think the current spec treats CMYK/printing as
a second class citizen, and SimonSapin’s concerns are
very valid
Florian: Yes, but that is using things beyond the syntax level.
This is just introduced for syntax reasons. Now we're
going beyond syntax and using color spaces. You don't
allow it to do the smart thing.
glazou: Let's take this back to the ML and move on with the agenda.
Florian: So put this on the list?
TabAtkins: Yes please.
Brand Color
-----------
glazou: TabAtkins you said something on the ML?
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Jul/0131.html
TabAtkins: Someone said they can take this?
gregwhitworth: I was going to speak to what it was. We've been
approached by windows phone to add an accent color
and we looked at other phones, such as iphone that
may have this. We think there should be a broad
consensus. It's not really a highlight, which was
deprecated. We were looking for what does the WG
feel the best place for this is. We'll need
something.
TabAtkins: I'm not 100% clear on use cases. Some examples of how
this is used in an application, that would be cool. I
don't get it right now.
<dbaron> A generic accent color is a bit hard to use in
combination with other colors since you don't know what
other foregrounds/backgrounds will work with it.
gregwhitworth: I can provide that. It's system color, but that's
deprecated. You're setting an accent, so you're
doing a theme on the desktop. Initially we were
going to say appearance, but that's deprecated too.
We're looking a place to stick a color.
TabAtkins: This is why I need examples. I can imagine several
different ways to do it, but it depends on what you're
doing with it. Color might not be best because you
might need light and dark.
glazou: What you said sounds similar to CSS system colors we had
in the past. We retired that because eventually there
wasn't enough to do with that.
TabAtkins: That's why I want to get past the abstract.
gregwhitworth: I'll follow up on the thread with examples.
Transform as a shorthand
------------------------
TabAtkins: I posted a summary on the list about an hour ago.
TabAtkins: It's adding three properties, transform, rotate, and
scale. Syntax is similar to the functions and
implemented in a similar way to transform-origin.
TabAtkins: In particular they are pre-pended to the list in
translate, rotate, scale order.
TabAtkins: After the transform-origin business.
* dbaron notes that "after" vs. "before" is ambiguous depending on
whether you're using row vectors or column vectors...
<SimonSapin> dbaron, my experience with implementing transforms is
randomly swapping matrix multiplication order until
it looks like other implementations
TabAtkins: That's basically it.
smfr: Does your proposal have the transform-origin business?
TabAtkins: Yes. They're not required to be there, we can just say
they use transform-origin, but I think it's nice to
have them separable.
fantasai: There will be lots of cases where you'll want to change
the origin.
TabAtkins: Yes, As I said these should be short hands of original
divs.
TabAtkins: So translate would be X,Y and Z. So they're useful to
cascade separately. If I'm doing several rotations
around a non-default axis, that's useful.
glazou: Other opinions?
krit: I'm skeptical to be honest. Maybe we should that more time
and talk at the F2F?
TabAtkins: We've talked about this for 2 or 3 weeks, but the F2F
is an okay delay.
krit: I think two more weeks is okay.
TabAtkins: I'm not saying it's unreasonable.
* fantasai is happy to take this to F2F,would prefer people
focused on krit's request for reviewing L1
smfr: I think Apple's feeling is this is an unnecessary
complication. We won't be too upset if it happens, but I
object to splitting into separate properties. We've resisted
that in other places. I don't protest the simplification,
but I don't want to break them into more longhands.
TabAtkins: Well, there was background-position that we resisted
breaking, two browsers broke it into independent X and
Y because authors wanted that. I don't see a difference
between those.
krit: I think that's a bad example because that was partly from
implementation details.
MaRakow: Split background properties have been pretty painful as
it introduces a lot of complexity and a huge test matrix.
* fantasai notes the main use case for splitting bgpos was image
sorites, which is a hack
<TabAtkins> The use-case was a hack, but the reasoning behind the
use-case (wanting to position things according to a
grid, where you want to write X+Y rules rather than
X*Y rules).
glazou: It appears this still needs more discussion. The scope of
the proposal...everything. We need more to make a decision
and there's an objection from Apple.
glazou: fantasai, you say you want it as F2F item?
fantasai: I think it's fine to bring this up at the F2F. I'd
rather people focus on Krit's request to review level 1
and that's the same people.
<adenilson> +1
glazou: Other opinions?
glazou: Do people agree with fantasai?
Krit: No objection to the priorities.
glazou: Let's do as Krit wants and continue working on the other
proposal. I don't feel this is entirely ready, even after
the discussion.
TabAtkins: I'm fine with review, but it's ready to be done.
<dbaron> presumably the proposal is
http://lists.w3.org/Archives/Public/www-style/2014Jul/0315.html ?
glazou: We need more than an e-mail for the proposal.
TabAtkins: What do you mean?
glazou: A document or section? A changes section?
TabAtkins: The entire proposal is pretty complete in the e-mail. I
can write it in the visual style of a spec.
smfr: Is this to go in transforms 1?
TabAtkins: I won't do anything level-wise that means there will be
objections to the spec because of level. It can go
where ever as long as it get in somewhere.
krit: Having a more spec looking document might help the review.
With examples. It's maybe asking a lot, but just reading an
e-mail can be hard.
TabAtkins: I'll put something together.
fantasai: I think this would be level 2. Maybe create a WD of
level 2 for this? I don't want to put a time limit
because the same people need to spend time reviewing
level 1.
TabAtkins: I don't think every object being done separate is
useful, but I don't care what level it goes in.
fantasai: If you want to draw up a document, get permission to put
it on the dev pages.
TabAtkins: It's on my github.
glazou: So when it's published, will Google implement right away?
TabAtkins: No
glazou: I want to make sure this is on the normal rec track.
TabAtkins: This is a personal proposal.
glazou: Then I have no objection for it being in level 2.
krit: Let's go on with an unofficial draft first.
TabAtkins: Agreed.
TabAtkins: Levels isn't relevant yet.
glazou: Everyone agrees? No objections?
fantasai: Unofficial draft, what will you call it?
TabAtkins: I'll call it my proposal on my github.
fantasai: I'd prefer it doesn't get put on github. We're writing
proposals.
TabAtkins: I'm doing e-mail attachments.
glazou: We used to be able to store proposals on w3c. Bert and I
sent proposals and I think TabAtkins should be able to.
TabAtkins: We stopped when I got objections to putting proposals
on that.
glazou: Not on dev, it was on the WG page.
TabAtkins: Oh. None of us have that permission
fantasai: That is annoying. We should have a way to put everything
on dev that's unofficial.
glazou: Everyone fine with that?
<gregwhitworth> I like GH myself, maybe a W3 GH repo?
<gregwhitworth> Then it gets pulled in automatically?
krit: No objection to dev or github.
SimonSapin: On w3c.org, how do we do that? Through CVS?
glazou: I suggest TabAtkins uses his github.
Ruby
----
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Jul/0620.html
glazou: We have two topics. First was by Boris about leading and
trailing whitespace rules.
fantasai: I think that will have to stay on the mailing list, I
haven't gotten to it yet. Unless someone has interest on
the call.
dbaron: I think they're both better on the mailing list.
SteveZ: I was confused from Boris' example why the base isn't just
text and whitespace is disappearing.
fantasai: There's special handling in Ruby to clear what you use
of indentation. We have a bunch of rules to generate
anonymous boxes and I need to sit down and find the
right way.
TabAtkins: Ruby bases and text are on different lines and there's
rules about putting things for white space.
fantasai: There's rules about anonymous box and white space
discarding and I need to sit down and find a fix.
fantasai: If you care about white space at a higher level, read
the spec and send comments.
SteveZ: I've tried, but get confused between elements and boxes.
fantasai: They should all be boxes.
SteveZ: White space is an element thing.
fantasai: A content thing.
SteveZ: But they're elements. They're nodes, but not boxes.
fantasai: There's a bunch of examples in the spec.
SteveZ: Trying to read it and the Ruby HTML spec doesn't work well
together. I'll do it on the mailing list.
glazou: So both items will go off the call. That's the last thing
on the agenda. Bert F2F details?
September F2F
-------------
Bert: Register. If you don't register, you don't get any network
access.
Bert: If you have questions or things for the wiki, let me know. I
put the things I thought should be included, but let me know
glazou: You've reserved a room? That's not mentioned on the wiki.
Bert: I don't know the name of the room, but there is one reserved
for us.
glazou: Anything else?
glazou: Okay. Then I think we have a short call.
<gregwhitworth> How do you register, send an email is there a
magical button?
<plinss> http://wiki.csswg.org/planning/sophia-2014
glazou: gregwhitworth, to register you need to add your name to
the wiki
gregwhitworth: How to you do that?
<fantasai> http://test.csswg.org/shepherd/
plinss: Use w3c.org or shepherd credentials. It's a bit tricky,
but we had a lot of spam.
gregwhitworth: Thanks.
<Bert> (If you can't use the wiki, send me e-mail, and I'll edit
the page.)
glazou: The main page of the wiki says how to register through
shepherd.
glazou: Thank you for today and I'll see you next week.
<adenilson> bye.
Received on Thursday, 7 August 2014 00:56:55 UTC