- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Apr 2014 19:59:58 -0400
- To: www-style@w3.org
Charter Update
--------------
- Plh plans to send the charter in by the end of the week.
CSS Masking LC/Rename mask-box to mask-border
---------------------------------------------
- RESOLVED: Change mask-box to mask-border
- Krit and fantasai brought the group's attention to the changes
made to Masking and asked for review before a decision on
going to LC.
Proposal to split CSS Text level 3
-----------------------------------
- There was a lot of concern about splitting Text into smaller
pieces since they are highly related.
-A few potential smaller splits were discussed and a look into
what pieces were holding the spec up most was advised.
- The details of a potential split was declared to be perfect for
a F2F conversation.
Calc() in MQ
------------
- RESOLVED: No change to calc() in MQ
Box model/Render tree
---------------------
- Due to the lack of immediate concern, this was declared another
great F2F topic.
inline-x auto-sizing
--------------------
- There was some concern about it not being easy to standardize
atomic inlines.
- Fantasai will come up with some proposed text.
Changing MediaQueryList to use events
-------------------------------------
- Defer to mailing list.
Scrollbar Stickiness
--------------------
- Also staying on the mailing list.
Adding any-pointer and any-hover MQs
------------------------------------
- There was a request for more time to read up about this proposal.
- MaRakow and TabAtkins will discuss technical details about the
proposal on the mailing list.
officially using the behavior of 'animation' wrt parsing
<custom-ident>s in properties.
----------------------------------------------------------
- TabAtkins stated that he needs to go back to this text and come
up with another draft before consideration.
Seoul F2F
---------
- WG members were reminded to add discussion topics to the wiki
- Anyone that hasn't already reserved their hotel room show do so
ASAP.
Variables
---------
- RESOLVED: New LC for Variables
Revisiting calc() and whitespace
--------------------------------
- Zcorpan drew attention to his e-mail with the same subject and
requested review for discussion on next week's call.
====FULL MINUTES BELOW=======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Elika Etemad
Daniel Glazman
Koji Ishii
Dael Jackson
Brian Kardell
Philippe Le Hégaret
Shinyu Murakami
Edward O'Connor
Simon Pieters
Matt Rakow
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Brad Kemper
Peter Linss
Michael Miller
Anton Prowse
Lea Verou (briefly in attendance, but had connection issues)
ScribeNick: dael
Charter Update
--------------
glazou: Let's start
glazou: We have a full agenda, but any extra items?
glazou: Sorry for that
glazou: Any extra items?
plh: I can do a short charter update.
plh: So I've got all the necessary stuff to send the charter to AC.
plh: I expect to send by end of the week at the latest.
glazou: Any questions?
CSS Masking LC/Rename mask-box to mask-border
---------------------------------------------
<krit> http://dev.w3.org/fxtf/css-masking-1/#box-masks
glazou: So the first issue is the rename.
krit: This was a request from the last call. The reasoning was
mask-box is similar to border image so it mostly affects
ordering.
krit: The request to was rename to mask-border since that
describes what it does.
krit: The cost for that is that boxes have a border. Also box is a
rectangular shape so that might be good for SVG shapes.
krit: But I don't have a preference. I like box or border. I'd
like to hear concerns about renaming.
fantasai: I'd like to note there's other things for masking. One
related is there's a fill keyword in mask-slice which is
similar to border image.
fantasai: Like border image, mask doesn't affect the middle so it
is like a border.
krit: So that would be a vote for mask border.
krit: Any other issues/concerns?
rossen: Did any reasons to not rename get raised on the mailing
list?
krit: Just my pros and cons.
rossen: So it sounds like no one else objects to border?
krit: No.
rossen: So it's fine than.
glazou: So is there any objection?
rossen: The only one is there's the mask-border...There's left,
right, top, and bottom parts and for mask even though it
can be just a single border?
krit: There's a mask border property in the future that takes four
arguments. It's an offset for tiles. There isn't longhand
for each side.
krit: Does that answer your question?
rossen: Yes. It's going to be like borders in that respect?
fantasai: Borders can't take image. It doesn't have per-side.
There's one setting for the whole box.
rossen: Ok.
<dbaron> So this is the mask property that's analogous to border-
image, and we're now calling it mask-border?
krit: So can we get a resolution?
rossen: One more. Do you want to change to mask-border to reserve
the shorthand or is border-mask another option?
rossen: As fantasai pointed out, I'd expect the border-mask so
that way it would be clear.
fantasai: If it was border-mask, I'd expect only border to be
affected but this does the whole element.
fantasai: So I think mask-border is correct. If we add border-mask
that would just do border.
rossen: That would be crazy.
fantasai: Yes. My point this the effects the whole thing.
rossen: Are we sure we'll never do that?
fantasai: I don't think we can ever be sure.
rossen: By choosing mask-border we prevent border-mask.
fantasai: Well, if we choose that now we can't have border-mask.
rossen: So you think that this won't prevent things in the future?
fantasai: We can never know for sure about things in the future,
but hopefully it'll be fine for now.
glazou: dbaron asked in IRC if mask property is analogous to border
-image and we're now calling it mask-border
fantasai: Yes.
glazou: So is there any objections?
RESOLVED: Change mask-box to mask-border
glazou: So back to item 1 on the agenda. LC for masking?
fantasai: There's more issues I think we should discuss.
glazou: That's the only one I was told about.
fantasai: One was there's mask-type about using alpha or luminance
to interpret image, but there wasn't an analog to mask-
border so we added that type.
krit: Biggest change was that I added layers to mask property
similar to background and mask-composite to allow you to
composite layers.
<krit> http://dev.w3.org/fxtf/css-masking-1/#the-mask-composite
krit: That's linked here (above)
krit: What I want to do is ask for 1 or 2 weeks review so everyone
can look at the changes and then go to LC if there's no
objections.
glazou: What do people think?
fantasai: I'm in favor of review period.
Several: yes
glazou: Any objections against that?
[silence]
krit: Do we want to bring it up during the F2F?
krit: Or do we just go to LC automatically?
fantasai: I think we should talk again.
glazou: I agree. I think 2 weeks review and all questions can be
addressed in the week before the F2F since that's a bit
more than 2 weeks.
glazou: So that's a good time to discuss issues.
krit: Okay.
Action everyone review CSS Masking and send comments
<fantasai> lea, can you help get feedback on the spread radius
changes from the authoring community?
<leaverou> fantasai: yes, but I will need some help on what to ask
Proposal to split CSS Text level 3
-----------------------------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014AprJun/0036.html
[Members only list]
koji: The idea is the spec has been split several times. In the LC
we have more than 70 issues and I think that means that it
just keeps getting issues and therefore delayed.
fantasai: My concern is with the fact that a lot of these features
are interrelated so I'm hesitant to split the spec more
than before.
fantasai: Maybe if we have a solid base as 3 and do additions as
partial modules, but I think I'd prefer to churn through
the issues.
fantasai: I think the problem is no one looked at the spec until
we are in LC
koji: Like textbox is interactive so there will be interaction
between specs. I don't see...
fantasai: The relation between justify and align and spacing is
very tight. It's not just vocabulary. If you change the
alignment, than justification changes.
koji: I agree.
<Bert> q+ to ask if we know what part is the slowest and if we can
put some effort into solving it.
koji: Perhaps it should have spacing in that one spec.
koji: Maybe break out white space and text transformation.
fantasai: We could, but that's too small.
koji: Okay.
koji: Um.
Bert: I'm still undecided for what's best, but do we know what's
the slowest part and can concentrate on that?
Bert: If you don't know the slowest, maybe splitting is the only
way, but I'd rather keep it together.
rossen: Is it possible to focus on the hard problems first and
after that reconsider a split?
glazou: Unless there's a firm proposal, I suggest we go to e-mail.
koji: What to e-mail?
glazou: The discussion on how to split. Otherwise we'll spend a
lot of telecon time
rossen: Is the question how or if?
krit: I think the biggest problem is that the spec can grow. In
the last TPAC Kenny raised indentation questions and that
added to the spec.
krit: On the other hand line break and alignment do require
discussion. The size and broadness is making progress slow.
glazou: Okay.
rossen: So back to the list?
glazou: That or dedicate F2F time.
glazou: We have to have a really complete discussion in the same
room.
glazou: It's too big for telecon time
Calc() in MQ
------------
TabAtkins: This topic was raised by zcorpan.
TabAtkins: He thinks calc() is low value in MQ so we should
disallow it to simplify MQ.
TabAtkins: I disagree and think language consistency is preferable
since calc() is just a length and it should be allowed
everywhere length is in CSS.
TabAtkins: Making arbitrary wording due to implementor concerns
makes the language harder to learn.
glazou: I don't think he was arguing on implementor constraints,
but on use cases.
glazou: But I agree that consistency matters and I'm with you on
that front.
TabAtkins: He did also raise for implementor issues because we're
using it in sizes and that does make it more complex.
zcorpan: My main reason was lack of use cases, but it seems
there's implementor interest so if browsers will
implement it I don't object.
florian: Implementor interest is there, no one has said it's a bad
idea, but no one is rushing to it.
zcorpan: I saw Mozilla had interest in implementing as well.
zcorpan: I raised this because we're doing authors a disservice if
it's not implemented but we pretend it exists.
fantasai: To help on that front, maybe add a note on level 3
saying calc() isn't there, and say on level 4 that we
are including it, but it's at risk.
fantasai: That way it's clear that anyone using MQ3 it doesn't
have calc()
florian: But why would MQ say anything about that?
TabAtkins: It should be where lengths are allowed.
hober: I'm fine with fantasai's suggestion, but I think it's
easier for us to restrict it now then realize it's a
mistake and restrict later.
florian: MQ3 is already a rec and I'm not sure we should edit a
rec to remove something we're planning to add later. It
doesn't mention calc() in the first place and if we want
this it feel better to talk about calc() than MQ
TabAtkins: And some people are planning on implementing calc() in
MQ now.
TabAtkins: Since zcorpan drops his objection if there's
implementors, I suggest no change.
TabAtkins: Any objections to that?
<SimonSapin> +1
zcorpan: Works for me
glazou: Other opinions?
<glenn> +1
SimonSapin: I agree
several: I agree
glazou: So any objections against no change?
RESOLVED: No change to calc() in MQ
Box model/Render tree
---------------------
TabAtkins: I think this is best addressed at F2F.
TabAtkins: It's more blue sky. Something for the future.
glazou: Bkardell, does that work for you?
bkardell: I won't be at F2F, but it works.
glazou: Can you join for one part?
bkardell: I think so.
TabAtkins: I can try and represent for him too.
<SimonSapin> (I unfortunately won't be at the F2F either but I'm
interested to call in for this)
inline-x auto-sizing
--------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0225.html
glazou: fantasai, this is you.
fantasai: What was it again?
glazou: It was from last week's call, plinss had it on.
SimonSapin: It talks about generalizing the width calculation with
non replaced atomic inlines.
TabAtkins: This is asking for 2.1 errata generalizing something
that's for inline-block right now to apply to all
atomic inlines
glazou: Is there anything to discuss on telecon for now?
fantasai: Well, does anyone object to the idea or should I come up
with wording to propose an errata?
bert: Nothing to object, for CSS2.1 it seems like you might say
the same thing.
fantasai: We have the flex so if this was changed to all atomic
inline, other specs could just say it's atomic inline
and than other specs won't have to duplicate and we
reduce errors.
bert: I'm not sure that helps. For example, baseline alignment
various atomic doesn't work the same.
fantasai: This is just margin and width
bart: But the concept..
fantasai: The concept exists in CSS2.1 already.
<SimonSapin> q+ to say that inline-table is an atomic inline but
is special sizing behavior, IIRC
* florian sorry, got to leave. If we reach topic 10, I defer to Tab
SimonSapin: I wanted to mention there are inline-tables that have
special sizes so perhaps it won't be that easy to
generalize.
??: What did he say?
glazou: fantasai, can you repeat what SimonSapin said?
fantasai: He said that inline tables have a special sizing so
perhaps it won't be that easy to generalize
<SimonSapin> I'm not sure, though
glazou: It seems this requires more work or at least a text
proposal so let's decide that approach and move on.
Changing MediaQueryList to use events
-------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0603.html
glazou: Do we need to continue the discussion on this?
glazou: Anyone willing to continue, or do we move on?
TabAtkins: I haven't picked this up on the list so I need to do
that.
Scrollbar Stickiness
--------------------
glazou: Same question here.
<glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0112.html
TabAtkins: This would also benefit from staying on list.
Adding any-pointer and any-hover MQs
------------------------------------
TabAtkins: Currently the pointer and hover let you query aspect of
the pointing device and is defined as whatever the
primary pointing device is.
TabAtkins: For example, a touchscreen laptop has the touch screen
and the pointer. This becomes hard when you do
something like plug in a mouse.
TabAtkins: We wanted to know user's probable interaction and what
they might be able to do.
TabAtkins: We let it determine what's the most likely thing for
users to use, on a touchscreen laptop it's the trackpad
etc.
TabAtkins: Hover does all the values that might be on the screen,
it just tells you what the user might be capable of.
TabAtkins: I think this addresses a larger issue rather elegantly
and I want to add this to MQ, but I'm wondering about
other thoughts
glazou: Comments?
rossen: I'm not caught up on this one, but I'd like to run this by
others. Can we wait a week?
glazou: Is that okay for you?
MaRakow: I was looking at this and I think the challenge is along
the lines of... it's look at this a course or fine.
MaRakow: This is fine if there's just primary and secondary, but
if you end up with more tiers it's limiting.
TabAtkins: Do you have examples where primary might be hard?
TabAtkins: On my chromebook the touchpad is primary, screen
secondary. Every example I can think of one can be
reasonably assumed as the primary and I think it's okay
to play favorites.
MaRakow: My main thought is what you're trying to do is negotiate
between what's best for the device and what's best for
the author. If I have 3 options you can rank those by
what's best
MaRakow: And then you can correspond precedence. But when you have
multiple tiers and the author has things for 2 and 3, does
it use 2 not 3?
TabAtkins: So the thing is the pointer can smash all them together?
MaRakow: Maybe this is best on the mailing list, but I think that
picking an input is more complex here.
TabAtkins: Okay.
TabAtkins: We can get more detailed with technical details on the
list, I'm happy with that.
glazou: Anything else on this topic?
TabAtkins: No.
officially using the behavior of 'animation' wrt parsing
<custom-ident>s in properties.
----------------------------------------------------------
glazou: We had a comment on this from Xidorn the public ML.
TabAtkins: That comment confuses me because this is what I thought
he was asking for which means I misread.
TabAtkins: I need to go look into what he wants and withdraw this
text.
glazou: So nothing to discuss now.
Seoul F2F
---------
glazou: We have time, anything else to discuss?
glazou: One thing before anyone else adds items, I think plinss
mentioned this, but we need F2F items. Please place it on
the wiki.
glazou: If you don't have a hotel room, please book soon.
Variables
---------
fantasai: Variables hasn't had anything since LC last year.
TabAtkins: I've been working on comments.
TabAtkins: Last resolution is CR once I finish the DoC.
TabAtkins: I've made significant changes so we should republish as
LC.
TabAtkins: So if we can get that with a 4 or 6 week waiting period
I'd be happy.
glazou: When were the last significant changes?
TabAtkins: A month-ish ago.
glazou: Did people review?
TabAtkins: The implementor, Cameron, did.
fantasai: The major changes were call discussed, right?
TabAtkins: Yes.
glazou: I wanted to make sure no one would object to LC without
review here.
glazou: So any support, objection, or whatever to the LC?
TabAtkins: I support it
glazou: I do to
<astearns> support publishing
<glenn> +1
fantasai: We need it publish, so I support.
glazou: Any objections to new LC of Variables?
RESOLVED: New LC for Variables
TabAtkins: I can prep today. Can we publish this Thursday or wait
for Tuesday?
bert: I have holiday tomorrow so won't be available and don't want
to risk it tonight.
glazou: Most of Europe is on holiday tomorrow.
TabAtkins: I'll prep for Tuesday.
Bert: Tuesday is fine.
glazou: Anything else?
fantasai: Anything else to publish?
Revisiting calc() and whitespace
--------------------------------
<zcorpan> http://lists.w3.org/Archives/Public/www-style/2014Apr/0480.html
[css-values] Revisiting calc() and whitespace
zcorpan: I have another topic, I just sent an e-mail regarding
calc() and whitespace.
zcorpan: My proposal is don't be fussy with whitespace. We changed
parsing to allow white space around + and - and it seems
silly to not support it.
dbaron: So just changing parsing means it's required in some place
not others which is confusing.
fantasai: I think the previous concern is still valid.
glazou: In you're e-mail, the 4th calc() example, do you want that
valid?
fantasai: That's invalid.
glazou: It is now, but zcorpan says it's hard to explain
zcorpan: I want it valid to 1+ not 2+
<TabAtkins> That is valid in JS: `1 + + 2` == 3
<SimonSapin> calc(10px + -2px) ?
fantasai: I'm leaning no change here.
zcorpan: We can think over this and discuss in a week.
TabAtkins: Yep.
glazou: Okay. It'll get discussed on www-style since it was just
posted.
glazou: Anything else?
glazou: Okay. It's a short call. Thanks everyone and we'll talk
next week.
Received on Thursday, 1 May 2014 00:00:25 UTC