- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 8 Aug 2019 05:11:16 -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.
=========================================
Charter Update
--------------
- The new charter ( https://w3c.github.io/charter-drafts/css-2019.html )
will go before W3C management next week. Anyone who would like
to review should do so soon and open any issues on github:
https://github.com/w3c/charter-drafts/issues
CSS Images
----------
- RESOLVED: Default behavior for all images to respect EXIF
orientation (Issue #4165: Should CSS decorative images
respect EXIF-orientation by default)
- The last few edits will go into the spec next week with the plan
of requesting publication next call.
Text Decoration
---------------
- RESOLVED: If multiple layers exist with text-shadows we draw them
all (Issue #3932: Need for clarification on how
::selection text-shadows work)
- RESOLVED: Background on a highlight layer paints over shadows on
layers below (Issue #3932)
- There was concern with the background overpainting leading to
ugly results when the background is smaller then the
text-shadows below it. If there is more information that
this will be a real problem the group will revisit the
resolution.
- The group agreed not to use 'weight' for issue #4138 (Rename
`text-decoration-thickness` to `text-decoration-weight`?)
however there wasn't agreement between 'thickness' and 'width'.
There is one shipped implementation using 'thickness' however
'width' is more consistent with other CSS properties. An on call
straw poll had a slight majority leaning no change/'thickness'
however before resolving the question will be asked again with
more people on the call.
- fantasai will draft proposed text for issue #4134 (What happens to
the wavy & double lines when `text-decoration-thickness` is
applied?) that will give general guidelines that wavy and double
lines must scale, but not giving specific sizes.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Aug/0000.html
Present:
Rossen Atanassov
Tab Atkins (IRC Only)
David Baron
Amelia Bellamy-Royds
Brian Birtles
Tantek Çelik
Benjamin De Cock
Elika Etemad
Simon Fraser
Dael Jackson
Brain Kardell
Myles Maxfield
Cameron McCormack
Melanie Richards
Devin Rousso
Alan Stearns
Fuqiao Xue
Regrets:
Rachel Andrew
Christian Biesinger
Manuel Rego Casasnovas
Christopher Schmitt
Jen Simmons
Greg Whitworth
Scribe: dael
Charter Update
==============
astearns: xfq any update or anything you need from me or Rossen?
<xfq> https://w3c.github.io/charter-drafts/css-2019.html
xfq: Link to current draft^
<xfq> https://github.com/w3c/charter-drafts/issues?utf8=✓&q=is%3Aissue+is%3Aopen+csswg
xfq: Nothing needed from chairs. Here ^ is open issues from florian
xfq: Agree with testing policy change. Haven't done it yet
xfq: Delays of horizontal review haven't made the change because
likely to get objections from horizontal groups. Not a blocker
of W3C management review.
xfq: W3C doesn't have management meeting this week. I will request
review next week. If it gets approved will start AC review soon
<xfq> https://github.com/w3c/strategy/issues/188
xfq: Had a comment ^ from Richard that it would be good to group
deliverables into WD & CRs. I don't object. If no objections I
can do that
astearns: I like Richard's suggestion. I would put CRs at the top so
stuff furthest along is at the top.
xfq: Looks good to me
astearns: For horizontal review might be good to go with template
and open florian issue on template itself to get wider
discussion on how things should get processed
astearns: Sounds great to get review started next week
astearns: Any other issues on the charter please open on the repo
astearns: Anything anyone would like to add or amend to the agenda?
Agenda Setting
==============
fantasai: I've only got 20 minutes
* fantasai looking
<fantasai> images stuff and text-decor
astearns: fantasai anything you want to get to in your 20 minutes?
astearns: Everyone else please look at issues and if an issue is
fantasai related move it up
fantasai: Images, text-decor, Lists 3 on counter
astearns: So follow first 4 items
astearns: Other re-ordering?
fantasai: Let's pull #13 above text-decor
fantasai: I think after that can repub images
CSS Images
==========
Specify fallback behavior when replaced or background image content
not available
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1984
astearns: TabAtkins added but he's IRC only
fantasai: Have some discussion from last week
fantasai: Wanted to get WG review I believe. Then we were supposed
to make edits
astearns: Needs edits tag was removed
fantasai: I'll fix that
astearns: Maybe were edits...There is a PR
<astearns> https://github.com/w3c/csswg-drafts/commit/73d7635574d54f5afb154b5bcf24a2fc086e2093
AmeliaBR: There were edits 3 weeks ago discussed last week. Nothing
since last week
Should CSS decorative images respect EXIF-orientation by default
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4165
astearns: Added by smfr
smfr: Cleaning up issues for if images respect EXIF. Question came
up if decorative ones should respect EXIF. Should we allow
authors to control orientation in decorative images?
smfr: Simple question is do decorative images respect EXIF by default
AmeliaBR: I think default behavior should be to respect it,
especially if that's the default for content images. We
should be consistent unless there is webcompat reasons
AmeliaBR: Like having extra parameter that can change things. Adding
the extra shouldn't delay spec default
fantasai: Default behavior will have to go in L3, image function is
in L4 so it would go there
smfr: One data point I don't think we have web compat data because
no platform has respected EXIF for decorative images by default
astearns: Distinction between content and decorative is background?
smfr: Yeah. Content images are images in replaced elements
AmeliaBR: Instead of decorative we should say css images. Images
spec through css property. Exception is content property.
New image-orientation property would effect images
embedded using content
fantasai: Yeah. Early defined replaced to work using content
property. Definitely interchangeable. List markers and
background images and stuff are not replace in box tree.
Content images are
smfr: Images in SVG too which we haven't talked about
astearns: Concern was on compat for spec default to honor EXIF. Do
you have any idea of what % images used on web have EXIF
data?
smfr: TabAtkins had data. It's less common to use thing with EXIF
data as decorative. I'm not as concerned as I was with content
images. We can try and see what happens
astearns: I know people use background image for content data. I
think it would be surprising to take a URL that's an
image, but it in background and it flips
<TabAtkins> Yeah agree.
fantasai: Agree with AmeliaBR default should be consistent between
all the images
smfr: Happy to resolve now and come back if compat
<TabAtkins> Should agree unless there's compelling compat data.
astearns: Proposal: default behavior for all images to respect EXIF
orientation
astearns: Additional concerns?
astearns: Objections?
RESOLVED: default behavior for all images to respect EXIF orientation
astearns: My understanding is we do not yet have param in image
function to override in next module
fantasai: No. Inclination is not to add unless authors say they want
this. We've historically had problems getting image() impl
so I'd rather not add without demand
AmeliaBR: Have vague resolutions to add params to control image for
things like lazy-load. Once we get all that ecosystem of
params maybe this gets added in if there is demand
astearns: Seems fine place to leave it. Anyone want to fight to put
in a param now?
smfr: I think it's fine. Agree with fantasai to wait
smfr: It is odd we have image-resolution apply to all aster but
image-orientation is content images. Should think in the future
AmeliaBR: Re-access image resolution?
smfr: I would go in other where image-orientation should effect all
images.
astearns: Since we're consistent in orientation data, consistent in
orientation property makes sense
fantasai: Reason why not is that images typically come from
different sources. Might have a bunch of SVG used for
background or border. Not going to want to have that
rotate but might correct rotation so a photograph.
Discussed this in the past and decided does not effect
anything other then content and images
fantasai: Makes sense to be consistent on EXIF. I don't think
explicit values need to be everywhere. I don't think
orientation wants to effect decorative and content
smfr: from-image is the only one you'd care about for css images
AmeliaBR: Only you can assume applies to many images. If you had
content and bg images wouldn't necessary align. Probably
try for image-resolution property. Might be worth
considering finer grain control there. I don't know if
there are impl of that to get author feedback
fantasai: Idea was for css images that we would address use case to
override explicit orientation through image()
astearns: Sounds like we're toward no change for rest of questions
in issue. Correct?
fantasai: Open to adding image orientation overrides in image() if
there's demand. Default is respect EXIF
astearns: Then let's close this issue.
Publication
-----------
fantasai: Just need to make edits for first 2 issues so next week
astearns: And for this issue as well.
astearns: Please take a look at images 3 and likely will call for
republication next week.
<fantasai> For reference, DoC is at
https://drafts.csswg.org/issues?spec=css-images-3&doc=cr-2012
Text Decoration
===============
Need for clarification on how ::selection text-shadows work
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3932
fantasai: I was going over what we want for text-shadows. Came up
with a bunch of questions for ::selection text-shadows
fantasai: Last time we discussed only thought about ::selection but
have multiple highlight pseudos that can layer. Models
discussed don't make too much sense.
<fantasai> https://github.com/w3c/csswg-drafts/issues/3932#issuecomment-510220043
fantasai: Summary ^
fantasai: Default case selection with a background suppresses
text-shadows because otherwise might not get enough
contrast. Spelling and grammar do not suppress
text-shadows. Need to make it that having a highlight
there shouldn't suppress text-shadow below
fantasai: 2 models. Any non-transparent background disables shadows
on layers below. Background on any paints over layers
below.
fantasai: Highlight pseudos might want to change order and paint
background in between
fantasai: There are questions on multi-layers with text-shadows and
they all spec text shadow do we draw top most non-none?
All?
fantasai: I don't have a clear answer to these questions so I want
feedback from WG
AmeliaBR: I don't think have any other way in CSS where you can
composite together text-shadow from different declarations
fantasai: Right, because shadows inherit. Parent inherits to child
so shadow takes effect on child unless you do something.
Here is a bunch of layers without parent/child so no clear
inheritence. But we don't want something like
spelling-error to prevent a shadow just because it now
exists
AmeliaBR: As with everything on selection highlight classes I wish
we could make sense of this in normal cascade way. I think
trying to draw 2 text shadows on same text is strange.
AmeliaBR: For background layering multiple backgrounds seems to make
sense. Question of if it's performant to draw shadows that
will be obscured.
fantasai: I don't care if we draw background over or don't draw
because the background will obscure. Either gets
reasonable behavior
astearns: Main thing is pick easily impl and can be consistent.
Seems edge case because selection happens on editable text.
fantasai: Could select to copy out. That's frequent
smfr: Some add funky text shadow to change anti-aliasing
astearns: ooh, fun.
smfr: I'm confused about how things are supposed to work. Understand
text-shadow style gets cascade into text-shadow on element and
paint result. fantasai sounds like saying selection has own
text-shadow style hence the layers
fantasai: Didn't quite follow. In this case you have a word and it
is a spelling error and a grammar error and it's selected.
fantasai: Properties on each pseudo element cascades in and
inherited through...trying to remember because
changed...[reads spec]
fantasai: You aren't going to have the text-shadow value inherit
from base document element. Properties are inherited from
parent. Each element has own ::selection and the
::selection of span inherits from ::selection of p which
inherits from ::selection of body. Text-shadow around that
word's text-shadow property won't have that value on it.
fantasai: If going to draw text we would see text-shadow:none and
that's not okay for spelling error. You don't expect a
spelling error to suppress shadows. Even though spelling
errors don't have text-shadow you want to draw the shadow
<fantasai> https://drafts.csswg.org/css-pseudo-4/#highlight-cascade
smfr: It's about the decoration style clobbering the text-shadow of
unselected version
fantasai: Could do it for selection, but not for spelling and
grammar. Making it disappear with only difference is
underline doesn't make sense and could make text unreadable
smfr: Implementation no problem paining multi shadow. Prefer to
avoid complex logic if things are transparent
fantasai: 2 related questions. 1: How do we deal with suppressing
shadows when drawing background because selection has
background. Can do that by saying if background in
non-transparent we don't paint shadows below. Or paint
shadows first and then paint background
smfr: background may not be opaque
fantasai: Right. Or smaller then text-shadow
fantasai: You could distinguish between two, but difference isn't
that important question of what's easier to implement
smfr: Want to look at native platform to see if those make sense and
should be matched
fantasai: Second question is if we have multi-layers spec
text-shadow. So author decides spelling error creates a
blurred red text-shadow and grammar is green shadow and
selection is orange shadow, do we draw all or only top
most non-none?
smfr: I think draw all. Draw what author asked for
smfr: Mac native does paint text shadow under selection, I think.
You do get combination
fantasai: Prop: If multiple layers with text-shadows we draw them all
fantasai: Resolve on that?
astearns: Objections?
RESOLVED: If multiple layers with text-shadows we draw them all
fantasai: Background either suppress or paint over lower level, I
think smfr suggests we paint over?
smfr: Yes
fantasai: Background on a highlight layer paints over shadows on
layers below
astearns: Obj?
RESOLVED: Background on a highlight layer paints over shadows on
layers below
astearns: Is that enough to spec interop?
fantasai: That's enough to spec. Interop depends on impl.
astearns: There are test cases I expect will need to be amended to
cover
fantasai: Yeah
<dbaron> I'm not crazy about the background painting over thing.
<dbaron> seems like the shadows may well peek out at the edges.
astearns: dbaron you mentioned you're not crazy about peaking out? I
believe that is the case and shadows will show if larger
then background
fantasai: I don't care which way it goes between the 2
<fantasai> as long as we have an answer
astearns: Let's go with that option. dbaron if you have a change or
objections please update the issue
<dbaron> yeah, I don't feel that strongly, but the behavior seems a
bit ugly
<fantasai> Also OK if we want to make it a UA choice between the two
<fantasai> just so long as it's only those two options and not "do
anything" :)
astearns: Anything else on this?
Rename `text-decoration-thickness` to `text-decoration-weight`?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4138
astearns: Jen suggested weight because typographic term. We have
width, thickness, and weight as possibilities for the
property that determines how wide/thick a text underline is
astearns: Opinions on what we should do?
myles: We shipped thickness. Prefer no change
astearns: Anyone else?
<TabAtkins> I prefer no change
<TabAtkins> (I prefer we'd kept it as 'width', but oh well.)
fantasai: I personally favor width because every other line
thickness in css is width and that's helpful to authors
<fantasai> https://github.com/w3c/csswg-drafts/issues/4138#issuecomment-517121344
fantasai: bradk said same ^
<tantek> +1 fantasai
heycam: Prefer not to change here. I'd like to stick with [missed]
astearns: I believe heycam wanted preference for width
AmeliaBR: Would have leaned width, but not worth changing shipped
implementation
<tantek> seriously how did we all screw this up?
* tantek wants the history / blame on the resolution for thickness
<tantek> outline-width etc.
astearns: Jen suggested weight because it's typographic. Somewhat
against because we don't use it for line thickness
elsewhere. Font has more then line thickness
myles: Also 400 is reasonable weight
astearns: Should reject weight. Have people on both sides of width
and thickness
fantasai: Sympathetic that we impl and shipped. Inconsistency will
effect authors going forward and will have to remember
this is only one that has a different name for what it's
doing. That's an ongoing cost
drusso: Would argue it's different. Thickness of line under text I
don't think is a width. border-width is how wide is it.
Underline people think thick or heavy
fantasai: Majority of people don't speak English, they're looking
for patterns. It's just another line.
<tantek> agreed with fantasai, for non-native English speakers, it
makes no sense to appeal some minute difference of meaning
between thickness and width
myles: Value in css matching colloquial talk
fantasai: Yes. But higher value in css matching itself
astearns: tantek asked for where we resolved on thickness
<astearns> tantek:
https://github.com/w3c/csswg-drafts/issues/3118#issuecomment-432288810
myles: At f2f, forget location. Did twitter poll asking people what
width means, horizontal distance or vertical distance of
line. 60/40 split with 60% being wrong answer
<tantek> wow those linked minutes do not have any reasoning for
thickness
<tantek> that's really bad
<fantasai> https://lists.w3.org/Archives/Public/www-style/2018Dec/0004.html
astearns: I'm torn. Like consistency, but things are shipped. I'm
inclined to leave things as they are with thickness. It's
poss a mistake and we need to create line-weight alias
<tantek> "shipped" is not good enough
<tantek> webcompat would be
fantasai: We won't make an alias. We'll either get this right now or
we live with this
myles: Agree. If we didn't do font-stretch we won't do this
astearns: tantek in IRC says shipped isn't enough, should only
consider web compat. Do we have content using this?
fantasai: Hardly any I think, shipped recently
myles: We did resolve before we shipped
tantek: There's no reasoning in that resolution, not even a straw
poll. I think we should throw that resolution out. I don't
trust it.
myles: You were in the room tantek
tantek: I don't remember it.
astearns: I remember more discussion then captured in minutes, but
it was short.
tantek: Well, it was scribed more now then it was then
tantek: We had resolution on some discussion. I see a non-trivial
amount of folks uncomfortable after the fact. I'd request a
straw poll to see if it's a few of us uncomfortable or if
it's wider questions of the resolution
astearns: Can straw poll
Rossen: We don't have as many people as compared to other calls. If
this is problematic resolution let's push to next week with
more people and give a week to think
tantek: I don't disagree, but doesn't conflict with my straw poll
astearns: For people on call to get tone of room. Please type 0 if
don't care. 1 if prefer width. 2 if you prefer thickness
<bkardell_> 14
<fantasai> fantasai: 1
<astearns> 0
<fantasai> bradk: 1
<myles> 2
<smfr> 2
<dbaron> 2
<Rossen> 2
<bkardell_> 0
<heycam> 2 (because I prefer not changing)
<AmeliaBR> 1
<drousso> 2 (because i'd rather not change)
<xfq> 0
<birtles> 0
<melanierichards> 0
<tantek> 1 / 0 (weak preference)
astearns: People on call slight preference for no change
astearns: Let's set this to go over next week with more people on
call. Decision will be keep thickness or change it back to
width
<tantek> I'm not seeing fantasai or tab on the poll who previously
said 'width' in the above
<bkardell_> slight/weak preference prob, but I said 0 because i
think it is weak
* fantasai is in the poll above
* fantasai also noted bradk's preference, which he asked to have
noted in the meeting
What happens to the wavy & double lines when
`text-decoration-thickness` is applied?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4134
astearns: Should we spec how wavy lines should be drawn?
heycam: More control over these things, more authors will expect
specific effects. Presence of thickness will make people
aware of difference in render for wavy lines
AmeliaBR: Agree something should be specified. No strong opinion of
what. Clear rendering definition is worthwhile
Rossen: Any expectation that this property will be different then
stroke?
fantasai: Yes because when scaling stroke thickness you're not
changing path. Here you expect thickness of line and size
of wave will scale
Rossen: Suggestion is both the control points and stroke change?
fantasai: Yeah because if you don't change control points you just
get a thick line. It is spec as wavy line
<tantek> more thickness = lower frequency?
<astearns> tantek: more thickness = more amplitude
<tantek> text-decoration-radius?
<fantasai> :(
AmeliaBR: Better compare at least for double line is double borders
where as you scale up the total width of border is divided
between two strokes and space between. I'd expect that for
double line. Wavy I'd expect waves to take full width. If
the waves stretch to keep proportional curve that's
unspecified since we don't define what it is to start with.
Rossen: I'd be interested to hear behavior on different platforms.
Desktop word when scaling overall text the thickness and
waviness of underlines does not change. Consistent across
office products. Curious if different
<fantasai> rossen, the issue here is that the thickness of the
underline is specified to change, in that case we can't
be consistent with the platform if the platform isn't
changing the thickness
myles: Couple points. Straight double underlines we've got platform
conventions for position. Shouldn't spec gap. Wavy underlines
a use case is spelling market or cjk names/titles as an
honorific. The shape of those might intend to be different.
Shouldn't give amplitude and frequency controls. If give
controls should be for semantic.
myles: I don't see authors asking for high level of control on
shaping underline
astearns: I don't think talking adding properties. Just specifying
something so get slightly more consistent rendering across
browsers and platforms
fantasai: Might need to just spec that for wavy lines that thickness
of line as well as amplitude and frequency are meant to
scale up. UA can adjust and it doesn't have to be a linear
curve. If you're increasing thickness of line then
amplitude and frequency needs to scale up
fantasai: Can say something similar for doubling. Thickness of 2
underlines and space between should scale. Should look
good in large font sizes.
astearns: We're past time. We should close this.
astearns: fantasai can you come up with a proposal for what to do?
fantasai: If people are happy with the general guidelines I can draft
astearns: Draft it, put in issues, and then we'll agenda+ for
specific text
fantasai: Agree with myles shouldn't spec exact curves and amplitude.
astearns: Thanks everyone for calling in and letting me go a bit
over. We'll talk next week.
Received on Thursday, 8 August 2019 09:12:42 UTC