- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Mar 2016 17:32:01 -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.
=========================================
Snap Points
-----------
- RESOLVED: The only pseudo elements that snap points apply to are
::before/::after but add a note that suggest there
"might" be a future pseudos that can support snap
points.
- There needs to be more use cases before deciding how to behave
with snapping to unreachable elements.
- Still no decision on renaming proximity and mandatory. Current
suggestions are near|always, force|allow, force|proximity,
force|near or keep the original names.
- RESOLVED: Defer 2D snap to the next module level of snap points
bookmark-level: auto
--------------------
- bookmark-level will stay the same in CSS Break.
Sizing
------
- gregwhitworth will investigate if min-width on tables is possible.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2016
Scribe: gregwhitworth
Snap Points
===========
Applicability to pseudo-elements
--------------------------------
florian: Not sure how much we can do without Matt R. and Tab
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Jan/0193.html
florian: The snap points spec does not say whether pseudo elements
can have snap points or not.
florian: The pseudo spec implies that everything should work
unless there is an exception.
florain: Snap points not having an exception they should apply.
florian: There are many specs that say it one way, others another
and some don't at all - so assumptions are made and at
times are incorrect.
rossen: This is in context of snap points why?
florian: Because I wasn't sure.
dbaron: The way to solve this is to find a spec that should have a
definition for this and assign the all elements and
hyperlink to a definition to that.
<dbaron> i.e., there should be a hyperlink in Applies to: <a>all
elements</a> with the anchor linking to something that
says "all elements" includes ::before and ::after.
fantasai: Any spec that states specifically applying to ::before
::after should be removed unless it's stating that it's
excluded.
ACTION TabAtkins to change bikeshed to: there should be a
hyperlink in Applies to: <a>all elements</a> with the
anchor linking to something that says "all elements"
includes ::before and ::after
<trackbot> Created ACTION-753
<tantek> question, what do implementations do with snappoints on
:before and :after?
florian: The second part of the question is can you have snap
points on other pseudo elements other than
::before/::after - TabAtkins said no
astearns: Usecase is to snap to spelling errors.
rossen: There's scrollTo for that type of thing,
tantek: ::first-line you wouldn't.
tantek: It's not cut and dry.
fantasai: There has to be a clear use case as it's significant
implementation cost to achieve this.
fantasai: I'm not convinced to add this to the spec unless there
is author demand.
fantasai: You might want to have it snap into the viewport, but
that's an edge value.
florian: I think ::before/::after are compelling.
fantasai: For consistency sake.
rossen: Even they're on the border.
plinss: I'm confused about future things, and I don't like
constricting it pointlessly.
florian: It's due to implementation complexity.
plinss: Think about pseudos for columns, paged etc - we shouldn't
set a precedent.
fantasai: I would happily introduce a ::column pseudo that takes
only the scroll-snap properties.
rossen: It's most useful on structural elements.
plinss: If it's a big barrier I'm ok with a should.
rossen: For us it is.
fantasai: I would prefer not to add it now, because of the
additional testing.
fantasai: The pseudo draft says whether it applies or not, and
when we add more we can add them in.
astearns: That means in the future if we have compelling use cases
for this we can bring them back in to have support.
astearns: In general closing them off now, does this close them
off forever.
rossen: No - just for this version of the spec.
esprehn: I don't think you're ever stuck, we can just add more
properties if necessary.
esprehn: As an implementor, anything other than ::before/::after
is really hard.
tantek: There has to be a way to spec an opening for more pseudos.
plinss: I'm open to a note that says we may apply this to new
pseudos in the future.
tantek: I'm ok with an informative note, I don't want to mislead
people.
RESOLVED: The only pseudo elements that snap points apply to are
::before/::after but add a note that suggest there
"might" be a future pseudos that can support snap points.
Snappability of unreachable elements
------------------------------------
Scribe: ewilligers
florian: If a snap point has always been beyond reach, and you
scroll beyond,
Florian: (draws on board)
[Florian draws a scroller, with snap-padding on the top and bottom.]
[There's a large element, fills the size of the viewport]
[There's also a tiny element, at the bottom of the scrollable area]
[Both request center snapping]
<alancutter> Photo of Florian's diagram: http://imgur.com/27CdHCU
Florian: It has a somewhat large snap-padding area.
Florian: We have a large element with a center snappoint, some
margin,
Florian: a small element with a center snappoint,
Florian: the snappadding is larger than the small element.
Florian: There is no way that you can scroll the small element
into the center.
Florian: The spec is vague / contradicting itself - two parts of
the spec.
fantasai: That is a valid snap point.
Florian: One: things that are unreachable would be the most
appropriate to snap to, you must snap to them.
Florian: Spec does not clarify "most appropriate"
Florian: Second part of spec: if an element is entirely outside
the scrollsnap area, it is not considered.
Florian: Suspect was intended for 1d scrolling.
Florian: Lots of things should be up to UA, but not this.
Florian: Making things reachable should not be UA dependent.
Florian: Spec is ambiguous. "Must" part relies on ambiguous term.
fantasai: We should reorder the paragraph. Expected snap position
is bottom of screen.
Florian: The part of spec that says you must snap to it use
ambiguous words. Other part of spec contradicts: part
that speaks about corridor,
Florian: accidentally contradicts "if you never enter the scroll
area, not considered."
esprehn: As a user, what do you want to have happen?
Florian: I think it is a wording issue.
fantasai: We need a specific wording proposal.
astearns: The next step is for Florian to propose a wording
change, send to the list.
Florian: Based on tab's answer, I thought there was actual
disagreement.
Florian: Spec describes 3 types of scrolling, ... semantic
scrolling, inertial scrolling, 4th type: indirect
scrolling: move focus, or change carat. no wording in spec.
fantasai: Explicit scrolling is scroll to specific position.
Florian: You are not scrolling to specific position. On focus,
scroll is a side effect. Do we have invisible carat /
focus button. It is not clear.
fantasai: There is a section in spec that Tab and I added, dealt
with target case.
<fantasai> "If a page is navigated to a fragment that defines a
target element (one that would be matched by :target),
and that element defines some snap positions, the user
agent should snap to one of that element’s snap
positions. The user agent may do this even when the
scroll container has scroll-snap-type: none."
fantasai: The user agent should snap... So should we apply this to
more cases like :focus?
Florian: What happens if container has mandatory snapping and
element does not have a snappoint?
fantasai: You need to be careful with mandatory snap position.
Authors need to be careful.
Florian: Other option: things that match the target pseudo class
and focusable things and editable things in a mandatory
scroll container if they are not within things that have
a mandatory snappoint, have a snappoint.
hober: I prefer first option.
Florian: In that case, the magic is not that hard, but if we want
to go without, make clear to authors.
Scribe: ewilligers, alancutter
esprehn: I want to talk to accessibility people.
Florian: As currently defined it will not.
Florian: I think the magic is something we can work and and will
be useful.
zcorpan: Web authors will hate this.
zcorpan: It gives behavior they didn't ask for.
zcorpan: In general we should avoid magic stuff.
gregwhitworth: While I sympathize with authors, end users will
expect endpoints when they hit tab.
gregwhitworth: I would prefer accessible users to see input that
is selected over the preferred behavior of web
authors.
esprehn: People make their browser different sizes that produces
bad situations.
zcorpan: You are talking about keyboard navigation.
zcorpan: When navigate by keyboard, user tabs between form controls.
zcorpan: I would expect snapping to not happen.
gregwhitworth: I think that's what we're saying, we should put
together a bunch of test cases.
gregwhitworth: We could potentially fake it in some cases.
gregwhitworth: I don't know if we can resolve but it's worth
testing.
Florian: We need to eventually resolve this,
gregwhitworth: Sure.
Indirect scrolling
------------------
Florian: I have a related other topic, also about indirect
scrolling.
Florian: Focus on something, moving the carat, proximity snapping.
We have a button with no snappoint.
Florian: There's nothing to prevent scrolling into visible area.
astearns: If this is the email that you sent on the mailing list
we should wait for editors to respond.
Florian: If this in not a good time to talk let's talk later.
Naming of proximity/manditory
-----------------------------
Scribe: ewilligers, alancutter, esprehn
fantasai: There was a bikeshedding discussion to have, about the
naming of proximity/mandatory
astearns: What are the proposed names?
fantasai: The proposal was "near" and "always". Any other ideas?
esprehn: Sounds great.
Florian: I prefer the current one.
astearns: The benefit to near and always is shortness and we use
it in other CSS things.
Florian: We removed them.
Rossen: I prefer proximity and mandatory.
<zcorpan> have these shipped?
<fantasai> yes, but we removed everything that shipped
<zcorpan> ok
astearns: Sometimes it's good to have bikeshedding face to face
but it seems like it's not working right now.
fantasai: force / allow?
<fantasai> scroll-snap-type: none | force | allow
2-d snapping keep or push out
-----------------------------
esprehn: We support shipping a minimal subset.
dbaron: Not sure what we currently implement.
ojan: Our people working on snapshots are not here.
esprehn: They're interested in shipping an interoperable
implementation.
Rossen: Is there an official resolution to this in Sapporo?
Rossen: Can we put this for resolution?
hober: We didn't have an exact resolution in Sapporo.
Florian: If this is something we all agree on at-risk is fine. At
risk is the wrong tool and we should remove it.
dino: We don't want to be the trail blazers and implement it and
find it's not useful.
Florian: At Risk allows you to do that.
dino: If the other implementors don't want to do it what's the
point?
rossen: This is a really awesome feature, when we ship it would be
great if we can without prefix/holding back.
Florian: We don't want to drop it and end up with a spec we can't
add it back to.
hober: We have version control.
<zcorpan> hober++
fantasai: We already accounted for this in the text.
dino: We appreciate the great work from TabAtkins and fantasai,
dino: but we want the spec to be merged soon so we can implement
soon,
dino: not saying keep it out forever.
fantasai: Florian is saying we don't want to make changes in the
merge that make it impossible to go back to the 2d
design later.
fantasai: I don't think that'll be a problem.
fantasai: That's not what we resolved on, but I don't think
that'll be a problem.
astearns: I think we have consensus?
RESOLVED: Defer 2D snap to the next module level of snap points
Naming of proximity/manditory
-----------------------------
astearns: Force and allow snapping, much shorter words.
SteveZ: Doesn't say the same thing.
Florian: Permit is a good synonym for allow.
SteveZ: Force is a verb, it needs to be a verb...
esprehn: What's the default value?
Florian: None.
esprehn: Why not auto?
<zcorpan> none | force | auto
Florian: Proximity is auto?
Rossen: Auto is the default word for magic.
Florian: It's hard to guess what it does from the name, proximity
is more clear.
<zcorpan> none | force | proximity
dbaron: Near and exact?
Rossen: Force and proximity sounds good.
Florian: Force and proximity makes force sound like a noun when it
is a verb.
shans: What about exact?
Florian: Exact is bad, it sounds like you have to go exactly to
that point.
dbaron: We seem to be happier with nouns and adjectives than verbs.
<Rossen> none | force | near
bookmark-level: auto
=====================
astearns: Next thing, bookmark level auto.
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0310.html
Florian: I want to talk about bookmark-level.
Florian: There is a set of properties, bookmark-level. When you
generate PDF,
Florian: The bookmark you get in PDFs that take you to certain
parts of the document.
Florian: The nesting of your sections seem like something derive
from the structure of the document instead of
Florian: requiring authors to define it.
Florian: "auto" could derive this structure for the author.
esprehn: Which thing does not exist?
Florian: Bookmark-level: auto, this should be something you can
figure out from the structure of the document.
Florian: Instead of manually specifying it.
Florian: Things could get out of sync.
esprehn: Does any one implement bookmark-level?
Florian: Print formatters do.
Florian: This will lower the work required to take a document for
the screen to a PDF with bookmarks.
Florian: I don't think we can do this with selectors.
Florian: I tried existing selectors including non-implemented ones
and failed.
esprehn: auto doesn't seem very hard to implement this (as an
implementer that doesn't implement bookmark-level)
esprehn: As long as it's not like counters in CSS I support this.
plinss: I kind of have a fundamental issue of why are we
reinventing hyperlinks?
esprehn: I don't want reset, skip, increment, etc. again.
Florian: I don't mean we should mandate how a sidebar works.
plinss: This whole feature smells like something very specific to
PDF and has nothing to do with the web platform.
astearns: dpub folks have been talking about an explicit <nav>
element with links.
astearns: I don't think it's adding a random feature it's
streamlining a process.
fantasai: There are multiple implementations of bookmark-level.
Florian: Viviostyle has it in their roadmap to implement this for
screens.
esprehn: I think this is part of CSS and shouldn't be treated as a
separate focus group.
esprehn: Thinking of Houdini this is not the way we want to go
with CSS.
esprehn: We want to add extensibility points instead of magic.
Florian: What is magic about it?
SteveZ: It's a table of contents.
plinss: If you want an element that generates a table of contents
that should be part of the document not CSS.
Florian: Our engine needs to implement this to be compatible with
existing content.
plinss: Table of contents is content, not styling.
SteveZ: A table of contents is a relabeling of content. It's
presentational.
plinss: I disagree.
SteveZ: It's taking existing content and putting it elsewhere in
the display.
skk: The bookmark sounds like a data structure and not like styling.
esprehn: With custom properties you can define the bookmark level
property to do whatever you want and we don't have to
talk about this.
Florian: It has three interoperable implementations, it's not a
new feature.
tantek: Let's see the usage numbers, if it's like 10...
Florian: Should I go to WHATWG for this, is the CSSWG not allowing
this?
Florian: I can't do this with houdini with current browsers.
esprehn: I don't think this fight is productive, there's an out
now for this.
Florian: This is a request for a new keyword for an existing
property.
Florian: Not about removing this property from CSS.
astearns: We are not going to resolve modifying or removing this
property today.
<zcorpan> in httparchive 470k pages i see one page matching
bookmark-level in css (actually prince-bookmark-level:1)
http://www.wowrean.es/ http://eu.wowrean.es/public/print-default.css
Fragmentation and Transforms
----------------------------
<Florian> http://jsbin.com/fuloge/edit?output
Florian: If you open this, it appears that Chrome and Webkit do
one thing.
Florian: Other browsers, and print formatters, do something else.
Florian: Chrome and WebKit are the only ones that get this right.
Florian: It's a list of numbers positioned relative down.
dbaron: You have to use frame source. It doesn't work in jsbin.
dbaron: The question is "does position relative work across
pagination?"
Florian: I think the spec says...
<Florian> https://drafts.csswg.org/css-break/#transforms
dbaron: Is this CSS break? This is a new spec, newer than the
implementations.
Florian: Am I correctly understanding that the spec is asking for
Chrome's behavior?
astearns: The spec is a bit older than David represented.
<dbaron> OK, the spec is 4 years old
<dbaron> still newer than all implementations
astearns: It ended up this way so we would not lose content when
paginating with relatively positioned content.
dbaron: Does Chrome get this right because it gets all the other
parts of this section wrong and it gets this right?
Florian: We're wondering what our implementation should match.
esprehn: Firefox looks like it's moving all the content down in
each column.
astearns: Both behaviors have their uses.
astearns: Either in printing or in scrollable situations.
astearns: I think Firefox's behavior looks nicer in this case.
esprehn: We implement this section of the spec wrong.
Florian: So after fixing you're likely to match Firefox?
fantasai: This rule is only about pagination, not about columns.
fantasai: The reason for that is if you don't do that you lose
content.
fantasai: We recommend that for printing we do this slicing after
having transforming stuff.
esprehn: I suspect our response is we will not implement this,
multicol implementors have said this seems very
complicated.
<gregwhitworth> In addition, I opened a bug on Chrome that deals
with multicol that got duped to this one, and it's
assigned - they may be able to address this while
they're in this code:
https://code.google.com/p/chromium/issues/detail?id=223068
<gregwhitworth> not be there should not be an option IMO
Florian: I'm not happy about the "should", some browsers will
behave different.
fantasai: I would rather a should than nothing at all.
dbaron: I'm skeptical about "should" because it takes a lot of
energy to implement this and browsers are probably going
to implement something else.
dbaron: I'd rather not add complicated things to specs for things
no one implements.
<fantasai> "3. SHOULD This word, or the adjective "RECOMMENDED",
mean that there may exist valid reasons in particular
circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed
before choosing a different course."
<fantasai> RFC2119
esprehn: We are interested in an interoperable version of
multicol, we're not interested in anything fancy.
Florian: Once that happens all browsers and print formatters will
do the same thing.
hober: We don't want to regress with regards to the epub corpus;
too much there.
Florian: I have my answer regardless of what the spec ends up
saying.
astearns: Sounds like a good place to leave this.
fantasai: If Hyatt has a *better* solution, be happy to consider
that for the spec.
astearns: Shane wants to have a talk about scroll linked animations.
astearns: The second thing is koji had an additional topic if
you're ready.
astearns: We have <30min left.
[Discussion of word-break: break-word; moved to CSS3 Text section of
minutes.]
Sizing
======
fantasai: Do we know whether we can switch table cells to honor
the min-width property?
gregwhitworth: I don't have data but I'm shocked that you can't
use it.
gregwhitworth: We can gather data.
fantasai: Proposal if it's possible: min-width applies to table
cells.
dbaron: We could add properties that set the intrinsic widths,
unlike the min/max-width properties that set constraints
on the width ... useful outside of tables.
ACTION gregwhitworth: look into allowing min-width on tables to
work, and auto to work like it currently does - will
require test cases for L2 of tables and possibly sizing as
dbaron said it's helpful for intrinsic sizing beyond tables.
<trackbot> Created ACTION-754
fantasai: Let's switch to sizing.
fantasai: Was talking to Tab about sizing module.
fantasai: Our proposal: Taking keywords that we have and define
them in terms of CSS2.1 (which makes them mostly
undefined) instead of trying to define thme fully.
fantasai: ... This would let us trim down the spec a lot.
astearns: Sounds like a fine plan, make the edits, send to working
group and see what feedback you get.
<fantasai> https://drafts.csswg.org/css-sizing/
fantasai: Dropping chapter 4 and 5, and fill-available keyword
astearns: Anyone object to this idea?
Florian: Does this limit us to refer to these concepts?
fantasai: No you can still refer to them in Sizing 4.
astearns: I'm not comfortable with resolving on this strategy just
yet as we've only had 5 minutes to think about it.
fantasai: I have an issue with alignment but I'll talk to dbaron
first.
astearns: Adjourned.
Received on Wednesday, 23 March 2016 21:32:59 UTC