- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Dec 2016 23:04:15 +0300
- 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.
=========================================
Scheduling
----------
- It is still undecided if there will be a meeting next week.
- A location is being sought for to host a summer F2F in Europe.
There's also a doodle for members to add availability
information.
Relative URL resolution in var() references
-------------------------------------------
- RESOLVED: No change in current custom properties for issue #757.
Need to solve this issue with future work.
'>>' and '>>>' should be a token
--------------------------------
- RESOLVED: We drop the implicit requirement that selectors
parsing remains LR1 and as a consequence we remove
specialized selectors from the syntax and replace
accordingly.
Consider making device-pixel-ratio a standard alias
---------------------------------------------------
- RESOLVED: Do not add device-pixel-ratio unprefixed.
- It was left undecided if -webkit-device-pixel-ratio should be
defined in the Media Queries spec. Several people had no wish
to define it since it's an alias to the resolution media
query, but there was concern that that's compatibility hostile
since currently you need -webkit-device-pixel-ratio to be
web compatible.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Dec/0053.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Bert Bos
Tantek Çelik
Alex Critchfield
Simon Fraser
Daniel Glazman
Tony Graham
Brad Kemper
Dael Jackson
Chris Lilley
Peter Linss
Myles Maxfield
Michael Miller
Rachel Nabors
Simon Pieters
Anton Prowse
Liam Quin
Matt Rakow
Melanie Richards
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Majid Valipour
Lea Verou
Steve Zilles
Regrets:
David Baron
David Cramer
Elika Etemad
Vladimir Levantovsky
Scheduling
----------
astearns: Let's start. I've heard a couple people are not
available next week
astearns: Is there anyone that could come and wants a meeting next
week?
* Bert won't be here next week
Florian: I could come.
gsnedders: I'm the same.
astearns: Other opinions?
jensimmons: I can make it
glazou: I'm unlikely be be available.
astearns: Alright. We will see I think. It sounds there will be a
bunch of people out. We definitely won't have the 28th.
If we don't have a call next week there will prob be
enough for a Jan 4.
gsnedders: Assuming people are around.
astearns: mmm....true. People will have had time to recover, I
think.
[discussion on webex problems]
astearns: Other scheduling topic was if we can have a meeting in
the summer.
astearns: fantasai put up a doodle.
<astearns> doodle for summer meeting http://doodle.com/poll/n7dg3i2hmuvzagws
astearns: I expect there will be enough business that it would be
useful. I don't know if anyone could host. Europe makes
sense for location.
astearns: If anyone has a European location please get a hold of
Rossen or me. Please put your availability in the doodle
so we can see if there's a time that would work.
<Bert> (I'd be happy to host. Meeting rooms enough. Hotels may be
expensive in that period...)
jensimmons: I live in NYC but I'm sure I could get Mozilla in
Paris or London.
Florian: Paris is beautiful.
gsnedders: New London is small. I'm not sure there's space there.
Rossen: Also W3C hosting in Sophia something we can explore.
Bert: Yes, the rooms here are all available. The advantage is
you're on the cost. You have to book a hotel early, it's
high season. I'm happy to host.
Rossen: Sounds great. We'd be happy to be hosted.
<gsnedders> I could potentially help to arrange something around
Scotland, but don't have hte funding to pay.
astearns: Let's plan on if and when and where we'll have a meeting
in the summer when we meet in Seattle.
glazou: One thing about Sophia in the summer if you mean July and
August it's extremely painful to drive there. It's a
gigantic traffic jam. If you remember last time we were
there in summer it took us an hour to get to dinner.
glazou: So end of June is waaayyy better there.
Rossen: That's really good input
Florian: jensimmons if you can check on Mozilla availability it
could be useful. And then we weigh in Seattle.
Relative URL resolution in var() references
-------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/757
TabAtkins: I wasn't around last week.
TabAtkins: I'm not sure...is frremy on?
frremy: I am
TabAtkins: mmkay. Can you summarize why you think my solution
won't work?
frremy: I think there are 2 reasons. First you need to spec the
URL in a property that only contains the URL which will be
a pain. Even if you could do something like background
you'd have to create your own syntax and that will change
over time.
frremy: Second is if you look at the way yours works it resolves
at computation time and I don't think we want to replace
with computed because we resolve before the computed time.
It assumes if you have time it brings them at computation
time.
frremy: I think that's why if it makes sense.
TabAtkins: That we can't do complex properties in level 1 of
Houdini is true of everything. That's a limitation of
living in level 1. We'll aim to relax that in the
future as we get more of a handle on it. Houdini should
reproduce everything CSS does eventually. It's not a
URL specific problem.
TabAtkins: Computation is more interesting. Your example of a
custom property of 1em being used in a font size...I
think that's invalid because you introduced another
chain. URLs just resolve on the sheet they're in. It's
not the same deal. Dependencies aren't ever cyclical.
Which style sheet it's in matters.
TabAtkins: That's what people are asking for.
frremy: I don't think the solution is a fix. It seems like it
would be a custom thing for only URLs. I checked in Edge
and Chrome and they don't support custom URLs. I don't see
why we wouldn't fix it the right way.
frremy: It seems like we need to fix it so let's fix it.
TabAtkins: Your solution of look for things like URLs and keeping
the information around doesn't work. There are several
functions that use URLs and they carry them around as
just strings. That means you have to track every string
as well.
frremy: No, if you think about strings I don't want to resolve
that. It's based on the token that's URL or image. A
string is a string. If you want to define a URL or image
this is where you resolve.
TabAtkins: Or any future functions.
frremy: Yep. You resolve the image or url, not the string. Keeping
source for string doesn't make sense.
leaverou: If we're adding new URL function would it help to accept
a second argument as the base that would accept a custom
origin?
TabAtkins: I think that's straight up a useful feature.
<ChrisL> yes, we need better control of the base to resolve against
TabAtkins: It doesn't directly address the issue. If you have an
untyped custom prop with a URL it doesn't know it's a
URL unless we go with pretend typing.
Florian: If you specify the origin as CSS origin it doesn't solve
the problem?
TabAtkins: Right.
leaverou: You could have a custom prop with its own origin and set
it as it's own origin. It's hacky.
Rossen: It's a good thing to keep the relative things relative.
You would have to deal with the case where you spec the
base.
leaverou: Is frremy implementable?
ChrisL: It doesn't sound it. We'd need a URL function that would
allow the base so that people can control that. We need to
support relative and absolute URLs. Duck-typing strings is
a terrible idea.
TabAtkins: Everything works as you expect if it's typed using
Houdini. It's untyped that are causing problems because
we know they're URLs.
astearns: Sounds like we should try to solve frremy problem in the
future but keep the current terrible string URLs in
variables as they are now.
TabAtkins: That's the solution if we do nothing. Which I'm fine
with.
frremy: I think it's a mistake but if this is what we want to do
it's an option.
astearns: Will you object to doing nothing?
frremy: I can't object to doing nothing :D
Rossen: I wouldn't say this is objecting to doing nothing. All
frremy is asking is to keep pursuing a better solution. If
we solve it now or kick it down the road and keep at it,
that's tbd by the group. By ducking our head in the sand
it doesn't mean the problem is gone.
Rossen: I'm not hearing consensus around this is the only way
we'll solve it. I'm hearing what frremy says kinda makes
sense but maybe not the right time.
astearns: And I thought that's what I was expressing. We need to
solve it but won't do so with the L0 custom properties.
leaverou: Perhaps this is another reason to prioritize the
declarative API
Rossen: frremy are you okay with this for now?
frremy: Current behavior isn't working at all. If you think it's
not working and we document it's not working it's fine.
It's just not what I think authors want. If we doc it it's
fine.
Rossen: We document it this way...
frremy: I'm not saying we should put it in a spec. I'm fine
keeping as is.
astearns: As specified the strings should resolve at computation
time and relative URLs will resolve at that point to the
style sheet they're resolved. If that doesn't work in
Chrome or Edge that's a bug.
astearns: The spec says at computation time the URLs will resolve.
Am I wrong?
leaverou: I agree with astearns.
frremy: I don't think it's specified in the spec.
TabAtkins: It is. Once you substitute it into a property that
knows it's a URL it's resolved.
leaverou: Right now it doesn't work in Chrome.
frremy: Same in Edge.
astearns: That they don't work is a bug. That they prob won't
resolve to the expected URL is something we'll fix in
the future
TabAtkins: And we have a solution spec in simple cases. We expect
to address most or all needs as we expand what a typed
custom property can express
astearns: Let's close on this.
RESOLVED: No change in current custom properties for issue #757.
Need to solve this issue with future work.
'>>' and '>>>' should be a token
--------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/712
TabAtkins: For grammar reasons to keep the selector grammar being
a single token look ahead earlier CSS added in special
tokens just for selectors.
TabAtkins: By making them special tokens in the CSS we needed
special selectors with one look ahead. We introduced >>
and >>> combinators.
TabAtkins: And these are under the same issues. If we want
selectors as one token of look ahead we need to make >>
and >>> a single token in syntax
TabAtkins: Question is, is LR1 in selector syntax important to
maintain. If it is I can modify for specialized tokens.
If not I'll avoid doing so and we can try and remove
special syntax. This would make selectors LR3. It would
simplify things because we won't have selectors only
tokens.
TabAtkins: Other benefit as dbaron pointed out, specialized tokens
mess with grammar. Having these extra tokens can have
similar problems to the unicode issue. Do impl still
think maintaining selectors as one look ahead is
important?
<TabAtkins> unicode issue = "u+a { color: blue; }" was invalid,
because the selector part parsed as a unicode-range
token, while "u + a { color: blue; }" was valid. This
is confusing.
glazou: First, personally, I think either solution is fine. I want
to give a user specific tale. I read the issue in detail
on github. Most people never noticed you can add a comment
between : and class selector. Most are unaware that if you
have two combinators you can have a comment in between.
From a user prospective these kind of controls are really
complete. You can't divide into pieces.
glazou: The attribute selectors between the name and the value the
|= can't divide into two pieces. Whatever is best for
implementors would be fine for me.
TabAtkins: I agree. The details of where you can put comments it
are just random and arbitrary. This is just a what is
easiest for implementor issue. I agree.
TabAtkins: If people need to consult and come back later I'm fine
with that. We need a decision at some paint.
Rossen: On our end I don't believe it will be a big deal. Did you
guys have a solution or experiment in Chrome?
TabAtkins: Ours is fine. We have it a separate tokens. You can do
>>> with comment in between. It's if it should be
allowed.
Rossen: I don't believe the complexity will be there. I think
we'll be fine.
glazou: I just thought about a case. a>b>c and you remove the b.
glazou: Suddenly the whole thing is something else. Is it
something we want? I'm not against it but we should
consider. Removing the b changes the behavior.
TabAtkins: That's a weird thing to do. Hopefully it's a typo and
you notice.
glazou: All types of weird things happen in style sheets.
Rossen: I think the case from glazou is the editing scenario and
you're typing and you could get weird behavior with a typo.
TabAtkins: In editing if you leave white space in the place of the
b it's not valid. It's only if you remove all which
space it because valid.
<liam> [ this comes up if you comment out the b too, e.g. for
testing ]
Rossen: Sure. Let's not debate. It's reasonable to expect you may
run into it. Let's just put it on the record.
<leaverou> Question: Does this affect the Houdini Parsing API as
well? If so, having it as a series of child combinators
decreases usability for developers.
astearns: leaverou had IRC question. [reads]
TabAtkins: It does not effect Houdini. We're not exposing weird
selector tokens. They're all exposed as just a string.
leaverou: Houdini doesn't parse selectors?
TabAtkins: As far as Houdini APIs are concerned you won't see a
difference.
leaverou: This is just internals?
TabAtkins: Yeah.
TabAtkins: From Houdini side we removed those weird tokens.
TabAtkins: Chrome is okay with separated tokens. Sounds like MS is
okay. Do we want to resolve, see if Mozilla has an
opinion?
astearns: dbaron commented in the thread, but I don't think I see
an opinion there.
<glazou> https://github.com/w3c/csswg-drafts/issues/712#issuecomment-264568190
TabAtkins: He said adding more tokens was bad with the unicode
range issue I mentioned. Well, potentially problematic.
TabAtkins: He also pointed out in this exact case it wouldn't make
selectors not LR1, but if I go to where I want and
throw away the old tokens it would make selectors LR3
or at least 2.
astearns: Two options. Resolve today and see if anyone complains.
Or we wait for more input.
astearns: I'd be happy resolving today.
TabAtkins: They're easy changes to make.
glazou: If it helps we could also reverse the question. Do we want
to allow comments between the > signs in these
combinators. If the answer is no it gives a direction
Florian: I think we don't care. We care about consequences of
impl, but don't care about the comments.
TabAtkins: Yeah. Comments is already weird.
Rossen: I'm in favor of progress. Resolve and move on. The problem
will clearly come back.
TabAtkins: Proposed resolution: We drop the implicit requirement
that selectors parsing becomes LR1 and as a consequence
we remove specialized selectors from the syntax and
replace accordingly
astearns: Objections?
Florian: Do you mean becomes?
Florian: I'm only asking about resolution phrasing.
Florian: Just replace becomes with remains for the resolution.
glazou: Yes. I agree with the proposal
RESOLVED: We drop the implicit requirement that selectors parsing
remains LR1 and as a consequence we remove specialized
selectors from the syntax and replace accordingly.
<TabAtkins> (We still maintain the implicit requirement that
Selectors syntax, like CSS parsing in general, should
be a small finite amount of lookahead, of course. Just
drop the strict requirement that it be LR(1),
specifically.)
Consider making device-pixel-ratio a standard alias
---------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/417
Florian: Three parts. We have a MQ called resolution. It used to
be -webkit-device-pixel-ratio. webkit name is common
enough that non-webkit implementors are implementing.
Compact spec documents this.
<zcorpan> https://compat.spec.whatwg.org/
Florian: Q1: Are we happy that this is only in compact spec or,
given that it's implemented by all browsers should we
inline into MQ spec?
Florian: I think we can resolve on that first.
TabAtkins: I'm for pulling into the full spec. We put it in a
compat appendix and document in a core spec.
<MaRakow> seems fine
Florian: That would be my favorite thing to do.
Rossen: Moving to a different spec means we'll pursue [missed]
Florian: I'm not talking about device adaptation. The MQ spec.
There's a compat spec that lists things that need to be
prefixed.
Rossen: What I'm saying is you won't take the prefix and put it in
the MQ and say implement as the
-webkit-device-pixel-ratio. But also un-prefixing it.
Florian: That's Q2.
Rossen: The resolution on Q1 weighs on Q2. If it's only about
quirking and keeping up with that I'd prefer to keep it
just in that spec. If we're evolving it would be good to
pursue.
<zcorpan> quirks spec and compat spec are different specs :-)
Florian: This is a feature we have under a different name.
astearns: We have it under a different name and the
-webkit-device-pixel-ratio so it's compat not quirk.
Rossen: We called compat quirks
Florian: It's not the same thing.
zcorpan: Quirks is things browsers have in their quirks. This is
in all rendering modes so not a quirk.
Rossen: Let's talk in compat. So adopt this and keep it moving
forward or leave as is?
Florian: Given this is an alternative name for an existing
behavior that everyone has to impl we should put it in
the spec.
MaRakow: Do we have precedent? I think we should keep as if it's
it's the same.
Florian: People who do compat remove it from there if it goes
mainstream.
MaRakow: Then I'm happy both ways.
Rossen: If we're not doing anything except put it in or spec
what's the point? If we're planning on changing then let's
move. That's why the decision of where to put it weighs on
this.
Florian: So part 2. Even if we don't resolve on doing anything
other then adding it, if you impl MQ it's not sufficient
to just use resolution. You must also do
-webkit-device-pixel-ratio. So they belong in the same
place.
smfr: They're not the same. There's difference in zoom.
Florian: They are. There's a difference between safari and
everybody else. Everybody else treats them the same, but
safari and everyone else doesn't do the same. Within each
browser the names are consistent.
smfr: I think authors using -webkit-device-pixel-ratio are IDing
the iOS behavior. Since there's not software zoom on iOS
it's the same as resolution but on mac desktop it's not the
same.
Florian: The standard name behavior on safari is the same. You
treat both standard and non-standard the same. Which is a
spec violation of resolution. If we should match safari
is a relevant conversation, but there is no browser that
treats the names differently. The two names do the same.
MaRakow: When we implemented -webkit-device-pixel-ratio it didn't
make a huge interop difference there. But there were
cases with a ratio of 2 there was a difference. There may
be benefit of specing it with a note to rec preferring 2.
We didn't see issue with it being an alias of resolution.
Florian: We've touched on all the points including the extra one
if people should match safari.
smfr: Webkit will impl resolution MQ as specified and if we do
that there's little pressure to unprefix. We're okay with
the difference on software zoom. I think
-webkit-device-pixel-ratio should be historical.
<MaRakow> +1 to smfr
Florian: Mozilla while implementing -webkit-device-pixel-ratio
felt uncomfortable when the standard name wasn't the same
thing. So they wanted to add device-pixel-ratio. I don't
think that helps anyone.
MaRakow: I agree. It's a historical property.
Rossen: And keep it in the compat spec. Agreed.
Florian: So we seem to have easy agreement to not add unprefixed
device-pixel-ratio to any spec.
Florian: It's not in any browser.
Rossen: Not in compat spec?
Florian: Unprefixed is no where.
Rossen: Oh, sorry.
astearns: So who in Mozilla wanted to add the unprefixed?
Florian: Someone with a github name I can't parse.
MaRakow: dbaron mentioned it last time we talked. I think he felt
uncomfortable adding prefixed without an unprefixed. I
think he said it was unpleasant but didn't disagree.
astearns: Objections to resolving not to add device-pixel-ratio
(unprefixed)?
RESOLVED: Do not add device-pixel-ratio unprefixed
Florian: The remaining questions are tied. Do we want to
acknowledge the existence of the prefixed version. If we
want to pretend it doesn't exist we're fine. If we want
to inline we have to agree on what it does. Do we want to
leave it to the compat spec or is a CSS thing everyone
has to impl?
Rossen: We would prefer to leave it in the compat spec.
Florian: That seems compat hostile.
Rossen: I don't believe compat under-specifies.
Florian: It doesn't say what it does.
<zcorpan> Florian you can file an issue on the compat spec
myles: Then why not change the compat spec?
Florian: We don't maintain it.
myles: That makes sense.
Florian: Maybe my test is wrong, but from my testing...in all
browsers neither resolution not
-webkit-device-pixel-ratio are affected by pinch zoom. In
all except safari both are affected by page. In safari
neither are affected by page zooming. So browsers agree
both names mean the same thing.
astearns: Would it make sense to file an issue on the compat spec
to say -webkit-device-pixel-ratio is an alias of
resolution?
Florian: That's what they say.
astearns: So resolution is defined in our spec. If it just says
they're aliases no matter what spec it's in doesn't much
matter.
Florian: I thought I heard smfr say is they're willing to fix
their implementation of resolution to match the spec, but
not -webkit-device-pixel-ratio and therefore they'll be
similar but not same.
smfr: We don't have a final decision, but that's my preference.
Florian: Not my preferred solution, but...
astearns: We're at top of hour and I'm not hearing consensus.
Florian: Here's a proposed way forward. With this resolution I can
close the issue. Currently the spec is clear these names
do the same and safari is buggy. If safari wishes to
change it can. Or it can file a bug on the spec. They're
defined as an alias. If they wish that to change they can
also file a bug.
Florian: It seems safari hasn't made up their mind so we can't
discuss it effectively for not.
astearns: I think that's a good summary. We'll see for next week.
I'll see if there's enough agenda items and if people
will be around.
Received on Wednesday, 14 December 2016 20:05:21 UTC