- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Feb 2014 20:37:29 -0500
- To: www-style@w3.org
CSS2.1 ED
----------
- SimonSapin requested that CSS 2.1 be posted on a publicly
available site. Though most of the group agreed with him that
it should be public, there was much discussion on how to
handle importing the log previously private comments.
- RESOLVED: plh will handle the log over the
next two weeks. If no objections to it becoming public,
SimonSapin will move CVS to mercurial.
MQ3 errata
----------
- ChrisL will publish the errata document.
Font Loading LC
--------------
- TabAtkins requested that Font Loading be brought to LC. The
group requested another week in order for TabAtkins to
finalize some edits and for everyone to have a chance to
review the document further.
CSS Masking
-----------
- krit reminded everyone to review CSS Masking and give comments
before it goes back to LC.
ShadowDOM
---------
- TabAtkins reported that he had reviewed the implications of
switching from combinators to pseudo elements that Fantasai
suggested. Mostly he found no issue, but was concerned about
shadow-deep.
- TabAtkins and Fantasai will meet in person later this week and
report their conversation back to the mailing list.
Counter Styles
--------------
- RESOLVED: Accept TabAtkins's proposal and reject the comment
from Xidorn in the disposition of comments.
=====FULL MINUTES BELOW======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Koji Ishii
Dael Jackson
Brian Kardell
Philippe Le Hégaret
Peter Linss
Edward O'Connor
Anton Prowse
Matt Rakow
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Bruno de Oliveira Abinader
Leif Arne Storset
ScribeNick: dael
glazou: Let's start
glazou: Any extra items?
glazou: I noted one from Tab about shadow vs ::shadow.
glazou: We have a light agenda so may have time for more.
CSS 2.1 ED
----------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0139.html
<SimonSapin> http://www.w3.org/Style/css2-updates/css2/
SimonSapin: So when working on implementations for CSS2,
SimonSapin: I would like it to be up to date including the errata
items.
SimonSapin: It seems we have a ED but I'm not sure if it's really
up to date.
SimonSapin: If it's not, can we make it so?
plh: Bert?
SimonSapin: Is this a snapshot or up to date?
bert: This is a snapshot. The real version is at
https://www.w3.org/Style/Group/css2-src/
bert: That's the ED and has been for 50 years or so
<SimonSapin> http://www.w3.org/Style/CSS/current-work
SimonSapin: So that URL...I think it would be beneficial for a
public WD just like other docs.
SimonSapin: Listed on current work.
bert: I don't think it's useful to have it be public.
ChrisL: We're charted as a public group so we should have
everything public. Please move it.
glazou: CSS errata is part of charter.
bert: I don't like moving doc because we'd lose 15 years of
comment history. If we do, I don't want to move to mercurial
because it's a pain.
<sgalineau> We shouldn't keep documents non-public because of
personal dislikes of the version control system.
<ChrisL> Do we really have to argue about the desire to have a
member-only draft for this thing?
SimonSapin: It's possible to import the history. We don't have to
lose it.
plh: Why don't you move it to Github instead of mercurial?
bert: I don't know if that's easier.
plh: The community around it is much larger. The mercurial doesn't
have as many cycles.
plinss: Our mercurial is mirrored.
plh: Ok. that could work.
fantasai: I think all our drafts should be in same repository so
it makes easier for editors to help each other with
their drafts...I don't think we should have just this
one in github.
bert: I think github is easier, but I don't want to move
everything there.
florian: I prefer git as well, but also think having everything in
one place is more important
florian: To put CSS 2.1 on mercurial we have to import the history.
florian: So the proposal is to import into mercurial, even though
we don't love mercurial. And maybe we should later
consider moving elsewhere.
<SimonSapin> If it helps, I can do the work of importing the
change history from the CSV repository (given access).
glazou: So Bert is it okay with you if SimonSapin helps you?
glazou: It seems like it's consensus from the WG.
bert: If someone can make a repository on mercurial, I don't know
how to do that.
bert: I only get errors when I use that one, I have a different
one for this draft.
???: I have no idea how that happens.
glazou: I never get an error.
glazou: Wait...switching isn't the discussion. The question is
moving the CSS2.1 document to or from repo.
florian: I was agreeing. Mercurial might not be everybody's
favorite, but it's what we've got.
glazou: Bert, I'm sorry, but it's mercurial and SimonSapin will
help.
glazou: So it's an action on SimonSapin to help with hints from
bert?
bert: I don't like losing history...the link will be gone.
bert: It's member only so we can't put the history in the public.
We're not going to look through 15 years of history for
confidential stuff.
<SimonSapin> The plan is to import *only* CSS2.
<SimonSapin> Not anything else that might be in the same repo.
<SimonSapin> It's also possible to truncate the import at some date
glazou: ChrisL is there problem making things in the CVS go public?
ChrisL: Technically yes, but in practice the comment history...the
only point that might be unknown is anything since CSS 2.1
was published.
ChrisL: So in practice I don't see anything member only. It will
be why changes were made. I can't think of anything that
might be hard.
ChrisL: Bert thinks there might. We either copy with our without
comments. Either way it's public so people can look.
plh: We don't know what's in that history. Some companies might
have something in the repository they don't want public. I
know what developer comments can be like.
plh: Maybe allow people to look that are on members only. Let them
say if they have concerns. If we don't hear anything we
publish.
plh: That would help.
<krit_> 2 weeks for reviewing a 50 years history?
<ChrisL> Sounds like a good plan.
glazou: It's unfortunate to wait, but it's a good compromise. I
don't want ACs to fall because this decision.
plh: In two weeks people can speak up.
glazou: I hope it can be 1 week.
Rossen: Are you expecting something?
glazou: In theory everyone should look for controversial or
problematic that needs to hide. If everyone doesn't have a
problem that's fine, but we have former members.
glazou: I know it sounds stupid, but because the way we used to
work we need to do this.
glazou: If we want the whole history.
<tantek> Is there an open format for change histories / commit
logs? a little export/import action?
* sgalineau tantek, that just seems contrived
florian: I'd suggest 2 weeks. It's lots of history.
glazou: I'd like to close this. Is everyone okay with plh's idea.
[general agreement]
glazou: Bert, can you download the comments and send it to the
private mailing list for everyone to review?
bert: You want me to download all the comments?
glazou: In a CVS.
plh: I'm willing to take an action item to do it.
glazou: You may want to deal with the former members.
plh: Let's do it properly.
glazou: Let's do it in two weeks. If we don't hear anything in two
weeks, we bring all the comments over.
SimonSapin: As I understand, the form for CSS 2.1...all the
previous iterations are a part of it. I don't know
what we want to move here.
bert: The build is profiles written by Arnold and ??? and me. I
don't know what's in the history of those.
SimonSapin: Do we need to understand how it works, or just copy
over as is?
<fantasai> Simon was saying that the build system for CSS2.1 is a
different system than the ones we use for the CSS3
drafts, and he's not sure what's involved for moving it.
glazou: In short, is the source format compatible with the new
system?
bert: No. The way we did it back then was complex. Same things we
do now, different ways.
bert: It's in the same directories, everything is there.
glazou: We have two weeks. SimonSapin will you take that time to
look in the CVS directory and see what you can do?
SimonSapin: Ok.
glazou: So, proposed resolution. plh will handle the log over the
next two weeks. If no objections to it becoming public,
SimonSapin will move CVS to mercurial. Ok?
RESOLVED: plh will handle the log over the
next two weeks. If no objections to it becoming public,
SimonSapin will move CVS to mercurial.
glazou: One more thing. There's discussion on charter milestones.
Charles proposed a change that wasn't in line with WG
opinion.
glazou: I rejected it because I didn't think it was right. I'll
ask you to write something to replace his prose.
??: Do you have a link?
glazou: I'll see. It may be private.
MQ3 errata
----------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Feb/0517.html
florian: We've discussed and resolved to make these changes, but
no one has done it.
florian: Can we action someone to make the changes? There's not
much to discuss.
<ChrisL> maybe editor of MQ4 can do it?
florian: I'm the editor in MQ4, but I don't have access to MQ3
errata.
bert: I think ChrisL has made some changes, I may have too.
ChrisL: If it's just publishing, tell me where and I'll make sure
it gets done.
florian: That should be the link that was pasted above in IRC.
florian: I can clarify any questions.
glazou: Is that okay?
ChrisL: Yes. I see the link from glazou? That one?
glazou: Yes.
florian: And if anything isn't clear, just tell me
Font Loading LC
---------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0162.html
TabAtkins: You'll remember from Paris it was nearly done. It got
feedback from jdaggett.
TabAtkins: I forgot to publish the FPWD until last week. Still I
think it's mature and has been reviewed.
TabAtkins: I think it's stable and ready, let's go to LC, gather
remaining feedback and do the edits.
<sgalineau> which other implementors have reviewed it?
* fantasai wants sgalineau's question answered
ChrisL: So this is a fairly brief period, but this was previously
in CSS3 fonts, right?
TabAtkins: I don't recall.
dbaron: It was, yes, although it was brief.
TabAtkins: That was the old form, but yes.
ChrisL: If you think it's stable, put it forward, and people
disagree they'll let you know.
TabAtkins: We do LC when we're done with design and we're done
with design for this.
glazou: On the website there's two issues in the doc. Shouldn't
they resolved before last call?
ChrisL: Yes.
TabAtkins: I can go resolve the issues today.
glazou: One is technical so we need time to review the fix.
TabAtkins: Let me pull them up quick.
florian: Is it something we can discuss without prep?
TabAtkins: 2 issues. One is what the font-face does for works.
It's basically done and just needs text
TabAtkins: Second issue is about local fonts. I think it's easy
and can be resolved. I just need to ignore them. The
issue is do we need a special feature and I think we
don't and we just drop it.
fantasai: Has John Daggett done a really complete review like typo
style?
TabAtkins: Yes.
fantasai: Did other people? Did they find anything?
TabAtkins: Yes.
Rossen: We looked at it but not that much depth.
Rossen: I'm passing it on for more.
glazou: So do you need more time?
Rossen_: Let's get a week.
glazou: Let's defer for a week so there's a bit more review and
TabAtkins can make his edits.
CSS Masking
-----------
krit_: There was a new WD pub two weeks ago. That was for more
feedback.
krit_: I'd like to remind people to look before we go to LC so we
find as many issues as possible.
krit_: fantasai had some issues from the first LC and I think I
resolved them, but it would be great if she could look at
it again.
fantasai: Thanks for the reminder.
ShadowDOM
---------
TabAtkins: I've been talking over fantasai suggestion from last
week about switching to pseudo elements.
TabAtkins: Mostly I'm okay. For shadow and content it works.
TabAtkins: Only one issue is with shadow-deep because it doesn't
correspond to anything real.
TabAtkins: fantasai explained it as switching to a virtual tree,
but that is weird.
TabAtkins: It wouldn't match anything is CSS. Potentially queries
could return the shadow roots.
TabAtkins: We're uncomfortable with making that as pseudo. We want
that as a combinator.
TabAtkins: Then it seems odd for them to be sometimes pseudo,
sometimes combinators.
fantasai: I'm not convinced shadow-deep needs to be a combinator
because there could be something in the DOM. It's a
thing you can talk about and define as existing.
fantasai: That our DOM isn't structured shouldn't change the CSS
syntax.
TabAtkins: But we'll never have a DOM thing for that.
fantasai: But it exists as a concept. So our syntax shouldn't be
restricted. We should chose from conceptual consistency.
bkardell: The shadow root looks okay, but shadow-deep root doesn't
make sense as a thing to talk about instead of nesting
roots.
TabAtkins: We talk about the composed tree, not something rooted
at a post. So shadow-deep doesn't exist.
fantasai: What you're doing is a sub tree of the tree.
bkardell: It's a tree, though, real or conceptual.
fantasai: If you're talking about foo, it's great grandmother's
niece may have a shadow, but you wouldn't reach it.
TabAtkins: My problem is this may let us define everything as a
pseudo instead of combinator.
fantasai: I don't think so.
TabAtkins: The reference combinator could be seen as something
hanging off in an alternate tree.
fantasai: No. There's a connection, but no one is making a
different tree for the child.
fantasai: There's no child/parent there. It's just a link.
TabAtkins: But that's all parent/child is. It's just a link.
fantasai: That's too abstract.
TabAtkins: I think your example is too.
bkardell: Pseudo is supposed to select the whole tree. A pseudo
element, not the whole tree
bkardell: So, we can define it as the root instead of the whole
tree. I think the concept is a bit off.
TabAtkins: You can map it to whatever element is hanging off.
TabAtkins: The tree isn't exposed. It won't be in any way.
fantasai: Neither is ::first-line.
TabAtkins: We plan to expose it more.
bkardell: Is there any reason you'd need to piece some? Or do you
intend to piece everything?
TabAtkins: If you only want to grab a foo-button that's a
descendant of some thing.
TabAtkins: I think we should be more judicious to what we expose
as pseudo elements to things that could be returned as
javascript.
TabAtkins: That seems to be a reasonable rule.
TabAtkins: Attributes have that. Some representation of the DoM.
Shadow, roots, work that way.
TabAtkins: I don't think an element in the tree can be exposed
usefully.
TabAtkins: I don't think it's an ultimate node in a tree. And
that's a pseudo element.
TabAtkins: So...what do we do now? Fantasai and I have a knife
fight and the winner is right?
TabAtkins: Before we have a knife fight, any other opinions?
Rossen: Are you planning on getting together for this?
fantasai: Yes.
rossen: I think we'd be interested in being there too.
florian: think the conceptual is a bit off.
fantasai: I'm worried that things like regions would be off from
shadow DOM for esoteric reasons we discuss here.
TabAtkins: Well and who knows what pages will use.
florian: I'd rather have actual consistency than theoretical
explanations about what should be pseudo elements.
glazou: Will you report to mailing list about the results of the
meeting?
TabAtkins: Yeah.
TabAtkins: Was that the last thing?
glazou: Yes.
Counter Styles
--------------
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Feb/0523.html
TabAtkins: I have a question. There's been a lot action on counter
styles in the mailing list.
TabAtkins: Xidorn gave a lot of feedback and on one topic we've
been unable to agree and I'm going to have to reject it
in DoC. Do we need a resolution for that?
fantasai: Yes. Anything resulting in a significant change or
significant rejection should be discussed.
TabAtkins: Ok.
TabAtkins: The Counter Styles draft has a number of ways for one
thing to refer to another. That means there's a
possibility of loops.
TabAtkins: The 3 places you can loop is counter style fallback,
the speak-as value, and in the override.
TabAtkins: The override is the one under question.
TabAtkins: Having a cycle isn't an error. It's useful to have
counter styles that fall to each other for different
values.
TabAtkins: Speak-as doesn't do that. If there's an error it
defaults.
TabAtkins: There aren't any use cases for a cycle to be useful and
I think it should create an error.
TabAtkins: Xidorn has said that there should be cycles and they
could be needed. Only if a given descriptor goes into a
loop should we create a default.
TabAtkins: The only time that's useful is when creating a
compression. It seems like a silly trick and not a
reasonable use case.
TabAtkins: Xidorn's main argument against my position is that it
requires cycle checking which is an abstract issue, but
we already require it for fallback loops.
TabAtkins: So it doesn't seem an undo amount of work.
glazou: I guess you've explained this well. So, TabAtkins
recommends to reject comments. I agree with him. Other
thoughts?
* fantasai defers to dbaron on this one?
<dbaron> I'm here; I don't really have an opinion since I don't
have a good sense of what override is used for.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2014Feb/0729.html
florian: It's without a use case so we should pick the simpler
to implement.
TabAtkins: I think they're both equally complex. It's a matter of
if you look at scriptor at use time or later. I think
they're equivalent.
florian: In that case, why do you prefer yours?
TabAtkins: Generally we treat things known to be errors as
something to kill instead of something to repair.
glazou: dbaron you there? fantasai wanted your feedback
dbaron: I don't have a good sense of what override is used for so
no opinion.
TabAtkins: It's for when a counter style is almost right and you
just want to tweek a little.
dbaron: Are you requiring cycle detection in one descriptor, or
multiple?
TabAtkins: Currently required in speak-as. The override is within
themselves. If there's a cycle detected we switch to
override decimal.
dbaron: What if you want to know what it's spoken as. Say, b
overrides a and a has a speak-as to b?
TabAtkins: So B has a speak-as to a and a is overriding b?
That should be fine. There's no odd cycle there. The
missing descriptor takes on the default and it'll speak-
as.
dbaron: a overrides b
TabAtkins: Oh. So A will say I'm missing the speak-as. It'll grab
from B. So A will have speak-as A as well.
TabAtkins: So you look at speak-as A as auto. So B looks at it and
says I'm auto as well.
dbaron: Okay.
TabAtkins: I made sure the things that refer to each other are at
different levels so you can process in order and have
it work.
<fantasai> Maybe override isn't a very good name? It's not
actually overriding the named style, just creating a
new one based off it as far as I can tell.......
glazou: After that, what do people think? Should we reject the
comment?
plinss: To clarify, what you're proposing to reject is the
override?
TabAtkins: Yes. His proposal is to let cycles happen. If a loop
happens, default that one descriptor, but let the rest
take the value from there.
plinss: Your position makes sense.
plinss: The proposal makes more sense, but I'd like to be
consistent. If the author defines it and it works 99% of
the time, the 1% seems a surprise.
TabAtkins: If the counter styles create a problem, we take care of
that. The other is if descriptors create a look you get
odd results.
dbaron: I think plinss is talking about fallback.
TabAtkins: There's no problem with fallback cycles. It renders as
decimals if you literally cannot render in another form.
TabAtkins: I think it's reasonable to recover there so you don't
negate the entire thing.
plinss: I'd rather things only fail when they need to and have
everything be consistent.
plinss: But I don't want to complicate everything.
Florian: The proposals don't change when, but how.
Florian: The loop will be detected in both. Do we invalidate
everything in the loop, or only some?
Florian: Either way we detect the loop.
TabAtkins: That's correct.
florian: Do we keep the thing that could be resolved despite the
loop?
TabAtkins: I recommend that because it's going to be an error,
kill the overrides entirely.
<florian> +1
Rossen_: I support TabAtkins that sounds most sane.
glazou: Me too.
glazou: We have 1 minute left.
glazou: A resolution would be useful. Can we live with TabAtkins
proposal?
fantasai: Works for me.
<ChrisL> Works for me too
florian: Ok.
dbaron: I'm okay either way
fantasai: TabAtkins said failing early makes the mistake more
obvious which is another benefit
* SimonSapin fail early, fail often.
glazou: So, the proposal: Accept TabAtkins's proposal and reject
the comment.
RESOLVED: Accept TabAtkins's proposal and reject the comment from
Xidorn in the disposition of comments.
glazou: I think that's it. Thank you everyone.
Received on Thursday, 27 February 2014 01:37:56 UTC