- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Aug 2019 19:06:21 -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.
=========================================
2020 F2F Dates
--------------
- Apple will look into dates and locations for the second F2F in
2020. If anyone has conflicts please add them to the wiki so
they can be factored into date selection.
Text Decoration
---------------
- RESOLVED: No limit. If past what the UA can render it's clipped
(Issue #4059: Limits on text-underline-offset to
preserve semantic meaning)
- RESOLVED: No change to the current spec, use thickness (Issue
#4138: Rename `text-decoration-thickness` to
`text-decoration-weight`?)
CSS Images
----------
- Myles will review issue #1984 (Specify fallback behavior when
replaced or background image content not available) for next
week's call.
- RESOLVED: Update note saying this is not for implementation and
will be dropped (Issue #4164: Should the values of
image-orientation include the <angle> variants?)
- After issue #1984 is resolved there will be a call for
republication.
CSS Lists
---------
- It seems like browsers function interoperably in issue #4181
(Should automatic list-item increment adjust for ol[reversed]?)
after the initial value is determined so the group was leaning
toward UA magic to handle this.
- RESOLVED: Update to match 2.1 and make counter(name, none) invalid
(Issue #4163: counter(name, none) should be invalid)
- RESOLVED: Republish Lists 3 with open issue on ol[reversed] and
reversed counter.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Aug/0004.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Dael Jackson
Brian Kardell
Brad Kemper
Peter Linss
Myles Maxfield
Anton Prowse
Devin Rousso
Jen Simmons
Greg Whitworth
Regrets:
Christian Biesinger
Scribe: dael
Rossen: We should get going
Rossen: We have a pretty full agenda.
Rossen: As usual, are there any additional agenda items you want to
consider or any changes to current agenda?
2020 Spring f2f dates
=====================
Rossen: Gentile ping to see where we are with securing space.
Ideally if we can lock the week down.
Rossen: Not adding pressure to organizers, I know it's not easy.
Apple folks, do you have any inclination as to if you're
able to host? If yes, do you have readiness to commit to a
week regardless of location?
<jensimmons> for quick reference:
https://wiki.csswg.org/planning#upcoming-meetings
smfr: We need a week to get answers. Willing to host, need to see if
availability for dates group is interested in
Rossen: When you say dates interested in this is the thing we
wanted. What are the dates?
smfr: Thought we had options
Rossen: Currently only have constraints, but not an actual agreed
week. That's why we're handing it to you to check if there's
a better or easier week
smfr: We can look and come back with options
Rossen: Let's do that. If you can nudge myles or hober or whoever is
handling to look at timing we can go from there
smfr: Any constraints, please add to wiki
<jensimmons> the week of April 13 doesn’t work for me, and likely
Rachel Andrew
Rossen: Definitely. Add constraints now so as Apple looks at
availability they can take those into account.
Rossen: smfr and team as soon as you have preliminary plans ping us
on the private list and we'll make plans. People are trying
to arrange travel
smfr: Do we know normal headcount?
Rossen: Usually 30 +/- 5. Location dependent
dbaron: I'll put in assuming the meeting spacing I'll put where our
dates would be from January and TPAC.
Rossen: We have Spring for Apple and Summer in Kyoto. dbaron if you
want to add ideal space between we can go from there
florian: Kyoto is probably not in summer.
Rossen: I think it was Kyoto/Tokyo/France/NYC so there's
possibilities
Rossen: I'm sure folks will get back to us.
<dbaron> Also, I updated https://wiki.csswg.org/planning with
"evenly spaced" meeting dates, so if people have conflicts
in late April or late July, those are particularly
important to note.
Text Decoration
===============
Limits on text-underline-offset to preserve semantic meaning
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4059
myles: Apple delegation has done internal soul searching and we're
now comfortable with no limit solution. No clamping
<astearns> \o/
<bradk> Yay!
<florian> yay
<jensimmons> Excellent!
Rossen: Is that only thing we wanted to resolve?
myles: I believe that's the only topic of conversation
fantasai: There's going to be a limit because UA has limit of what
it can do. If the spec size is greater then that should
underline be clipped or clamped?
fantasai: Let's say limit is 5 pages long. Author expects underline
on 6th page. Is the underline on the 5th page or not
rendered?
myles: Match text shadow which I believe is clipping
fantasai: Makes sense. If you get greater than a couple pages
clamping gets you unexpected lines, which might overpaint
something unexpected
TabAtkins: I think if it's greater than a few lines it's confusing
so clipping is fine
fantasai: Proposal: no limit. If past what UA can render it's clipped
<florian> +1
Rossen: Okay.
Rossen: I'm the biggest non-fan but won't object
Rossen: Any objections or comments or can we resolve?
Rossen: Objections?
RESOLVED: No limit. If past what the UA can render it's clipped
Rename `text-decoration-thickness` to `text-decoration-weight`?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4138
Rossen: Last week discussion narrowed to 2 choices.
Rossen: Evenly distributed preference. More people voting thickness.
<fantasai> largely due to the "no change from impl" principle
Rossen: Are we ready to resolve on thickness?
bradk: What are the 2?
jensimmons: I opened this and didn't intend to re-open thickness vs
width conversation. My intention was to say is weight a
good solution. I think it's great and makes sense to
lots of people. Opposite is that text-decoration-weight
doesn't match values. Seems like you guys disregarded
weight.
jensimmons: I'd rather keep thickness
Rossen: Did rule out weight. Slight preference, but wanted majority
of group to resolve on not change. That way FF can move
forward and we can close the issue
jensimmons: Does look from straw poll...Looks to me there was a
definite preference for thickness, lots that didn't
care. Some people preferred width.
fantasai: A number were due to not wanting a change. It wasn't so
much preference as not change things
bradk: Width is not under consideration?
Rossen: Width was last week. We can take a straw poll again.
Rossen: Higher level discussion. We did rule out weight. Going to
original issue it was rename thickness to weight and we can
say no. In the middle of that width was brought up with some
preference for width. Fine spending a few minutes about
rename to width. Or just close original issue no change
Rossen: Anyone want to straw poll?
<fantasai> curious to poll a) weight b) thickness c) width d) no
change (= thickness)
bradk: I'd like width so consistent with other border thicknesses. I
think it's unnecessary cognitive burden to remember which is
which
myles: You're right about the burden. But also burden in calling it
something unrelated to what it does. Web search to change
underline the results say thickness. So people are clearly
using that.
bradk: Boat has sailed. If we change to thickness we should have
border-thickness and outline-thickness
myles: We've got 1 shipping impl and 1 non-shipping
bradk: I meant borders have thickness not width
jensimmons: Agree with myles. At the heart some people come at this
from css prospective and they're looking for internal
consistency and things should match. On the other hand
there are folks who are looking at the words for what
they are and consistency beyond CSS and intuitive for
learning CSS. And they say it's okay because it makes
sense in the larger world
<chris> Agree with myles and jen
jensimmons: Every time I see width I think it means the length of
the line not the thickness. I totally understand where
both prospectives come from. I think we don't share same
way of looking at things.
<fantasai> border-width, outline-width, stroke-width
bradk: To me there's so many terms an author has to learn that
having 2 terms for same concept is confusing and makes it
harder to learn. New user that learned thickness of a border
is border-width or an older user with that ingrained it's
harder to remember text-decoration is thickness for the same
concept of how wide the line stroke is.
Rossen: I don't want to re-do the entire conversation. I want us to
resolve what is the stroke called. We ruled out weight. I
see IRC advocating weight. I prefer to keep this to
thickness vs width
Rossen: I hear both sides and bradk has a valid case here for width.
Rossen: Let's take a straw pool
jensimmons: I'm disappointed that I proposed weight and it was
considered in a meeting where I wasn't there. Normally
folks try and make people in the conversation. And now
we're re-litigating a decision. I'm surprised this
happened because that's not usual for the group
Rossen: You had asked us to discuss without you here. We don't
usually hold off when there's group consensus. Making
decisions in that regard is fine and according to what we've
been doing. It's also fine to bring the topic back and say
you want to re-discuss something.
<florian> Jen did say we could decide without her. But if we are
re-litigating, I think her option should be included
<fantasai> +1 to Florian
Rossen: We can have a straw poll of thickness vs width. Since you're
bringing the point back if you want to reintroduce it let's
add weight for completeness. We'll decide based on straw
poll. Sound fair?
florian: Can we use fantasai straw poll?
<fantasai> suggestion was a) weight b) thickness c) width d) no
change (= thickness)
Rossen: Best to use same order as first time.
Rossen: Nevermind, first didn't have weight
Rossen: a) weight b) thickness c) width d) no change (= thickness)
Rossen: Enter choices in IRC
<myles> BBBBBBBBBB
<bradk> C) -width
<bkardell> present+
<fantasai> c
<smfr> b
<astearns> d
<jensimmons> Prefers A. Would be ok with B.
<plinss> c
<chris> b
<drousso> b
<stantonm> b
<TabAtkins> b due to compat, c in my heart
<fantasai> TabAtkins, that would be d :)
<TabAtkins> oh so I guess that's D, not B. Then C in my heart.
<Rossen> b
<dbaron> b or c
<rachelandrew> b
<florian> abstain
<emilio> b
<dauwhe> b
Rossen: Waiting on anyone?
Rossen: 10 seconds
<chris> looks like the winner is B
Rossen: I think it's clear decision is thickness and no change to
current spec
Rossen: Resolve on no change to the current spec, thickness
RESOLVED: No change to the current spec, use thickness
Rossen: jensimmons anything else FF engineers waiting on?
jensimmons: Another issue fantasai was writing text on
Rossen: Anything on the agenda?
jensimmons: No, thanks
<jensimmons> there might be clarifications needed about wavy and
double lines…. https://github.com/w3c/csswg-drafts/issues/4134
fantasai was tasked with working on the spec.
<fantasai> jensimmons, for the record, I think what I was actioned
to write was that the line thickness, amplitude, and
frequency should scale together (not necessarily strictly
proportionally, but roughly proportionally), and double
similar to border-width: double in the same way
CSS Images
==========
Specify fallback behavior when replaced or background image content
not available
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1984
<TabAtkins> https://github.com/w3c/csswg-drafts/commit/3f884b87c54b38afd7742fb8e123a7d27ddd3ac4
TabAtkins: When we spoke last time waiting on Apple; myles wanted to
review. fantasai committed text [above] for replaced
image. Want to ensure spec did not rule out leaving image
in place while waiting for new image
TabAtkins: If Apple wants to review that's fine but want to do
soonish
myles: Can I give myself an end of week deadline?
TabAtkins: Next call is fine.
Rossen: Next week's call is fine. TabAtkins anything else on this?
TabAtkins: It's good
<fantasai> myles, end of week would be great in case you have things
we should try to fix before the call :)
Should the values of image-orientation include the <angle> variants?
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4164
smfr: WK is working on image-orientation. there's one with angles
and one without. Any other browsers interested in angle
variants?
fantasai: Because we made from-image default orientation I don't
think strong use case for none. If not having web compat
problems is this a necessary property? Still need
definition because css print profile. If defaulting to
EXIF do we need property at all?
<dbaron> I didn't think the <angle> values were useful...
TabAtkins: I don't recall affirmative use cases for none
myles: Easier to add CSS to fix a busted image then to rotate
fantasai: True. Ideally information should be in image or html. If
photo is sideways it's data is wrong
fantasai: If you turn off CSS or in reader mode you want it to be
upright. If image is wrong you should fundamentally fix
and not patch with CSS
emilio: Gecko impl the angle values and unshipped when spec
deprecated it. I don't think it's a lot of work to
re-implement them
<emilio> https://groups.google.com/d/msg/mozilla.dev.platform/A1aaENcsR6k/fPB1AvyaCAAJ
dbaron: I also don't think that useful and a weird use of angles
myles: Under specified because don't say which orientation rotated
from
<fantasai> rotated from the orientation before applying EXIF
TabAtkins: Question on myles' comment. Use case was something where
image pixel are correct and EXIF is busted? Or more broad?
myles: Yes. Comment not about angle value, but presence of property
TabAtkins: With regards to angles unspecifying implication was
rotation from none...says 0deg corresponds to none.
Implies you rotate from that. I don't think
underspecified, but can be tweaked. Hopefully don't need
to be implemented. They're there because print renderers
have them.
<myles> TabAtkins: where does it say that 0 means none?
<myles> i don't see it
<TabAtkins> myles, hm, I was sure there was something written there
about that. Guess I remembered wrong.
smfr: fantasai suggested removing property. But if Mozilla has been
shipping with from-image removing is tricky. emilio do you
have info on how long shipped?
emilio: I don't think we have use counters. Could add. Been shipping
for a long time if I recall. I'll find a link
<emilio> smfr: https://bugzilla.mozilla.org/show_bug.cgi?id=825771,
landed in ff 26
dbaron: If we're going to try and change the default I would suspect
that any of the things using it are doing so to set
from-image not none
fantasai: +1
fantasai: Unless using it to set a value other than from-image
there's not a change if we remove property. Already
resolved to change initial to from-image so might not need
property
smfr: Possible to get photos with bad EXIF information. If you take
a picture straight down you get an angle. I can imagine trying
to fix that. It does fail with things that strip css
fantasai: My inclination is impl that support this try and switch to
from-image as default. Impl that don't change to from or
EXIF. If that works we try and remove property. If it
doesn't we keep
<dbaron> What fantasai just said sounds like a good plan to me.
plinss: If building photo editing software might want to show image
naturally as it is and then manually rotate
TabAtkins: Editing you're parsing photo into a canvas?
plinss: Maybe. Could parse EXIF data yourself, but there is utility
to keeping. Agree from-image and none are only properties
with from-image as default
Rossen: unshipping of Mozilla behavior and resolve on that behavior
Rossen: Which way are we leaning?
TabAtkins: Fine with dropping if impl are okay on supposition we can
make switch to from-image
plinss: Compat risk when I was writing code for this you don't know
if browser will rotate and can't tell. Anyone with code that
cares about this is already screwed so wouldn't worry about
compat.
plinss: Would be nice if you can tell browser rotated but don't know
how to tell in css
fantasai: Query size of box if it's not square and get aspect ratio.
Can tell you a bit
<TabAtkins> plus, as established, the number of images with
non-Top-Left orientations is < .0001% of all images on
the web.
plinss: But then have to parse image and then you might as well
parse EXIF data
Rossen: Leaning toward dropping image-orientation
fantasai: Proposal: update note in draft to indicate we might drop
the entire property for browsers and keep a definition
with the <angle> values for historical reasons and say
it's optional. Then remove. Or information this is in css
print by not rec for impl
Rossen: Proposed resolution: Update note saying this is not for
implementation and will be dropped
Rossen: Objections?
RESOLVED: Update note saying this is not for implementation and will
be dropped
Publication
-----------
Rossen: If we've got 1984 still open we'll push republish until next
week
CSS Lists
=========
Should automatic list-item increment adjust for ol[reversed]?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4181
TabAtkins: If we can achieve through UA stylesheet or do magic.
Magic to host language or in css
TabAtkins: emilio points out [missed]
[audio problems with Tabatkins' line]
<TabAtkins> So anyway, Emilio points out that it's literally
impossible to do the [reversed] behavior via UA
stylesheet.
fantasai: We have normal lists, they're great. We have reversed
lists where increment is -1. Where you start is a separate
issue. Each li decrements counter needs to be implement.
Only magic is that it's incremented by 1 on list item box
<fantasai> ol[reversed] > li { counter-increment: list-item -1; }
fantasai: Put in spec you can do on UA stylesheet. Works in general
easy case. HTML spec includes any box with display of
list-item in the numbering and excludes non-list-items. If
you put a div in the li and give that a display: list-item
it increments. The list relies on the CSS
fantasai: You can't reflect the current behavior. I can try and
share a test case
<TabAtkins> aka the [reversed] behavior is *literally* just "do
normal list item numbering, then reverse all the numbers"
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Col%20reversed%3E%0A%3Cli%20style%3D%22border%3A%20solid%22%3E%20x%3Cdiv%20style%3D%22display%3A%20list-item%22%3ETest%3C%2Fdiv%3E%0A%3Cli%3E%20y%0A%3Cli%3E%20z%0A%3C%2Fol%3E%0A
fantasai: 3 things we can do. 1) use UA stylesheet and get impl to
do something different that doesn't account for display
value of boxes. 2) have magic and host lang can change
magic. 3) create css property that says what magic
increment is
<fantasai> Behavior of li counting in HTML
https://html.spec.whatwg.org/multipage/grouping-content.html#the-li-element
dbaron: I think there are a bunch of edge cases that suggest
modeling this as a decrement is wrong approach. 2 ways to
model. Starting value is magic, items decrement, counter
goes forward. Other is counter counts from end to beginning.
This is different results at times, like if you change
counter in the middle
dbaron: Tend to think modeling this as magic to get the beginning
and then decrements will get wrong result in a bunch of cases
TabAtkins: You think counting backwards and interacting with
counter-set is good?
dbaron: I'm looking at browser behavior and actual behavior of value
attribute with reverse is not sensible or interop
dbaron: Maybe value is already broken and other way is right
TabAtkins: Something odd in FF. FF and Chrome agree value effects
following things and not proceeding. Differences in what
number the very first item starts in. They agree it's
count forward
dbaron: Maybe stuck with wrong model
TabAtkins: Both models have arguments. Fine with either
fantasai: Did run a test with decrement as -2 and it starts counting
into negative numbers. Start number was no adjusted to
account for that
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3Eli%20%7B%20counter-increment%3A%20list-item%20-2%3B%20%7D%3C%2Fstyle%3E%0A%3Col%20reversed%3E%0A%3Cli%20style%3D%22border%3A%20solid%22%3E%20x%3Cdiv%20style%3D%22display%3A%20list-item%22%3ETest%3C%2Fdiv%3E%0A%3Cli%3E%20y%0A%3Cli%3E%20z%0A%3C%2Fol%3E%0A
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7121
<TabAtkins> Dunno why Firefox starts numbering at 7 even tho there
are only six items.
Rossen: From the 3 choices at the beginning seems like we're getting
to none of them?
TabAtkins: Aside from that my test shows a weird start number,
browsers seem consistent in how they treat things
TabAtkins: Figure out value of last item that would increment, use
that as the first value. Figure out magic value where if
nothing screws with numbering gets you to 1 and then
start at that ind do minus 1
TabAtkins: I'm on side of UA magic so there's interop I don't
believe css needs to control on it's own.
dbaron: html editors might be unhappy. html editors seem unhappy
that css claims their stylesheets are doing wrong thing
TabAtkins: [missed] reverse engineering at the time and we're saying
do this with css now. Seeing you got no bugs I think
we're fine and we can do this
<Rossen> fwiw current Edge result is [-1, 1, -1, -2]
fantasai: Still not clear on how reverse is supposed to work.
fantasai: Would like to get updated draft published because cleaned
up counters section substantially. We should publish and
mark reverse lists as an open issue.
fantasai: Should we publish draft with previous state or should we
publish with the concept of the magic increment? Should
leave issue open, but what to publish with
fantasai: Inclination is publish no change from previous because
that's clear we have not solved and update later after we
conclude
Rossen: Do you want to discuss next before publish?
counter(name, none) should be invalid
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4163
fantasai: If you say counter(name,counter-style) it represents list
using that. There is a none value that's value of list
styletype. Some implementations think that's valid as a
counter style. CSS 2.1 forbids that. I updated spec to
match css2.1
fantasai: If people disagree and think counter(name, none) should be
valid we can reconsider
TabAtkins: I wrote that near 10 years ago. Can't comment on
justification so whatever
fantasai: Objections to updating spec to match 2.1?
<TabAtkins> No objection.
RESOLVED: Update to match 2.1 and make counter(name, none) invalid
Publication
-----------
Rossen: Prop: Republish css lists 3 with everything changed and open
topic on reverse counters and reverse to previous draft state
<TabAtkins> I want to make sure we're not putting the ol[reversed]
rule back in the stylesheet.
<TabAtkins> Because that def doesn't match any implementation
whatsoever.
<TabAtkins> And never will.
<TabAtkins> Okay so I'm opposed to putting it back in any case.
fantasai: stylesheet in appendix we should put it back and make it
clear it's an interpretation. Also okay not mentioning
reverse at all and removing it
Rossen: Okay republishing with removing?
<TabAtkins> Yeah, let's remove all official mention, and just have a
note that "hey this exists, we'll define how it works
later"
fantasai: Yes, if removed and not says it's magic
<fantasai> wfm
Rossen: Will republsish with issue open
Rossen: Objections to republish lists 3 with open issue on
ol[reverse] and reversed counter
RESOLVED: Republish lists 3 with open issue on ol[reversed] and
reversed counter
Received on Wednesday, 14 August 2019 23:07:55 UTC