- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Mar 2014 20:47:29 -0400
- To: www-style@w3.org
Seoul F2F
---------
- Glazou asked that those that volunteered to speak at the event
with the Korean government message him with proposed topics.
Rename extent/measure to block-size/inline-size
-----------------------------------------------
- RESOLVED: Rename to block-size and inline-size
CSS Scoping
-----------
- TabAtkins and fantasai discussed the proposed agreement that
they came to for combinators and pseudo-elements in Shadow
DOM.
- They also brought to the group their proposal for CSS Scoping
which includes their above solution, some styling text from
Regions, and new proposed syntax of @scope.
- RESOLVED: ED for CSS Scoping
- Granting a FPWD for CSS Scoping will be considered at next
week's telecon after the potential issues are integrated
into the document.
Asynchronous Decision Making
----------------------------
- Specific details on how the group will handle asynchronous
decision making was decided:
- All requests will go through the co-chairs.
- Co-chairs will post the request for decision on both the www-
style list and the internal working group list as well as
the twitter account.
- Most decisions will be given at least a week for comments
with urgent and administrative decisions potentially
being given shorter periods.
Ruby Anonymous
--------------
- The group agreed in principle with twk's proposal for CSS Ruby
being in line with HTML5's treatment.
- fantasai will look specifically at fixing the spec.
Transitions
-----------
- dbaron's question about handling how style changes interrupt an
already-running transition and put it on a different path
was discussed with Google's implementor being willing to
help him come up with a solution.
- RESOLVED: Move to matrix for the serialization of the computed
value for Transitions.
=====FULL MINUTES BELOW======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Tantek Çelik
Elika Etemad
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Koji Ishii
Dael Jackson
Taichi Kawabata
Brad Kemper
Philippe Le Hégaret
Peter Linss
Edward O'Connor
Simon Pieters
Anton Prowse
Matt Rakow
Dirk Schulze
Alan Stearns
Lea Verou
Greg Whitworth
Steve Zilles
Regrets:
Bert Bos
Bruno de Oliveira Abinader
Simon Fraser
Chris Lilley
Florian Rivoal
Simon Sapin
ScribeNick: dael
Seoul F2F
---------
glazou: Let's get started
glazou: I have an extra item about Seoul,
glazou: The meeting with Korean government.
glazou: They asked us if we can do three talks about the CSS WG
and the future of CSS tech.
glazou: I'm willing to do the first about how we work.
glazou: I noticed astearns and Dave Kramer said they'd talk if
needed.
glazou: Are they still willing?
astearns: I am.
glazou: Can you message me about what you'd like to talk about?
astearns: Yes.
glazou: That goes for Dave, who isn't here.
glazou: That's all from me. Any other extras?
Rename extent/measure to block-size/inline-size
-----------------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Feb/0822.html
TabAtkins: Just a continuation of the previous discussion?
TabAtkins: Not much came from thread, but we can go with a straw
poll. I'm fine with any of the options.
fantasai: What are the options?
TabAtkins: I think it was length.
<fantasai> block/inline-size, block/inline-extent, block/inline-
length
fantasai: Does anyone want another option? So there's size,
extent, or length (above).
fantasai: I think the concerns about size were mostly being
perceived as 3D.
fantasai: With <length> and "length" it was just we use it
everywhere for all kinds of things
TabAtkins: Yes. We do use size for 1D in several specs. At least I
do.
TabAtkins: That's all I have to say. I'm happy to poll.
fantasai: That's a summary of people's thoughts. Did I miss
anything?
glazou: We can do a straw poll with these three.
<sylvaing_> what's the question?
<fantasai> Straw poll: inline/block- [size|extent|length|abstain]
glazou: Let's do that. Microsoft?
glazou: MaRakow and gregwhitworth?
glazou: Question is block/inline size, length, or extent.
MaRakow: I'm not sure. I want to discuss with rossen.
MaRakow: I'd have to abstain until I hear from rossen
gregwhitworth: I don't have enough info to quantify. I think we're
in Tab's bucket.
<astearns> size > extent > length for me
<fantasai> extent > size > length for me
glazou: Krit?
<krit> Abstain
sylvaing_ : Abstain
<leaverou> Abstain, as I just joined the call
astearns: I like size
zcorpan: Abstain
<SteveZ> extent > size > length for me
glenn: Extent
<BradK> I was in the elevator just now. I prefer length
fantasai: Extent
plinss: Abstain
<plh> Abstain
<rhauck> Abstain
<antonp> *not* length
hober: Slightly prefer extent, but rather abstain.
antonp: Not length
dbaron: Probably size, though not strongly.
TabAtkins: Size
SteveZ: Extent
* sylvaing_ from the depths of Tab's pockets, Microsoft says...
bradk: Length or size
koji: Size
tantek: Abstain
glazou: Myself, size
krit: Abstain
glazou: Did I miss anyone?
[Silence]
glazou: That's tough.
fantasai: It occurs to me that we might at some point have
properties with these names so we should go with easiest
for authors.
fantasai: I prefer extent for vocabulary within specs, easier to
keep things straight, but for property names size is
easier for authors to relate to.
TabAtkins: That makes sense to me
<antonp> +1 to what fantasai said
* dbaron was assuming that it would eventually be exposed to
authors
glazou: So a lot of people are saying extent. Any objections
against extent?
TabAtkins: fantasai switched to size.
glazou: Sorry, size. Any objections against size?
* BradK likes that size is only 4 letters
RESOLVED: Rename to block-size and inline-size
CSS Scoping
-----------
TabAtkins: From the naming conversation. Last week fantasai worked
with me and Demetri.
TabAtkins: We came up with names we're all happy with, right
fantasai?
fantasai: I think they're better. They're a good starting point.
I'm not 100% sold.
fantasai: I think it's better than what was before.
TabAtkins: I didn't want to start and have you hate them.
TabAtkins: In general, we ended up agreeing the pseudo-elements
make sense.
TabAtkins: So shadow combinator is now a pseudo element. Just like
::attr, it doesn't add boxes, just structure.
TabAtkins: So children of shadow-root and treated and children of
the DOM
TabAtkins: The content combinator is now a pseudo element as well.
Same treatment for children.
TabAtkins: We're leaving shadow-deep as is. We don't like it as a
pseudo element and it's just a powerful descendant
combinator. However, now there isn't shadow, we're just
calling it deep.
TabAtkins: We don't love the name.
* krit TabAtkins: How much time do we have to decide about the
name before it is shipping?
fantasai: This combinator that they envision isn't just through
shadow-tree, it's also a regular descendant combinator
which will grab actual and shadow descendants.
fantasai: So it makes sense it shouldn't be pseudo element in this
case.
fantasai: So removing shadow from the name made it clear it worked
for regular tree children.
fantasai: TabAtkins suggested that if we do ASCII we use triple
child.
<fantasai> a >>> b
TabAtkins: The idea is we could do an alias for descendant so you
could do a double >> and for deep it would be a >>>.
TabAtkins: It's an issue in the draft, but otherwise we're okay
with what we have.
<gregwhitworth> I like combinators.
TabAtkins: :ancestor() pseudo, which was identical to host, we
changed to host-context. This makes it tighter and more
clear about the variation.
TabAtkins: Expresses relationship in a more general fashion since
this is for theming purposes.
TabAtkins: So we now have 2 pseudo elements, one combinator, and 2
pseudo-classes
TabAtkins: Hopefully this is more harmonious with the WG's
desires, so we're hoping for approval.
* dbaron wonders if this proposal is written down somewhere
<fantasai> http://dev.w3.org/csswg/css-scoping/#selectors
* astearns dbaron: if you were asking about >> and >>> it's issue
2 in http://dev.w3.org/csswg/css-scoping/
* dbaron was asking about the whole thing
* astearns dbaron the whole thing should be in
http://dev.w3.org/csswg/css-scoping/#shadow-dom
* dbaron yep
* tantek appreciates the progress on this subject
fantasai: I think it's a good starting point and I'd like to talk
about the draft overall and what concerns people have.
fantasai: Pull those concerns into the draft and get consensus to
work and give us something to work off of.
TabAtkins: Um hum.
glazou: Ok.
fantasai: If no one has comments, I'd like to go over what we did
to draft.
fantasai: We took the shadow-style mod that TabAtkins drafted and
expanded the scope.
fantasai: We pulled in regions draft that astearns had removed and
added scope styles that didn't have a defined place.
fantasai: We put it all in the same draft and names it CSS Scoping
(working title)
<fantasai> http://dev.w3.org/csswg/css-scoping/
fantasai: You can scroll to the table of contents to see what's
there.
fantasai: Only thing that's new is we define scoping and added
@scope and we mostly have an issue on @global vs other
ways to handle use-cases.
fantasai: It links to appropriate areas of specs. We'll have to
add font-face as an issue. There's shadow-styling, and
than there's regions pseudo.
fantasai: We want to expand to regions columns, fragments, and
hope that'll be defined in the same sections.
fantasai: So what does the working group think: Are there issues
we should call out in the draft, can we publish
officially in the WG?
astearns: I think it's great you added regions, but in Seattle we
said we'd do page-styling as the first fragment. So I'm
assuming that this section gets worked into page-styling?
fantasai: Yes, we didn't touch the technical text, we did an
introduction. The idea is define page-styling primarily
and we'll get the rest almost for free.
fantasai: For right now, it's just a copy-paste of your stuff.
astearns: Right, okay.
fantasai: Anyone else have anything they want to say?
fantasai: Okay. So I propose we add an issue for handling global
rules like font-face to scoping.
fantasai: I would like to get an opinion from the WG if you like
@scope and if we can add it officially.
TabAtkins: All @scope does is take the mechanism from style-scope
and lets you paint it into a style sheet.
fantasai: I figured it would be good to have syntax so you don't
have to scatter style throughout your document.
<fantasai> @scope #selector { <stylesheet> }
fantasai: It looks like the above.
dbaron: I'm worried this might change the performance tradeoffs we
make when implementing scoped styles because it would
encourage authors to use them at a finer level.
TabAtkins: That is true. The use-case for scoping in style sheet
can be solved largely with nesting. The big difference
is it changed how the cascade works.
TabAtkins: It is useful, but you don't want to apply it all the
time. We can say not in CSS and just focus on the
nesting.
fantasai: I think we can add an issue explaining that this makes
it easier, so would impact optimization..
fantasai: That may or may not be good, but it is something to
think about.
<tantek> Interesting, it looks like scoped styles can potentially
solve some of the SASS / LESS use-cases
<tantek> Can you nest @scope ?
<fantasai> Currently, yes.
<tantek> Whoa cool.
<tantek> @scope .container { @scope .subcomponent { img {
height:1em; } } }
TabAtkins: Does anyone in the WG object to this becoming an ED?
TabAtkins: And/or FPWD?
TabAtkins: Unless fantasai thinks there's something to do.
fantasai: We need to add issues where there's concerns, but I'm
happy to do FPWD.
glazou: TabAtkins you asked two questions, ED or FPWD.
TabAtkins: They're separate.
glazou: FPWD is more formal than ED.
glazou: Any objections to ED?
RESOLVED: ED for CSS Scoping
<tantek> I am for FPWD
krit: Is there a way to add the issues and hold before FPWD?
fantasai: Yes.
krit: I think we can wait a week and it's okay.
glazou: So you want a week to review? Is that okay?
fantasai: Yes.
<tantek> does that mean absent objections, FPWD in one week?
glazou: So let's review in a week.
fantasai: I'm going to add performance and global rules issues.
Are there others that people want called out?
fantasai: Anything we want people to know we're not sure about XYZ?
glazou: Apparently not.
<BradK> Will nesting be in the same draft?
<fantasai> no
<tantek> I think if there is anything else people want called out,
they have a week to email the list about it and get it
noted in the draft.
<tantek> Sound reasonable?
fantasai: Okay. We'll aim to publish next Thursday and put the
issues in the draft. That gives a week.
TabAtkins: Given that we have a call the day before, I'm okay
waiting for the resolution next week
tantek: I think it's good to have a resolution now because people
on the list get a chance to know the ball is rolling.
glazou: I can be 5 min at the next telecon.
glazou: Everyone has an action to review and we decide.
Asynchronous Decision Making
----------------------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0260.html
glazou: This is about using e-mails for establishing consensus.
glazou: Everyone agrees about it I think. Is plh on the call?
glazou: My question is should we, is it better to have it in the
charter? The decision policy of current charter says
nothing about this and other groups using async have
something in their charter.
glazou: It doesn't stop us, it's just cleaner.
glazou: Other than that, I agree that if you want e-mail based
decision, plinss or I will send it. It's better done by co-
chairs.
<tantek> +1
glazou: plinss, what do you think?
plinss: I agree.
glazou: There's only one thing to remind people, we don't live in
same time zone and have different schedules. One day isn't
enough; we need to leave a reasonable time,
glazou: So we can figure out general opinion of those reading.
TabAtkins: I think plinss had done 2 days. I think that 48 hours
is fine.
glazou: If it's for something settled, agreed generally with
people in the mailing list, 2 days is okay.
tantek: I'm going to suggest a week because a lot of us travel to
meetings and sometimes 48 isn't enough.
tantek: If it's urgent 48 is okay, but else wise a week.
<astearns> +1 to week default, but can be decreased to a minimum
of 48 hours
* sylvaing_ agrees it's hard to think of a decision that required
less than a week
* zcorpan would prefer a week also
fantasai: I agree. There's times I won't check e-mail for a few
days. For simple administrative decisions 48 is okay to
prove consensus since we don't expect objections.
fantasai: If it's technical a week is good
<tantek> thank you glazou
* plh notes that webapps has or thinking to have 10 days
glazou: It's okay. It'll be a week by default. plinss or I could
use the twitter account to make people aware.
fantasai: I think you can CC the internal ML list too.
glazou: As tantek said, we travel a lot and twitter is easy on a
mobile device when e-mail is hard.
fantasai: I think you should still CC in internal list.
* TabAtkins sylvain, we've had things where we didn't get to the
"publish as ??" agenda item in the call, and did a
quick 2-day CfC on the list for it.
* sylvaing_ Tab, we're talking about a default. as fantasai said,
admin things can use a shorter deadline.
glazou: So everyone agrees more calls for consensus on the mailing
list, sent by the chairs, default it one week.
krit: If you use twitter, you should also announce to both lists.
glazou: Absolutely.
<tantek> Agreed, CfC should be on www-style
krit: Okay
glazou: SimonSapin does this address all your concerns/questions?
glazou: I'm not sure he's here.
Ruby Anonymous
--------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0392.html
glazou: Can you summarize?
tkw: Summarize my proposal?
tkw: The email I sent you, I'd like to change the section of CSS
Ruby 2.2 to be similar to HTML 5.
tkw: As you know the HTML5 is only for Ruby and frames. CSS Ruby
isn't an interpretation of HTML Ruby so creating an anonymous
box is HTML but not CSS
tkw: So HTML and CSS should be consistent, but it's not. It'd like
to propose changing to CSS Ruby work with HTML5.
fantasai: I looked at your message and agree with goals. I haven't
looked at exact steps, but I agree we should fix is.
tkw: This is technical, but in HTML5 Ruby base text should be
interpreted as Ruby, but anonymous box in CSS Ruby does not.
[tkw was accidentally disconnected from the call]
fantasai: We're just missing text to deal with anonymous content
which is an oversight on my part.
* dbaron thinks this needs some time for not-in-teleconference
review of the proposal
glazou: I agree with dbaron we need offline review. We put this on
agenda so everyone was aware.
fantasai: I think this is an action on me.
glazou: fantasai can you summarize?
fantasai: We agree this should be fixed, there's an oversight in
the spec. I think I need an action to fix this.
tkw: I think so. I want to help fix it with fantasai.
fantasai: I'll look at your text and check it's correct.
fantasai: I'll pull it.
tkw: Thank you.
glazou: Thank you.
action fantasai look at the proposal for CSS Ruby
* trackbot is creating a new ACTION.
<trackbot> Created ACTION-622 - Look at the proposal for css ruby [
on Elika Etemad - due 2014-04-02].
Transitions
-----------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0530.html
glazou: First issue was from dbaron.
dbaron: A few months ago we agreed on this new model that we
thought would work to explain how transitions start.
dbaron: I know some people from Google implemented it in chrome
and found it seems to work.
dbaron: That said there's an open issue that I don't know how to
explain and I'd like some feedback on how to.
TabAtkins: I talked with Shane yesterday, ultimately we think
we're pessimistic about being about to implement
transitions and animations as a hack over cascade.
TabAtkins: We're not sure what it should look like, but we don't
think pure cascade would work.
TabAtkins: We'd need something like "and than do magic."
TabAtkins: Shane is willing to figure out what needs to be done,
not what we're currently doing. There will be edge
cases better addressed by animations anyway.
TabAtkins: Shane would like to help figure out transitions and
animations and how they interact. We don't think it'll
be a normal cascade,
TabAtkins: But we'll help.
<fantasai> Can we get an example of what doesn't work without
magic?
dbaron: I don't think this is related to cascades.
TabAtkins: Because you're trying to figure out how to trigger, it
still requires running cascade twice or doing
dependability tracking, but that might be a related
issues, not this one.
dbaron: It would have been nice to have that sooner.
TabAtkins: I know. Sorry. Shane did want to help write and figure
out what needs to be done, so I'll get him in contact
with you so we can figure out what is reasonable.
dbaron: Okay.
glazou: Anything else on this subject?
dbaron: Nope.
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Dec/0317.html
glazou: Next issue was from krit
* glazou very hard to hear krit...
* glazou thinks krit is too far away from microphone
krit: From mailing list was a reservation about the transform. So
the computed style..
TabAtkins: He's proposing we define the serialization to always
use matrix() or matrix3d()
dbaron: We can't do that for spec.
TabAtkins: Computed only.
dbaron: Or the resolved value.
dbaron: That the resolved is matrix() or matrix3d()?
TabAtkins: Right now there's no difference between computed and
used.
TabAtkin: Do you think it's valuable to say it's the used value?
krit: Will there be a difference in the future?
dbaron: I think it's computed vs. resolved.
TabAtkins: Resolved is either computed or used depending on
property.
dbaron: Ah. We may want to add better APIs in the future and not
want this to apply.
TabAtkins: Wouldn't with just serialization. Then it wouldn't
necessarily apply.
dbaron: Yes, but even including serialization.
krit: That's what I started on the mailing list. There's
implementations that depend on the matrix already.
TabAtkins: Given that everyone serializes the same way, we should
spec it and work around it later if needed.
glazou: I think it would ease the pain in the case of matrix based
computed value is we, officially as a WG we...we have an
algorithm, but no code.
glazou: If we do this it'll help web dev relying on matrix.
<leaverou> This (matrix decomposition) could be a part of the new
CSSOM somehow as well.
krit: Two different issues. First, there's multiple algorithms.
The one in the spec has requirement to change.
krit: Even if we have one for CSS, there's still different use
cases for decomposing.
krit: API isn't great, but exposing the matrix into JS is better
which we could do in the future
glazou: Only 6 components?
krit: 6 or 16.
glazou: It doesn't seem like enough. I understand the multiple
decompositions, but it's giving them one algorithm.
glazou: Matrix will be complex.
TabAtkins: There will be a default in DOMmatrix. It's not defined.
krit: I'm not sure if we should. Decomposing algorithm isn't ideal.
There are different proposals that are new, but if we have
API like DOMmatrix, you can create JS library to do it for
you.
glazou: Okay, that solves my issues.
glazou: Do we need a resolution?
krit: Yes. On serialization.
glazou: Any objections? dbaron?
dbaron: So serialization of the computed value is where the
mechanism that achieves that result changes to matrix?
dbaron: I'm okay, but we may need to change it in the future.
glazou: Other comments?
glazou: Objections?
RESOLVED: Move to matrix for the serialization of the computed
value for Transitions
glazou: It's the top of the hour, the remaining items will move to
next call.
glazou: Thanks and talk to you next week.
Received on Thursday, 27 March 2014 00:47:59 UTC