- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Feb 2017 20:31:49 -0500
- 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.
=========================================
Request to publish FPWD of CSS Timing Functions
-----------------------------------------------
- RESOLVED: Publish FPWD of CSS Timing Functions.
- The short name will be css-timing.
A new property for text decorations to skip ink
-----------------------------------------------
- RESOLVED: Use text-decoration-skip-ink with at least values of
auto and none and have it cascade separate from
shorthand. We will have some normative text describe
how auto works, but we'll figure the details out in
the future. Do this in L4.
Create a display property value for visually hiding an element while
making it available for AT
--------------------------------------------------------------------
- RESOLVED: Republish CSS Speech CR.
Stretching image grid items in both dimensions
----------------------------------------------
- RESOLVED: The sentence beginning with "Items without an
intrinsic ratio use," is what we as a WG wanted to use.
- RESOLVED: Replaced elements with only one intrinsic size are
sized as start in that dimension and stretch in the
other.
Path to PR with CSS Cascade
---------------------------
- RESOLVED: Drop scoped styles from current level of CSS Cascade.
- There was a request to add tests to the Cascade test suite to
help the spec get to PR.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Feb/0067.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Dave Cramer
Alex Critchfield
Simon Fraser
Tony Graham
Koji Ishii
Dael Jackson
Philippe Le Hégaret
Vladimir Levantovsky
Chris Lilley
Myles Maxfield
Thierry Michel
Michael Miller
Rachel Nabors
Simon Pieters
Anton Prowse
Melanie Richards
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Regrets:
Brian Birtles
Bert Bos
Tantek Çelik
Steve Zilles
Scribe: dael
A new property for text decorations to skip ink
-----------------------------------------------
astearns: We have plenty of people on the call.
<astearns> https://github.com/w3c/csswg-drafts/issues/962
myles: Is koji on?
myles: If he's not on we shouldn't discuss.
Rossen: People trickling in.
Request to publish FPWD of CSS Timing Functions
-----------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Feb/0044.html
astearns: That is something we had decided to do, but birtles is
now ready to prep FPWD. Does anyone have any comment?
<ChrisL> +1 to publication
??: Yes, please
<fantasai> I think it would be good to also get corresponding
updates to Animations and Transitions onto /TR
<fantasai> Otherwise in favor
<fantasai> Last Transitions draft is from 2013
<fantasai> Last Animations draft is from 2013
<fantasai> These are wayyy out of date :(
<Rossen> fantasai, yup...
Rossen: That's the timing functionality that was taken out of web
animations?
astearns: That and frames.
Rossen: Let's do it.
astearns: Objections?
smfr: Does this effect transitions and animations in that it
removes text?
ChrisL: I don't think so.
TabAtkins: In a later publication we should probably remove them,
but it doesn't have an immediate effect.
astearns: And according to birtles it's just frames and he talks
about new timings functions, not so much what's in
transitions and animations.
astearns: Again, objections?
RESOLVED: Publish FPWD of CSS Timing Functions
astearns: Should short name be css-timing or css-timing-functions
lots: Timing, please
astearns: Great. Short name is css-timing
Florian: When doing FPWD and we resolve on a different short name
than the ED what's the procedure for renaming in the
short name?
astearns: If it was just on draft server the short name was
provisional. It's only fixed on FPWD.
Florian: But there are incoming links.
TabAtkins: We have redirecting if needed in the htaccess file.
<fantasai> Florian, yes, inform plinss
<fantasai> We used to have a .htaccess file
<fantasai> We don't anymore
<fantasai> TabAtkins, ^^^^^
<fantasai> plinss is maintaining redirects in a different system
TabAtkins: css-timing hasn't been reffed much but we can set it up.
astearns: [reads fantasai]
TabAtkins: Well, we still have a system.
Florian: Okay, thank you!
<fantasai> TabAtkins, yes, but it doesn't work by editing a file
in the csswg-drafts repo...
<fantasai> wish it did
A new property for text decorations to skip ink
-----------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/962
koji: This is about the resolution to add text-decoration skip ink
to L3.
koji: This is a proposal. 2 discussion points. 1 is property name.
Is text-decoration-skip-ink appropriate? Since we don't do
text underline-skip would be better.
koji: Other is about values. fantasai said auto|yes|no
<fantasai> pretty sure she didn't say yes | no as keywords to
use ...
* fantasai agrees with the principle of what they do
koji: If this is fine what auto should be is a discussion point.
astearns: Let's go one at a time. Can we resolve on changing the
name?
Florian: Related is if it should be part of the L4 shorthand. If
it is it should start with the same thing. If it's not we
can be more creative.
<fantasai> Should not be part of shorthand
<fantasai> It should cascade independently
koji: I'd prefer not to make short hand because this is styling
decoration underlines.
Rossen: I'm trying to understand...this proposed behavior is
supposed to describe what webkit currently does for text
decoration underline?
myles: For skip ink yes
Rossen: And you (myles) do this auto for text decoration underline?
myles: I don't remember exactly.
Rossen: Let's assume you're doing it at least for underline. Is it
done unconditionally? There's no additional optional
values?
myles: Conditionally where you can turn it off. The initial value
was changed to ink so users can use a value of off.
Florian: But if it's on it's always on? auto or yes?
myles: We do auto because we have special CJK behaviors were we
turn on/off at a glyph level.
Rossen: That sounds good.
Rossen: Thank you.
Rossen: Both skip and auto make sense in how you desc them.
<fantasai> text-decoration-ink: skip | no-skip ?
koji: Ink has same behavior in beta(?).
myles: I don't have many preferences. I just have that the auto
keyword to do what I described should not go away.
koji: I agree. We're interested in opt out and opt in.
Florian: Do we need all three or auto and don't skip?
myles: Currently webkit it's impossible to skip on CJK.
Rossen: But you can opt out of the auto with the non-skipping
version?
myles: Yes, you can opt out
Florian: So you have 2 values. Do we want 2 or 3?
myles: The reason we decided to never skip on CJK is because it
looks terrible more or less always. But my preference isn't
strong.
Rossen: We shouldn't make bad decisions easy.
Florian: Adding a value later isn't hard
astearns: We can do auto and no for now. If a need appears later
to force it we can consider it them
<Rossen> +1
myles: I think that's a good idea.
Florian: I think that helps with naming. In that case having
text-decoration-skip: auto makes sense because it knows
not to do line-through.
Florian: That also depends on koji's point about no short hand. I
didn't understand why.
koji: I think you had an example that most of the other properties
apply to a specific element but skip-ink applies to root
elements
Florian: mmm...okay
astearns: And fantasai put in irc that they should cascade
separately. I'm not sure the reason.
astearns: I'm not hearing a strong desire to change the name to
underline.
astearns: I think we should keep the name as text-decoration-skip.
Florian: Even if not part of the short hand?
fantasai: Behavior is a lot more like text underline position.
You'll want to set it at a higher level for how you want
to behave for the document. Turning on and off for the
underline is separate. Thus they shouldn't be conflated.
Florian: Then they shouldn't have same prefix.
fantasai: Yeah, in general we try that but something is closely
related will share a prefix and not be in the shorthand.
astearns: I would prefer the same prefix so you don't have to
remember a different word. And it's easy to remember
difference because people will be using it differently.
koji: We have text-emphasis where it's not in the short hand. I
think if this should be in the short hand can be separate.
Florian: It's intuitive enough.
Florian: Can I suggest off instead of no?
myles: None?
Florian: That's fine too.
Rossen: Can we summarize?
Rossen: I've heard it's text-decoration-skip: auto|none
<Florian> text-decoration-skip-ink: none | auto
astearns: I think it's text-decoration-skip-ink
koji: yes
<fantasai> I'm provisionally OK with this. Need to think about
integration with other text-decoration-skip values.
<myles> ✅
astearns: proposal: text-decoration-skip-ink: none | auto with
auto as the default.
Rossen: Reason to not remove ink?
Florian: There's a level 4 that skips in other places. Ink is a
sub case that's in level 3.
Rossen: So...I see.
<astearns> https://www.w3.org/TR/css-text-decor-3/#text-decoration-skip-property
Florian: Should we define what auto does?
myles: No. :)
Florian: There has been discussion on github that auto shifts the
baseline. I don't think it should do that.
koji: That was a misunderstanding.
myles: If we don't define auto UA can tweak.
Florian: I'd rather UA not to use skipping for positioning.
<fantasai> agreed
Rossen: Aside from bikeshedding I think these are good things to
agree on.
astearns: Is text-decoration-skip-ink with values as none|auto
with auto default...is anyone opposed?
fantasai: It's okay to me. I'd like to think about how it
integrates with other skipping, but it's fine for now.
We should note that it's not in the shorthand.
astearns: Yes, and I believe how it works with the rest is for the
next level.
dbaron: So that's saying that impl are expected to turn it on by
default upon impl.
dbaron: We're saying that there will be no way to opt into more
skipping than default.
Rossen: As of now, yes.
astearns: For this level. We're doing the minimum to finish this
level of text decoration. We'll add more later.
dbaron: Okay.
<dbaron> It feels a little odd to introduce it as a change in
behavior rather than opting in to the different behavior
Florian: As part of peopling auto to UI does that make it
non-testable? Because then auto could be same as none.
astearns: I would prefer having some suggestions that it SHOULD
skip ink in roman but not Arabic.
astearns: I'm not sure that the impl notes should be normative.
Florian: If we don't we can go to rec with no impl.
Florian: That doesn't sound helpful.
myles: If there are non-normative or normative notes they
shouldn't list every language. Maybe a couple of examples
are valuable. Saying which language should and shouldn't
shouldn't be in spec. I should say script, not language.
dbaron: On the other hand then you're asking impl to figure it
out. So 4 teams do it.
myles: The teams can talk.
astearns: I'm not sure any team has an exhaustive list.
Florian: We can have a base case and exceptions.
myles: We can say it's expected to skip in Latin and others are up
to UA.
Florian: Yes. Can that be a must?
astearns: Objection to having a normative must on skipping ink in
Latin cases?
ChrisL: It's not an objection, but it comes across that this is
the language we care about. I know that's not the
intention but it sounds a bit awkward. I don't have a
better suggestion.
<fantasai> +1 to ChrisL
ChrisL: I just have a slight concern. We could ask i18n for help.
fantasai: It would make more sense to go the other way and say
skip ink for everything except cases where you know you
shouldn't. This is mostly on or mostly off. If we want
to make an exception for if there's a case where you
think it looks bad you can not do it. But it should
clearly say if you don't know what to do you should
define what to do
dbaron: Saying do it is awkward for something that will be the
default.
dbaron: If it were an option dev turn on that's fine. But given
that the default is skip ink we need to gather a list
where it would look bad.
<dbaron> Like, say, is skip-ink desirable for Kannada?
<dbaron> or Malayalam?
<fantasai> dbaron: I think it is desired for South Asian and
Southeast Asian scripts. The ones I've investigated use
it.
<dbaron> fantasai, those in particular have different sorts of
descenders, which is why they seem interesting (and
different from many North Indian scripts)
<fantasai> dbaron, http://scripts.sil.org/cms/sites/nrsi/media/LannaThai.png
fantasai: I would prefer on and off and if you want to do it
language dependent you can do it that way.
Florian: It's glyph based.
myles: We found it looks terrible in too many cases with untagged
docs.
Rossen: The huge benefit is when it comes online and it just
works. When I've seen it on Apple it was cool to see it.
No authors had to do anything. I agree we need to do
better homework for when to turn it off by default. I
don't think we need to decide it this moment.
Rossen: We'll continue working on this feature. I think we can
wrap up by agreeing to adopt the properties and values and
then continue tech details of auto's definition.
Florian: In general I agree. I want to add a nuance. I'm okay with
doing homework later. I don't want to call it done in L3
without an explanation.
astearns: Things are going in circle. I think we should close for
now. I do believe we can resolve we're using
text-decoration-skip-ink with at least values of auto
and none and it cascade separately from shorthand. We
will have some normative text describing how auto works,
but we'll figure the details out in the future.
astearns: Objections to leaving it there?
fantasai: The spec is in CR. The goal for me has been to wrap up
issues and do a stable CR. Maybe it should go next draft.
astearns: That's possible.
astearns: Would there be objections to moving this to next level?
Rossen: Once we accept we can move it back in to L3
Florian: I'm okay with L3 or L4. It just needs to be with its
defined normative behavior.
<fantasai> +1 to Florian
astearns: Proposed resolution: everything before in L4
astearns: Objections?
koji: Webkit has a separate behavior we had the ability to opt out
and this removes the ability.
astearns: I think this is process. We're defining it, it's just in
a next module level so we can get to the current impl
interop things done.
Florian: L4 isn't an ED yet
astearns: I'm hearing no objections
<fantasai> I really object to having "no skipping" and "maybe
skipping, not sure if we want this to be mostly
skipping or mostly not skipping"
<fantasai> If it's "no skipping" and "skip unless it's really
bad"... I could deal with that.
RESOLVED: Use text-decoration-skip-ink with at least values of
auto and none and have it cascade separate from
shorthand. We will have some normative text describe how
auto works, but we'll figure the details out in the
future. Do this in L4.
Create a display property value for visually hiding an element while
making it available for AT
--------------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/560
fantasai: I think we decided not to do anything. This was really
if we wanted to do anything with speak or speak-as.
There may be further discussion on this draft, but I
don't see solid proposals. Maybe republish CSS Speech.
astearns: Anyone have something more to add?
astearns: Shall we resolve to close the issue?
fantasai: I would say do we want to republish CSS Speech CR.
astearns: With what changes?
fantasai: We renamed some values and def they're effected by
visibility.
<fantasai> We did that last month
astearns: Objections?
RESOLVED: Republish CSS Speech CR
ChrisL: New features, or just text? Do I do the non-technical?
fantasai: It's non-technical
ChrisL: DoC?
fantasai: I can update in 5 minutes; there were only 2 issues.
ChrisL: And a changes section?
fantasai: Yep.
ChrisL: Thanks.
Stretching image grid items in both dimensions
----------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/523
fantasai: The discussion we had in Seattle...Mats said it was
unclear if we're distinguishing by if it's replaced or
has an aspect ratio. TabAtkins and I thought it should
be based on if they have an aspect ratio. Images that
don't generally take their size from the container
anyways.
fantasai: We need to answer what happens to an image that has no
aspect ratio & no size.
fantasai: An SVG with no viewbox, width, or height
fantasai: Other question is what if it just has width.
Rossen: For SVG these things are defined in integration spec. The
internal sizing algo for all the permutations. I don't
think there's anything new that will be added for SVG.
Rossen: You can word it so SVG is treated as non aspect ratio
image and it won't effect sizing in SVG. It's just a
choice of which to we apply in SVG.
fantasai: Only thing that really makes sense if for it to take the
size of the fixed size grid container. That's what we do
in blocks when we can.
Rossen: I think this is reasonable.
Rossen: From text POV if we tried to make a distinction between
what applies with and without intrinsic ratio this isn't
the place. If we want the spec to call out this applies to
when it has an intrinsic size and this is when it does and
leave out the definition for another spec.
fantasai: Right. We don't say when, but we define different
behavior for when it has one and when it doesn't.
Rossen: From what I understand Mats pushed back this isn't well
defined in grid?
fantasai: We had defined it and Mats pushed back it didn't match
what was resolved in his understanding that all replaced
elements have one behavior which is the shrink to fit.
Rossen: I think if we change the wording to refer to replaced
elements with an intrinsic ratio it solves both issues.
Rossen: Does that sound right?
fantasai: I need to look at the wording.
astearns: As much as I'm following, we need a resolution that our
previous resolution only applies to replaced elements...
Rossen: The other way. It currently applies to all replaced
elements.
<fantasai> https://github.com/w3c/csswg-drafts/issues/523#issuecomment-275869984
fantasai: Here's the comment ^
fantasai: [reads]
dbaron: Yep.
dbaron: I think Mats' point is he wants the WG to resolve
something that matches what people put in the issue. Since
there have been previous edits where edits and the
resolution diverge. He's sensitive that edits and
resolutions can diverge and he's pointing those out.
Rossen: Yes. That's a valid point. Having a tighter definition of
which replaced elements will be good.
fantasai: There's two questions we need to resolve [reads]
<fantasai> The two questions we need to resolve are
https://github.com/w3c/csswg-drafts/issues/523#issuecomment-277103785
fantasai: First should get stretched.
astearns: Before we get to the questions don't we need to resolve
that we meant the previous resolution to only apply to
those with an aspect ratio.
astearns: What is the THIS that only applies to things with an
aspect ratio?
Rossen: Instead of stretch we respect the intrinsic ratio. [looks
for exact previous resolution wording]
<fantasai> Items without an intrinsic ratio use, in both axes, the
width calculation rules for non-replaced block boxes as
defined in CSS2.1 § 10.3.3. (Meaning, auto values in
either axis are effectively sized to fill the remaining
space.) However, the box alignment properties have
special effects: when align-self/justify-self is
neither normal nor stretch, an auto size for the grid
item in that axis is treated as fit-content instead of
as the stretch-fit size. Se[CUT]
<fantasai> Items with an intrinsic ratio follow the same rules,
except that in the case of a normal alignment value, an
auto size for the grid item is sized as for align-self:
start (consistent with the width calculation rules for
block-level replaced elements in CSS2.1 § 10.3.4).
fantasai: Current spec text^
Rossen: The resolution says we're keeping the current behavior
as-is.
astearns: What's the change to satisfy Mats?
TabAtkins: We talked about replaced elements when we meant those
with aspect ratio. Resolving that. Then some questions
falling out from that.
Rossen: Reading from fantasai text we're talking about [reads]
This is talking about intrinsic ratio.
fantasai: That's not what was in the minutes so Mats wants
confirmation.
astearns: Proposed resolution is that the sentence pasted above is
what was intended from the Seattle resolution and we
resolve on that text.
astearns: Objections?
RESOLVED: The sentence beginning with "Items without an intrinsic
ratio use," is what we as a WG wanted to use.
astearns: Okay, the questions.
fantasai: We didn't really talk about the first case. It makes
sense to me that the axis with an intrinsic size should
follow the second clause. In the dimension without a
size it behaves as stretch.
astearns: So that first sentence would be that items without an
intrinsic size in the axis....
Rossen: I'd rather say items with defined size in only one
dimension, that dimension is start and the other is
stretch.
fantasai: I'm happy to word smith, but if we conclude on the
behavior.
Rossen: Proposed: replaced elements with only one intrinsic size
are sized as start in that dimension and stretch in the
other.
ChrisL: I think that makes sense.
astearns: Replaced elements with one intrinsic size and no aspect
ratio.
fantasai: Yes.
astearns: Objections to Rossen proposal?
RESOLVED: Replaced elements with only one intrinsic size are sized
as start in that dimension and stretch in the other.
astearns: We'll let the editors get that into the spec text.
Rossen: fantasai you doing this?
fantasai: I'll do the edits.
Path to PR with CSS Cascade
---------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Feb/0067.html
astearns: Main thing is drops scoped styles.
TabAtkins: Which is due to support. FF might impl, but no one else
is planning on them.
dbaron: We are keeping our impl for now.
fantasai: It is also defined in cascade L4.
astearns: If we drop from level 3 would we also from L4?
fantasai: We can decide on that once we're blocked on PR. Do we
have 2 implementations of revert keyword?
fantasai: That's the main new thing on L4.
* fantasai notes current level is kind of vague, given both are in
CR
astearns: Objections to dropping scoped styles from current level
of css cascade?
RESOLVED: Drop scoped styles from current level of css cascade.
fantasai: We need action items for getting impl test into the repo.
fantasai: If no one wants to import tests they can point to where
the tests are so someone else can import.
fantasai: If we don't have tests we can't go to PR.
astearns: Anyone willing to take an action item?
TabAtkins: I can find the ones for us.
ACTION TabAtkins to find cascade tests
astearns: I guess we'll see if the blink tests are sufficient. I'd
like more participation since we don't do enough
compiling of test suites. I'd rather volunteers.
fantasai: What I can do is I can grab and import the Mozilla tests
and they have 2 copies.
dbaron: I'm having trouble finding tests. The only tests I know we
have are mochitests.
dbaron: You can't import those.
fantasai: If you can drop in the URLs we can look to try and
convert.
fantasai: Then it's more solvable of a problem.
astearns: We're over time. Thanks everyone for calling in.
<Florian> I'd like to take this opportunity to remind people to
watch the csswg-test Pull Request queue. There's quite a
bit of tests there sitting and waiting.
<Rossen> +1 to Florian<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Thursday, 16 February 2017 01:32:55 UTC