- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 May 2017 20:12:38 -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.
=========================================
Spec Rec
--------
- RESOLVED: Request PR for Writing Modes.
How does 'inherit' keyword behave in a child of ::first-line?
-------------------------------------------------------------
- Those who had done a review generally thought the proposal
sounded sane, but conversation will continue on github to
handle specifics and get more opinions.
Media Queries 4
---------------
- RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/841
no change.
- RESOLVED: Mark the various hover and pointer things as at-risk.
- RESOLVED: Push scripting MQ values to L5.
- RESOLVED: New WD of MQ4.
Better terminology for ~ sibling combinator?
--------------------------------------------
- RESOLVED: Change the title to subsequent. (In reference to
better terminology for ~ sibling combinator:
https://github.com/w3c/csswg-drafts/issues/1382 )
- RESOLVED: Request PR on Selectors 3.
Scroll Snap
-----------
- RESOLVED: Accept the spec text proposed in
https://github.com/w3c/csswg-drafts/issues/1084
- There will be a request for publication next week.
FPWD for level 4 CSS Overflow
-----------------------------
- RESOLVED: FPWD of Overflow 4
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017May/0031.html
Present:
Rossen Atanassov
Tab Atkins
Tantek Çelik
Benjamin De Cock
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Myles Maxfield
Michael Miller
Anton Prowse
Liam Quin
Matt Rakow
Melanie Richards
Florian Rivoal
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Regrets:
Rachel Andrew
David Baron
Dave Cramer
Bert Bos
Robert Flack
Daniel Glazman
Chris Lilley
Jen Simmons
Lea Verou
Scribe: dael
astearns: Let's get started.
astearns: Any extra items?
Spec Rec
========
astearns: Writing modes.
astearns: I think we're ready for PR.
astearns: One of the last edits went in. Only thing I'm aware of
is to fix a URL which is publishing a document to be at
a URL I think.
astearns: We don't have Bert or Chris on the call. I do see liam.
astearns: Do we need to do anything else before PR?
Florian: Is change section up to date & DoC and everything.
astearns: Changes has everything. DoC is up to date. We've
responded to all comments. We have impl report.
liam: Have we met the exit criteria?
astearns: Yes. Impl report shows we have enough passing tests and
explains where things aren't working.
astearns: All changes since last CR was editorial.
astearns: As I understand we don't need another CR.
liam: Dropped features were at risk?
astearns: Yes, and mentioned in changes.
liam: Then we just need a record of a request of PR.
astearns: Objections to asking for PR transition for writing modes?
RESOLVED: Request PR for writing modes
<Rossen> Congrats!!
<dauwhe> hooray!
astearns: liam can you handle this?
liam: Officially it'll have to be Bert or ChrisL.
astearns: Great. I'll ask which of them can handle it since they
couldn't be on the call.
astearns: Fonts.
astearns: myles is there an update on tests?
myles: I reviewed them. Chris did pull to get them in.
gsnedders: There's a new pull request.
myles: I reviewed 2 yesterday. There's one from today I haven't
looked at.
astearns: Sounds like progress is being made.
astearns: Only last is I'll add 2.1 to the things being tracked.
astearns: Next thing we need on 2.1 is Bert to make some edits.
How does 'inherit' keyword behave in a child of ::first-line?
=============================================================
github topic:
https://github.com/w3c/csswg-drafts/issues/1097#issuecomment-300553985
fremy: We added this last week and people needed more time to
review.
fremy: Did people review?
Florian: I did not.
astearns: Looks like you added the summary which is great.
astearns: Is it just Florian that needs to look?
<TabAtkins> I haven't reviewed it, but now that Elika and I have
thought more about ::first-line this week, we should
be able to understand it better now.
Florian: I don't think so. Reason I need to look is to see if it
will scale to similar pseudos. That's forward looking.
For now someone else needs to check.
fantasai: I think...I was looking at proposal with that in mind.
There's parts to the proposal.
fantasai: The part that says if you inherit non-inherited you go
directly to parent is fine.
fantasai: There was some discussion I didn't follow about how
::first-line is text inside a span inside a
::first-line...it didn't make sense. Text inside a span
should inherit from a span and text inside a
::first-line inherits from ::first-line.
fantasai: There was something about how a styled ::first-line
should act like the ::first-line isn't there.
fantasai: There were three variants we need to preserve for things
to work in the same way.
fantasai: One part of proposal was about variables and I don't
have a strong opinion on that. There was concern about
setting display via a variable but has same problem if
you set not via a variable
fantasai: I'm not sure variable behavior in there is necessarily
what we want, but at this point in time it doesn't much
matter. It's a question for as we extend in the future.
We might want variables to work more like normal
inherited then.
fremy: Reason we didn't want variables to work is because
::first-line is more special then fragment. There is
condition that you need to be inline to be ::first-line. We
didn't want to spend too much time figuring this out.
Florian: From birds eye view it seemed sane. I didn't review
details.
fantasai: I suggest we go one by one for the proposal.
astearns: Do we want to continue on GH?
fantasai: I'm okay either way. I want dbaron's opinion on this.
astearns: And dbaron can't be on so I suggest...this transcript
will go into the issue. We can refine in GH and resolve
next week.
fantasai: Sounds good.
astearns: fremy?
fremy: Yes. It just should be done at some point.
astearns: Yeah. There's a few things to hammer out. Getting dbaron
next week. Please @ him on the issue if he's not there.
fremy: He's in the issue.
Media Queries 4
===============
any-hover can't be used to detect mixed hover and non-hover capable
pointers
-------------------------------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/841
<Florian> https://drafts.csswg.org/mediaqueries-4/#any-input
Florian: We have two pairs of media features. hover/any-hover and
pointer/any-pointer
Florian: hover and pointed describe the primary way for
interaction.
Florian: The any variant are for additional peripherals.
Florian: pointer can tell if things point accurately, hover is can
it hover. Generally you should design without relying on
hover or accurate point, but if you can detect that it's
supported feel free to take advantage. Any is for if you
have a bit more granularity.
Florian: Issue being raised is there are scenarios this can't
detect. Example, primary is a mouse but a non-primary
can't hover and you can't detect that.
<tantek> e.g. laptop with touch screen
Florian: I agree that there are non-detectable cases. I disagree
it's useful. If you know there is a thing that cannot
hover, what do you style differently?
Florian: The other argument to not do this is to do this we either
make hover:none and hover media feature be able to exist
at the same time.
Florian: I think there's down sides to make it work and I still
can't see how you would use it. But the person who raised
it feels it's useful.
<tantek> yeah I tend to agree with the problem the issue is
documenting
fantasai: For hover/no hover proposal....
fantasai: I was thinking if you had hover, no hover, and none...if
the things that would possibly have hover if all are
no-hover then you have none.
Florian: So if you just query hover media feature it's supposed to
be true. If one of the values other then none are
true...you're saying no hover is true only if there's a
no hover thing in addition to hover thing and if there's
never a hover thing you query through none?
fantasai: Through hover we only query primary, right?
Florian: Yes. Question is on any-hover.
Florian: When you have a set where some can hover you want to
detect that some can and some can't.
fantasai: Then any-hover would be true. any hover no hover would
be true.
fantasai: But any-hover:hover is false therefore hover:none is
true.
Florian: If we only do it the way it currently works we don't have
to worry about if something is an input. If it can hover
it clearly is one and if it can't it doesn't matter. If
we do this we need to classify things that can hover and
are a media device vs aren't a media device. We have to
classify all sorts of fuzzy things.
Florian: If we exclude keyboards it's kind of bad. If we include
them the MQ will almost always return that you have a
thing that can't hover.
Florian: Overall I think we can tweak to try and expose, but any
way is complicated and I don't see how the author would
use this.
fremy: I think I agree with you. I think we can fix it I don't see
a strong use case and I would be fine resolving we don't
need to fix.
tantek: It's pointless to talk about devices that can never hover
as causing exceptions. I would assume author is thinking
about can the pointing device support hovering. I don't
think if authors are considering this also has a keyboard.
Florian: In general, yes. Quoted use case was if you know among
the ways a user can interact there is one that cannot
hover you shouldn't make any part of UI to hover.
tantek: That's impractical. Every device with hover has a keyboard
since hover was created. I disagree with that statement.
Authors have known for a long time there's an input
modality that doesn't support hover.
<liam> [+1 to Tantek here]
tantek: Existence of some other input modality should not impact
authoring decisions about using hover.
Florian: I think I agree. Where I'm disagreeing with commenter is
if we were to take presence of things that can't hover,
not taking keyboard would be weird.
tantek: The presence of pointing things, not the presence of
things.
<tantek> "presence of things that can't hover" is not useful
<fantasai> A pointing device is one that can spit out x y coords.
Keyboards can't do that in general (unless you've made
them control the cursor somehow)
Florian: How is the presence of things that can point and not
hover more useful? That's the point I don't get.
tantek: This has nothing to do with things that can never hover.
This is pointing inputs that can't or can't hover.
astearns: One of the confusion points is in the comment Patrick
talks about input devices, but clarifies that he's only
talking about pointing devices.
tantek: That's my understanding.
fremy: What can you do differently as an author if you know
there's a device that cannot hover.
fremy: Every windows laptop has a touch screen. What would you do
differently?
Florian: Maybe you may want to do something special for touch
screen + touch pad, but the MQ wouldn't tell you that. It
would just say there's something that cannot hover. You
don't know what it is, just know it can't hover and it's
not the main thing the user uses.
liam: If you know the user has something that doesn't hover you
can't rely on every press having hover pre-light.
Florian: It's not primary way. We'd have an answer on the main way
the user interacts.
liam: Sure, but doesn't matter if it's primary. The user could use
it. It's saying something useful.
<MaRakow> +1 to feature not seeming useful
<tantek> has anyone prototyped any of these?
<tantek> IMO this is a good example of a feature that really ought
to be incubated (prototyped) before we seriously consider
it
<tantek> I really don't want to see browsers waste time
implementing a feature that just makes things worse /
more confusing for authors / users
astearns: Even though the main device is hover capable, the
presence of other non-hover modality makes it a better
idea not to rely. Patrick points out he's happy with it
saying try not to use hover with examples where there
could be problems.
astearns: Sounds to me like using hover affordances is usually a
bad idea. Patrick is okay with the amount of warnings.
I'm not hearing a huge push to add additional capability
for these worse scenarios beyond what we have. Is that
accurate?
tantek: I'd agree.
Florian: I'm trying to find that section. He's happy with that in
addition to what he suggests.
astearns: [reads last comment in issue]
astearns: Given we don't have enthusiasm for designing a new way
of detecting less hover capable devices, I'd be happy to
close as-is and leaving open that we might design
something in the future that has the additional case,
but it should be prototyped. There should be an idea of
the use cases and showing why it will be useful.
tantek: Does that mean leave the feature in?
Florian: any-hover is in the draft and it can take hover or none.
You can detect if nothing is hover capable, but you can't
detect a mix. We're leaving that as-is.
<fantasai> Sounds good to me. We can extend in the direction I
outlined later, too, if we want. :)
astearns: And I understand the draft does have warnings that even
if the MQ says something is hover capable you may not
want to use hover affordances.
tantek: Has anyone impl?
Florian: I think pointer and hover are in Chrome. Maybe just
pointer.
TabAtkins: I think we do both, but not 100% certain.
Florian: can i use says both on Chrome, edge & safari
<tantek> well if we has so many impls, seems like we should be
able to try it out with examples?
astearns: Proposal is leave in draft and close no change.
Objections?
RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/841 no
change.
Rename 'scripting: enabled'
---------------------------
Florian: I just noticed there's one issue on MQ DoC. Other then
that we should do a new draft.
<tantek> yes I'd like to see a new WD published please
Florian: Last issue is fantasai saying scripting-enabled should be
called something else.
<Florian> https://drafts.csswg.org/mediaqueries-4/issues-wd-2016-01-26.html#issue-4
Florian: fantasai do you remember what you wanted this to be
called?
Florian: We discussed, but never concluded. Are you happy with
scripting: enabled | none?
fantasai: I think that's fine.
tantek: I think you're missing a massive use case, headless script
execution.
Florian: That level of granularity was pushed to another level.
tantek: Yeah, okay.
astearns: Sounds like there's agreement.
Florian: Can we resolve current naming is okay?
fantasai: Enabled means if there's any scripting at all it's true,
even if only runs first 10ms?
Florian: Yes. There is scripting support. No fine grained
knowledge of what.
fantasai: Is that clear in description?
<Florian> https://drafts.csswg.org/mediaqueries-4/#scripting
Florian: [reads]
fantasai: That's not sufficiently clear
astearns: [reads more]
fantasai: That's a different question. This is going to flip on
for things that run until onload event.
fantasai: An author won't think about those things. If they
trigger enabled that needs to be super clear. This
script may or may not run, this may only run for first
few ms. It needs to be clearly spec what triggers it for
both impl and developers. THat enabled doesn't mean you
have event support.
Florian: Just because we marked it as at-risk and removed
something doesn't mean what we left behind makes sense.
ACTION Florian clarify the scripting section as per fantasai
description in minutes.
<trackbot> Created ACTION-851
Florian: Did we resolve name is fine?
tantek: I'm curious if having this feature is worth it in level.
Florian: You'd like to push to sort out variants together?
tantek: That's what I'm hearing from the conversation that it may
be needed.
Florian: I think it's a good idea. Enabled value needs to mean a
different thing depending on if loading should exist.
astearns: Is there a value in none even though non-none doesn't
work as expected?
fantasai: Depends on what you're doing. If you're depending on
event support you want to get none. But if you're
depending on if this script will run then it's not
important.
fantasai: I agree with tantek that it's good to have this together
in a level
tantek: What people impl today in none in the static loaded
website. I don't think we need another mechanism for only
none.
Florian: I'm happy to push it all to L5.
Florian: Especially since that's the last issue on L4 and we can
do a last WD.
astearns: Objections to pushing scripting to next L of MQ?
RESOLVED: Pushing scripting MQ values to L5
astearns: Objections to new WD of MQ4?
<fantasai> go for it
<tantek> +1 new WD MQ4
RESOLVED: new WD of MQ4
astearns: That will go for wide review.
<tantek> btw on previous issue, have we marked any-pointer
any-hover at-risk?
<tantek> or are we not doing so because of impls?
Florian: tantek I don't think we need at risk b/c they're
implemented.
tantek: Are they impl the way we want them to be? We don't want to
codify something that would create bad authoring or
confusion.
Florian: Agree. It's the part of the spec I'm least convinced we
did right. If you want to at risk it now that's fine.
tantek: And that communicates to Patrick we hear your concern and
we're making as at risk to keep looking at it.
Florian: Fair.
Florian: Do you want any-* as at risk or also pointer and hover.
tantek: I don't know how to separate.
Florian: I'm okay with that.
tantek: And I think that would support more input from Patrick.
astearns: Do we need a resolution or is that editorial?
Florian: Resolution, please.
astearns: Objections to marking the various hover and pointer
things as at-risk?
RESOLVED: Mark the various hover and pointer things as at-risk.
Better terminology for ~ sibling combinator?
============================================
github topic: https://github.com/w3c/csswg-drafts/issues/1382
astearns: Can we do this without dbaron?
fantasai: So far best suggestion to switch following with
subsequent or any-following-sibling
astearns: any-following-sibling is easier to spell.
fantasai: You'll never type this in code.
astearns: True.
fantasai: dbaron was okay with subsequent.
astearns: Since he did the issue, I'm okay with it as well.
astearns: Objections?
RESOLVED: Change the title to subsequent.
fantasai: There was a substantive change that Chris pointed out.
fantasai: [missed]
fantasai: We do have the tests and the passes and the impl report
is a test that tests all the things.
astearns: Everything in the spec, or just this change?
fantasai: Just this change.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5188
fantasai: test^
fantasai: If you do the right thing it passes.
<fantasai> passes in Chrome and Firefox
astearns: Sounds like we should put that change in, get the tiny
impl report, and ask for PR.
fantasai: I think impl would be a link to this test case and
statement FF and Chrome pass.
astearns: There's a thread on this for the private list we can
propose inlining and ask ChrisL. I suspect we'll have to
say what browsers don't pass.
astearns: Objections to asking for PR on this edited REC with this
one change.
RESOLVED: Request PR on this spec.
Scroll Snap
===========
github topic: https://github.com/w3c/csswg-drafts/issues/1084
astearns: Looking for WG approval for this change.
astearns: Objections?
RESOLVED: Accept the spec text proposed in
https://github.com/w3c/csswg-drafts/issues/1084
astearns: This was CR before, we're republishing CR. We have a
good changes section?
<fantasai> "https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-scroll-snap-1
fantasai: Here's issues ^
astearns: DoC?
fantasai: I think this should do, but I can use the link to the GH.
fantasai: I do need to update changes section.
astearns: Why don't you update the changes section and we'll put
the publication next week.
FPWD for level 4 CSS Overflow
=============================
github topic: https://github.com/w3c/csswg-drafts/issues/1374
astearns: Is it correct that everything in 4 way already in 3?
Florian: Correct. No new features.
astearns: Any objections to FPWD of Overflow 4?
RESOLVED: FPWD of Overflow 4
Florian: I'll also make sure any L3 edits are reflected in L4.
fantasai: I'd recommend just dropping those sections.
Florian: That's better.
astearns: We don't have time for the last item, so we'll end a
minute early.
astearns: Thanks everybody.
Received on Thursday, 18 May 2017 00:13:44 UTC