- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Jan 2019 20:00:48 -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.
=========================================
CSS Syntax
----------
- RESOLVED: Change syntax to specify behavior implemented in
majority of browsers (Issue #3182)
- RESOLVED: Defer the remaining syntax issue with a note we may
address in future spec (Issue #2757)
- TabAtkins will compile a disposition of comments and request
publication on next week's call.
CSS Text
--------
- Instead of solving for the handful of properties in Issue #3414
(CSS properties should apply to some SVG elements as well) the
group will aim for a general solution to update all 'applies to'
lines to have information about how they interact with SVG
elements.
- In order to do this, interested individuals will work on a new
language to use for applying to SVG elements as well as to
make it clearer what the current general text around
'elements' really means.
- Once this is agreed to by the group one large PR will be
drafted to make this change to all specs simultaneously.
- The goal is to have a first draft of the new language for
discussion at the next F2F.
- RESOLVED: Amend the previous resolution to include form feeds so
they're processed same as lone CRs (Issue #855)
CSS Inline
----------
- People continue to think on issue #2950 (Better name for
initial-letters property) so it will be added to the F2F agenda.
- On the call today one suggestion was line-span, but there were
concerns that could be misinterpreted.
Resize Observer
---------------
- There was concern that the approach taken to resolve on Issue
#3329 (Which box information should we pass to the callback) was
too broad and could be confusing since the data returned here
would not be returned in other similar calls. Discussion will
continue at the F2F.
CSS Grid
--------
- RESOLVED: Define repeat interpolation using the more restrictive
rule in
https://github.com/w3c/csswg-drafts/issues/3503#issuecomment-453674839
[require that the first arg is a number, and identical
between start/end; different values, or keyword values,
both go discrete]
CSS Logical Properties
----------------------
- RESOLVED: Do not allow quirks in 'inset' shorthand (Issue #3525)
- RESOLVED: Close this issue (Issue #3519: border-block/
border-inline syntax) and add a note to the spec saying
this is an intentional restriction
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jan/0009.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Amelia Bellamy-Royds
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Benjamin De Cock
Elika Etemad
Simon Fraser
Dael Jackson
Brad Kemper
Vladimir Levantovsky
Chris Lilley
Peter Linss
Nigel Megitt
Michael Miller
Anton Prowse
Melanie Richards
Jen Simmons
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
David Baron
Florian Rivoal
Scribe: dael
CSS Syntax
==========
Correctly handle "escaped EOF"
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3182#issuecomment-455376948
TabAtkins: The spec for syntax- this is a weird corner issue and I'm
going to match implementation. Turns out the way
implementations handle an escaped end of file is to omit
a replacement character
TabAtkins: Resolved this at one point, but resolutions are
confusing. Spec doesn't say that right now. A slash at
the end of the file doesn't create an escape as per spec.
Firefox, Chrome, and Safari think it counts as an escape
for replaced character. Want to edit spec to match impl.
TabAtkins: Edge does extremely wrong things for the slash so I don't
think we can draw from that.
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/3182#issuecomment-426019418
TabAtkins: This is what they do ^
TabAtkins: I can't tell what they're doing internally, the
serialized isn't round trip-able
TabAtkins: Only difference in other browsers is Firefox serializes
it as an escape for itself which is same result as
omitting. It's a CSSOM serialization issue.
syntax-relevant has all browsers behaving the same
astearns: Concerns?
Rossen: I haven't had a chance to look. Reading through TabAtkins's
comments. I won't push back, but I'm curious what we're
doing. I'll comment if I want to re-open.
astearns: You're fine resolution now?
Rossen: Yep. Just like any other issue
astearns: Objections to changing syntax to spec behavior impl in
majority of browsers?
RESOLVED: Change syntax to specify behavior implemented in majority
of browsers
Publication & Consider disallowing NULL code points in stylesheets
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2757
TabAtkins: Only remaining issue is if we should do something more
aggressive with a NULL. I'd like to defer to a future
version. Given that I'd like to request new CR publication
astearns: Would it make sense to leave something in syntax saying we
might get tighter in the future?
TabAtkins: Happy to do so.
fantasai: I suggest we hold on publication to let you finish DoC and
let Rossen look at that issue so that we can go next week
TabAtkins: I want to get it out because it's been 5 years
fantasai: Yes, definitely let's do next week
astearns: Do you want resolution on defer?
TabAtkins: Yes
astearns: Objections to defer the remaining syntax issue with a note
we may address in future spec
RESOLVED: Defer the remaining syntax issue with a note we may
address in future spec
<fantasai> \^_^/ Yay for [impending] new publication!
astearns: Updated publication next week would be great with an
updated DoC
TabAtkins: Alright
CSS Text
========
When to/not to include preserved trailing spaces
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3440
fantasai: Is koji on?
fantasai: We'll need him.
astearns: Can you add a comment pinging him so he knows we're
waiting?
fantasai: kay
CSS properties should apply to some SVG elements as well
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3414
astearns: Is AmeliaBR on?
astearns: Looks like krit is asking for some things to apply to SVG
text
fantasai: Wanted to ask if we want to deal with them for all our
specs. Doesn't make sense for a few properties. If we've
got a case with some but not all we've got a case where if
you don't specify a property does it apply?
<Rossen> +1 to what fantasai said
chris: That's not what we mean. We don't say it applies to HTML
elements, we just say elements
AmeliaBR: Reason it came up is...concern if we rely on SVG spec to
mention which properties apply it will regularly get out
of date as new properties are introduced. Trying to move
that into property definitions and make sure it's covered
by the applies to part of property definition box
AmeliaBR: As chris said in cases where we have applies to all
elements it can presume to apply to SVG elements. But then
there are some places it says applies to but it's CSS box
type. It's about being consistent and making sure those
boxes are useful
fantasai: All elements means all elements formatted with css box
model. SVG has typically been outside our spec zone.
Incorporating which applies to what SVG makes sense. But
if we're going to do it we should do it to all specs.
fantasai: If we want to do that we should resolve to do that for all
specs at once so everything is consistent. And it goes in
at once so there's no point where we've got uncertainly.
fantasai: That's what I'd like to see us do
AmeliaBR: Agree with that strategy. I think it should be thought of
in conjunction with some other open issues about
redefining how applies to line works. Open issue about if
pseudo elements are in all elements
fantasai: They're not except before and after which in their own
definition says that.
fantasai: I think if we list every pseudo element we could do that.
before and after it would be redundant because they say
they're not a special type.
<AmeliaBR> https://drafts.csswg.org/css-text-3/#word-spacing-property
AmeliaBR: Specific properties krit brought up, they say applies to
inline boxes which is a very CSS term
AmeliaBR: That's where the issue for those came up. Might come to
having to sit down and come up with a set of new terms
that can be used for covering the SVG layout/element types
as well as the CSS box types
AmeliaBR: That's probably the first step. A proposal for which
categories to use for what makes sense to describe the SVG
properties. Then come back to WG for confirmation and then
make a giant PR
fantasai: Makes sense. Don't rely on all elements to help you out,
though. Border applies to all for SVG. We'll have to
change things around.
AmeliaBR: It might change all elements to all css boxes or something
like that.
AmeliaBR: Not going to figure it out on the call. If anyone has
ideas we can brainstorm in the issue. First step is figure
out what the categories should be that makes sense in both
contexts.
AmeliaBR: Once that's decided it's going through every spec and
making sure it makes sense
fantasai: Direction sound good to everyone?
chris: sgtm
fantasai: I'll tag this issue against all specs
astearns: I don't know if that'll be that useful. But mentioning in
a comment this will apply to all specs might be sufficient.
astearns: How many SVG folks will be at F2F? I'm wondering if this
is something we can noodle on
chris: I hope to be
AmeliaBR: I will be in person
AmeliaBR: krit, though, won't be around. Not sure about myles or eric
astearns: Let's see if we can wrap this up by the F2F
astearns: Anything else on this issue?
Question re white space processing rules for U+000D
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/855#issuecomment-451191125
fantasai: We discussed handling lone carriage returns. Last couple
resolutions talked about carriage, but not form feeds. In
current spec text form feeds are different than every
other control character. They are not rendered
fantasai: Wanted to know what we wanted to do. Treat as 0 width
space or no?
<fantasai> https://www.w3.org/TR/css-text-3/#white-space-processing
fantasai: Spec section ^
<fantasai> Form feeds (U+000C) (that are not segment breaks) are
rendered as a zero-width space (U+200B). Control
characters (Unicode category Cc) other than tab (U+0009),
line feed (U+000A), and form feed (U+000C), must be
rendered as a visible glyph which the UA must synthethize
if the glyphs found in the font are not visible and
otherwise treated as any other character of the Other
Symbols (So) general category and
<fantasai> Common script. The UA may use a glyph provided by a font
specifically for the control character, substitute the
glyphs provided for the corresponding symbol in the
Control Pictures block, generate a visual representation
of its code point value, or use some other method to
provide an appropriate visible glyph. As required by
[UNICODE], unsupported Default_ignorable characters must
be ignored for rendering.
astearns: I don't have a strong opinion but makes sense to treat
form feeds in a consistent way
astearns: Anyone have a reason to treat form feeds differently?
astearns: Objections to amend the previous resolution to include
form feeds so they're processed same as lone CRs?
RESOLVED: Amend the previous resolution to include form feeds so
they're processed same as lone CRs
astearns: That will require test changes an that will get us feedback
fantasai: I re-tagged the next few for F2F
astearns: I had asked that.
Better name for initial-letters property
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2950#issuecomment-438736819
jensimmons: As issue says we're debating a name. Kinda hit me is a
way to approach is describe what this does. I wrote some
stuff, but I disagree with myself.
jensimmons: Right now I'm thinking maybe line-span is a possibility.
I originally rejected because span is in the html, but
there's em in html and em unit in CSS and that's never
confused.
fantasai: Okay with that
jensimmons: Made me wonder if you can do more than make a letter
big. Like if you had an image would it do anything?
fantasai: Yes, if you apply to an atomic element it will apply.
There is text on how this works with inline blocks and
images.
astearns: Definitely intended to work in that case
fantasai: I think that was my favorite from the list
astearns: Other opinions?
dauwhe: Plausible to me
<AmeliaBR> But to clarify: it still only applies to the first
element of a block? So that's the bit that isn't conveyed
by the name.
bradk: line-span makes it sound like it would be any inline element
and it would span the line. That was my concern
jensimmons: Agree we need to think about that
astearns: Table this for now and get to it at F2F. Let's try and get
to this on the first day to make sure we give it needed
time
Should first/last baseline values of `vertical-align` belong to
`alignment-baseline` or separate longhand?
---------------------------------------------------------------
astearns: This for F2F?
fantasai: We have question if first vs last which line we use for
vertical alignment. Is that a separate property or
combined with baseline.
fantasai: I don't have a single good argument in favor of one or the
other. I'm looking if anyone has an idea or use cases to
clarify.
fantasai: Otherwise I don't know how to decide.
astearns: Anyone on this issue want to register an opinion?
astearns: We'll put this on F2F agenda. Look to see if anything can
be clarified.
Resize Observer
===============
Which box information should we pass to the callback
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3329#issuecomment-452477429
gregwhitworth: This comes down to we changed the spec because we
resolved we wanted to watch more boxes. Then it was
what information should we return? Author wants to
observe border box, what do we return? We previously
stated all that you could potentially observe so that
we answer anything the author wants to watch.
gregwhitworth: We don't want author putting multiple observers to
watch multiple boxes.
gregwhitworth: What would happen is in the issue. We would return
border box, content size box, scroll box, and device
pixel border box.
iank: I'm observing border box size and the content box size
changes, am I notified?
gregwhitworth: No. If you want the content box you should observe it
iank: Worries me webdev will observe border box and then complain
it's not working as expected. Did you consider getting people
to list all boxes and nulling things not needed?
gregwhitworth: Initially we were going to allow them to observe
multiple. We can add an option to return us what you
want to return. We can add an option that says of the
ones we have which do you want options returned.
gregwhitworth: It's kinda a shot in the dark right now. Even if they
have the option they could still have the same
problem of observe border and dimensions on content
iank: Border box size would be null in that call
Rossen: Verbosity of proposed API. The entity in the platform is the
css box. All other boxes are properties of that object. My
worry is if we go down path to expose such models where you
are creating an identity for a property you're complicating
lifetime of the API. Sounds a bit odd to me to go down that
path
Rossen: Almost equivalent of pretending any other property of box is
a scriptable object
smfr: One of the things I find odd is that we don't have any other
APIs that return content box stuff. It seems odd to get these
boxes is only resize observer. Why not expose on the things
that are an imperative to get boxes
smfr: Also odd API only returns sizes. I'd like rectangles for all
of these and they should be relative to top left of border box
smfr: To resolve what changed is you return all rectangles and an
enum to say which changed
astearns: Would be which changed, it's which of them changed
smfr: Yes
gregwhitworth: Not opposed to having results return in other static
areas. This was just an issue for the resize
observer. Not sure if you want to expose in CSSOM or
whatever.
gregwhitworth: smfr are you saying you want shape is what would be
return from getClientRects? I had talked with Aleks
that we'd have getBoundingClientRects be what's
returned for these boxes. But we said it's about size
change not position
smfr: These rectangles are in local coordinates. Which I think is
fine. This API shouldn't be able to do abspos or client pos.
If you're giving size of contents I'd also like offset from
top left. That seems natural and cheap to compute
gregwhitworth: Makes sense. I can open that issue. Are we providing
for sake or is that a thing authors want commonly?
That they want to check the offset
smfr: I would imagine the users care about fitting things inside. I
think it's about size and not position
gregwhitworth: Then why include offsets? Just in case?
smfr: If you tell me content size I might want to know how much is
border and how much padding. If I have to call gCS it might
trigger a layout which is expensive so that should be in
resize observer
smfr: One final piece of feedback on algorithm, but we can come back
to that
gregwhitworth: That is good F2F item.
gregwhitworth: Rossen to your point on model, any other
recommendations on achieving the end case?
Rossen: If we're going to discuss at F2F I'd defer to then.
Providing all the information in a property bag that doesn't
require additional readbacks would be the preferred model.
Rossen: The misalignment seems a bit odd here
gregwhitworth: Okay
Rossen: Let's table and discuss at length at F2F
astearns: I'll add F2F tag
CSS Grid
========
Interpolate repeat()
--------------------
Github: https://github.com/w3c/csswg-drafts/issues/3503#issuecomment-453674839
TabAtkins: Question was raised by Boris. How are repeat functions
interpolated in grid template rows
TabAtkins: It's retained in computed values because some can't be
resolved at computed value time. Computed value animation
runs on will have repeat functions. How do they
interpolate. This isn't in spec.
TabAtkins: They have 2 functions. After some discussion in issue and
some nice examples there's 2 options that are consistent
with how we interpolate
TabAtkins: First is we're very restrictive. To get smooth
interpolation first argument must be a number and track
listing must have same number of things. 2, 10px, 10px to
2, 20px, 20px will be smooth. If you have auto fit no
smooth
TabAtkins: Other poss is we allow any values for first. If same
transition by doing nothing. If they're numbers and
different they transition as int. If you try and go into
to keyword it goes discrete.
TabAtkins: Still require track listing match with normal
transitioning rules. You could not go from a repeat 4,
10px to repeat 2, 10px, 10px. An auto fit and auto fill
we can't match and I don't like special casing that
TabAtkins: I propose: We require that either the first argument be
the same value or both int. Track listings must be
interpolate-able normally
fantasai: 2 proposals. Main difference is the first one you can only
interpolate if it results in same # of tracks. 2nd version
we try and follow value interpolation patterns we have and
that allows more possibilities. Disadvantage to that is
you're not interpolate between # tracks and therefore
position of elements can change.
fantasai: Do we want as much smooth in value space but have layout
discontinuous or do we want to align what's possible to
interpolate in layout with value space
TabAtkins: With caveat that discontinuous layout does happen if you
end up in discrete. We do allow int based on grid
positions we also can have skipping. This is the whole
grid, but similar in idea
astearns: I think I would like to have many example is spec
whichever we choose
TabAtkins: Yep
fantasai: Anyone besides me and TabAtkins have an opinion or want
more time?
astearns: fantasai do you have a preference?
fantasai: From what I know I'd go with first option. More
restrictive.
fantasai: It seems like interpolating in value space and having
things jump around, I'm not sure it would be that great. I
don't feel very strongly because I don't understand
strongly implementation for layout system. I'd do whatever
Mats thinks is right
fantasai: We can poke Mats. Any other opinions?
astearns: Often we will be more restrictive to begin with and then
later add smooth interpolation to things that were
previously discrete. That's an argument to more
restrictive because we can get to more liberal eventually
astearns: Other opinions?
astearns: Am I correct about being able to loosen in the future?
fantasai: I think you're correct
astearns: Proposal: Define repeat interpolation using the more
restrictive rule in
https://github.com/w3c/csswg-drafts/issues/3503#issuecomment-453674839
astearns: Objections?
RESOLVED: Define repeat interpolation using the more restrictive
rule in
https://github.com/w3c/csswg-drafts/issues/3503#issuecomment-453674839
CSS Logical Properties
======================
Should the `inset` shorthand allow quirks in their lengths like the
individual properties do?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3525
fantasai: Top, left, bottom, and right properties in quirks mode
allow px without px unit. 100=100px. Do we have same quirk
for logical longhands? Related is what about inset
shorthand?
<fantasai> (inset shorthand shorthands the physical properties, top/
left/bottom/right)
TabAtkins: I don't see a reason to allow quirks in new properties.
Need to not rely on top because that imports quirks
<bradk> No quirks
fantasai: We can add a note saying this notation doesn't import
quirks
astearns: I'm agreeing shorthand shouldn't have quirks and deal with
that in spec definition as well as add test cases
astearns: Other opinions?
astearns: Objections to not allowing quirks in 'inset' shorthand?
RESOLVED: Do not allow quirks in 'inset' shorthand
border-block/border-inline syntax
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3519
fantasai: Mats pointed out they only let you set one value which
assigns to both sides. Asking if we should allow setting 2
different values. Short answer is I think no because
border property includes color, length, and border style.
Shorthand that deals with that doesn't allow 4 sides. So
you can only set both sides to same thing.
fantasai: I think that's fine. I think Oriol thinks it's fine. But
we could do that.
<fantasai> https://github.com/w3c/csswg-drafts/issues/3519#issuecomment-454987242
astearns: Given we have not done it for border property I don't
think we should do this for border-block and border-inline
<oriol> I agree with fantasai
rachelandrew: Agree. It's less confusing if it's the same as 4 value
TabAtkins: Yeah
astearns: Proposal: Close this issue and add a note to the spec
saying this is an intentional restriction
astearns: Objections?
RESOLVED: Close this issue and add a note to the spec saying this is
an intentional restriction
astearns: Thanks everyone for calling in
Received on Thursday, 24 January 2019 01:01:43 UTC