- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Nov 2020 19:42:10 -0500
- 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 View
----------
- Many of the use cases addressed in PR #5677 (Add notIfViewed to
ScrollIntoViewOptions; add FocusScrollOptions) were handled in
the Scroll Snap spec so zcorpan will review and open an issue if
anything is missing. There may also be a need to reference
Scroll Snap in CSSOM View so that the relationship is clearer to
authors and implementors.
- RESOLVED: Change the PR to just if-needed bits with a reference to
scroll snap as long as it's handling the use cases (PR
#5677)
CSS UI
------
- The resolution to only allow appearance:button on buttons (Issue
#5147: Change appearance: button to only apply to buttons) and
have it behave the same as appearance:auto was re-opened from a
request to be able to have link elements also be styled as
buttons. The group was divided on the proposal.
- Some members were arguing that this is not about styling but
about a desire to have buttons able to do more link-like
things and therefore this should be discussed within the
WHATWG.
- Another argument was that part of why the desire to style
links as buttons didn't come up before is that the native
form control styling is too limited and therefore this
should be covered in OpenUI.
- The third argument is that this is specifically a request
about styling and therefore the request to allow links to be
styled as buttons is a logical extension of the property.
- RESOLVED: Close this issue no change and open a more narrowly
scoped issue (Issue #5147)
CSS Contain
-----------
- Since the last time the group discussed issue #5595 (Proposal:
content-visibility: hidden-matchable) there was discussion on
GitHub about the accessibility concerns raised on the call and
the concerns have been resolved.
- smfr will further look into how Safari is indexing pages to see if
that's a valid use case for the proposed property.
- There is a concern with the current proposal having a difference
in behavior between fragments which would cause confusion.
Discussion will continue in the issue to try and resolve it.
- On the next call (in two weeks) the group will start by discussing
on if this proposal is something which should continue being
pursued.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Nov/0009.html
Present:
Rachel Andrew
Adam Argyle
Joseph Arhar
Rossen Atanassov
Christian Biesinger
Mike Bremford
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Brandon Ferrua
Simon Fraser
Megan Gardner
Chris Harrelson
Dael Jackson
Brian Kardell
Brad Kemper
Jonathan Kew
Vladimir Levin
Daniel Libby
Chris Lilley
Peter Linss
Tess O'Connor
Simon Pieters
Anton Prowse
Morgan Reschenberg
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Greg Whitworth
Regrets:
Tab Atkins-Bittner
Lea Verou
Scribe: dael
astearns: Does anyone have any adjustments to the agenda?
CSSOM View
==========
Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/5677
zcorpan: A brief explanation. We wanted to extend ScrollIntoView and
Focus API to control if scroll should happen and if it does
what the alignment should be; center, start, end alignment
zcorpan: I think the question is what the API shape should look
like. Which use cases we're trying to solve.
zcorpan: There's at least one polyfill implementing these behaviors
so we have some data on what webdevs want
zcorpan: Question is what to build into the platform and how
zcorpan: One option is add or utilize CSS properties for this. Or
having a dictionary you pass into Focus or ScrollIntoView
methods. Other both
zcorpan: Scroll behavior smooth you can do both. CSS property for
smooth scrolling and you can opt in/out from JS
astearns: When you say that there's JS and CSS options for smooth
scrolling it's just opting into it not any of the
alignment?
zcorpan: Smooth scrolling exists for ScrollIntoView. Issue is adding
scroll alignment and if needed
fantasai: Shouldn't scroll alignment be handled by scroll snap
alignment property?
zcorpan: Maybe. Not familiar with it
fantasai: Has a scroll snap align with the values you typed.
Supposed to take into account when scrolling even when
scroll snap is not on.
fantasai: afaict that defines the alignment. There's a margin for
spacing. All supposed to be for ScrollIntoView type
operations
zcorpan: if-needed means if a scroll should happen or not depending
on if the element is already visible
fantasai: The default behavior is if-needed. So if I tab to
something not in view it scrolls to view?
zcorpan: Exactly. Default is different for focus and scroll into
view. Scroll into view always scrolls and focus is only if
needed. You can override the behavior for both APIs if we
extend the methods
fantasai: Always means what? Scrolls even if in view?
zcorpan: Yeah, scrolls to spec alignment
fantasai: Like a target. Gotcha.
fantasai: We don't have anything like that.
fantasai: For alignment I recommend reading scroll snap
smfr: Also scroll padding that does scroll margin and padding
fantasai: All take effect even when scroll snapping not on
zcorpan: That's good. Then possible CSS property is sufficient and
we don't need to override in API. Depends on if you want
different alignment for different API calls
fantasai: Start with the CSS property, make sure it's implemented,
and wait if people ask for different behavior in different
APIs
zcorpan: But if-needed primitive still needs to be added if I
understand
astearns: Is that an extra value or a new property?
zcorpan: Not sure if it makes sense as a CSS property. Could add to
focus and ScrollIntoView
astearns: And determine if it needs to be in CSS on usage
fantasai: If you need to bring something into an alignment on scroll
when it's target of ScrollIntoView I think you can turn on
scroll snap. Don't know if there's a use case for a CSS
property. I can see wanting to get one or other behavior
out of APIs with different behaviors
zcorpan: Agree
zcorpan: Other issue is that browsers have different default
behavior for scroll alignment on focus
zcorpan: I think the way to fix that is by changing Firefox to match
WebKit and Blink
zcorpan: There is a Mozilla bug about that. Not fixed yet.
astearns: Mozilla bug is backed up by spec text?
zcorpan: The PR leaves scroll alignment on focus undefined. We'd
need to spec what we want
zcorpan: Two behaviors are centering or start alignment if I
remember correctly. Firefox does start alignment, WebKit
and Blink do center. That's on focus
astearns: And is there an issue about the default alignment
behavior? Did we resolve on what we wanted here and get
spec updated to back getting it fixed in Gecko?
zcorpan: It's part of this discussion, not a separate issue
astearns: Does the PR define the behavior?
zcorpan: No, not for focus
zcorpan: If the WG thinks one behavior is better we can resolve and
spec. Otherwise we can wait for Firefox to change or WebKit
or Blink to change to match FF
astearns: I don't know that I have an opinion which behavior is
better
astearns: Could see an argument for Gecko because want to start
reading at the top instead of having to scroll after focus
emilio: I don't know if it's the same bug but we've discussed
changes a couple times. We needed feedback from our a11y
folks.
<zcorpan> The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1410112
emilio: Other thing is if you do scroll if you're already visible. I
haven't read the whole log so may have discussed. I remember
Blink having a compat issue we didn't. In general I don't
think we'd be opposed to changing
zcorpan: Bugzilla I pasted in IRC explains the two behaviors
zcorpan: Three cases we care about. Element entirely in view is no
scrolling; interop. Partially in view where WebKit and
Blink scroll to nearest edge in block and inline. Entirely
out of view they scroll to center, center.
zcorpan: Nearest edge is the edge of the viewport closest to the
element
astearns: The least amount of scrolling to take the element entirely
into view
<emilio> https://github.com/w3c/csswg-drafts/issues/4778
emilio: This is more subtle. In inline axis WebKit and Blink used to
have a magic value where if it was out of view by less than
an amount it wouldn't scroll. That's another thing to take
into account
emilio: Generally centering makes sense. For sites that don't use
proper padding the element might hide under fixedpos which
is unfortunate
astearns: Suggest we resolve to reduce the PR to just the if needed
bits and wait to see if Gecko can change and we spec
default behavior if they can
smfr: What about prevent scroll argument?
zcorpan: That is specified and implemented
zcorpan: As far as I know. Not sure if it's everywhere. It is in
Chromium at least.
fantasai: astearns there was an argument for why there's centering
in Gecko?
emilio: WebKit and Blink center. Gecko is sometimes unfortunate with
scroll padding
astearns: Proposal: Reduce PR to just the if-needed bits
zcorpan: And check if scroll snapping is enough for alignment use
cases
fantasai: If you work on scrolling zcorpan read the whole module and
let us know if we need adjustments.
zcorpan: Can do that
smfr: I feel like both css properties and API properties there's a
lot about scroll. Might need algorithm to describe
interaction. if-needed take into account scroll padding?
fantasai: Should. In scroll module it is expected to apply to all
the APIs
smfr: Okay
astearns: If it isn't there might be work a reference to scroll snap
in CSSOM View. Just so people can follow breadcrumbs
zcorpan: Essentially spec if-needed behavior in terms of scroll snap
<fantasai> https://drafts.csswg.org/css-scroll-snap-1/#scroll-padding
<fantasai> https://drafts.csswg.org/css-scroll-snap-1/#scroll-margin
astearns: Objections to change to PR to just if-needed bits with a
reference to scroll snap as long as it's handling the use
cases
RESOLVED: Change the PR to just if-needed bits with a reference to
scroll snap as long as it's handling the use cases
CSS UI
======
Change appearance: button to only apply to buttons
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5174
florian: Background- general story is pre-standard version of
appearance had a whole bunch of values which caused
appearance to change. Button made things into buttons.
Standard version attempts to only have none and auto. Auto
lets form control be what they should be and none makes
them HTML elements.
florian: Button value for appearance is necessary for compat. Compat
study done in Blink is if it behaves like auto and lets
things that are buttons be like buttons that's enough.
Button syntax exists, same as auto.
florian: Doesn't break the web, but it breaks what people want.
People don't want arbitrary things to look like buttons,
but they want links to look like buttons.
florian: Might not break the web, but if you look at github page the
new issue button is a link not a button.
florian: This didn't always show up on web compat study they're
styled buttons. Since the stylistic abilities on native
controls are limited it doesn't always show as applying
appearance button.
florian: Request is to extend that if you do it on a link element it
causes it to look like a button
florian: We noted it during discussion on closing the issue before
it might be wanted but we did it anyway. As soon as we
resolved people said they did want it.
florian: I don't have an issue, wanted thoughts.
emilio: I sympathize with the use case. But if people are doing it
it would have come up in the analysis we did. People have
been able to do this for a long time and they haven't. Why
should we re-introduce on basis that it might be nice
sometimes
jensimmons: Trying to think about this from author PoV. One of the
struggles for people teaching best practices very often
there are engineers who confuse a link and a button. Use
links when should be buttons and the other way. They do
a link because want styling and then have JS. I don't
know if having demand for this is a good signal. might
be demand from people that need to understand better
<fantasai> jensimmons, see
https://github.com/w3c/csswg-drafts/issues/5174#issuecomment-707015527
jensimmons: Not sure of that either. There's a struggle among
teachers to teach the right way to do things. I don't
have a clear sense of the answer. But demand is not
always a good thing
iank: I think, one thing from me, and this might be a not yet
signal...a lot of what we see is people styling own buttons
because native aren't stylable enough. Might be more
comfortable with this question after we make native form
controls more stylable.
iank: Other interesting point is extending buttons to do more
link-like things. I'm not saying no but maybe not yet until we
understand more
florian: To jensimmons I agree with overall problem. Not sure which
way it goes. There are places where you want behavior of a
link that's what you want. You just wnat it to look like a
button and bad to use HTML element to do that. Is that
stronger or reverse, I'm not sure
florian: As to not show in telemetry I think it may have been there
but not break web. Could also be there less because not
able to style native buttons. If they could style they may
want to use it more and use it on links. It right now makes
it look like non-native button as buttons and links are
native and you don't want that.
emilio: I'm not sure that argument makes sense to me but I may be
misreading
emilio: If you style a native button to look non-native, that you
can do. Not sure what capability we're lacking
florian: Claim is that you can do and people do it. And that's why
you're not finding it. But where you want to not change
them away from buttons and want to keep button buttons and
link buttons on a consistent style you need ability to do
button style on link
emilio: Button resets a bunch of styles as well, like
text-transform. Also a different layout box. Appearance:
button is a paint-time hack. I don't feel like argument is
super strong. I can see it
zcorpan: First on the principle level feels a bit dirty to allow
button on links. Buttons are buttons and links are links.
That's the principled stand. There are practical concerns.
Some are in the thread and can be resolved by changing
HTML. When it's open in a new tab, not all browsers can do
that for submitting forms.
zcorpan: Other was a bug where if you submit a form without any
fields it still adds a ? to the URL which is shouldn't.
zcorpan: Also, I know tel:links only works as links. Can't submit a
form to a tel URL and have it open the phone app on your
device yet people want that call us button to look like a
button but their only choice is to use a link. Could be a
use case
zcorpan: Or allowing forms to submit to tel. Not sure why that
doesn't work
fantasai: Forms to submit to tel makes no sense. You guys are trying
to justify the difference between button and link are
because the style. That's ridiculous. The idea is you pick
your markup based on what it is and behavior it should
have and then you style to what it should look like. They
are links and behave like links. Only reason it has
anything to do with button is want it to look like a button
<fantasai> https://github.com/w3c/csswg-drafts/issues/5174#issuecomment-707015527
fantasai: Trying to argue to make button act like link we should add
an appearance to make it look like a button. Specific
comment and use case in the issue ^
fantasai: Even on this page you have a new issue with all the button
style and link properties. Github uses custom styles. This
is what people want to do.
fantasai: Makes a lot of sense to handle at CSS layer.
appearance:button is the correct. Should allow as it is in
the past. It's not complicated to impl, we know how to
apply button style to a box.
fantasai: I think it makes sense. Maybe there's good tweaks to HTML
but if they want to have something look like a button they
shouldn't have to use the button element
<tantek> from my experience with web authors, this is not a use-case
they want
<tantek> as the person that came up with appearance for this exact
use-case, I'm saying this is not a path worth going down.
plinss: I want to counter that. When building a web app the best
practice is to have app state in the URL. Buttons to drive
things. You often do want buttons that act like links. Most
web component libs have href on the buttons. There's an
argument to give button all the capabilities of a link
<bradk> How buttons and links work is not a CSS issue. How they look
is.
<tantek> we already agreed to stop trying to make appearance more
incrementally useful. I'm a bit surprised this is being
re-opened without new information. one random github
comment is not new information
emilio: I was going to say fantasai's argument is the opposite of
what we've been doing with appearance for the last couple
years. We reduced number of values and restricted to apply
to specific elements to avoid people doing this stuff. I
don't see why we should change direction again. Appearance
has been a mess
florian: I can see inbetween. In previous appearance you could make
a select drop down look like radio. You had values for all
pseudo elements that are components. Turning button in drop
down to look like scroll bar. Made no sense. Good to get
rid of
<tantek> the right approach is to work on making OpenUI work for
this kind of use-case and related use-cases
florian: Buttons are an arbitrary container. Turning stuff into
buttons isn't crazy. Ask is limited. It's not asking for a
div. Link and button behavior is close. In this limited
case it's not that hard.
<tantek> disagreed. the behavior of links and buttons is not "sorta
close" at all, nor are their semantics.
<bkardell> tantek: I would like to hear the argument you're making
there ^
<tantek> bkardell: great, participate in OpenUI for those discussions
astearns: At the end of queue, not hearing consensus
plinss: One more point I forgot. Generally with custom elements
buttons have behavior, not just appearance. Unless we give
behavior the style won't give you everything.
<tantek> plinss's point is exactly why we abandoned the 'appearance'
property approach
plinss: If all the behavior you want is a link, use a link.
florian: Links that behave like links should be links. Good to have
it look like a button? People do it
plinss: But you have visual effects and everything on your button
and you won't get that on a link. You don't get the grid
placement, etc. Easier to have a button that acts like a link
<jensimmons> btw, I tweeted this question out:
https://twitter.com/jensimmons/status/1329115564233662464
<tantek> to be blunt, this is the wrong call to solve this problem.
this should get pushed to OpenUI
<chrishtr> I agree with the OpenUI suggestion.
<tantek> and please stop trying to make appearance a thing (insert
Mean Girls meme)
astearns: I suggest that we close the issue without adding the
suggestion of making links look like buttons. If people
want to make further arguments they can raise a separate
issue
zcorpan: tantek suggested bring this to OpenUI group
astearns: I think that's fair
zcorpan: And for HTML changes we should discuss with WHATWG
astearns: Right, if there are behaviors that should be shared can
discuss there
astearns: Proposal: Reclose with no additional change
astearns: Objections?
<tantek> +1 to close without change.
florian: I do kind of buy into fantasai argument. I'm not in a rush
to go that way but a bit uneasy about closing without
consensus
astearns: I think it is a separate consideration that could have its
own issue
florian: Fair, narrower
astearns: I'd like a new narrowly defined issue and maybe refer back
to it. Let's not re-raise it unless you think there's a
possibility of consensus
florian: It's a bit tricky since pre-standard did allow. In terms of
behavior browsers can do its. Spec as is would ask to remove
astearns: And if they do and find problems that's argument for
changing spec
<gregwhitworth> zcorpan: I would expect the potential HTML changes
and "need" for appearance changes to fall out of
Open UI discussion. As plinss noted, if buttons
commonly are trying to use things on links and it's
a common paradigm then this should be documented
there and propagate to HTML
astearns: I'd like a narrower issue and to close the older one
astearns: Objections?
RESOLVED: Close this issue no change and open a more narrowly scoped
issue
CSS Contain
===========
Proposal: content-visibility: hidden-matchable
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5595
jarhar: Last time we talked on this some concerns on a11y on this.
Simon mentioned browsers indexing pages
jarhar: What I talked in GH for a11y there was discussion with
jcraig and Alice which I hope resolve the a11y concerns
jarhar: Anchor navigations is interesting. The thing about adding
before the element anchors we can't have async behavior when
scripting. Even doing it on nav is breaking. Probably best
to keep sync scrolling for the fragments
jarhar: Could fire before-match but then it would have different
behavior than find in page. Could be cases with an element
fragment scroll before the element is revealed but find in
page is okay
jarhar: Gave example on mobile wikipedia where element fragment
navigation works where you expand the fragment. I see
argument of a one stop shop but on the other hand depending
on how handler impl it might not reveal it on time and that
might not be great
jarhar: It would be cool is smfr could expand more on how browsers
index. Interested in supporting more.
jarhar: We could talk more about if people think this is the right
idea if that's fine
astearns: First thing, concerns about a11y. Any comments or concerns
on that discussion to bring up?
astearns: Okay, we'll assume GH discussion was enough
astearns: Second is indexing pages
smfr: I need to figure this out. May be Safari looks at DOM so not
an issue. I need to research more on that
jarhar: Thanks, I appreciate it
astearns: Extending proposal to anchor navigation. You're proposing
not to
jarhar: We could make it a one stop shop but might break some
websites which expect the async behavior and you'd get
different for find in page vs element nav. Anyone with
thoughts on which idea sounds better
fantasai: I just don't understand events model. I haven't dug into
it.
jarhar: Elaborating a bit. In chrome when I implemented when I put
before-match event for find in page it was async. Between
text and scroll I added event. Some sites in before-match
change the style async where it reveals after the scroll. To
support that we changed find in page scrolling to be async.
Nothing breaks if we wait 2 animation frames.
jarhar: Added async to support this
jarhar: With element fragments it's a little more brittle. Sync
behavior is more baked in. Making async is likely to break.
Could keep it sync but it might not work on all sites. Want
to avoid pages not revealing content on time due to security
mitigations. It would be bad to have a page miss expanding
content in response to before match
fantasai: I think it makes sense.
fantasai: Concern is that I don't want us to be in a world where the
behavior of an element target or ID targeting element has
substantially different behavior then using text fragment
style of ID content
fantasai: Having one of those expand a collapsed section and the
other not is weird
jarhar: Makes sense
fantasai: I don't know how to solve technical end, but having behave
different is not good
jarhar: scroll to text fragment we were in better place because
newer. When I made it async it didn't break
fantasai: There's scroll to text fragment which is in URL and find
in page which isn't URL. Having those different is better
than having 2 types of fragment be different. Clicking on
a paragraph and if it has an ID determines different
behavior is bad. I don't have a solution
jarhar: Good concern. I can dig more and see if there's a way to
make scrolling async for navigations. Might not be clear if
I break anything but hopefully there's tests
vmpstr: I wanted to point out that you mentioned should be no
difference if linking with a fragment link vs scroll to
text. Currently pages can expand fragment link nav. Not mech
to expand a section when there's scroll tot ext fragment.
vmpstr: This prop brings parity to same level. Not same API but
capability is the same
<fantasai> https://www.w3.org/TR/selectors-4/#the-target-within-pseudo
fantasai: I understand from you can get same functionality. But if
there's a doc with collapsed section, some has ID and some
don't. Asking for the ID shouldn't change if it closes or
not. If author is expected to have 2 impl chances are
they're impl the thing they thought of and one will
uncollapse and the other won't
fantasai: More understandable if targets are different. Less okay if
2 different types of target have different behavior
fantasai: We do have :target-within pseudo class and that should be
matched by text fragments and selectors. Styling-wise it
can be done. Don't know JS stuff
<tantek> TBH this is one of the problems with Google's scrollToText
as compared to fragmentations. Pages can expand both
fragment link nav *and* fragmentation link nav, but not
scrollToText
astearns: And we are at time. I suggest we go back to see if there
is a solution for fantasai's concern. Let's keep this on
the agenda and bring it up at the beginning of the next
call to answer if this is a good thing because I'd like to
get you that answer
jarhar: Sounds great
astearns: No call next week, we'll talk in two weeks
Received on Thursday, 19 November 2020 00:42:53 UTC