- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 21 Jun 2017 20:32:11 -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
--------
- The open Values & Units topics will be prepared for discussion
next week.
Make selection change behavior configurable
-------------------------------------------
- There were three proposed options:
1) no change
2) change from current and make it so clicking in
user-select:none undoes current section
3) have two values, one for each behavior
- RESOLVED: option 1: no change and add perhaps a non-normative
note explaining adding this on the root isn't a great
pattern
word-break: break-all doesn't break before sentence-ending punctuation
if UAX #14 is used
----------------------------------------------------------------------
- RESOLVED: line-break: break-all on its own has the effect of
allowing breaks everywhere.
- This change will be put in L3 of CSS Text.
Clipping of content that overflows a column
-------------------------------------------
- RESOLVED: Columns do not clip by default
Clarify that column-* properties only apply to block containers
---------------------------------------------------------------
- RESOLVED: Columns are properties applied to block containers
only.
Alias "nowrap" as "no-wrap"
---------------------------
- Those arguing in favor of the alias did so for author usability.
- However, the argument against the alias is that it adds weight
to the API and sets a precedent for doing this again in the
future.
- The two sides couldn't agree within the time of the call so the
topic was deferred back to github.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jun/0023.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Dael Jackson
Brad Kemper
Tomoya Kimura
Peter Linss
Myles Maxfield
Thierry Michel
Melanie Richards
Florian Rivoal
Alan Stearns
Greg Whitworth
Regrets:
Bert Bos
Tantek Çelik
Daniel Glazman
Tony Graham
Vlad Levantovsky
Simon Pieters
François Remy
Scribe: dael
Rossen: Let's get going.
Rossen: Hello again. As usual, wanted to check if there are last
minute items people want to add to the agenda today
fantasai: We could add bikeshedding outset properties, but that's
only if we run out of topics.
fantasai: top/left/bottom/right shorthands.
Rossen: Yes, we'll do it if time permits.
Spec Rec
--------
Rossen: I only saw gregwhitworth reply. There were a few progress
changes around fonts and variables. Seemed like writing
modes was close. Are we ready with transition fantasai?
fantasai: There were substantive changes to the spec. I can't
recall if it needs CR.
Rossen: Is this on you or Chris?
fantasai: I need to know if we're publishing CR or PR before I
give it to Chris.
Rossen: And I don't see Chris on the call. I'll ping him.
Rossen: Values & units, is it ready?
fantasai: I think changes section isn't compiled.
fantasai: I did find discrepancies between L3 and L4. There's also
open issues in the DoC.
<fantasai> https://drafts.csswg.org/css-values-3/issues-cr-2016
fantasai: I updated with resolutions yesterday. Issue 4 requires
edits and is still open.
<fantasai> https://github.com/w3c/csswg-drafts/issues/708#issuecomment-302240095
fantasai: Issue 13 ^ is still open b/c there are comments from
Patrick.
<fantasai> https://github.com/w3c/csswg-drafts/issues/708#issuecomment-303786908
fantasai: And the one after it ^
Rossen: Do any of those needs to be on the call agenda?
fantasai: I suggest for next week. I'll prep a list
<Florian> Also waiting for CR publication of css-contain. It's on
Chris / Ralph's desks
Rossen: Okay, and last is UI. It was pending some test reviews I
think on fantasai
fantasai: I need to do that. Florian promised to pester me today
* Florian pesters
Rossen: Thank you.
Make selection change behavior configurable
-------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1317
Florian: user-select: none makes it impossible to select things.
But also if something is selected somewhere else in the
doc and you click in a user-select: none area the spec
says this should not effect existing selection.
Florian: I believe we picked this because in native UI there are
often places that are inert. However, someone has said
they sometimes want the other way around where if you
click in a user-select: none area it should unselect.
Florian: Example for that I think was a FB page with posts. Post
content is selectable, but if you click in the empty
areas, like the margin around the post, people expect
that to undo the selection
Florian: My original reaction was then don't use user-select: none
However people that do app-like things do
user-select:none on the root and make some small area
selectable.
Florian: Maybe they shouldn't be doing that, but maybe there is a
need. We should either flip the behavior or create the
ability to do the two behaviors. What do people think?
fantasai: I don't think flipping makes sense. It seems there are
two behaviors wanted here.
Florian: I think I agree flipping wouldn't be good. I'm less sure
if we want 2 values or we recommend people don't do
user-select:none on the root and instead selectively
apply it.
Rossen: Have we circled back with the editing group and asked if
they have any best practices for such scenarios?
Florian: We have not but could.
Rossen: I think they have reviewed these kinds of patterns. I
don't think we should re-invent the wheel here. If they
have a recommendation we should match.
Florian: I think it's fair to ask. I'm not sure we'll get an
answer as the editing TF is focused on content:editable
and that isn't primarily about selection. This is also
used in non-editing places.
Rossen: I don't disagree, but since editing is their charter I
would expect most people would be expert in editing
behaviors and use cases so they may have a recommendation.
If they don't we're at square one.
Florian: Even if they do, this isn't about just editing so we may
not want to just take it. We need to think about
non-editing use cases. That's the majority of the use
cases. This is about making tool bars and labels
non-selectable so when people select something to copy/
paste they don't get UI as well.
Florian: It does interact with editing, but it's not limited to
that.
Rossen: What are the options on the table?
Florian: 1) no change
2) change from current and make it so clicking in
user-select:none undoes current section
3) have two values, one for each behavior.
Florian: Together with option 1 it comes with add a note about
setting user-select:none on the root having undesirable
behavior.
Rossen: What do people think? Can we live with #1?
bdc: From a designer perspective I feel this is a very minor issue
I've never seen before. I feel we have everything in place to
leave as-is. I would personally go with option 1.
Rossen: Thanks.
Rossen: Other opinions or should we resolve?
Rossen: Objections to option 1: no change and add a non-normative
note explaining adding this on the root isn't a great
pattern
RESOLVED: Option 1: no change and add perhaps a non-normative note
explaining adding this on the root isn't a great pattern.
word-break: break-all doesn't break before sentence-ending punctuation
if UAX #14 is used
----------------------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1171
Florian: Title is a bit old. Now, at the last F2F we agreed to add
a break-all value to line-break that might, in isolation
allow breaks anywhere and everywhere. We did not decide
if this should work on its own or if putting it on
line-break should only effect punctuation.
Florian: We said impl would prefer it work on its own and it
appeared unlikely there were use cases to have breaks
around punctuation but not inside words, but we weren't
sure.
Florian: I tried to ping i18n but there has been no answer.
fantasai: I asked on one of the telecons, they said they had not
heard of a use case.
Florian: So we should have line-break: break-all have effects on
its own.
fantasai: I agree.
Rossen: In the absence of other recommendations from i18n or any
other proposals, do we resolve?
fantasai: I think we can.
Rossen: Any other opinions or options before we resolve?
Florian: Proposal: Line-break: break-all on its own has the effect
of allowing breaks everywhere
Rossen: Objections?
RESOLVED: line-break: break-all on its own has the effect of
allowing breaks everywhere.
* fantasai thinks we need a shorthand for line-break and
word-break so that we can have some kind of sensible
interface to all of this nonsense
<Florian> +1 to fantasai
Rossen: Is this a change to the current spec?
Florian: Yes, we're adding this new value.
Rossen: And this is L3 or 4 of text?
Florian: I've made a pull for L3 but I'm not sure we resolved
either way.
Rossen: fantasai, do you have a preference?
fantasai: I don't. I think the feature is so simple it could be in
3.
fantasai: We can mark at-risk.
Rossen: Okay.
Rossen: We'll add it to L3.
Clipping of content that overflows a column
-------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/314
Florian: The TR version of multicol and the ED are contradicting.
Florian: Browsers aren't interop.
Florian: If something overflows from a column should it be visibly
overflowing or clipped when the line is in the middle of
the two columns.
Rossen: Do you mean overflow in the inline direction in a column,
block, both?
Florian: That's the other part. Specs are vague and they don't
define all cases. The case I'm interested in is not the
kind that triggers fragmentation. I'm interested in any
other kind of overflow.
Florian: Both versions contradict. TR says clip, ED says overflow.
Both use wording that means you do that in some cases,
but don't say what to do in other cases.
Florian: I think we should not clip and overflow for everything
for 3 reasons. First, there are use cases for positioned
content to overflow. 2 is that lists, numbered or
bullet...because the default HTML styling have the
bullets overflow by default because it's padding on the
<ul> in the stylesheet. That means bullet stick out and
that's bad.
Florian: If we're doing it for this we should be consistent and
not invent a new behavior to let some things overflow and
some clip.
Florian: That's bad, especially if one day we have a selector to
select column boxes.
<bradk> +1 on those examples
<rachelandrew> I think currently firefox overflows, Chrome clips
<rachelandrew> https://codepen.io/rachelandrew/pen/YpXqNY?editors=110
Rossen: Speaking of our impl, the columns themselves do not clip
and the multicol box wrapping around all the columns may
or may not clip depending on the overflow prop. You're not
clip in either horizontal or vertical. I don't have bugs
suggesting we change this. So I would be in support of
your proposal.
Florian: Current spec says not to clip in some cases, but doesn't
define other cases. The behavior you describe agrees with
FF, but not Chrome. I think Safari is with Chrome.
gregwhitworth: Is there a test case? I'm looking at bugzilla and
all browsers have overflow.
Florian: 5 minutes ago I made a test case and I lost it, but with
a float with a margin that makes it stick out and Chrome
clips that.
Rossen: That's why I was asking about inline or block. Block
direction has very specific rules in fragmentation and
when we have monolithic boxes that don't fragment multicol
lets you create net column. If your column count is fixed
you may overflow in the box direction eventually and that
should be controlled by overflow property.
fantasai: Even if you have fix column count you can overflow by
creating more columns.
Rossen: You're correct.
Rossen: You can always have an item that overflow the height.
fantasai: We're talking about an item that overflows the column
box itself. Overflow in block we're clear it's visible.
Overflow in the inline you have a box in the first
column and it'll overflow, will it overlap content in
the second column?
Florian: That's the core. Slightly broader do we want to
distinguish between types of content that might overflow
or do we want one answer for all the things?
fantasai: I'm guessing one answer is easier to impl.
Florian: Yes, and that's not what the spec says
fantasai: Also, abspos elements is a different question as it's
not in the column.
Florian: It depends on the containing block.
fantasai: Right, they would be clipped by containing block, not
the column necessarily. So the abspos case splits into
two sub-cases.
Florian: I think I would like nothing gets clipped and if people
come up with use cases to clip we'll add a selector for
column boxes and they can use overflow on that.
<Rossen> https://codepen.io/rachelandrew/pen/YpXqNY?editors=110
Rossen: To be on the same page, rachelandrew pasted a codepen^
Rossen: I want to make sure this is the test case we're talking
about. There's an image in the middle which is too wide.
Question is does it clip.
Florian: That's one of the cases.
Rossen: What is see is that all browsers but FF clip.
Rossen: This is most likely a change in our behavior that was made
for interop purposes.
<fantasai> Rossen, the original spec called for clipping iirc,
that's why multiple browsers clip
Rossen: If we agree to not clip it means we'll have to change all
but one implementation. We have to be mindful of the
effect of the overall web compat.
Florian: I thought you said Edge doesn't clip.
Rossen: We didn't used to. At some point we must have changed for
interop.
fantasai: Or it could have been for spec compliance. It did say to
clip.
Rossen: What I wanted to point out is if we change the spec it
means changes to webkit, blink, and edge. I'm not sure
what that would mean for web compat.
Florian: Another argument for that is multicol has been more
successful in printed media and prince does overflow.
Rossen: That could be, though I've seen epub readers use multicol
for pagination. Those might suffer.
Florian: Then again, these do not want to have the selective
clipping and overflow, they likely want always clipping
which is not what we have today.
Rossen: It might suggest this is either an optional value to
multicol where you can say clip or not and then put the
behavior in the author hands and then we decide what the
default is.
Florian: If we want to put it in author hands...
dbaron: It seems like the overflow is the easy way to make it
author controlled.
Rossen: dbaron did you mean overflow of multicol or have it apply
to a selector.
dbaron: Probably some sort of pseudo element. Problem is overflow
defaults to visible and it's weird to have one thing
default to clipping.
Florian: I think visible is a good default. For regular multicol
there's no clear reason why clipping would be a good
default and turning list into multicol isn't crazy.
Rossen: If you put together market share I'd say a majority of
content does clipping.
Florian: You can cope with it, doesn't make it good.
Rossen: It's what's expected on the web.
Florian: Except for people in print and people using FF.
dbaron: I also haven't seen this as a compat issue for us.
gregwhitworth: [missed]
dbaron: I don't remember seeing it
Florian: I don't think it would be mobile browsers, I think it
would be apps that use browser as the run time.
<fantasai> Those would be easier to handle, since when they pull a
new copy of the engine they can make the adjustment via
::column { overflow: hidden; }
Rossen: That's what I was referring to. I've seen multiple touch
webapps that do provide epub experience based on multicol.
Florian: I think that's how ibook works.
Florian: I'd like to go visible by default and have a column
selector that could take overflow.
Florian: Current behavior isn't clip by default. It's clip by
default except something and that's not great.
<dbaron> do Chromium, WebKit, and Edge all clip columns in both
dimensions?
Rossen: What is not clipped? I couldn't find anything.
Florian: abspos and the like?
Rossen: You cannot make a column be a containing block
fantasai: You can make an element in the column.
Rossen: In which case the element itself is clipped.
fantasai: Box can overflow the element.
Rossen: If you have a non-breaking word that expands past the
column it's clipped anywhere except FF
<Rossen> https://bug1282363.bmoattachments.org/attachment.cgi?id=8765359
Florian: And floats with negative are clipped. I haven't tested
transformed content. Maybe everything is clipped, I
haven't tested all variants.
Rossen: Going through the test case what you're desc for abspos is
clipped in FF.
Florian: If we can prove there's no compat problem, would we agree
visible by default is a better behavior or not?
Rossen: I cannot speak on better or not.
Rossen: It's preferential.
fantasai: It's more expected since that's what we do everywhere
else.
<bradk> Overflow should be visible
* dauwhe ran Rachel's codepen through Prince. Photo overflows
column all the way to the page edge
Rossen: I'd like to hear from blink or webkit if they're willing
to change.
myles: I'm not prepared to comment.
TabAtkins: I dunno.
<rachelandrew> I don't have a strong opinion, not sure many
authors are using this (on the web)
Rossen: I think the overall behavior proposed change is well
understood. Let's try to close and see how to move
forward. Florian's proposal is to change the behavior and
define that overflow of items inside columns of multicol
are not clipped. And if we add a column selector with
overflow is a separate topic.
Rossen: In the absence of the column selector, are there
objections to changing the behavior of items being clipped
to not clipped.
<fantasai> is in favor
<bradk> +1
* Florian is in favor
Rossen: objections?
RESOLVED: Columns do not clip by default
Rossen: If there are use cases for clip we'll decide if we need
the selector
<fantasai> It's possible to workaround the lack of clipping on
columns by wrapping the columns entire contents in a
block with overflow: hidden. This also addresses the
weirdness of the clipping boundary being in the middle
of the gap instead of at the near edge.
Clarify that column-* properties only apply to block containers
---------------------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1364
Florian: This is not a hard change for the spec. If there's
agreement I'll do it.
Florian: There is behavior agreement, it's a question as to if we
should update multicol to say it or are we happy with
where it's defined.
Rossen: Opinions?
Rossen: Proposed: leave it where it is, don't change.
fantasai: It's an error in the spec and needs to be changed. We
need an exception for tables where they don't apply to
tables or table wrapper box. That should be called out.
<dbaron> yeah, seems better for the multicol spec to just say the
right thing
fantasai: For sure block containers. The list is really specific
and not quite correct
<gregwhitworth> not tables
Rossen: You propose to change to it applies to only block
containers?
fantasai: Yeah. Block containers is well defined.
fantasai: They weren't when the spec was originally written.
Rossen: Reasonable. Other opinions?
Rossen: Proposal: COlumns are properties applied to block
containers only
Rossen: Objections?
RESOLVED: Columns are properties applied to block containers only.
Alias "nowrap" as "no-wrap"
---------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1537
Rossen: shane added this
TabAtkins: I can explain
TabAtkins: Deal is a while ago we discussed...we agree nowrap was
a legacy mistake. It was a legacy issue. There was
discussion as to if we should try and fix it and add an
alias of no-wrap where nowrap is accepted.
TabAtkins: zcorpan brought up counter argument that they'll have
to recognize no space as they'll have to return it in
cssom. Is it worth it to add the alias?
TabAtkins: My position is same as Naina where I do see people
making this mistake still. I've never been happy with
the no dash version and I still have to fix it when I'm
using the property. I think it's good to add the alias
and in the future just use the dashed one.
Rossen: What's the default and how does this roundtrip? Do we need
to have enough state inside to know which was cascaded as?
TabAtkins: I don't have a strong opinion. It is lower cost to map
the dashed version to the no dash. You don't need
anything new in the data structure. It's probably
better for authors to maintain them separately.
TabAtkins: I would slightly prefer them as distinct values in the
OM, but I'm not hugely opposed.
dbaron: I'd prefer not to have multiple different mechanisms for
value aliasing and I think we have the parse time one.
Rossen: I'm on the same page. As a first step I'd be okay with
parse-only aliasing. Next would make it mess, but we could
do it if we have to.
TabAtkins: I don't remember any other value time aliases. In the
property spec it doesn't matter which way, they'll get
it back. Values don't have that affordance.
Rossen: We have some mostly around legacy webkit values from what
I recall. Again, the feedback is it's a pain, but possible.
Rossen: If we can do parse only aliasing we would be happy. If you
say this makes author life easier that's fine. Supporting
the round tripping...ehhhh...if we have to.
Florian: It's not hard to impl.
Rossen: But cascade is tricky
dbaron: You have to decide if they're different as computed.
Rossen: And if they are different when you have to roundtrip it
becomes messy if they're variables involved
TabAtkins: It's just adding a new value. We take nowrap definition
and copy/paste it to no-wrap.
myles: That's my primary concern. If there's no actually
difference it's only increasing the API surface.
Florian: It doesn't have behavior benefits, but typo benefits.
TabAtkins: I suspect a lot of authors mistype this. I do. Platform
comprehensibility is important and making this one
weird exception work is not 0 benefit.
myles: I don't think adding a new alias value is worth the API
cost.
<dbaron> So in Gecko we have parse-time aliasing for
overflow:hidden/-moz-scrollbars-none,
user-select:none/-moz-none,
writing-mode:horizontal-tb/lr/rl/lr-tb/rl-tb,
writing-mode: vertical-rl/tb/tb-rl, and probably some
others since this was from visually scanning a list of
tables
Rossen: We have 3 possible scenarios.
1) no change at all, don't add dash.
2) add dash as parse aliasing.
3) add dash version as a recognized new value that behaves
same as no dash.
Rossen: What do people prefer?
<bradk> Treat it like a prefixed value?
myles: I prefer 1 because setting up the pure alias that isn't
about prefix sets a precedent. We don't want the to keep
occurring.
TabAtkins: This is fixing a legacy mistake so I don't think this
establishes a strong precedent.
Florian: I think we'll ask about currentcolor but that's where it
will stop.
myles: That we know about now.
TabAtkins: Worse case scenario is if we import more SVG
<fantasai> https://www.w3.org/TR/css-writing-modes-3/#svg-writing-mode
dbaron: I scanned the keyword tables in gecko I found two parse
time for moz prefix and one for standard that's writing
mode. So existing case for parse time is from writing
modes.
myles: Why don't we continue this next week since it's after time?
Rossen: We can try and resolve on #1. TabAtkins would you object
to resolve on no change?
TabAtkins: I wouldn't be the happiest. I wouldn't want to throw
this out because it's late.
Rossen: In that case let's go back to gihub. We can try and
resolve this next week and it'll let Naina weigh in.
* astearns notes that Naina wanted to be on the call for this
discussion
<fantasai> defers to dbaron on this issue, fwiw
<dbaron> I don't have strong feelings about 1 vs. 2
<dbaron> I just prefer not to do 3.
Rossen: We'll continue next week. Thank you everyone, talk to you
next week.
Received on Thursday, 22 June 2017 00:33:16 UTC