- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 23 Dec 2017 09:59:11 -0500
- To: "www-style@w3.org" <www-style@w3.org>
[This continues the meeting minutes previously labelled “San Francisco”;
the meeting was actually at TPAC in Burlingame. Apologies for the delay.]
=========================================
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
-----
- RESOLVED: Make it so that setters to the .style api are appended
rather than put in place
CSS Lists
---------
- There was interest in getting a better definition for list-item
outside marker positioning into the spec.
- RESOLVED: Add Francois as co-editor to the Lists spec.
CSS Scroll-Snap
---------------
- RESOLVED: When using scrollIntoView you SHOULD take scroll snap
margin into account.
- RESOLVED: scrollIntoView MUST use the element position if it has
one and snapping is on.
- RESOLVED: Implementation MAY use the snap position if snapping is
off.
- RESOLVED: We will make the changes to specs as necessary to ack
scroll snap when no arguments are provided to
ScrollIntoView.
- RESOLVED: Keep scrollIntoView() options as they are.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
L. David Baron, Mozilla
Christian Biesinger, Google
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre
Emil Eklund, Google
Elika Etemad, Invited Expert
Javier Fernandez, Igalia
Rob Flack, Google
Simon Fraser, Apple
Chris Harrelson, Google
Daniel Holbert, Mozilla
Jihye Hong, LGE
Koji Ishii, Google
Brian Kardell, JS Foundation
Brad Kemper, Invited Expert
Ian Kilpatrick, Google
Tomoya Kimura, VOYAGER Japan
Vladimir Levantovsky, Monotype
Chris Lilley, W3C
Peter Linss, Invited Expert
Myles Maxfield, Apple
Xidorn Quan, Mozilla
Simon Pieters, Invted Expert
Naina Raisinghani, Google
François Remy, Microsoft
Melanie Richards, Microsoft
Florian Rivoal, Vivliostyle
Alan Stearns, Adobe
Surma, Google
Dave Tapuska, Google
Lea Verou, Invited Expert
Jet Villegas, Mozilla
Greg Whitworth, Microsoft
Eric Willigers, Google
Scribe: gregwhitworth
CSSOM
=====
logical/physical property cascade and the .style API
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1898
TabAtkins: Someone pointed out that there are problems with the way
logical properties are defined when trying to use the DOM
APIs.
TabAtkins: They get resolved in the normal order and then go through
the cascade and we deal with the physical and logical
based on ordering and writing mode.
TabAtkins: When you set a property it gets appended to the list of
properties in the style attribute
TabAtkins: and if you set one that's already there it just replaces
it
TabAtkins: so this can cause it to be out of sync with what would
happen in the cascade.
TabAtkins: The proposal is to amend the CSSOM that if something is
there it is always appended.
TabAtkins: Related to this
TabAtkins: we had an issue with !important and we resolved to append
to make this work.
dbaron: I'm happy to make that change.
dbaron: We had a long discussion and resolved the opposite way:
dbaron: a setter should append.
dbaron: At the time implementations were inconsistent due to
optimizations
dbaron: for existing properties in the fast path they would replace
and others they would append.
dbaron: One question, would having to do that mess up optimizations?
TabAtkins: When we discussed it internally we were fine making the
change.
dbaron: I found the minutes from 2013 but I'm looking for the other
one.
<dbaron> Things I found were https://lists.w3.org/Archives/Public/www-style/2013Sep/0469.html
and https://lists.w3.org/Archives/Public/www-style/2013Oct/0007.html
but I think there was further followup after the latter
astearns: So I'm clear, the suggestion to append or remove and then
append?
TabAtkins: Those are equivalent.
dbaron: I think it may turn out that it's not equivalent in the
future.
TabAtkins: We should figure out which one we want, it will need to
have a note to determine this.
dholbert: You could inspect the style attr and determine that way.
TabAtkins: The current model limits to only one.
astearns: I'm hearing two engines happy to change.
astearns: Any compat concerns?
dbaron: Possibly.
astearns: The compat issue would be limited to logical props
shorthands?
TabAtkins: No.
fantasai: It would only affect people looking at style attr value and
expecting a particular order
fantasai: which doesn't make much sense, so it's probably not very
common.
florian: I doubt it's common.
Rossen: Tools and editors might be doing this.
TabAtkins: I'd be surprised if the editor was reading the style attr
and writing to .style.
Rossen: They could.
astearns: The proposed resolution is to change CSSOM to append
values via the .style API and add a note.
TabAtkins: Yeah, and try to figure that out in the future.
astearns: Any other opinions? objections?
RESOLVED: Make it so that setters to the .style api are appended
rather than put in place
<dbaron> some links to discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=172073
https://lists.w3.org/Archives/Public/www-style/2008Feb/0116.html
https://lists.w3.org/Archives/Public/www-style/2008Feb/0118.html
<dbaron> (and there's more that I haven't found yet)
CSS Lists
=========
Interop on List-item outside marker
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1934
[fremy projects]
[notes: https://1drv.ms/b/s!Av6HldQ1OB8gppU68lZS-mwqvguVcg ]
fremy: More precisely the positioning of the marker.
fremy: You can center things, but it's 2017 and we still don't know
where to put the bullets.
fremy: Got a bug to put the bullet in the right place.
fremy: [shows bug in Edge]
fantasai: Wait it is spec conformant?
dbaron: Yes it is.
fremy: [shows Chrome]
fremy: Let's fix it.
fremy: So I started to look at the spec and it's missing.
fremy: Spec isn't ready to implement.
fremy: Put the 2.1 spec text and technically Edge is matching but
the spec is very vague.
dbaron: I think I may have been responsible for that note.
fremy: I get the impression that nothing is defined.
dbaron: In Chrome it is inside the principal box so it violates the
2.1 text.
fremy: We want to fix this issue, but we want to spec it.
fantasai: Yes.
tantek: All of those sentences come from long discussions and not
agreeing.
[References are to the 2.1 text, which defines things as mostly undefined]
fremy: So I'll describe how Edge is implementing this.
<leaverou> since we're talking about weird bullet positioning, I'll
quietly drop this Chrome & Edge issue here, in case it's
relevant… http://dabblet.com/gist/3731c920fa0ee56efe3ec24a33a88964
[fremy shows slides and he will post them a bit later]
fremy: There are two different steps, find out which line box do you
need to affect with the bullet
fremy: then horizontally position the bullet.
fantasai: How we end up describing this, we'll need to really think
about the markers - what they need to do and what they're
trying to achieve typographically
fantasai: we shouldn't need to switch the model.
TabAtkins: Attaching it to the first <li>, and the first item may be
overflow: hidden and the marker can disappear.
dbaron: That doesn't happen in Gecko because we position it to the
align but it's not actually contained in that.
dbaron: Back when Gecko did what was in fremy feedback and when we
fixed it we don't get bugs.
iank: We're looking at re-implementing markers, our current list
marker behavior is not nice.
iank: We're doing something very similar to what you described.
iank: I'll need to check with Koji, we're doing something very
similar to what you described, so if you could specify it that
sounds great.
fremy: That's what we want.
eae: Now is the right time for us to spec this.
<TabAtkins> <li><div style="overflow:hidden">...</div> <= list
marker is clipped in Chrome!
fremy: To reply to Tab, to have overflow: hidden we can't put it
inside of a non-bfc and this is would not happen.
astearns: So what is the action?
fremy: I wanted to know if there was interest, it seems like there
is.
fremy: Sure I'll be a co-editor but I care more about interop.
RESOLVED: Add Francois to the Lists spec
<leaverou> TabAtkins: A bit late but bullet is not clipped in Chrome
in your example, it just inserts a line, see here:
http://dabblet.com/gist/07b894c9f6c1bbc3237c422172d0e5b9
<Rossen> leaverou, there is a bullet, right?
<leaverou> Rossen: yes. Tab said there wouldn't be.
<Rossen> leaverou: good, we have interop then :)
CSS Scroll-Snap
===============
Interaction of scroll-snap and JS scrolling APIs
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1707
TabAtkins: The scroll snap spec defines that if you do a fragment
nav and it defines margin or something, you should pay
attention to those.
TabAtkins: It doesn't have any guidance on similar scrollIntoView
APIs rather than just target scrolling.
TabAtkins: We have the API opt into that
TabAtkins: the API has other properties of its own.
florian: When you say some properties what are those?
fantasai: The things we were considering: the scroll snap margin
that's the indication that there should be additional space
fantasai: if it has a snap position that's an indication that you
should snap that position.
fantasai: The third thing, the UA could opt into using the snap
position even if snapping is not turned on because the UA
is trying to determine this and they may utilize this info
from the author for the best end user behavior.
astearns: It's a bit vague, but you're going for a must to consider
the padding and positioning.
smfr: If it's an element is in scrolled to it but look at it's
container's scroll margin?
fantasai: Usually you're looking at the border box for SIV and
we're proposing to take scroll margin into account.
florian: The other aspect about snap position, if snapping is not
turned on but it has position you may use that to position.
smfr: Would you only look at the targeted item or the ancestor chain?
fantasai: Just the one that's being targeted.
smfr: It seems weird that your taking a property that's meant solely
for scroll snapping and you're adding it to the SIV.
fantasai: This is adding author intent to the SIV.
smfr: You could add props to SIV.
fantasai: This makes it so that the author doesn't have to replicate
that info into each JS call.
smfr: Is the UA allowed to override scroll snap margins?
florian: Is it implied that we should take scroll padding?
fantasai: Yes.
florian: I recall doing it in general, but wasn't aware we did it
for this API.
fantasai: That was intentional, you shouldn't be able to get in a
state in JS that you can't get to as a user.
astearns: The two of you - smfr and Rossen - showed some concern.
myles: We have to make sure that websites that turn off scroll
snapping, with this change the margin will now have effect.
fantasai: Usually this will get you a better experience.
myles: I'll be for implementing this and seeing if this has a web
compat issue.
fantasai: I don't think we should have a web compat issue.
myles: I think we can resolve on this.
astearns: I'm hearing some movement to resolving.
astearns: Anyone object?
RESOLVED: When using scroll-into-view you should take scroll snap
margin into account
RESOLVED: scroll-into-view must use the element position if it has
one and snapping is on
RESOLVED: Implementation may use the snap position if snapping is off
florian: Should this change intersection observer?
TabAtkins: I don't think we should bring this in?
Scroll Into View options
------------------------
github: https://github.com/w3c/csswg-drafts/issues/1708
fantasai: There are several different options that target an
element, such as scroll into view.
fantasai: Then there is the focus api.
fantasai: They take a bunch of args for smooth scrolling or not, and
how that element should be aligned within the viewport.
fantasai: The default behavior should be following the scroll
snap if scroll snap specifies something; currently the
API definition overrides scroll-snap.
fantasai: The second question is, are those options even necessary
if there are scroll snap options?
TabAtkins: We discussed this internally, there may be areas where
you want to do one off alignment.
fantasai: Do you have a usecase?
eae: One is up and down arrows, you may want to align to the top or
the bottom.
iank: If you have a news feed you may want to use one or the either
based on direction.
dbaron: We had a discussion about these options a few weeks ago.
dbaron: In that discussion I pasted the link to our internal code
and if we want use cases where we use it.
<dbaron> The Gecko internal API is documented here:
https://searchfox.org/mozilla-central/rev/7e090b227f7a0ec44d4ded604823d48823158c51/layout/base/nsIPresShell.h#669-763
smfr: Is scrollIntoView default the same as SIV false?
smfr: We may scroll it into the top or the bottom, just as long as
it's in the view.
TabAtkins: This became a weird api for legacy issues.
eae: Our default is either true or false based on distance.
<smfr> webkit has scrollIntoViewIfNotVisible(bool centerIfNotVisible)
florian: Your usecase of the newsfeed I think we should solve that
in CSS scroll snapping.
myles: But that criteria of direction could be a bunch of different
criteria, I don't think we should do that.
dbaron: Some of the complicated ones come from the a11y code.
iank: It looks like scrollIntoView args might be different than
scrollIntoView with bool.
iank: If it's bool we set the block to start.
TabAtkins: That isn't per spec.
iank: ok
eae: Ours is completely broken.
TabAtkins: I may open an issue on this.
astearns: I'm hearing at least 4 threads of conversation.
astearns: Do we need to have any more discussion about scrolling the
least amount?
TabAtkins: That's a separate thing to consider for scroll snap.
astearns: 1. The argument at the end should be dropped - sounds like
they should not be.
2. Should scroll snap win when there are no args in SIV -
that sounds like there are no arguments against that.
<dbaron> there seem to be different behaviors for: various a11y
things, going to named anchors, focus changes, caret
position changes, dom apis to scroll element into view, and
some other things (e.g., things related to form autofill
popups or devtools)
fantasai: The two specs conflict.
fantasai: The OM spec doesn't ack scroll snap.
astearns: Does anyone have any objection to making those changes?
RESOLVED: We will make the changes to specs as necessary to ack
scroll snap when no arguments are provided to
ScrollIntoView
fantasai: Anything that does scrolling needs to be evaluated to
allow scroll-snap to specify default scroll positioning.
astearns: Any objections with not mucking with the ScrollIntoView()
args?
RESOLVED: To keep scrollIntoView() options as they are
Received on Saturday, 23 December 2017 14:59:50 UTC