- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Mar 2016 19:35:53 -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.
=========================================
CSSOM Selectors section review reminder
---------------------------------------
- The Selectors section of CSSOM will be on next week's agenda and
everyone should review it in advance.
calc() simplification for serializing specified values
------------------------------------------------------
- Tentatively the group decided combine identical units and
resolve all numeric and multiplication and division by numbers.
- On next week's call this will be resolved formally after
implementors have had time to speak to the appropriate
developers.
Rewrote grammar in terms of the Value Definition Syntax
-------------------------------------------------------
- Everyone accepted the rewrite and TabAtkins will add a note
warning that if this is inconsistent with previous grammar,
please send an issue because it's probably wrong
ch unit definition
------------------
- RESOLVED: Accept this change:
https://hg.csswg.org/drafts/diff/398d30b81c76/css-values/Overview.bs
Define <length-percentage> etc. productions
-------------------------------------------
- RESOLVED: Accept change for issue #5 of Values and Unit 3
(https://drafts.csswg.org/css-values-3/issues-cr-2015#issue-5)
Using the Snapshot to track pre-CR "shipping is okay" features
--------------------------------------------------------------
- RESOLVED: Add edits to 2015 snapshot and then republish.
- RESOLVED: Start an ED for 2016 snapshot.
Shortening minimum/maximum to min/max
-------------------------------------
- RESOLVED: shorten minimum/maximum to min/max in exclusions values
Media Queries issues
--------------------
- RESOLVED: Remove the on-demand value from hover.
- RESOLVED: Move light-level to the next level of Media Queries
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Mar/0329.html
Present:
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Ian Kilpatrick
Myles Maxfield
Thierry Michel
Edward O'Connor
Anton Prowse
Matt Rakow
Florian Rivoal
Andrey Rybka
Alan Stearns
Ian Vollick
Greg Whitworth
Steve Zilles
Regrets:
Rossen Atanassov
Tantek Çelik
Daniel Glazman
Peter Linss
Michael Miller
Scribe: dael
CSSOM Selectors section review reminder
=======================================
astearns: We should get started. Does anyone have additional items
to add today?
astearns: This is a reminder that we have an action on everyone to
review the CSSOM Selectors section. It will be on the
agenda next week. Please look and come with opinions or
give feedback on the list.
calc() simplification for serializing specified values
======================================================
TabAtkins: In short, every browsers disagrees about how/when to
simplify calc() expressions. We need to define it so we
have a stable serialization and representation. So we
need to figure out what to do. Everyone agrees on
computed and used values that are calc(). Resolve
everything as much as you can and you get a dimension a
percent and a number
TabAtkins: Specified values is the annoying part. Writing to a
style sheet and reading from the OM, what simplifies?
1px + 2px is 3px? If you have incompatible does it
simplify? Edge does not, chrome aggressively
simplifies, FF is in the middle.
fantasai: I wanted to point out this is for the specified style.
Computed is separate.
TabAtkins: Computed is easy and consistent.
dbaron: I thought Firefox was simplifying numbers and not other
things. We needed to do that to do division by 0 testing.
TabAtkins: I think that's what y'all do.
TabAtkins: Y'all combine numbers and not anything else.
<gregwhitworth> do you mind sharing the test so we don't have to
recreate it if you have it handy
astearns: You said compatible measures could be collapsed, but I'm
not sure that's always the case. Pixels and inches are
different when printed.
TabAtkins: No. Size may be different by they have a fixed ratio
defined by spec.
TabAtkins: We pinned that down about two years ago.
Florian: I think it's even older.
TabAtkins: So, what precisely if anything should be combined. We
can say nothing, numeric sub expressions, also
identicals, also compatibles. There's also a side
question of multiplication and division can be resolved.
TabAtkins: I'm happy with any answer. I don't think there's a big
implementation burden for anyone, but we have to agree
because we're all different.
gregwhitworth: I don't have a strong passion, but have you gotten
any feedback from authors on this?
TabAtkins: No, I haven't obtained any author feedback
* fantasai suspects they'd want it more expanded than collapsed,
since that's what specified styles are for
dbaron: I'm not crazy about merging different units because in
specified style we preserve units.
<fantasai> +1 to dbaron
TabAtkins: I have a slight preference for combining identical
units because when we represent in the OM, we can't
differentiate 10px + 10px from 20px. We'd like to
resolve multiplication and division so that we don't
have to represent those. We'd like a sum of united
values to be consistent with OM work
<SteveZ> how is 10px+10px different from 10px+1in?
dbaron: I think we had tentative agreement to extend calc() for
multiplication and division with units.
TabAtkins: We had tentative plans, but that's a niche calc() use.
We'd like the majority to be simple.
dbaron: So you'd have two different OM representations.
TabAtkins: Possible, or another list of complicated things and a
list that's simple values.
dbaron: That feels funny to me especially to design the initial OM
to assume we won't do that.
* fantasai is basically in agreement with all of dbaron's concerns
TabAtkins: I know that dealing arbitrary united that need to be
kept in some form will be complex. I don't want to
design to be purposefully complex. I know whatever we
do will have something on the edge. I want the majority
as simple as possible to work with.
astearns: Another possibility is to have a way of converting a
calc() to a simpler expression in the OM so you wouldn't
have to simplify what you're getting back.
TabAtkins: That doesn't change my argument. The representation as
a JS should be as simple as possible when we get it.
Even when we get the complex, we want to drop it so
it's simple. Even if under the hood you started with
something more complex.
dbaron: I'm okay with the conclusion, i.e.,the idea that you
simplify identical units and simplify
multiplication/division.
TabAtkins: We'd be fine with doing the same. Pulling back on our
simplification so in and px are distinct. Safari
matches us, IE is more different. What are your
opinions?
smfr: I'm fine with this for webkit.
gregwhitworth: I'll want to talk to the devs to see how bad it
would be to change, but on the surface no strong
opinions against change.
TabAtkins: I don't think it'll be hard, but I'm happy to let you
chat and make sure.
gregwhitworth: I'll let you know in the week.
TabAtkins: Tentatively we combine identical units and resolve all
numeric and multiplication and division by numbers.
* fantasai thinks collecting feedback from authors is pretty
important here
Rewrote grammar in terms of the Value Definition Syntax
=======================================================
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Mar/0254.html
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Mar/0267.html
TabAtkins: We only had a few instances in the appendix for CSS.
Selectors was one of the last and I wrote it in terms
of syntax tokens. I had one small edit from Simon. As
best as I can tell the grammar is now correct.
Otherwise, this is a review request to make sure I
didn't mess anything up.
TabAtkins: Unless there's comments I don't have anything further.
fantasai: We need a big warning that if this is inconsistent with
previous grammar, please send an issue because it's
probably wrong.
TabAtkins: Happy to do that.
<dbaron> yes, fantasai's suggestion of a warning is good
ch unit definition
==================
<astearns> https://hg.csswg.org/drafts/diff/398d30b81c76/css-values/Overview.bs
astearns: There was a change. ^
astearns: We just need a resolution on if the change is good.
<dbaron> did you check https://wiki.csswg.org/spec/property-dependencies ?
fantasai: There were two change sets. We're comparing the first
sentence, in red, to the text in green. The second
sentence in red wasn't there before.
fantasai: We said the fallback is .5em and we changed that to
account for when text orientation is upright and you're
vertical the height should be 1em.
Florian: I'm in favor.
dbaron: Did you check property dependencies wiki?
Florian: I believe FF already does this.
fantasai: To the extent we have units that depend on font
information, those units will depend on features that
effect font, such as text-orientation. That's regardless
of the change.
dbaron: I think that's true, but we need to edit the wiki. I guess
I should do that now.
dbaron: I think this is the...it should be a fourth line in the
type-based dependencies.
Florian: I don't know if FF falls back to 1em in upright, but it
uses the vertical metric in upright when available. In
terms of dependency it seems about the same.
dbaron: I think it's okay, it does need to be considered.
fantasai: I was going by text orientation already effects font.
fantasai: Regardless of this change, if we have a problem, we
already had it.
<dbaron> wiki updated
astearns: So dbaron will update dependencies wiki. Any other
comments? Objections?
RESOLVED: Accept this change:
https://hg.csswg.org/drafts/diff/398d30b81c76/css-values/Overview.bs
Florian: Koji didn't like it, but wasn't willing to block, for the
record.
Define <length-percentage> etc. productions
===========================================
fantasai: I was looking for the resolution where we decided to
merge these into a single type, so we do need a
resolution. There's one concern where we discussed
adding keywords to calc() and if we're doing that, the
point was to create a value type that was everything in
calc() and we can't do that with a bunch of keywords.
fantasai: That makes me question if it's necessary to have this
production.
TabAtkins: It's not always valuable. I think we...we eliminated
the cases where a separate <length> wasn't combine-able.
<fantasai> <length> | <percentage>
fantasai: If you have <length> or <percentage> in the grammar it
should always combine.
TabAtkins: I think that's now true. One of the motivating examples
was something we fixed. I think it makes our grammars
more readable.
fantasai: We can't extend this to include keywords which at some
point will be combinable.
TabAtkins: I'm willing to take on that burden when we hit it. We
can say it takes values from this property plus <length>
and <percentage>.
fantasai: I'm fine if this is a syntactic shorthand it's fine.
TabAtkins: So far there's no semantic difference. In theory would
could create something that's a percentage and number
and not combinable, but that's not recommended in our
rules for percentages.
<gregwhitworth> what keywords are we referring to?
<gregwhitworth> or are they hypothetical?
astearns: [read gregwhitworth question]
fantasai: There's been requests to allow calc() to combine with
auto and things like that and it's reasonable that we
will at some point allow that.
<gregwhitworth> oh, ok
<gregwhitworth> interesting
fantasai: That will allow us to have computed values and let us
animate from 0 to auto which people want.
<dbaron> (similar for min-content, max-content, etc.)
fantasai: Right now it's <length> and <percentage> and combo there
of, but I don't expect that restriction to hold in the
future. To simplify grammar I don't mind. To have a pre-
combined <length-percentage> I don't mind.
<fantasai> <length-percentage> = <length> | <percentage>
fantasai: I should be length and percentage 100% is = length.
TabAtkins: If you say <length> and <percentage> separate you need
prose so they use the same 0 base. <length-percentage>
assumes that, but says they'll be defined so combinable.
fantasai: I want it just to be a syntactic shortcut. We should
just have it just as defined as grammatical. It needs to
be defined for <length> or <percentage> or
<length-percentage>.
TabAtkins: If we ever defined something where they're not
reliable, we shouldn't do that. It's a distinction
without a difference. Your situation is identical to
mine. Only if we really mess up will they become
distinct.
<dbaron> (worth minuting that fantasai and TabAtkins both agree we
should never have percentage and length in a property and
have them not compatible)
TabAtkins: Back to the topic. Are there objections to making a
resolution?
astearns: fantasai you're fine?
fantasai: As long as it's a short way of writing things, yes.
TabAtkins: That's how defined in the spec.
astearns: Yes, I agree with dbaron. We should never have
percentage and length in a property and have them not
compatible
<fantasai> ACTION: fantasai clarify the thing dbaron wrote above
in the spec
<trackbot> Created ACTION-761
RESOLVED: Accept change for issue #5 of Values and Unit 3
(https://drafts.csswg.org/css-values-3/issues-cr-2015#issue-5)
TabAtkins: We made that mistake for position where they're not
combinable.
fantasai: Technically they are.
TabAtkins: They can't be a single unit until layout time. You
can't say here's two amounts in px...
astearns: This isn't the issue we're discussing.
Using the Snapshot to track pre-CR "shipping is okay" features
==============================================================
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Mar/0303.html
TabAtkins: We should.
astearns: I agree.
gregwhitworth: How come we aren't adding this to 2016.
<SteveZ> +1
fantasai: It's a bunch of definitions added in 2015. It's fixing
2015 doc.
TabAtkins: Why don't we publish this under 2016 because it's 2016?
fantasai: I see this as a correction to the previous snapshot.
These were taken in 2015 and not documented. For 2016 we
might add additional things. I want to distinguish. If I
made a typo in 2015 I'd fix it. This is equivalent.
<dauwhe> EPUB 3.1 will likely be referencing the 2015 snapshot
TabAtkins: I understand the theory. Practically it's 2016 so we
should publish 2016. If you want to correct 2015, go
ahead. But let's publish 2016 which is 2015+changes.
fantasai: We haven't added anything new.
TabAtkins: We have. This thing. It is the year 2016. There are
changes. Let's make it part of 2016. Let's not tie
ourselves into semantic knots.
astearns: I disagree it's a semantic knot. These should have been
in 2015 so let's fix. WE should also pub 2016.
TabAtkins: Fine. But let's publish 2016. As soon as we're aware we
should touch the snapshot we should do a new year.
fantasai: There's nothing to add to the 2015.
<SteveZ> i agree that we should be publishing a 2016 and updating
2015 for the reasons Tab is expositing.
TabAtkins: I'd like to publish to put a new date on it. If people
get used to year, they should be looking at the current
year. If it's the past year it feels obsolete.
fantasai: It's Q1 of 2016.
TabAtkins: I will publish 2016 for you. We can get it done and
update as needed. It's just there to help people. And
it helps people know it's up to date.
astearns: But if we publish in both we have a doc that looks up to
date, but no different.
TabAtkins: But it is up to date. It's the current date. There's no
confusion about "it's 2016, but why am I looking at
2015". It's the problem with dated URLs. They see
something old in the URL and don't know why they're
looking.
astearns: [reads dauwhe comment "EPUB 3.1 will likely be
referencing the 2015 snapshot"]
astearns: You don't care if it's 2015 or 2016, TabAtkins, but I
think we should put them in both and I don't care if we
have 2016 just yet.
TabAtkins: So our desires are congruent. fantasai seems to
actively not want 2016. Unless that's an objection,
let's publish both.
dauwhe: I'd like to see a change section in 2016 saying no changes.
fantasai: That's going to be confusing. 2016 will have a lot of
changes, but we'll publish one saying no changes and
then we'll make changes. That won't have the same impact
as the same.
TabAtkins: I don't think public impact is important. It's useful
to say what's stable.
fantasai: Most of our drafts are at least a year old. I don't see
this as a problem.
gregwhitworth: I wanted to bring up why I brought this up. I
brought it up, and I'm cool with it in 2015, is
because it felt like we were pulling teeth for 2015
and we keep 2016 as a wiki and at the end of the
year we shout from the rooftops what we did in 2016
and that'll be the snapshot. Basically have it as a
wiki and at the end of the year we'll link to it.
TabAtkins: Thumbs up.
<TabAtkins> I agree with Steve too
SteveZ: I wanted to say I think every snapshot should have a
"what's new in 20xx" section. If you do that you don't
have to put anything in it right now, that's consistent
with wiki. Then anyone can look and see what's new. That's
consistent with what we've done with drafts.
fantasai: It's inconsistent with new levels of a draft. We don't
do a level 4 until we have something to put in.
TabAtkins: We do that because drafts aren't dated. They represent
functionality. Snapshot is the state at this time. The
2015 is what the state is in 2015. There's semantic
value in the name. How much are you arguing that you
object to the 2016 snapshot publishing?
fantasai: I have a strong preference that we don't.
astearns: I'd suggest that we put these changes in the 2015
snapshot and start a 2016 wiki and we publish it at the
end of the year using the wiki as a guide.
Florian: Why not a ED?
fantasai: I'm happy with just an ED
TabAtkins: An ED is the same as a wiki for the editors.
fantasai: And easier.
astearns: I agree.
<Bert> +1
astearns: So, proposal: we put the edits in 2015 snapshot and
start an ED for 2016 snapshot. Objections?
fantasai: Sounds good to me. Can we also resolve to republishing
2015 after the edits.
RESOLVED: Add edits to 2015 snapshot and then republish.
RESOLVED: Start an ED for 2016 snapshot.
Shortening minimum/maximum to min/max
=====================================
astearns: Rossen said it was okay but they shipped minimum/maximum.
I'm okay
<fantasai> It's easier to type also
TabAtkins: I'm okay [missed]
astearns: We use them in property names, but also in values.
TabAtkins: Also in property values with min-content.
astearns: So does anyone object to this change?
RESOLVED: shorten minimum/maximum to min/max in exclusions values
MQ issues
=========
Transition to CR
----------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0047.html
Florian: I'll start with the last point...We're doing this to head
to CR and put the less stable things into level 5. THe
point is to solve these issues or decide they should be
pushed to level 5.
Florian: Is there a problem with this approach?
fantasai: I'm in favor. Our goal should be to have CR ready over
the summer.
Florian: Yes.
Florian: I don't have a lot of free time right now. If I did we
could have LC worthy by F2F.
<dbaron> I'm happy with that too, as long as the grammar changes
(allowing and/or more and parens more) are in 4 :-)
hover: on-demand
----------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0041.html
Florian: Hover lets you check if the primary pointing device can
hover.
Florian: There is hover: none which says you can't. There's a
value that says you can.
Florian: There's on-demand which says you can hover, but it takes
some effort. So if you're on a phone and have to long-
press.
Florian: There's multiple questions. If we do keep this, should it
be in the boolean? so on-demand and none are grouped.
Florian: Other question is do we need on-demand and we don't hover
if impossible or difficult? I think gregwhitworth and I
say not needed. TabAtkins disagrees. TabAtkins, can you
explain the other side?
TabAtkins: It was low value, but there are cases where a hover
interface is possible, but not as convenient and it's
still reasonable to target those with hover at times.
If you'd rather just do hover or not, it's not a huge
loss.
<dbaron> could the feature be split into two features?
gregwhitworth: Do you guys have use cases for these MQ in general?
gregwhitworth: Where the demand is coming from? Are you seeing a
lot of requests?
TabAtkins: Hover is easy. People do sophisticated attempts at
device detections to know if people can hover. That's
spread everywhere.
Florian: And it's much better to have hover MQ then doing a query
for device size.
gregwhitworth: Cool, thanks.
fantasai: I think this and pointer accuracy are sure critical for
distinguishing between mobile and not. Like you have
tablets with large screen the same size as a laptop.
TabAtkins: Physically you can't distinguish anymore.
smfr: I'd prefer not to have on-demand hover because in iOS it's
pretty special and magic. I'd prefer not to have it because
I don't think it'll express what we're doing correctly.
Florian: So remove the on-demand and clarify none means impossible
or inconvenient.
<smfr> sounds good
TabAtkins: And hover is when it's an easy and natural part of the
interface.
Florian: I think that was the original, yes.
astearns: [reads dbaron IRC "could the feature be split into two
features?"]
dbaron: I think the later discussion makes that irrelevant.
astearns: Objections to removing on-demand value?
RESOLVED: Remove the on-demand value from hover.
light-level and a11y
--------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0046.html
Florian: You can detect if it's too bright or too dim to see
anything by your screen and light level.
Florian: It has dim, normal, and washed. There's also a note
saying types of adjustments to cope with washed are
similar to the type done for a11y reasons. People with
low vision like increasing contrasts and font sizes.
Florian: For example people with dyslexia like large font and
reduced contrast. So it says that the UA may allow the
user to trigger this manually.
Florian: A couple of people have said they want this remark
removed. Probably because we should have a dedicated MQ
for that so people shouldn't abuse this one. My take is
we should have dedicated MQ, but I think it's a good
opportunity when we have a feature that serves both
purposes because when we make dedicated a11y features
they're not used.
Florian: It doesn't prevent us from having the dedicated one for
people that do a good job on a11y.
smfr: This always comes up...I think it's the responsibility of
the OS to deal with different light conditions. I don't
think we should have light-level MQ.
Florian: The feature entirely?
smfr: Yes.
Florian: So how do you do your GPS inverting screen at night?
smfr: We have a feature in iOS that detects and adjusts. We also
have a11y features that do things. If the OS has that
functionality and the page does, they can interact poorly.
It's better if it's just the OS.
Florian: I don't think any OS does screen inversion.
fantasai: I think this feature needs more discussion and therefore
should be deferred to the next level.
<gregwhitworth> I agree with fantasai here.
astearns: I agree. Is that okay Florian?
Florian: I'm a bit surprised at the push-back because it's been
there a while, but if there is a big discussion okay, I
guess.
astearns: I'm a bit surprised too. It would have been good to have
this on the mailing list. But let's resolve to push this
to the next level.
Florian: Yeah.
TabAtkins: I'm fine.
RESOLVED: Move light-level to the next level of Media Queries
astearns: Thanks everyone.
Received on Wednesday, 23 March 2016 23:36:51 UTC