<scribe> ScribeNick: dael
Rossen_: We'll get going in a
couple minutes
... We'll do 2 minutes past the hour
... It's 2 minutes past, let's start
... Wanted to call if there are extra agenda items or items to
change
fantasai: Brief announcement
<fantasai> https://www.w3.org/wiki/Process2020
fantasai: We posted an explainer to process changes and edits at this wiki^
<fantasai> https://lists.w3.org/Archives/Public/spec-prod/2019OctDec/0007.html
fantasai: If you have comments on improving, like the changes, dislike the changes, let me know about problems. If you have opinions forward them to spec-prod
astearns: TabAtkins wanted first item to be postponed slightly on IRC
Rossen_: I see Chris will be a bit late for fonts 3
astearns: TabAtkins will be at least 15 minutes late
github: https://github.com/w3c/csswg-drafts/issues/4482
... none
Rossen_: Text level 3
florian: Text 4; fonts 3
fantasai: fonts 4 as well; fonts 3 is REC/ ! :D isn't it?
Rossen_: It is.
... Let's do text L4
... Is it editorial?
florian: Not only. At previous
F2F we discussed word boundary in spaces, the text was added.
It was announced and review requested. We're not getting to CR,
but it's been in the ED for a while and it should go into an
official space
... It's been a year since it was published. Sounds like good
timing
Rossen_: And the edits are in?
florian: They are. It's the things I talked about at last F2F. Maybe some editorial tweaks
Rossen_: Great.
RESOLUTION: Publish new WD for Text 4
Rossen_: Fonts 4 should we wait for Chris?
fantasai: Chris is on IRC
... I think we publish since he requested
<ChrisL> Please wait until later
<ChrisL> Ok great
RESOLUTION: Republish Fonts 4
<ChrisL> Yay
github: https://github.com/w3c/csswg-drafts/issues/4411
<fantasai> https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-548945615
fantasai: Summary comment^
... Two proposals, make grid-template-areas a thing and exclude
names from inheriting. Currently grid-templates make start and
end and those would not inherit into subgrid
... Other option is we take those names and instead of saying
don't inherit in, they do inherit in and if there's partial
overlap we clip start or end so they exist in the grid and you
can position to the overlap
... Slight inconsitencies for both. If we exclude then a
manually created grid area such as named lines as foo-start I
implicitly create foo which I can position into. Kinda works on
a subgrid; if both lines overlap. True in both cases
... Question is do we want...we didn't want to create
inconsisent behavior for tempaltes. Want to say either set to
part it overlaps or exclude all lines. Those are the two
options.
... Would like to hear from other preference
Rossen_: Prefer second option.
<fantasai> A) Exclude parent template and its implicit line names from subgrid
<fantasai> B) Subset parent template to the part where it overlaps the subgrid, allowing it to be usable
Rossen_: Having the
grid-template-area lines not available from subgrid is quite
weird given that rows and columns are available
... I would lean toward the second solution if we have to pick
from these two
dbaron: Looks like Mats preference was first, but seems reasonably okay with either. Seems he had impl of 2nd and changed to 1st.
fantasai: He originally wanted B, then did A when we weren't sure
Rossen_: dbaron do you know why he switched?
rego: It was not impl in all cases. I had example in issue that was different in 2 cases where should be same. He didn't have whole impl. I think he did the simpliest thing
<fantasai> Mats's comments https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-542292465
Rossen_: If we go with option B
(the second option)
... Would that be okay dbaron if you're representing Mats?
dbaron: I'm only reading his comments in issue
jensimmons: Still trying to wrap my head around. Seems like Miriam Suzanne and rachelandrew were advocating for A
Rossen_: A in TabAtkins summary is option 2
<rachelandrew> option 2 for me (don't think my mic is working)
fantasai: rego I think case with
a difference is case of explicit line names creating implicit
area.
... TabAtkins and I discussed and concluded there wasn't a good
way to make that work. Would require changes to how line names
were handled. Couldn't figure out how to not cause changes to
normal grid
... Concluded line names from tempate are special and special
for subgrids but explicit line names don't. Which means you can
handle hte partial overlap nicely for template areas, but not
for area with explicit names
rego: So original impl from Mats is final?
fantasai: Yeah. Either way the line names created by template area need to be special so we either notice they're excluded or clamped for partial overlaps. Seems second is more useful
rego: Still don't like difference in the example. I understand it's useful so maybe it's good enough. I think the difference can create confusion.
fantasai: Ideally we would solve both, but didn't find a good way.
<fantasai> rego, see https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-542288855 for problems with the other options
Rossen_: Not hearing strong
opinions, but more people toward option 2
... Objections to resolving on "Subset parent template to the
part where it overlaps the subgrid, allowing it to be usable"
unless there's additional comments
<fantasai> Example of option 2 - https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-543174237
Rossen_: Objections to Option 2: Subset parent template to the part where it overlaps the subgrid, allowing it to be usable ?
RESOLUTION: Pick option 2 effectively subset the grid area into the subgrid
fantasai: That's last subgrid so I'd like to propose every non-subgrid feature goes to L3 so we can go to CR
<fantasai> https://drafts.csswg.org/css-grid-2/#alignment
fantasai: There's a bunch that
haven't been edited in. We'd defer this ^
... THere's a handful where we resolved ot add features and I
propose we start a new WD with those and put subgrid L2 to
CR
<ChrisL> +1 on CR for Grid L2
fantasai: We didn't edit them in because Grid 1 was a little unstable. But none of those features are as urgent as subgrid
<tantek> +1 on CR for Grid L2 with only subgrid added
Rossen_: Proposal: Break Grid L2 down to only contain subgrid features. Take L2 to CR. Start L3 with all things moved
<dbaron> presumably L2 will have the L1 stuff too?
RESOLUTION: Start L3 with all work that is in L2 but not about subgrid
<tantek> dbaron, that was my assumption too
<jensimmons> +1 Let's get going on Lvl 3 baby! All the ideas about how to make Grid better!!!
fantasai: Q for ChrisL. Grid 2 is
a diff spec and doesn't have L1 content L1. There's a lot in
Grid L1 that aren't posted to CR.
... I don't think I can copy it over yet. Is it okay to publish
CR as a diff?
<tantek> I'd be ok with CR as a diff
astearns: I'd wait until we have L1 done. CRs are meant for review and diff is hard to review
<tantek> would rather than CR as a diff than have to wait until "L1 done"
fantasai: It's easier b/c it's one fairly isolated feature. We're adding this thing. I think it's okay as diff, but I want to fold in eventually
<ChrisL> Agreed, delta specs are harder to review
florian: Another is publish subgrid L1 as a CR
fantasai: No, not making this
another spec.
... I'll wait if we want.
<tantek> agree with keeping this as grid L2
<ChrisL> But okay if explicitly stated all of L1 will be included
fantasai: We're waiting on a handful of Grid L1, but we're hung up on not having tests
<tantek> I get the feeling most people here are ok with L2 as a diff CR
florian: CR should be acceptable as REC and a diff isn't. We should wait
jensimmons: I wonder if there's people that love grid enough they'd write tests
fantasai: I think a lot are written and we need to figure out where they are
Rossen_: We can wait until next week. It would be nice to make progress
fantasai: If it's up to me to do tests I won't get to it until mid-Dec at least
<tantek> I'd also be ok with L2 as another diff WD with explicit status stating we believe the additions are all CR-worthy, and that the only change expected before CR is the incorporation of all of L1
Rossen_: Let's get them in 2019
at least
... Reading ChrisL in IRC that he's okay if explicitly stated
all L1 included. I guess republish with a note? Not sure what
that looks like for CR
florian: Not convinced process allows that
Rossen_: Objections ot moving grid L2 as CR? We'll figure out format but we can resolve to do it now
<tantek> florian, wrong framing. Not convinced process disallows that :)
Rossen_: And from previous
resolution it means Grid L2 is the delta of 1 and subgrid
... Objections?
fantasai: Union of 1 + subgrid
RESOLUTION: Publish Grid L2 as CR
Rossen_: We'll work with ChrisL to figure out exactly what it looks like
<tantek> 🎉
Rossen_: That's awesome because Grid is awesome
github: https://github.com/w3c/csswg-drafts/issues/4482
TabAtkins: Several years ago we
defined the more complicated attr() functionality where it
supplies the type. If you say foo=5px we parse as length.
... No one impl. I realized why.
... It ends up being high cost for low value. Type checking
eagerly so at parse time we can reject it it means every thing
that does grammar checking have to account for possibility of
attr() being there
... Lots of fiddly detail work.
... We did it because we don't have valid at parse time but
rejected later. We now have that for var(). The var() machinery
and building on that gives us a lot of tools that didn't exist
earlier which make attr() easier
<bradk> 🐈
TabAtkins: Precise details of
grammar aren't laid out, but core is we make attr() act like
var(). It makes poperty automatically valid at parse time and
we do parse at computed time. We validate at that time.
... Specifying type lets you validate you put the right thing
in the attr(). Handling attributes elsewhere tends to allow
garbage and ignore. We maintain that and check type and make
sure it works.
... If we base on var() it's the same functionality for authors
and a significant decrease in implementation complexity.
... I'd like to persue this change and the impl wants to
experiment in it
<fremy> I strongly support this!
TabAtkins: Is WG ameniable?
emilio: I'm not opposed but
concerned about type checking token string and then doing
parsing again. When I looked at impl attr() I suggested doing
it like variables in bugzilla.
... Complexity of doing attr didn't seem so high either. I'm
concerned about parsing, tokenization, and then parsing on
performance.
... Other concern is XSS but that happens either way
TabAtkins: Reason why I don't htink first bit is a concern is it ends up being identical to custom values and properties API. Ideal is it works that way but it's inline
emilio: I think that's also a concern with custom properties. I don't want to block on it, it's mostly theoretical
TabAtkins: Never say never but I doubt used in performance sensistive ways
AmeliaBR: My first concern would
be how can we make it work logically with the existing use of
the attribute function in the content property
... You've been talking as distinguishing if an explicit type
is set. More I'm thinking maybe not necessary. If you don't
have an explicit type the type is assumed string and any
attribute can be parsed as a string, returned in a string. So
maybe not an issue b/c string is always valid in content
... I'd like to see the exact write up and note it makes sense
in backwards compat without special behavior
TabAtkins: Not possible w/o any
backwards compat b/c assume valid at parse time. Content
properties currently invaid but use attr() become valid at
parse time. It is a behavior change if we make unspecified type
attr() use this.
... Not sure what's best if we split parsing into separate
function rather then flag it as attr() here. Puts you in 2
parsing modes based on detail of function grammar.
... If we think it's okay for behavior change in content where
you wrote an invalid with a fallback and you're relying on that
that seems minor. Otherwise good with your option.
... There's some possibilities there, we can experiment
AmeliaBR: Youre example of something suddenly valid is if something else in content property would be a parse error. Like using slash syntax with alternative text in a browser that doesn't support makes a difference if it's parse itme error
TabAtkins: Exactly. You'd no longer have the fallback
AmeliaBR: I would lean toward having a separate function for the type version and use attr() for how it's curerntly supported. Might be problematic for UA that support attr() more widely
TabAtkins: No idea if various
printers support. I know no web browsers do. I'm not sure impl
quality of whole thing
... But this is a behavior change. It will be off if there's a
current impl. It's a custom thing or breaking change
... If no other questions just want to check for objections for
me creating a full write up of changes. I can do that for
review next week
Rossen_: Objections?
fantasai: Summary?
TabAtkins: There's a lot of
possible ways how, but it's a change in validation to make it
more var() like
... I'll have a write up fully next week. What's in the issue
is the right jist
... It's switch attr() to var()-type validation rather than
strict parse time validation
emilio: THe fallback might be able to be fix for attr(). Unfortunate to add new type of attr() that can't be detected. Nice if forced to a valid type. Worth thinking about
TabAtkins: Yep.
Rossen_: Objections to the approach of switch attr() to var()-type validation rather than strict parse time validation
<astearns> +1 to try this out
fantasai: Not sure, but let him write it up
Rossen_: TabAtkins there's no objections. Go ahead and write it up and we'll look when you're ready
cat: meow
github: https://github.com/w3c/csswg-drafts/issues/4475
<fantasai> See https://github.com/w3c/csswg-drafts/issues/4475#issuecomment-548908448
TabAtkins: Looks like reminant,
as spec grid-template-row/column when you asked for resolved
value you get width of implicit tracks as well as explicit.
Given you can't spec implicit tracks this doesn't make any
sense at all.
... Getting the width of implicit tracks is worthwhile.
Functionality is reasonable, but a number of useful grid things
it would be great to get from layout that aren't in properties
right now.
... IN past proposed things that would require new grid API to
get
... Resolved value of grid-templates does not round trip.
... Options; 1) leave as is. Resolved value is not a valid
value and confusing because unless you know number of implicit
rows you don't know where explicit starts
... 2) Change to only reflect explicit rows on resolved values.
implicit we leave for a more explicit API
... 3) continue to allow grid-template-rows to express implicit
but change grammar so it's valid. There is some value b/c only
explicit are used for auto positioning by default. Being able
to give bounds to auto while sizing outside could be
worthwhile
... Would need to be able to spec when the explicit grid starts
and stops which would also need to return in the resolved
value
... We leave as is, change return of gCS for this so that it
allows roundtripping either way
... Need to decide, this was an accident. If we leave as is
need to be more explicit
... I prefer changing to be just explicit tracks. I could
accept any of the 3.
fantasai: web compat is a substantial concern. Might be stuck with #1
emilio: Also I also prefer 2 if we can get away with the compat issue
TabAtkins: Web compat is alwyas a concern and we might be struck with 1. Between 2 and 3 is group okay if we try for 2 and revert if web compat proves otherwise?
oriol: In issue I propose feature
which allows define where grid line could be. It could place it
in another place. I think something like this could have its
own uses outside this issue. However I agree this prob needs
more thought and be in something like Grid 3.
... If we want to fix roundtripping we need mroe urgent for L1
so it's reasonable to try and remove implicit tracks
TabAtkins: Youre suggestion was
option 3, but as you say requires additional work. How it
interacts is unclear right now and a breaking change anywya. If
breaking, might as well do one that's easier to work with. If
we ever want explicit/implicit we can do that later
... Any strong preference for keeping current behavior? Or is
everyone okay with trying to change gCS and falling back to no
change if there's web compat problems?
<dbaron> please make it round-trip correctly :-)
<florian> I like the proposal
Rossen_: Try it out. It makes sense.
fantasai: We don't have syntax for that right?
TabAtkins: Not for 3. No one is suggesting widen the grammar first. This is keep as is and have gCS report explicit only or have gCS report more accurately
<fantasai> sorry, I was confused
Rossen_: Resolution would be for
give the 2nd option a chance and see if there are compat
reasons to instead keep current
... Other opinions or objections?
emilio: No obj but I want to makes ure both Geck oa nd Chromium...info from gCS is not useful. Both Chromium and FF have special dev tools b/c gCS is not enough.
Rossen_: We can look at extending
OM for grid
... I think you're pointing out more general issue. I don't
disagree
<emilio> https://searchfox.org/mozilla-central/source/dom/webidl/Grid.webidl, fwiw
TabAtkins: Point is valid in that what's currently returned is not enough for current use cases. So w're not losing anything and we should look into more advanced on
Rossen_: agreed
... Objectins?
RESOLUTION: Give the 2nd option a chance and see if there are compat reasons to instead keep current behavior
github: https://github.com/w3c/csswg-drafts/issues/4335
<fantasai> https://github.com/w3c/csswg-drafts/issues/4335
<TabAtkins> emilio, I'd love to with with you and jensimmons or anyone interested in this to figure out what devtools is using and how we could expose that to users.
fantasai: Want to clarify how
spaces are handled. There's not compat. We said serialize
between tokens we do a single space no matter if it's
needed
... Want to confirm with WG
astearns: Makes sense to me
emilio: Seems weird to change string b/c we don't change string in other places
TabAtkins: You do change the string somewhat. Youd on't if parsing splits tokens correctly. But you trim spaces at end and collapse many to one
oriol: In issue #3261 we resolved against preserving percise string in favor of normalizing. Just wasn't clear on what to do with spaces
TabAtkins: Thanks
astearns: emilio?
emilio: No objections
<emilio> TabAtkins: fwiw, this is the API exposed to devtools: https://searchfox.org/mozilla-central/source/dom/webidl/Grid.webidl, via https://searchfox.org/mozilla-central/source/dom/webidl/Element.webidl#322
astearns: Other concerns?
... fantasai has comment at end with proposal
... Objections to this?
RESOLUTION: Specify serialization as proposed in https://github.com/w3c/csswg-drafts/issues/4335#issuecomment-548962309
<astearns> trackbot, end meeting
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/CR/REC/ ! :D/ Succeeded: s/AmeliaBR/Miriam Suzanne/ Succeeded: s/have/have L1 content/ Succeeded: s/[missed]/I also prefer 2 if we can get away with the compat issue/ Succeeded: s/make sure/ note/ Default Present: Rossen_, dael, dauwhe, cbiesinger, rachelandrew, astearns, florian, jensimmons, oriol, dbaron, fantasai, tantek, rego, teleject, plinss, (irc, only), AmeliaBR, ChrisL, hober, chris Present: Rossen_ dael dauwhe cbiesinger rachelandrew astearns florian jensimmons oriol dbaron fantasai tantek rego teleject plinss (irc only) AmeliaBR ChrisL hober chris Found ScribeNick: dael Inferring Scribes: dael WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 13 Nov 2019 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]