- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 1 Jun 2016 19:34:58 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Consider accepting string as animation name
-------------------------------------------
- RESOLVED: Accept strings as animation-names
Scoped attribute on style element removed from HTML
---------------------------------------------------
- RESOLVED: Move fragment styling and @scope to a delta level 4 of
scoping module.
Logical equivalents for vw/vh units
-----------------------------------
- RESOLVED: Add vi and vb to values & units 4.
Naming logical values for the float and clear properties
--------------------------------------------------------
- Florian and TabAtkins were actioned with reviewing the naming
proposals for discussion on next week's call.
Improving use of github issues
------------------------------
- Issues won't be closed until a decision is reach or the working
group resolves on them.
- TabAtkins will add pre-pending the spec name as a part of the
issues template.
- TabAtkins will propose an etiquette of contributing guide to
include in the issues template on the mailing list for approval.
- RESOLVED: Add the labels listed here:
https://github.com/sandhawke/spec-labels-min/labels?sort=name-asc
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jun/0000.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Elika Etemad
Daniel Glazman
Tony Graham
Dael Jackson
Ian Kilpatrick
Edward O'Connor
Anton Prowse
François Remy
Florian Rivoal
Alan Stearns
Ian Vollick
Greg Whitworth
Regrets:
Alex Critchfield
Chris Lilley
Myles Maxfield
Jen Simmons
Steve Zilles
Scribe: dael
Consider accepting string as animation name
-------------------------------------------
astearns: Do we have a TabAtkins or a fantasai?
astearns: It is 5 after. Given that TabAtkins replied to the
agenda as to why they were tagged with agenda+ in
github, I'm assuming all these were bits TabAtkins wanted.
<astearns> https://github.com/w3c/csswg-drafts/issues/118
astearns: Is there anyone on the call with an opinion?
??: It's probably fine
Florian: Why do we want it? I missed a bit of context.
astearns: I'm reading from the issue. "I guess it's not a bad
idea, we've seen it in the wild. It's supported for
prefixed in blink but not unprefixed"
Florian: In general we try and stick with identifiers as strings
when they come from outside CSS. So in general we
shouldn't have strings, but if there's backwards
dependency...
glazou: I agree with Florian. Here we're naming an object in CSS
and we don't allow strings there.
TabAtkins: I'm here and can give reasoning. The big nice thing
about doing strings here is the animation shorthand was
defined badly and animation names are ambiguous with
other keywords. When we add a new keyword existing
working animations may fail to parse correctly. Strings
make that unambiguous. It goes against our general
principles, but custom-ident lives in an in-between
world.
TabAtkins: String, while slightly weird, does give authors a more
stable interface.
astearns: The problem of introducing keywords that break existing
sites is only accommodated if existing sites are using
strings.
TabAtkins: The hope is we can evangelize using strings and it
would reduce the sites we could break. It's thresholds,
not 0 vs not-0.
Florian: It's a bit ugly, but there's a reason. Okay, maybe.
TabAtkins: I wouldn't do this for any future custom idents. We can
do it correctly in the future.
glazou: As an editor it's weird in 2 ways. It's inconsistent with
other idents. I'm also scared by having leading or
trailing spaces. That will catch up editors, especially
with a complex UI.
TabAtkins: You have have leading spaces in custom idents.
glazou: I'm not saying it's a problem to have it, it's a problem
to work with them. When you see a whitespace and want to
copy you may make a mistake.
TabAtkins: That's true of all..
<fantasai> Do we really expect this to be a problem? It's not
perfect, and maybe we could've done something
differently in the past, but is it worth changing the
syntax here?
glazou: [missed some due to bad connection] Strings are so much
more than idents it's opening Pandora's box.
TabAtkins: But we have several strings and that's never been
brought up as a reason to avoid strings.
Florian: I can see the UI challenge.
* fantasai wonders what dbaron thinks
<dbaron> I'm in favor of allowing strings here.
<glazou> am I correct we have that proposal because a version of
chrome introduced strings there ?
<TabAtkins> no. this is a "feature" of the original webkit
implementation (pre-fork, so Chrome inherited it as
well)
<glazou> ok thanks
<glazou> TabAtkins do you have stats about usage of strings as
animation name?
<TabAtkins> no stats, no
Florian: I'm somewhere halfway between TabAtkins and glazou. I see
the UI challenge, but as TabAtkins is saying, what's new.
We have strings as identifier when it comes from
somewhere else.
Florian: Yes, this is annoying, but we have this problem.
TabAtkins: We have an ident string ambiguity in font family names.
You can have either one there and whatever you present
in the editor you can have.
Florian: For glazou's other question about Chrome doing something
silly, that's part of the reason. The bigger part is we
designed the grammar poorly and strings makes it
unambiguous.
<Bert> q+ to ask if @keyframe foo === @keyframe "foo"
<TabAtkins> Bert: Yes.
astearns: It sounds like 3 engines are in favor of allowing
strings. Opinions from Edge?
<glazou> I don't like it but no objection
fremy: It's a good chance I'm in favor.
astearns: I think that's a fair consensus to do it. Does anyone
actually object to allowing strings?
Rossen: I was talking on mute.
Rossen: I have to re-evaluate before we have a final answer, but I
don't see a reason to block. I don't have as strong as an
opinion as glazou. I'm not sure if he's there.
astearns: He's been typing in IRC because sound problems.
astearns: Bert is the IRC answer sufficient?
Bert: I think it's correctly answered and that's the answer I
hoped for.
astearns: Objections to making this change?
fantasai: If we were starting from scratch I'd be against this
change, but since we have implementations I don't mind.
TabAtkins: Starting from scratch we would have required animation
name to come first in the animation shorthand, avoiding
the problem.
RESOLVED: Accept strings as animation-names
Scoped attribute on style element removed from HTML
---------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/137
TabAtkins: The scope attribute on the style element was removed
from HTML because only one browser implemented and no
one else had interest.
TabAtkins: Parallel to that, fantasai and I wrote @scope rule.
Since the feature is low value for HTML I propose we
drop from scoping spec as well.
tantek: I thought the problem was back compat.
TabAtkins: I don't recall that, but I don't have a good memory of
the past.
<dbaron> I don't understand what the compat problem is.
tantek: I have an e-mail from you saying that. I think that means
that that's why it didn't take off in other browsers.
@scope is brand new and doesn't have a compat problem so I
would give @scope more of a chance.
TabAtkins: Can you link me that?
tantek: Is there a reason to drop @scope from scoping at this
point?
TabAtkins: It should be advancing soon because it has the current
definition of shadowDOM. So I'll be pushing it soon.
@scope was because HTML dropped it.
fantasai: What tantek says is fair and @scope is easier to use and
use frequently. So the usage pattern would be different.
For now with no browser interest it's worth pushing to
the next level. It may be worth revisiting in the
future, either @scope or something to offer more control
over the cascade.
fantasai: Scoping to elements and using the nesting or doing
scoping of the rule would be useful for authors. So
these are my more general rules and these are my
specific rules so it would cascade at the scope level.
Those things I'd like to pursue, but the current level
should just be the shadowDOM.
fantasai: I wouldn't drop it completely, it's worth looking into.
tantek: Would you be willing to mark it as at-risk so you could
drop at CR with no problems?
TabAtkins: It would be acceptable, but I'd rather punt to lvl 4.
fantasai: tantek's point is reasonable.
fantasai: I think it's fine either way.
tantek: It's a syntax issue?
fantasai: The part in the module is mostly syntax, yes. How scopes
are calculated in the cascade is in cascading.
tantek: I don't feel strongly. This is a gentle request to leave
it in. I think it is useful and there are use cases. I can
point to a few examples of bloggers doing it on their
sites. I've seen it on custom post settings. So it's page
level for the post perma-link, but shows up on their home
page where they scope it to just that post.
tantek: It's non-0, though maybe too small.
TabAtkins: I agree. I made this from lack of impl interest on a
parallel feature.
tantek: I could file it on Mozilla to check interest.
TabAtkins: So proposal: I punt fragment styling and @scope to a
delta level 4 of scoping module.
astearns: So it would indicate interest but not we're waiting on
impl interest. And what's left has been impl and could
advance.
TabAtkins: Yeah.
astearns: Objections?
<tantek> Thanks for consideration TabAtkins
RESOLVED: Punt fragment styling and @scope to a delta level 4 of
scoping module.
Logical equivalents for vw/vh units
-----------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/113
TabAtkins: I think Xidorn brought up there are use cases for using
viewport units in a logical axis way.
TabAtkins: He proposed vi and vb for the units.
TabAtkins: It sounds reasonable, but I leave it to the group.
fantasai: I'm in favor.
astearns: Anyone interested in implementing? Does Xidorn want to
work on it?
TabAtkins: I suppose?
fantasai: This is V&U 4 which we haven't even finished drafting.
Florian: If the use case sticks remains to be seen, but it makes
sense.
astearns: Anyone opposed to adding this idea to a future draft?
* fantasai hasn't forked V&U 4 yet, is waiting for the calc()
serialization section to get properly reviewed before
republishing and then forking
RESOLVED: Add vi and vb to values & units 4
Naming logical Values for the float and clear properties
--------------------------------------------------------
dbaron: Speaking of logical keywords, it would be useful to get
agreement on the keywords for float and clear. If it's
inline-start and inline-end or...?
Rossen: Our impl treats them as logical and the vertical. So
orthogonal flows you don't have the problem of floats
penetrating.
Florian: Tricky part was extension of page floats. We should
resolve on this and there's a lot of context I need to
load into my brain.
Rossen: I think what you're saying is mostly to positioned items.
It's mostly boundaries which is the page floats example.
Rossen: If you have floats scoped to BFC you don't have a problem
with float-left or -right being ambiguous across different
writing modes.
Florian: The problem is if float-start and -end should be renamed
to inline-start and -end to remove ambiguity.
dbaron: That's the issue.
dbaron: That is noted as an issue in the spec. We'd like to ship
and given there's an issue in the spec with the name
there's a problem.
<dbaron> the issue in the spec is at
https://drafts.csswg.org/css-logical-props/#float-clear
ACTION Florian look into naming of float-start and -end for next
call
<trackbot> Created ACTION-777
ACTION TabAtkins look into naming of float-start and -end for next
call
<trackbot> Created ACTION-778
TabAtkins: So revisit this next week for a definite answer.
Florian: I think so.
astearns: I didn't ask for additional items at beginning of the
call. We have time if you have additional items
Improving use of github issues
------------------------------
astearns: The items I put on the agenda this week were tagged as
such on github. That was really helpful. It would be
more helpful if you tag it and add the reason/what you
want to talk about on the call. Any other suggestions on
better use of github issues?
TabAtkins: I'm going to look into some issue management so we can
do some better organization. The issues list straight
up looking at it isn't a ton better than the ML. It's
not easy to get into. I'm going to see if I can get
something together to let people focus on individual
specs more easily.
fantasai: There's was a discussion about closing issues and I feel
strongly that we shouldn't close until the edits are done.
Florian: Right. Or we resolve to close it. But if it's not resolve
or not in the spec it shouldn't be closed.
<tantek> +1 to keeping issues open until resolution done (edits
done ok too)
astearns: And fantasai you mentioned it's still useful to have the
spec pre-pended to the issues. Since we have a giant
repo it's useful to see the tag or have it in the name.
So I do prefer that.
fantasai: And I need tags to filter my e-mail.
fantasai: That way people who file issues without permissions can
tag.
<dbaron> Ideally we could auto-tag issues based on the spec URLs
cited in the issue, and auto-complain in issues that
don't have a URL pointing to the spec :-)
TabAtkins: a) I did fix our spec snippit so it refers to github
and instructs to have the spec shorthand. We can use an
issue template in github so it will show with a header
that has css-foo in it so people remember.
astearns: Sounds good.
Florian: It does
<TabAtkins> issue templates:
https://github.com/blog/2111-issue-and-pull-request-templates
<TabAtkins> I'll add one to the repo today
astearns: dbaron also mentioned auto-complaining about issues
where a spec doesn't have issues pointing to it. I don't
think many do. Is that a problem?
astearns: It's easier if you link to the spec section, but often
e-mails on the list don't have URLs.
dbaron: I think it's more useful with a URL. If we had a bot to
auto-add the tags it could do so on the URL.
fantasai: Not all issues have a URL. Some are more general or have
an un-addressed use case. There's a lot of issues where
the URL would be the whole spec or more general.
TabAtkins: We can have a bot where if there's a spec link, auto
tag. If there's a tag and no spec you can auto add the
spec. These are all possible and not hard. And fun for
me.
Florian: Can we have a short dos and don'ts for when people file
issues? A memo up above an issues with instructions?
TabAtkins: I'm writing an issue template. It's stuff that's
pre-filled on title or content. We can add a
contributing guide that has the etiquette. We should
also have an official code of conduct if W3C has it. Or
add it.
Florian: I think W3C has one but it's mostly IP.
<fantasai> Here's the one for www-style -
https://wiki.csswg.org/tools/www-style
TabAtkins: I'll come up with something on the ML
dauwhe: Can this be on the main read me of the repo?
TabAtkins: Sure.
Florian: And it will be easier to moderate if we had a guide. Like
where TabAtkins didn't like all the +1 and if we had a
guide saying don't do that I think we could remove them.
* fantasai thought Florian said that Tab just removed all the +1,
and Florian would be more comfortable doing that if
there was a rule that said don't do that.
tantek: I think I agree with a lot of the comments. One thing I've
observed watching this group is we've evolved the use of
the email list in a way that's been more structured than
other groups. It doesn't surprise me that the switch to
github didn't add much on browsing, but that's because we
were already good. It will hopefully be easier for new
comers.
tantek: One thing is the social web WG has been using github from
day 1 and we've been taking things from commentary to CR.
We've had a minimal set of labels that I'll share.
<tantek> https://github.com/sandhawke/spec-labels-min/labels?sort=name-asc
tantek: This came from proposal, iteration, and in person
discussion. It's been working for us, so I'm giving it as
a starting point. Take it into consideration, if we need
to modify that's fine, but this starting point is useful.
Especially if we work towards a common set across WGs.
Florian: Thanks.
tantek: So we're actively using this to transition documents.
fantasai: Labels look good. I think "needs group input" is our
agenda+
tantek: Yeah. I think we tried to word by state rather than the
action in the semantics.
Florian: I think "needs group input" is a bit different than
agenda+. Agenda+ means lets talk this week.
tantek: It's also used as a way for the editor to say I can't
decide on this on my own.
<tantek> https://www.w3.org/wiki/Issue_labels
tantek: Additional background ^
tantek: This came from a much larger list.
astearns: I'd be up for adding these labels as-is and try them out.
TabAtkins: Yep.
astearns: Let's do it.
RESOLVED: Add the labels listed here:
https://github.com/sandhawke/spec-labels-min/labels?sort=name-asc
Florian: Labels are flat. We can't separate those labels from spec
labels, right?
TabAtkins: We don't. All the spec labels start with css- but
that's it.
fantasai: Except MQ.
fantasai: We may want a common prefix.
astearns: <snark>label management</snark>
tantek: We tried to put label management in the colors.
Florian: It shows.
astearns: Any other github issue ideas?
astearns: Any other topics, or is this a short call?
astearns: Thanks everybody.
<tantek> more context around Social Web WG's use of Github Issues:
https://www.w3.org/wiki/Socialwg/Github_Process
Received on Wednesday, 1 June 2016 23:35:56 UTC