- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Oct 2017 20:25:10 -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 Next Steps
-------------------
- There is a request to add needed tests to the flexbox test suite.
CSSOM View
----------
- There is a need to find out from implementors if they want to
standardize on Element.focus() and, if yes, on what.
- The two behavior options are detailed here:
https://github.com/w3c/csswg-drafts/pull/1805#issuecomment-331383688
with both options having multiple implementations.
- There was general support to standardize, but not enough
implementors were available to decide on which path.
- Discussion then turned to if ScrollIntoView is necessary given the
existence of scroll snap.
- If it is needed, there's also a need to define how it would
interact with the scroll snap properties.
- Discussion will continue on GH and may need to be split into sub
issues to decide what the default should be, what options should
be available to override the default, and how do the overrides
interact with scroll snap.
CSS UI 3
--------
- RESOLVED: Change the definition of cursor auto to look like text
over selectable text in CSS UI 3.
- RESOLVED: Add exception for editable text into L3 UI.
CSS Grid
--------
- There are two open items around percentage size that still need to
resolved:
- Should the block and inline axis be resolved symmetrically or
asymmetrically?
https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333759551
- What to do with percentage gaps?
https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096
- Both items have examples in the github issue, so everyone was
asked to review and add their thoughts to the issue to help
reach a resolution.
Filter Effects
--------------
- RESOLVED: Accept hue-rotate() as an exception to unitless values.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Oct/0034.html
Present:
Rachel Andrew (IRC only)
Rossen Atanassov
Tab Atkins
Bert Bos
Tantek Çelik
Benjamin De Cock
Robert Flack
Tony Graham
Jihye Hong
Dael Jackson
Brian Kardell
Peter Linss
Myles Maxfield
Michael Miller
Simon Pieters
Manuel Rego
Florian Rivoal
Alan Stearns
Sergio Villar Senin
Greg Whitworth
Eric Willigers
Regrets:
Dave Cramer
Chris Lilley
Lea Verou
Scribe: dael
Spec Rec Next Steps
-------------------
Rossen: There were a few specs in the publish pipeline which is
awesome. I wanted to check on if there has been any movement
on testing or if anyone needs help. Especially for things
like Writing Modes, Backgrounds & Borders, Flexbox.
Rossen: Has there been work? Do you need help?
florian: I have no made progress on writing modes. I don't need
help, just time.
Rossen: For writing modes, what is the timeline for rec? Is it only
those tests?
florian: They're the only ones on my radar. You'd need to check with
authors.
fantasai: Mainly the orthogonal flows, but they need implementors to
update. It was supposed to be CR published, I think. I'm
wondering if that happened.
Rossen: No.
fantasai: Writing modes 3 was supposed to be CR published and 4 as a
FPWD. I'm not sure where that's blocked. It hasn't
happened.
Rossen: I'll follow up with Chris.
Rossen: I'll see what the hold up is.
Rossen: Backgrounds & Borders is in the publish pipeline.
Rossen: Anything else to update?
gregwhitworth: Regarding flex I sent that review is completed, but I
haven't gotten to work on the tests at the base. I'm
not sure I have time before TPAC. If anyone wants to
help please send PRs on flex. I plan to write tests
for the changes fantasai has been making, but I don't
know about the rest. I would welcome the help.
Rossen: If you can help, that would be awesome.
Rossen: Please give a hand to gregwhitworth.
<gregwhitworth> Particularly before TPAC for those tests.
<gsnedders> wrt flexbox, also note there's a bunch of PRs awaiting
review at
https://github.com/w3c/web-platform-tests/pulls?utf8=✓&q=is%3Aopen%20is%3Apr%20label%3Acss-flexbox-1%20-label%3A%22do%20not%20merge%20yet%22
CSSOM View
==========
Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions
----------------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/pull/1805
<jihye> related PR in WHATWG: https://github.com/whatwg/html/pull/2787
zcorpan: This is about disabling scrolling from the focus method in
html. Or customizing how the scrolling should behave.
zcorpan: For scroll into view there is a dictionary to customize.
but for focus there is no way to turn off or customize
scrolling.
zcorpan: There is a proposal to do these things. The open issue is
what the API shape should be and the semantics and how to
get interop on default behavior.
<zcorpan> https://github.com/w3c/csswg-drafts/pull/1805#issuecomment-331383688
zcorpan: On one comment there is a table describing default
behaviors in browsers.
zcorpan: In chrome, opera, safari the behavior is different between
if it's partially in view or entirely out. In FF and Edge
there's no scroll if it's partially in view. You get
nearest alignment if it's entirely out of view.
zcorpan: That's where we're at. We should figure out a way forward
and a way to address these use cases.
florian: One thing mentioned in discussion is there is a number of
event options we might want to support. You don't strictly
need them but it's not convenient. Probably should take
some shortcuts, but how many isn't clear.
fantasai: I had a question on this point in terms of the options for
start vs end alignment of the thing you're scrolling into
view. These conflict with the scrollsnap properties. My
question is are these options necessary Do we need
something in JS to override them? Do we use those prop
instead?
fantasai: Has anyone thought about that?
florian: My intuition was the JS do the eq/ of maual and when you
release scrollsnap kicks in. I haven't thought in depth.
zcorpan: I haven't given enough thoughts about integration, but they
should pay well together and cssom view should be aware of
scrollsnap.
fantasai: What's the impl status of the options?
zcorpan: I don't know the current interaction.
fantasai: No, are the options implemented and deployed or just in
spec?
zcorpan: ScrollIntoView is impl at least in firefox and chromium.
I'm not sure if they're interop. It would work for basic
things. I think 'nearest' keyword isn't supported
fantasai: I think it would be worth thinking about if we need these
options or rely on css properties. If you have
ScrollIntoView why would you set a value different then
scroll snap. If there isn't the property many not need to
exist. If they do we need to think from that perspective.
dbaron: There's definitely use cases for this when not using
scrollsnap.
fantasai: But we have wording where if something has a snapping area
defined and you target that you can use the scroll s nap
into to choose the scroll offset. Snap area has a meaning
without snapping.
florian: That tells you have for offset from to top edge if your at
the top. It doesn't say how offset if you're at the middle.
fantasai: Scroll snap align would tell you.
florian: But only if you're snapping.
fantasai: By default that value is none. You're not choosing an
alignment, just marking an area.
fantasai: But if you have an alignment it means you have a preferred
alignment when that element is being considered.
fantasai: As far as the JS is concerned it's less powerful and has
to duplicate it with every call and keep track of that.
The declarative method has that associated with the
element the element tells you the information.
fantasai: The only reason I can think of is if there is a scroll
alignment and you want to do something different and you
may or may not snap to the preferred behavior anyways. I'm
not convinced that's something anybody wants.
fantasai: I think that needs thought as to if we need those options.
The information it's giving you for scroll options are
less powerful then th scroll snap options.
dbaron: I think many of the JS interactions the behavior you want is
specific to the interaction. If you're tabbing through
controls and focusing on next you want different the reverse
tab and focus previous.
fantasai: Right, but that's generally going to fall out of UA. If
next and previous rearrange based on layout it won't help
you. UA should choose if you shift to top or bottom and
pick the right side. Doing that manually through JS
doesn't seem right.
zcorpan: I think the point is that the one who decides the
behavior...like if you write an app it's the JS dev that
makes the call to pull into view, not the UA.
fantasai: Scroll into view the UA chooses a position to have the
thing in view. It's an optional argument so if you leave
out start or end it'll do dbaron's behavior but more
intelligently. The JS dev doesn't have to figure out lots
of things.
florian: But in some cases it doesn't. In some cases it just centers
the thing.
jihye: First of all when I suggested to add some options to control
scrolling when focus is called I wanted to prevent scroll or
make smooth scrolling. I think if that can be handled by
scroll snap?
fantasai: No, but the start vs end is provided by scroll snap. I
think you were trying to add this to a new API and they
were copied over. I don't think anyone has thought through
does anyone need this option if we have scroll snap. I
think we need to add the auto non smooth, but my concern
is adding start and end and in having it in the API. I
don't know why it needs to be in JS if there's css
properties to control it.
florian: Another axis of reflection is how much do we want to expose
on in view, partially out of view, out of view...how much
do we expose? Do we want a numerical threshold, leave it to
browser? There's various use cases we can think of and
various levels we can expose.
Rossen: Going back to zcorpan...in the beginning of your description
you had a more specific question of focus and if it should
align the same as scroll.
Rossen: The rest of the conversation seems necessary around if we're
going to expose these APIs and dive into how this interacts
with scroll snap. I'm trying to wind down the discussion.
zcorpan is there anything else you want from this?
<zcorpan> https://github.com/w3c/csswg-drafts/pull/1805#issuecomment-331383688
zcorpan: Regardless of API shape and scroll snap interaction there
is the default behavior of the focus method and how it does
scrolling. Do we want to align the behavior between
browsers and, if so, what should that be?
Rossen: Seems like webkit based browsers have one type of behavior
and edge and FF are aligned to not scrolling if it's
partially in view
Rossen: So impl, would this be something that you're interested in
aligning to and, if so, which should we align to?
<tantek> IMHO interop on that would be good, I would think webapp
devs would like it
Rossen: As an impl I'm personally for interop where possible, but
I'm not sure which is better b/c I haven't spent much time
on it and seeing how it intersects across windows platform.
But I want to hear what others thinks.
<tantek> +1 Rossen
florian: Additional question: has anyone checked if behavior is done
when calling focus method when there is padding?
zcorpan: If you check in the link
<zcorpan> https://jihyerish.github.io/all-about-focus/
tantek: Another question is if the scrolling is similar to fragment
link scrolling since that's done on to an element.
zcorpan: That is governed by html spec and calls scroll into view
algo.
zcorpan: I'm not sure if that's what you're asking.
tantek: I'd be surprised if that works differently as an app dev.
Rossen: I want to wind this down.
<florian> answering my own question from earlier: tab focusing and
script focusing appear to have the same behaviors
<florian> Also, based on the example pasted above, the FF/Edge
behavior seems much more intuitive to me. Could be
different in different examples, and could be subjective,
but for this one and for me, it's very clear.
Rossen: What you were looking for was alignment between focus and
scrolling. It seems your question to impl was answered as
either they don't care or they're happy with what they have.
Either case, the topic is still open. As fantasai pointed
out there are a lot of things to think about in terms of
snapping and how these should interact.
Rossen: I suggest we take those new questions back to GH. If not we
can work through during F2F. It seems your specific question
about focus isn't quite answered.
zcorpan: I think an option for going forward is if we can quickly
agree on API shape or behavior then trim down properties to
be able to disable scrolling in focus and then JS dev will
have to use intersection observer and ScrollIntoView.
fantasai: I have no problem with aligning params between focus and
ScrollIntoView. I don't have an opinion on the default,
but having the same options is reasonable. My main
objection is I think part of the API shouldn't exist, but
that's applicable to both.
Rossen: Agreed.
Rossen: Again, I was hoping you could get a better answer, but it
doesn't sound like there is one. Let's go back to GH and I
invite impl to think what the default should be and if we
can align. Focusing is important. People with a11y needs
require that quite a bit. I'm going to continue advocating
for alignment here.
fantasai: It seems to me there's 3 issues. 1) what's the default? 2)
should there be options to change the default 3) those
options, should they have params that would override
scroll snap or not. If we override scroll snap how does
that work.
florian: And another where do we care about things that are
partially or totally outside the screen.
Rossen: We'll have those recorded in the minutes and if needed we
can split into sub issues.
CSS UI 3
========
Auto cursor should behaves as default cursor except for text?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1598
florian: We've already narrowed problem considerably. It's only
about distinguishing things we can't in UA stylesheet.
There's two things reopened. We say one cursor over text,
one over everything else. We should change that to be one
over selectable text. That was in originally, seemed an
unintentional omissions.
fremy: I can give some background as to why this is useful. If you
have text inside a button you don't want the cursor to become
a text cursor, but you don't want that. To me it seems
straight forward and most browsers are doing this. I think
that should be in the spec.
florian: I sort of have this in L4. In L4 I put an exception to not
look like text cursor. I forgot the other things that might
make the text not selectable. [missed]
Rossen: What is the request?
florian: For a resolution to change the definition of the auto
cursor to change on selectable text, not all text. I'll
make edits.
<tantek> and I already +1 that here:
https://github.com/w3c/csswg-drafts/issues/1598#issuecomment-335863545
<tantek> last week
Rossen: That would mean change of behavior...fremy your example.
What would the change mean to you?
fremy: We are already doing this in edge. I think all browsers also.
fremy: This is aligning spec with browsers.
dbaron: Were you going to get to the editable thing?
florian: I wanted that sep.
florian: Proposed resolution: Change the definition of cursor auto
to look like text over selectable text.
Rossen: Objections?
RESOLVED: Change the definition of cursor auto to look like text
over selectable text in CSS UI 3.
florian: Second part is another thing where we may want to align to
browsers, but it contradicts previous intention. In the
general case browsers change to text cursor over editable,
even if it's not next. This is doable in UA stylesheet, but
we're interop in not doing that. There's reluctance to
change, especially on Chrome side. Do we want to change or
grant an exception for this because we are interop?
Rossen: Opinions? Esp from Chrome?
Rossen: Do we have anyone from Chrome?
Rossen: I guess there's no one from Chrome.
florian: Chrome seemed if other browsers commit to change and we
push hard they'll do it. They probably don't want to be
alone in this. I'd like to hear from Mozilla.
dbaron: I'm fine with having editable thing in spec. It's not 100%
clear to me that read/write pseudo does the right thing here.
dbaron: I just haven't thought through it. I'm okay with the
editable exception.
<tantek> +1 similar thoughts to dbaron
fremy: I'm in favor too. It's interop in all browsers. We can
change, but I don't think we need to. I don't think author
would expect it and changing something interop could cause
problems. My opinion is we should make the change to make
things easier for impl.
Rossen: I hear a lot in favor or don't mind.
Rossen: Objections to adding an exception into L3 UI?
RESOLVED: Add exception for editable text into L3 UI
<tantek> ready for CSS3-UI PR?
florian: That probably takes us to a passing test suite and we can
begin to move toward rec
<tantek> SGTM
CSS Grid
========
Percentages and intrinsic size
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/509
Rossen: fantasai summary?
fantasai: There is...the never ending topic keeps branching into
variations. The current variation has 2 issues. First is
that the resolution we took on percentage sizing, we made
edits that are symmetrical for block and inline axis.
Igalia guys said we implemented asymmetric. So that's an
issue of do we want to change for symmetric.
<fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333759551
fantasai: Summary comment ^
fantasai: Basically, I think we resolved this is correct behavior,
but if someone thinks different we should discuss.
<rego> related to first issue, this comment is also important:
https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334437618
<fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096
fantasai: Second is what do we do with % gaps. All options ^
fantasai: C and E are terrible. F is impl by chrome. B and D are the
ones they're combining. Gecko does A.
fantasai: I don't have a strong opinion, but we should think
carefully. We have a mix of impl and we need impl, spec,
and authors to agree on best option.
rego: Regarding first issue, I think the change to make symmetric
for columns and rows is contrary to rest of impl. We've been
checking options and if we do it we have to do extra passes.
We'd like to check if other impl will do that or if we should
revert status.
fantasai: Another pass for track sizing algorithm, or just through
the items?
rego: We believe it needs another pass of the algorithm. We were
finding some strange issues to resolve that.
Rossen: Are you talking about the % resolution of gaps?
rego: Tracks
Rossen: Okay.
Rossen: And there's no interop?
rego: There is interop, but it's contrary to what the resolution
says.
fantasai: It's an intrinsically sized grid with a % size grid track.
Does that % resolve. It does with columns, not with rows.
Spec says resolve in both axises.
<rego> the spec text is:
<rego> > then the must be treated as auto, for the purpose of
calculating the intrinsic sizes of the grid container and
then resolve against that resulting grid container size for
the purpose of laying out the grid and its items.
TabAtkins: Current is similar to how block works.
Rossen: But block has nothing to do with grid. We shouldn't define
one layout system with a completely different. The original
desire to keep things symmetric in grid was based on how a
good system should work. it's up to us to decline from that
model, that's fine if this is what everyone agrees we should
do. But let's not justify current with what we intended.
TabAtkins: Sure. We're just saying block behavior wasn't an
accident. It was reasonable to avoid extra layout in
common cases. Might not be right for grid, but there was
good reason behind our choice to copy it over.
Rossen: Trying for progress. Current proposal is to back out on our
original resolution from Seattle and go with the asymmetric
one.
TabAtkins: Intention isn't to get a resolution this week, it's to
bring it up for talk later.
Rossen: If you're not asking for a resolution, let's keep working on
it. We should resolve on this during F2F at the latest.
fantasai: Agree.
<rego> this was the change from the resolution:
https://github.com/w3c/csswg-drafts/commit/15cf0c6d56efdbb44383134ebe19dff672b01546
Rossen: We should put a time limit on this. We'll have to get
consensus.
<tantek> It does feel like an issue that would benefit from seeing /
discussing diagrams in person at the f2f
<tantek> Have we made progress on this at previous f2fs?
fantasai: It would be useful for people to think and comment on the
GH. Understanding the ramifications of this is most useful
if people think through use cases and behavior and we're
not going to get that around the table.
Rossen: Agree.
Rossen: Did you want to discuss gap % resolution or should we let
that go?
TabAtkins: I don't think we'd get that in 4 minutes.
Filter Effects
==============
hue-rotate() is being used with unitless zero angle
---------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/228
TabAtkins: When we realized several impl support unitless angles we
marked out the few to worry about and then said not to do
it in the future. Our dev figured out what is used and
the only one we didn't consider already is hue-rotate.
TabAtkins: Proposal is we add hue-rotate to the list of functions
that explicitly allow a unitless angle.
TabAtkins: I don't believe we need anything else.
Rossen: Options against?
Rossen: We're fine with that. I see dbaron said on GH he's okay. I
+1 his request to add a web platform test with that issue.
Rossen: Objections to accepting hue-rotate as an exception to
unitless values?
RESOLVED: Accept hue-rotate() as an exception to unitless values
ACTION TabAtkins to add a test case
<trackbot> Created ACTION-865
HTML
====
Change default <sup> and <sub> styling?
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1888
TabAtkins: Dominic read an article about <sub> and <sup> and was
wondering if he could change html stylesheet to support
them instead of the basic way we do. I think it's okay,
but we need yes/no from other people.
florian: There are comments. The problem is when you start nesting.
TabAtkins: Okay. Reasonable.
Rossen: Let's put it back to the issue. There's discussion. We'll
bring it back next week.
Rossen: That's the top of the hour.
Rossen: Thank you everyone, we'll talk next week.
Received on Thursday, 19 October 2017 00:26:08 UTC