- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 6 Apr 2016 19:03:40 -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.
=========================================
Upcoming F2F
------------
- Everyone was reminded to add their information to the wiki if
they're coming to the F2F and book their travel if they
haven't already.
Media Queries
-------------
- overflow-block and overflow-inline will be combined into
overflow with properties to specify inline and block direction.
- fantasai will write up proposed text for the new properties.
- RESOLVED: Add infinite value to resolution MQ.
- Florian will write up a proposal for a raster MQ.
grid-template
-------------
- There wasn't much desire to add grid-template back, but there
wasn't much objection either.
- fantasai will focus on making the grid shorthand more robust and
solicit more author feedback.
Publication for Sizing
----------------------
- RESOLVED: Publish Sizing
Flexbox DoC
-----------
- Everyone was actioned to review the entire Flexbox DoC.
- The items that need the most attention are issue #3 and an
additional paragraph added to order accessibility to
address concerns from the accessibility working group.
Serialization of calc()
-----------------------
- RESOLVED: Accept TabAtkins proposal for calc() serialization and
add a note that there remains a concern about editors
getting access to the bare string.
Test Suite
----------
- Everyone was asked to please contribute to the email thread on
the test suite.
Specification Status Wiki
-------------------------
- fantasai introduced a wiki compiled by Nick Guarino listing all
resolutions and actions regarding each spec:
https://wiki.csswg.org/planning/status
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Apr/0083.html
Present:
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Alex Critchfield
Elika Etemad
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Ian Kilpatrick
Peter Linss
Myles Maxfield
Edward O'Connor
Anton Prowse
Matt Rakow
François Remy
Florian Rivoal
Alan Stearns
Ian Vollick
Greg Whitworth
Steve Zilles
Regrets:
Dave Cramer
Daniel Glazman
Chris Lilley
Michael Miller
Jen Simmons
Lea Verou
Scribe: dael
Upcoming F2F
============
astearns: We'll give people another minute or so and we'll start.
astearns: Any extra to add to the agenda?
Rossen: I want to do a quick nudge about upcoming F2F for Houdini
and CSS.
Rossen: It won't be more than a minute.
Rossen: I wanted to remind people we're meeting in about a month.
If you haven't booked travel, please do so. Hotel
availability is disappearing.
Rossen: If you haven't planned, do it soon or ping Florian who is
doing airBnB.
Rossen: I only see a dozen who have signed up on the wiki. I'm not
sure if this is representative.
Rossen: Perhaps you haven't added your name, but I wanted to
remind everyone.
<Rossen> https://wiki.csswg.org/planning/san-francisco-2016
Florian: I haven't booked yet, but will soon. If you want in let
me know.
astearns: Thanks.
Media Queries
=============
naming overflow-block/inline
----------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0043.html
Florian: As we move to media features, print typically paginates.
We had a pair of properties to say what we do in inline
and block directions. fantasai pointed out a few naming
issues. I'm okay with her suggestion. If anyone is
interested we can discuss.
[silence]
Florian: So I'll just do it.
Florian: Renaming property itself, we have overflow-block and
overflow-inline. fantasai points out block is more
interesting and we should have a shorter name. I think
fantasai suggested a shorter name.
fantasai: I was thinking for now since there isn't a great demand
for an inline check, we can have these with just
overflow. If we want a switch that checks we can have
additional values. So overflow: scroll and overflow:
scroll-inline are both valid. Same with page/page-inline.
Florian: And you'd have inline-none?
fantasai: I think we could. You would check the combination.
overflow: none means not in the block. You would assume
not scrollable if it's paginated, but it could be in
which case it's true. overflow: scroll probably means
both dimensions.
fantasai: It's similar to multi-value property, but you only do
one at a time.
Florian: The only thing that bothers me is, is overflow: none in
block, or both directions?
Rossen: Currently none includes the other one, right?
Florian: It doesn't compute to anything, it's a MQ.
Rossen: Sure.
Florian: Right now we have overflow-block: none and
overflow-inline: none. If you merge, what does none mean?
Both or block because that's what people care about?
fantasai: It can be both.
Florian: And block-none is separate?
fantasai: If needed.
Florian: So do we put all in and some at risk or limit?
fantasai: I think there's no need for all. Generally people don't
like to scroll inline. As long as we make it clear the
author should assume no inline.
Florian: I have a use case and a UA. If you take the specs,
normally you don't want overflow in inline, but sometimes
you have a big table. For a UA Vivliostyle paginates but
on screen. So if you know you have inline-scroll you can
skip doing the painful things to squeeze horizontally.
It's not ideal, but there.
fantasai: That's not a bad case. In that case let me draw up a
concrete proposal and we can come back.
Florian: I think the general direction you propose is worthwhile.
ACTION fantasai draw up a proposal for overflow MQ
<trackbot> Created ACTION-763
Infinite Resolution
-------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Jun/0131.html
Florian: Resolution MQ. It assumes you have a resolution. However,
if you print you're not often to a printer, but a PDF
which is vector and has no resolution or is infinite. We
don't define.
Florian: TabAtkins and I concluded resolution MQ should have a
infinity value that would match vector. So if you're
doing if resolution > 200 dpi it shouldn't work on vector
format.
Florian: TabAtkins and I agree. Group?
fantasai: Makes sense to me.
astearns: Can you test?
Florian: It's a keyword. You ask if it's infinite and it tells you.
Otherwise you use inequalities.
astearns: Okay. I didn't see it in the thread.
Florian: It's a long thread.
astearns: Objections to adding this?
RESOLVED: Add infinite value to resolution MQ.
Florian: Even when outputting to infinity, your vectors stay
vectors. If you have raster graphics and you print to PDF
often they will have a max resolution. You may want to
query on this.
Florian: The main resolution feature doesn't. We're proposing a
new media feature that lets you check to what point
raster images are down sampled. It's either equal to the
resolution or lower if there's such a processing.
frremy: This seems to be something only printers know, not browser.
Do printer drivers expose this?
Florian: When browsers print to PDF it's not necessarily through a
printer driver. There's a lot of borrowed libraries, but
it's not necessarily from an OS stack. So I assume
there's some cases where you can know and some where you
can't.
<gregwhitworth> this feels like something we should investigate
then
astearns: Seems to me like next step for this bit is write a
proposal and send for review.
<tantek> astearns++
Florian: Idea was discussed on the thread, but specific syntax may
need to write.
astearns: Can I action you?
Florian: Yes.
ACTION Florian write up a proposal for raster MQ
<trackbot> Created ACTION-764
<tantek> Florian does this mean we have enough resolved to do
another WD of MQ4?
grid-template removal
=====================
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Mar/0345.html
fantasai: We discussed the grid and grid-template and noted
anything you want to say in template you can do in grid.
Eric Meyer posted that in some cases that's not what
wants. He wants to set some parameter of the grid up top
and then use grid-template shorthand. So, should we add
this back? It was removed last month.
astearns: The argument makes sense to me. Other comments?
frremy: I'm checking the spec now. We didn't remove
grid-template-row and grid-template-column, right? His use
case is covered by those properties. It doesn't seem you
need grid-template to do it, but I'm fine with it.
Rossen: Eric admits the same thing. My personal take is Eric was
used to grid-template, not grid-template-row and
grid-template-column. So that habit made him go to the
shorthand which didn't work. I'd like more feedback from
others before we add it back. Given we can use
grid-template-row and grid-template-column directly that
should be fine.
Rossen: I also wouldn't push much back on adding it back in. I'm
kind of impartial.
fantasai: I think the main case where it really makes a difference
would be if you had a template and the syntax for rows
and columns is quite different. But I'm okay to hear
from more people.
gregwhitworth: We saw a lot of issues in flex where people using
the shorthand solved a ton of author issues. I
agree we should get more feedback, but I was
thinking we should lean on the history of author
confusion with long hand because the reset helps
most authors do modern layouts.
astearns: So because in most cases we'd rather have them use the
grid shorthand, this case from Eric is enough of an edge
case it's okay to force him to long hands.
gregwhitworth: Yeah. This is mostly just because the issues we had
from flexbox where if people just used flex it
would work. I'd rather not add long hands where
there's a true use case where we can't solve with
shorthands.
fantasai: In this case we have long hands and a short hand. This
is an intermediary hand. I understand the flex case and
this isn't quite the same.
gregwhitworth: Okay.
Rossen: Would it be worth reaching back to Eric and getting more
feedback before we decide to add this back in?
fantasai: That makes sense. There's another comment where the grid
shorthand is limited, but I don't know how to solve that
quite yet.
Rossen: I'd rather solve that and make the shorthand really good
than have secondary short hands.
<gregwhitworth> agreed +1
fantasai: Okay. We'll come up with more expressive shorthand
syntax and get more feedback on if the intermediary is
necessary.
Publication for Sizing
======================
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Apr/0048.html
Rossen: Yes please.
astearns: Does anyone object to publishing a new version?
<tantek> ship it!
RESOLVED: Publish Sizing
Flexbox DoC
===========
<astearns> https://drafts.csswg.org/css-flexbox/issues-cr-20160301
astearns: First is people should look. I'd like to action the
group to review the DoC and bring up issues next week.
Issue 3
-------
<astearns> https://drafts.csswg.org/css-flexbox/issues-cr-20160301#issue-3
astearns: There's a specific item to review, which was issue #3
fantasai: Christian pointed out we had discussed what the min size
of auto does for the resolution of percentages inside a
flex item. We didn't discuss the reverse where it's
inside auto.
fantasai: We discussed and concluded the right answer is when
you're calculating an intrinsic size you treat the
percentages as if the size was auto which generally
causes percentages to fail and it's treated as auto. We
put that in the spec, but we wanted people to sanity
check and make sure it's clear. We think it's what we
want but we want to make sure because it's fairly
impactful change.
<fantasai> The reverse = the impact that percentage sizes have on
the resolution of min-size: auto
astearns: Has anyone had a chance to review this change?
Rossen: I haven't and I really want to. So I will.
ACTION Rossen review flexbox issue 3
<trackbot> Created ACTION-765
gregwhitworth: Does this make Chrome match FF?
fantasai: I don't know.
gregwhitworth: I think FF and Edge are doing the right thing there.
I was trying to do the mental visualization...I can
go look. I was just curious if you knew.
fantasai: I don't off the top of my head.
gregwhitworth: We can check offline.
Rossen: Yeah, it's definitely worth looking into. We'll look and
follow-up over mail. That okay, fantasai?
fantasai: Yep. I'm happy to give people time to review.
astearns: Christian is which engine?
fantasai: Chrome
astearns: Has anyone from Gecko looked?
fantasai: I don't know if dholbert has replied. I'll look. His
feedback has been super helpful.
fantasai: He did reply in the thread. Mostly with my edit being
not quite correct. We fixed that.
astearns: Anything else on this one?
order accessibility additional paragraph
----------------------------------------
<fantasai> https://drafts.csswg.org/css-flexbox/#order-accessibility
fantasai: The other thing for WG review is the addition of a
paragraph for a11y.
fantasai: We can just make sure it's the right thing to do.
fantasai: It's the very last note in that section.
<tantek> fantasai++ this is great work. Thanks!
<tantek> really well written
Rossen: We need to circle back with the a11y group on that.
Rossen: Get their blessing.
astearns: Has this been sent to their ML?
fantasai: A bunch was resolved on their call. I CCed the person
making most of the comments asking for this note. I
haven't heard from her.
Rossen: I'll make sure she replies.
astearns: We'll come back to this DoC maybe next week or week
after. Please do look.
Serialization of calc()
=======================
astearns: I know TabAtkins and Rossen have things to say. Anyone
else on the call with an opinion they'd like to express?
<dbaron> maybe :-)
fantasai: I think it would be good to hear from authors. That's my
main concern.
<fantasai> has opinions, but mostly defers to dbaron and authors
TabAtkins: There is 0 author talk about this. So negative
attention. Authors have clearly not spoken.
fantasai: We have some in the WG that haven't spoken.
Rossen: What I was saying is when I brought this up last week, I
want to make sure...there have been cross threads on this
for the last week...I want to make sure we understand what
we're talking about and my concern. We're only talking
about specified values and the serialization of those. I'm
not pushing back on computed and simplification of those.
Rossen: The thread that astearns started summarizing and
differentiating the approaches between serializing the
longhand as the author spec or simplifying before
serializing. I thought it was a really good summary on who
benefits from which approach.
Rossen: I have personally discussed how people mentally map
different models in their heads into calc(). I was working
with our internal designers making winJS.
astearns: Before you go further, I want one clarification. We're
talking specified values in the OM. THe only time
serialization is invoked is when OM needs to provide a
value. This isn't dev tools or how browser represents
specified value as you look. As far as I can tell dev
tools in a browser aren't doing anything. It's only when
accessing through an OM this is in play, right?
Rossen: Correct.
Rossen: I'm assuming in dev tools you serialize what's in your
style sheet, right?
TabAtkins: I don't know exactly. I know our dev tools let you at
invalid tools. So it's an early level of parsing.
iank: That's right.
astearns: In the vast majority of cases, people are using the dev
tools to tweek the values and what we define as calc()
serialization for OM has no effect.
TabAtkins: I just confirmed in Chrome even though we'll serialize,
in the dev tools it shows what you wrote.
dbaron: In Gecko we do show specified values in dev tools except
in a few cases where we preserve extra data, but else wise
we show specified.
Rossen: That's why we try and keep specified as close as possible
to author. We have a few code paths for dev tools that
preserve rollbacks, but we've been keeping dev tools and
OM the same.
Rossen: Again I'm trying to find the best path. I'm fine with your
proposal for the computed value. For specified if we're
going to fork and have one for tools and one for OM, this
is going to be a burden on our implementation, but it's
solvable. Is that the final proposal we have here?
Rossen: Or maybe I misunderstood.
astearns: [notes TabAtkins lost connection]
* TabAtkins is back
astearns: That seems to be to be the way to move forward. It's an
extra burden on you to take extra data into account so
you can give the right thing to dev tools, but I don't
see how to make typed OM for calc() specified values
unless we define this serialization.
astearns: So it's extra work for you to implement TabAtkins'
proposal, but it's just not workable to leave things as
Edge has them impl.
frremy: I'm not entirely agreed. It's possible to have the same
typed OM for specified value. So if you get pixel value
you get it at the same time and you get the same value. So
you can do the same thing at typed OM level. If you don't
ask for typed OM you get the value as is and if you don't
you get the value at that moment. I'm not sure it's
necessary to simplify.
frremy: It's easier and leaner, but not necessary.
Rossen: I think it summarizes to this being implementation detail
at this point. The point you're making is that the typed
OM has to have the representation TabAtkins mentions and
the rest of the serialization keeping the long hand is
better editing
TabAtkins: That requires us to hold a bunch of data just to
serialize the legacy string which we don't want to
encourage. This is just how you serialize when people
ask through the OM. You can have two representations,
but when you call whatever code stringifies it - it has
simplification.
Rossen: I think that makes sense. and that's what frremy was
mentioning.
TabAtkins: There's 0 functional difference between holding the
long and simple expression. For CSS data it doesn't
care how you represent internally, but this is how you
stringify.
gregwhitworth: Have we reached out to people that want to show the
specified style in the specified form?
TabAtkins: I did a search and couldn't find a person complaining
about it even though several browsers have done this
for years. Maybe someone cares, but it's not important
enough for people to complain on stack overflow.
astearns: Will the Parsing API solve this?
TabAtkins: Mayyyybe,
gregwhitworth: I'd like to not stack hypothetical specs. Typed OM
is getting close.
astearns: I'm saying that that case where editors want to show
what's in the style sheet may be a proper use case of
the Parsing API. If we put the use cases in the right
specs, it's good.
frremy: I kind of agree, but you cannot access the stylesheet from
the JS side if it's on a different origin,
frremy: So you cannot read the file. Even if you have a buffer you
can't get to the file. I'm not sure if this is really a
solution.
Florian: Did glazou say anything?
Rossen: He was mostly agreeing with the point I raised. That was
about it.
<frremy> devtools in the browser
<frremy> http://www.vorlonjs.io/#getting-started
<frremy> https://getfirebug.com/firebuglite
Rossen: I'm not looking to stall this forever, I want us to move
forward. As long as everything laid out on the table has
been throughly examined we can have a group consensus.
Florian: Only thing is when we say dev tools can do it, it's only
ones built by browsers.
<gregwhitworth> Florian, exactly
<gregwhitworth> http://vorlonjs.com/
Rossen: Absolutely. And what I was speaking about was things like
winJS and the office team that has their own minware. They
do everything from public OM. And if this is moving in
unexpected ways it'll make debugging hard. Florian is
right, debugger isn't in browser.
astearns: This is why I was suggesting what's currently in typed
OM about CSS text having the actual string makes perfect
sense.
frremy: But if you call style.padding-left = 3px you can't return
the original string. You still have to serialize at some
point.
iank: I've got one small data point. I was looking through
internal JS apps. One thing for having a normalized
serialization, one thing we do a lot is check to see if the
width = some string. There aren't a lot of calc()s or maybe
not any. If you don't have a normalized string it breaks the
calc() use case.
iank: It's another data point.
<iank) There are a few libraries which also do checks like:
node.style.width === node.style.height (dojo does this in a
graphics library)
astearns: Sounds to me Rossen proposed we resolve on TabAtkins
proposal for calc() serialization but there remains a
concern about editors getting access to the bare string.
Can we resolve on TabAtkins serialization with that
concern noted?
TabAtkins: Yep.
astearns: Objections?
Florian: I'm tempted to agree. This isn't the first time we ran
into this. We have a lot of places where we run into this
and we need to address this properly. We're not blocking
anything here not blocked elsewhere.
fantasai: I agree considering actual editors is out of scope
because there's a lot of places. Setting that aside, I
defer to dbaron.
TabAtkins: dbaron agreed two weeks ago.
astearns: dbaron might be muted.
dbaron: I don't have a lot to say now.
RESOLVED: Accept TabAtkins proposal for calc() serialization and
add a note that there remains a concern about editors
getting access to the bare string.
Rossen: So what happens next?
fantasai: TabAtkins and I need to make edits to the spec
Rossen: I think the note says hey authors we heard you and ignored
it, but we may revisit.
<fantasai> Yeah, not sure a note in the spec is needed
<fantasai> Note to the CSSWG maybe
astearns: I think more developers of dev tool kits.
astearns: I'm going to call that closed.
astearns: We have 4 minutes.
Test Suite
==========
astearns: gsnedders you there?
astearns: He said he might not make it.
astearns: Please note there is a thread on the test suite about
having the test suite able to be imported by browsers
and run more regularly. I'd like to add this to next
week and maybe the F2F so there's attention paid
Specification Status Wiki
=========================
<fantasai> https://wiki.csswg.org/planning/status
fantasai: There's a page on the wiki tracking outstanding action
items and resolutions for the spec. I didn't know about
transitions and animations, so I just compiled those. So
if you're not sure the status of your spec or if you
made edits, they're here.
astearns: It's biiiiiig list.
gregwhitworth: Is this auto-gen?
fantasai: All manual. And everything I know is done is crossed off.
astearns: This is cool.
astearns: Anyone else have a 1 or 2 minute thing?
astearns: Let's call it. Thanks everyone.
Received on Wednesday, 6 April 2016 23:04:40 UTC