See also: IRC log
<TabAtkins> fantasai: Align is published.
<fantasai> TabAtkins: Same diff. Implementations are free to use magic to implement it, but it should behave the same. If that set of rules does not yield Web-compatible behavior then we need to fix it so it is, so that the “magic” behavior is defined.
<astearns> trackbot, start meeting
<scribe> ScribeNick: dael
<fantasai> astearns, #5 can probably be done without me
<TabAtkins> Can someone adjust the topic to point to the current week's agenda?
<Rossen_> resent+
<Rossen_> hmm.... that's not where I needed a missed "r" :)
<myles> astearns: Rossen_: can we do the text decoration one first? i have to drop off early
<smfr> resist+
astearns: We'll start in a couple of minutes.
<astearns> sure
<Rossen_> I'm sure we can - Alan is driving today's call
astearns: We have plenty of people on the call.
<astearns> https://github.com/w3c/csswg-drafts/issues/962
myles: Is koji on?
... If he's not on we shouldn't discuss.
Rossen_: People trickling in.
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Feb/0044.html
<ChrisL_> +1 to publication
astearns: That is something we had decided to do, but birtles is now ready to prep FPWD. Does anyone have any comment?
??: Yes please
<fantasai> I think it would be good to also get corresponding updates to Animations and Transitions onto /TR
<myles> r+ r=me
<fantasai> Otherwise in favor
Rossen_: That's the timing functionality that was taken out of web animations?
astearns: That and frames
Rossen_: Let's do it
astearns: Objections?
<fantasai> Last Transitions draft is from 2013
smfr: Does this effect transitions and animations in that it removes text?
ChrisL_: I don't think so.
<fantasai> Last Animations draft is from 2013
<fantasai> These are wayyy out of date :(
TabAtkins: In a later pub we should probably remove them, but it doesn't have an immediate effect.
<Rossen_> fantasai, yup...
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.
... again, objections?
RESOLUTION: Publish FPWD of CSS Timing Functions
astearns: Should short name be css-timing or css-timing-functions
lots: timing please
astearns: Great. Short names is css-timing
Florian: When doing fpwd and we resolve on a different short name than the ED what's the proceedure 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.
<fantasai> Florian, yes, inform plinss
<fantasai> We used to have a .htaccess file
<fantasai> We don't anymore
<fantasai> TabAtkins, ^^^^^
TabAtkins: We have redirecting if needed in the htaccess file.
<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...
<astearns> https://github.com/w3c/csswg-drafts/issues/962
koji: This is about the resolution to add text-decoration skip ink to L3
<Rossen_> koji, it is very hard hearing you
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 skipping would be better
... Other is about values. fantasai said auto|yes|no
... If this is fine what auto should be is a discussion
point.
<fantasai> No, it also affects overlines
astearns: Let's go one at a time. Can we resolve on changing the name?
<fantasai> Should not be part of shorthand
<tantek> belated IRC-only regrets for the first part of this meeting
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> 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 desc 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'r 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.
<fantasai> text-decoration-ink: skip | no-skip ?
Rossen_: That sounds good.
... Thank you.
... Both skip and auto make sense in how you desc them.
koji: Ink has same behavior in beta
myles: I don't have many preferences. I jsut have that the auto keyword to do what I desc should not go away
<RachelNabors> Paying my respects to the newborn timing functions spec <3
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 thinkt hat helps with naming. In that case having text-docration-skip: auto makes sense because it knows not to do line-through
<fantasai> Florian, read up
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 sep. I'm not sure the reason.
... I'm nto hearing a strong desire to change the name to
underline.
... 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 doc. Turning on and off for the underline is seperate. 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 seperate.
Florian: It's intuitive
enough
... Can I suggest off instead of no
myles: None?
Florian: That's fine too.
Rossen_: Can we summerize?
... 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
<myles> ✅
astearns: proposal text-decoration-skip-ink:non|auto with auto default
Rossen_: Reason to not remove ink?
<fantasai> I'm provisionally OK with this. Need to think about integration with other text-decoration-skip values.
Florian: There's a level 4 that skips in other places. Ink is a sub case that's in level 3.
<astearns> https://www.w3.org/TR/css-text-decor-3/#text-decoration-skip-property
Rossen_: So...I see.
Florian: Shouldw e define what auto does?
myles: No. :)
Florian: There has been discussion on github that auto shifts the baseline. I don't htink 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.
Rossen_: Asside 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.
... We're saying that there will be no way to opt into more
skipping then 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.
Florian: As part of peopling auto to UI does that make it non-testable? Because then auto could be same as none.
<dbaron> It feels a little odd to introduce it as a change in behavior rather than opting in to the different behavior
astearns: I would prefer having
some suggestions that it SHOULD skip ink in roman but not
arabic.
... I'm not sure that the impl notes should be normative
Florian: If we don't we can go to
rec with no impl.
... 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 lang should and shouldn't shouldn't be in spec. I should say script, not lang.
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 exustive 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?
<fantasai> dbaron, in this particular case we apparently have precedent from the ancient browsers if the 1990s :)
astearns: Obj to having a normative must on skipping ink in latin cases?
<fantasai> +1 to ChrisL
ChrisL_: It's not an objection,
but it comes across that this is the lang we care about. I know
that's not the intention but it sounds a bit awk. I don't have
abetter suggestion.
... I jsut have a slight concern. WE could ask i18n for
help
fantasai: It would make mroe sense to go the other way and say skip ink for everything except cases wher eyou know you shouldn't. Tihs 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 awk for
something that will be the default.
... If it were an options 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.
fantasai: I would prefer on and off and if you want to do it lang dependant you can do it that way
Florian: It's glyph based.
myles: We found it looks terrible in too many cases with untagged docs.
<dbaron> Like, say, is skip-ink desirable for Kannada?
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.
<dbaron> or Malayalam?
Rossen_: We'll continue wokring on this feature. I thinkw e can wrap up by agreeing to adopt the prop 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 ot call it done in L3 without an explination.
<fantasai> dbaron: I think it is desired for South Asian and Southeast Asian scripts. The ones I've investigated use it.
astearns: Things are going in
circle. I think we should close for now. I do believe we can
resolve we're using txt-decoration-skip-ink with at least
values of auto and none and it cascade sep from shorthand. We
will have some normative text desc how auto works, but we'll
figure the details out in the future
... Obj 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.
WOuld there be obj 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 jsut needs to be with its defined normative behavior
<fantasai> +1 to Florian
astearns: proposed resolution:
everything before in L4
... obj?
koji: Webkit has a seperate 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.
<dbaron> fantasai, those in particular have different sorts of descenders, which is why they seem interesting (and different from many North Indian scripts)
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"
RESOLUTION: Use text-decoration-skip-ink with at least values of auto and none and it cascade sep from shorthand. We will have some normative text desc how auto works, but we'll figure the details out in the future. Do in L4
<fantasai> If it's "no skipping" and "skip unless it's really bad"... I could deal with that.
<astearns> https://github.com/w3c/csswg-drafts/issues/560
<myles> byebye!
<Rossen_> bye myles
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 o nthis draft, but I don't see solid proposals. Maybe repub CSS Speech.
astearns: Anyone have something more to add?
<fantasai> dbaron, http://scripts.sil.org/cms/sites/nrsi/media/LannaThai.png
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
astearns: Objections?
<fantasai> We did that last month
RESOLUTION: Republish CSS Speech CR
ChrisL_: New features, or jsut 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.
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Feb/0067.html
fantasai: The discussion we had
in Seattle...mats said it was unclear if we're discutinguishing
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.
... We need to answer what happens to an image that has no
aspect ration & no size.
... An SVG with no viewbox, width, or height
... OTher question is what if it just has width.
Rossen_: For SVG these things are
def 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.
... 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.
... From text POV if we tried to make a distinction between
what applies with and without intrinisic ratio this isn't the
place. IF we want the spec to call out this applies to when it
has an intrinisic 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 udnerstand 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 resolve din his understanding that allr eplaced 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 intrinisic ratio
it solves both issues.
... 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
^
... [reads]
dbaron: Yep.
... 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.
<fantasai> The two questions we need to resolve are https://github.com/w3c/csswg-drafts/issues/523#issuecomment-277103785
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]
... First should get stretched.
astearns: Before we get to the
questions don't we need tor esolve that we meant the previous
resolution to only apply to those with an aspect ratio
... What is THIS that only applies to things with an aspect
ratio
Rossen_: Instead os stretch we respect the instrinisic 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. See [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 meanth those with aspect ratio. Reoslving that. THen some questions falling out from that.
Rossen_: Reading from fantasai text we're talking about [reads] This is talking about intrinisc 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.
... Objections?
RESOLUTION: 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 abotu the first case. It makes sense to me that the axis with an intrinisic 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 intrinisic size in the axis....
Rossen_: I'd rather say items with defined size in only one dimension, that dimenstion 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 intrinisic size are sized as start in that dimension and stretch in the other.
ChrisL_: I think that makes sense.
astearns: repleaced elements with one intrinisic size and no aspect ratio
fantasai: Yes.
astearns: Objections to Rossen_ proposal?
RESOLUTION: replaced elements with only one intrinisic 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.
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Feb/0067.html
astearns: Main thing is drops coped styles
TabAtkins: Which is 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 impl of revert
keyword?
... THat's the main new thing on L4
astearns: Obj to dropping scoped styles from current level of css cascade?
RESOLUTION: dropscoped styles from current level of css cascade
fantasai: We need action items
for getting impl test into the repo.
... If no one wants to import tests they can point to where the
tests are so someone else can import.
... 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
<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.
ACTION TabAtkins to find cascade tests
<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.
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 mochi (sp)
tests
... You can't import those.
fantasai: If you can drop in the
URLs we can look to try and convert.
... Then it's more solvable of a problem.
<dbaron> layout/style/test/test_all_shorthand.html was the one I found
<dbaron> but it's a mochitest
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
<gsnedders> I'll also point out we still haven't made most of the metadata optional in the tooling so there's still a fair bit of metadata to add to tests if we want them for css-cascade
<fantasai> dbaron, making sure all of the things Mozilla has tested is also tested in the CSSWG test suite would make me a lot more confident that we've got good test coverage, even if we can't actually import the tests themselves. :)
<gsnedders> Of course, if we're just starting a new testsuite, we could just try putting them in web-platform-tests and using the tooling everyone else has been using.
<fantasai> dbaron, Mozilla devs are good at figuring out which tests need to be written
<Florian> tantek: can you review these: https://github.com/w3c/csswg-test/pull/1196 https://github.com/w3c/csswg-test/pull/1193 https://github.com/w3c/csswg-test/pull/1192https://github.com/w3c/csswg-test/pull/1192
<Florian> tantek: if not, who should? (I can't, I wrote them).
<fantasai> gsnedders: cascade is relatively small, it won't be too difficult to tag them
<gsnedders> fantasai: I'd like to see if the group actually finds the tooling everyone else has been using acceptable and then we can move away from our custom tooling even sooner
<fantasai> gsnedders: I'm not familiar with WPT tooling. Can it give me a list of tests applicable to a particular section of a spec?
<dbaron> fantasai: really, the way to find the Mozilla tests for things is to find the bugs that implemented the features that you want the tests for (including the other fixes in their dependency tree), and figure out where those patches added tests
<gsnedders> fantasai: insofar as it is encoded in the path of all tests, yes
<fantasai> dbaron, yeah :/ Would be nice if Mozilla had a better path-based sort
<fantasai> dbaron, or put Web platform tests into the appropriate export directories by default
<fantasai> whenever appropriate
<gsnedders> fantasai: WPT in general has avoided the CSS habit of putting hundreds/thousands of tests in one directory
<gsnedders> fantasai: and maintained a mapping of directory structure to section, which has as far as anyone can tell sufficed
<fantasai> gsnedders: That's not going to cover interaction tests, of which we have many
<dbaron> fantasai: we generally do, but there are a bunch of features that it's easiest to test by putting tests into existing large mochitests
<dbaron> fantasai: which we should probably have a CSSWG version of, but I haven't gotten to doing that
<dbaron> fantasai: In particular, I'm thinking of all the tests we have that are based on layout/style/test/property_database.js
<fantasai> dbaron: I recall you importing the CSS2.1 version of that at one point
<dbaron> fantasai: never finished
<gsnedders> fantasai: as does WPT; it's not ideal but there's never been anyone willing to add metadata to tests to make such a tool useful
<gsnedders> fantasai: (for interaction tests, that is)
<gsnedders> fantasai: either at test authoring time, or in hindsight
<gsnedders> fantasai: everyone else survives without this tooling despite interaction tests being no more rare; why does it make such a huge difference to the CSS WG?
<astearns> trackbot, end meeting
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/look back/look bad/ Succeeded: s/minutes./minutes; there were only 2 issues./ Succeeded: s/It's like/I'd like/ Succeeded: s/Mozilla is/Mozilla devs are/ Found ScribeNick: dael Inferring Scribes: dael Default Present: dael, antenna, astearns, rachelandrew, dauwhe, tmichel, antonp, gsnedders, myles, Florian, tgraham, TabAtkins, Rossen_, jensimmons, smfr, dbaron, Vlad, gregwhitworth, alex_antennahouse, zcorpan, plh, melanierichards, RachelNabors, ChrisL_ Present: ChrisL_ Florian RachelNabors Rossen_ TabAtkins Vlad alex_antennahouse antenna antonp astearns dael dauwhe dbaron gregwhitworth gsnedders jensimmons melanierichards plh rachelandrew smfr tgraham tmichel zcorpan WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 15 Feb 2017 Guessing minutes URL: http://www.w3.org/2017/02/15-css-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]
