- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Oct 2019 18:28:20 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Writing Modes
-------------
- RESOLVED: Close this issue (Issue #4357: Propagation from body to
document element is annoying) no change
Resize-Observer
---------------
- The group continued the conversation started at TPAC about the
proposal for device-pixel-border-box (Issue #3554)
- The name 'device-pixel-border-box' will need to be bikeshedded
since it's not referring to the border-box but instead the
content-box.
- Making the value optional could lead to too inconsistent of
results to be worth doing. This will be split into a separate
issue.
- The object will be a width and height not a rectangle since
there's no need for a top left setting.
- The discussion as to if there is a new API required if this is
added to resizeObserver will be split into a separate issue.
- RESOLVED: Add API to get content box height and width in device
pixel sizes to resize observer. Only return when
requested and applies to all element.
CSS Text
--------
- RESOLVED: If there is a language for which you do not know the
breaking rules. Rather then treating as unbreakable you
treat it as breakable anywhere similar to
overflow:anywhere (Issue #4284: Allow breaking anywhere
when dictionary is missing for SEA scripts)
CSS Grid 2
----------
- RESOLVED: Accept Mat's proposal which is that resolved value
unwraps repeat notations and does not insert track sizes
for subgrid (Issue #4362: `grid-template-rows/columns`
Computed / Resolved Values for 'subgrid' values)
- fantasai plans to request CR for Grid 2 during next week's call.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Oct/0008.html
Present:
Rossen Atanassov
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Chris Harrelson
Dael Jackson
Sanket Joshi
Myles Maxfield
Anton Prowse
Florian Rivoal
Devin Rousso
Ken Russell
Jen Simmons
Alan Stearns
Regrets:
Tab Atkins
Tantek Çelik
Scribe: dael
astearns: I think we have enough to start
astearns: As always, are there any changes to the agenda?
astearns: One change, we can't usefully do item 5 unless we get some
extra people on the call
astearns: Other changes?
Writing Modes
=============
Propagation from body to document element is annoying
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4357
astearns: Who wants to lead?
[discussion about if emilio has audio]
* fantasai notes there was a request to do device-pixel-border-box
earlier
* fantasai https://lists.w3.org/Archives/Member/w3c-css-wg/2019OctDec/0019.html
* fantasai notes we also need to set dates for the summer 2020 F2F
emilio: We resolved hesitantly on propagate the used writing mode
from body to document element and to viewport I assume
emilio: We have an implementation but afaict other engines are not
ready to implement since don't store value in layout tree
emilio: Resolution is hacky to implement.
emilio: Should we implement this? Do what other engine impl which is
just propagate to viewport? And tell people if they want
orthogonal set on document element
florian: Discussion on github is this looks hacky but doable in
Blink as well. Given we resolved there is some willingness
to do this. If not, I wonder why we resolved. We can reopen
but it's unpleasant. If can do in blink and FF and we're
moving the spec forward and it's nicest for author I would
hope keep as is
florian: If people not going to do it you're right it's not helpful
for spec to say one thing and do another
emilio: This is only thing that propagates to document element,
right?
florian: Propagation on other things is a bit complicated but less
so. Only thing that propagates in this way
emilio: As gecko dev I'm not in love with hack. Easier to propagate
to viewport. Happy to impl if other engines will do it
fantasai: In writing modes we wanted to make sure it's propagated in
same way as direction. Means spec was not quite correct in
way direction propagated.
fantasai: Adding writing modes and direction need to propagate
together. I understand how hacky it is, Blink solution
sounds pretty crazy. I think propagate was a mistake, but
it happens so have to address. Doesn't have to be perfect.
emilio: Direction in gecko does not propagate at all, only have hack
for scrollbar directionality and that would not be needed if
both propagate to viewport
emilio: Blink propagates to the viewport is to fix the same case and
the hack for look up body style from scrollbox is doing.
emilio: Intent is same, behavior is different as is impl complexity
florian: Would like to hear from blink. We can investigate ideal.
It's hacky but doable in gecko. If blink will do we don't
have to revisit. We have discussed preferable behavior.
emilio: But it was on assumption direction was propagate somehow.
But in blink and webkit it is propagated with writing mode
to viewport. In gecko there's no propagation, just lookup a
box for this style
florian: I suspect that if you fix bugs related to printing you'll
have to do it there as well.
emilio: Sure, but scrollbar position....that also works if you
propagate writing mode to viewport
florian: Direction only not propagate to document element is fine.
But direction if you don't go through element you create
horizontal flow and that's not nice. Ideally for authors we
propagate the whole thing properly. If can't do that there
are intermediate solutions.
fantasai: I think important point that page progression direction
and fragmentation direction needs to be consistent with
how modify scrollers. That doesn't require us to change
the root element
fantasai: Means content will overflow root, but in a direction we've
chosen. Similar to how the root element in the scrolling
case doesn't grow to accommodate the content. Solveable
but important to solve
florian: If we just propagate to viewport it's workable but less
nice for authors
Rossen: That solution will be commonly hit by authors because most
tools set direction on body rather than root element
Rossen: When originally discussed I was in full support as
documented in spec and that's the behavior in Edge where we
propagate from body to root and all the way to viewport.
Allows us to avoid all these corner cases of root element
and body element differing by writing mode and causing
scrollbars
Rossen: Unless explicitly set rules elsewhere that set different
writing modes explicitly
Rossen: In our impl it wasn't crazy to impl given we're kinda sorta
doing it in overflow. I looked at blink and what I described
is impl there. I don't know if we have resources right now,
but wouldn't be opposed to giving that a go and having
better results for authors as we have described
Rossen: Doesn't mean I'm saying I'll definitely land it in blink,
saying not opposed to landing.
Rossen: Looking at rune's comments on GH he's not crazy about it but
doesn't sound against. Don't want to speak for him/chrome,
but looking through what's needed and what we spec that
matches what as an author I would expect to see happen
emilio: I'm okay closing no change if this is eventually implemented
interoperably
astearns: Sounds to me that yes impl is hacky but people are willing
to change. Given author benefit I think we close no change
and wait on impl
astearns: Objections?
RESOLVED: Close this issue no change
* fantasai is just so sad that someone decided to do this
propagation for direction in the past, and now we're
stuck with all this nonsense
astearns: Thanks emilio for bringing this up
[agenda discussing]
Resize-Observer
===============
device-pixel-border-box size
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/3554#issuecomment-538465771
astearns: Discussed device-pixel-border-box size at TPAC
astearns: I recall we still weren't sure how change will effect
Safari. Example have now been provided. Do we have enough
information on impact to Safari?
smfr: Saw a couple of examples. I think Chris said he ran the tests
on Macbook pro retina with the fixes and it made it look
better. Can't say without doing work in webkit, but I think
sufficient proof this is useful. On non-apple it's well known
it's necessary
astearns: Any other new information?
chrishtr: Nothing new except demos and version of chrome that fixes
smfr: I'm surprised you could get good results. Most macbooks have
default scaling. Surprised you got good results on a machine
with that behavior
chrishtr: Tested on not absolute newest, but a macbook pro retina. I
think it does have value and OS scaling if it's outside of
control of application those situations can't be fixed
smfr: What I'm interested in understanding is if on hardware with
built in scaling such that you never get pixel perfect is
there improvement in device-pixel-border-box? Is there value
in making it optional and allow UA to not provide if it thinks
it can provide better. Or do we make it required and force UA
to do this when it's not going to get better
myles: Easy to test if you change resolution of OS in your macbook
pro
astearns: Sounds to me like we don't have an objection to adding
device-pixel-border-box size to the API, but may want
another issue about behavior of API possibly making it
optional?
ken: Would app fallback be multiply css pixel width and height by
device-pixel ratio if UA doesn't supply?
smfr: Impl will already have to multiply by device-pixel-ratio. No,
does multiply. Okay.
ken: That was the point, rounding or flooring can't get consistent
smfr: Okay, then makes optional thing annoying
ken: I don't know if built in scaling is higher quality but we got
really good results on macbook pros even with non-1 to 1
scaling.
smfr: Okay
smfr: Not objecting to adding. Question if needs to be rectangle or
just a size since left and top don't mean anything
chrishtr: Use case for canvas sizing top left not necessary
smfr: We don't have a dom size object
chrishtr: Yep. More consistent to have a rect, rect does have
meaning. Not used in canvas case
myles: Position of rect a little confusing if you consider overflow
area
chrishtr: Does mean where it is on device window though
chrishtr: It's used within the native texture if there's not special
scaling smfr referred to. If texture is scrolled it's
still...it doesn't take into account transforms and scrolls
myles: Values off the top of the screen?
chrishtr: I think would be fine to have size only for this reason
chrishtr: Top left doesn't seem to mean much, want to know canvas
size
astearns: Array of 2 values or are you minting a new size object?
chrishtr: I don't know. Maybe new size object?
smfr: If it always integral?
chrishtr: Yeah
smfr: Maybe you just have two long on the entry
chrishtr: That are just width and height
chrishtr: As relates to desire to add the equivalent method to
getBoundingClientRect it would change to get device pixel
width and height
smfr: If we agree to resizeObserver do we still need [missed]?
chrishtr: Don't think so, but Jeff Gilbert from Mozilla thought case
was strong so I was okay adding
smfr: Which case was it?
chrishtr: You have a full screen where you don't want resizeObserver
and you want a slight jump on resize frames
ken: Jeff also had concerns that it fires late and application would
fall behind a frame which is legit concern
myles: You would need to execute heavy calculations every frame with
this. resizeObserver means code only called when need to be.
ken: Agree, but in experience from a dev on FF stack we felt it was
important to alleviate concern. And FF intends to not recompute
if layout isn't dirty
smfr: I don't want every getBoundingClientRect to be more expensive
chrishtr: Adding a new thing
smfr: Okay, okay. Should discuss separately
chrishtr: Okay with me. Is Jeff Gilbert on? Want to make sure he's
okay to separate.
chrishtr: If he's not, maybe tentatively do that.
ken: I think Jeff would object. Not to represent his opinion, but I
think he would.
chrishtr: Great to resolve device-pixel-border-box size makes sense
and then follow-up on the other one
chrishtr: To make progress.
ken: Want progress too
astearns: smfr you would rather continue new API discussion or
resolve to add it and continue discussion?
smfr: Prefer to fork into separate issue
fantasai: Question, says doing device-pixel-border-box size. What if
person wants size of padding or content box?
chrishtr: Those other boxes have use cases and tracked via other
issues on the spec
florian: But not at device pixel level the others
chrishtr: No. Only use case for device pixels is canvas
fantasai: But why wouldn't people using canvas want to paint inside
the border?
<AmeliaBR> Wouldn't it be the content-box that is important for the
canvas? Since that's what they're using in their code?
chrishtr: Canvas has a certain size and border is outside of that.
Browser does that for you.
fantasai: border-box size includes border so if it's not included
it's not a border-box
chrishtr: It's the device pixel box size in case of canvas. It's
actual size of canvas
fantasai: Then it's the content box and we should call it that and
not border box
chrishtr: Right
ken: Sounds good
astearns: Other discussion?
fantasai: Summary of proposal?
astearns: Add an API to get canvas height and width to resizeObserver
chrishtr: Actual device width and height of the canvas. When changes
resizeObserver fires.
fantasai: I want to be clear. Adding and API which is only available
on canvas element. Reflects pixel size of content box of
canvas element
fantasai: And it has a name that is not device-pixel-border-box
chrishtr: Yes
smfr: Available for any element you resizeObserve not just canvas
fantasai: Have had various discussion on only canvas or all and want
to be clear
chrishtr: Only use case I know is canvas. Could do it for all
smfr: I wonder if this should be something the user of the API
requests.
chrishtr: For any API you ask for what you want and you're saying
only available on canvas?
smfr: Only want browser to do computation if author asks for data
chrishtr: For sure. Part of draft spec to observe multiple types of
boxes. You say what to observe. I agree browser should
only do this if needed
astearns: Further question of if someone requests this on not canvas
what happens
chrishtr: Allow or not allow is both okay. In terms of APIs
implicitly maybe better on all
smfr: Can imagine on something like video. Better on all
chrishtr: No impl difficulty from allowing it
fantasai: Add API to get content box height and width in device
pixel sizes to resize observer. Only return when requested
and applies to all.
chrishtr: Can bikeshed name
florian: Not objection, but want to be cautious on all elements.
pixels vs device pixels people can get confused about and I
have mild concern making this too easily available people
will try and use it.
astearns: A lot of things discussing now should be separate issues
once we have draft text in place.
astearns: Objections to adding this?
RESOLVED: Add API to get content box height and width in device
pixel sizes to resize observer. Only return when requested
and applies to all element.
astearns: Thanks chrishtr
chrishtr: I appreciate all the feedback
ken: Thanks for discussion
fantasai: Want to discuss optionality
astearns: Add an issue for that
CSS Lists
=========
Should automatic list-item increment adjust for ol[reversed]?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4181
<fantasai> https://github.com/w3c/csswg-drafts/issues/4181#issuecomment-522196318
fantasai: Where we are is in this comment ^
fantasai: Given TabAtkins isn't here maybe not now
CSS Text
========
Allow breaking anywhere when dictionary is missing for SEA scripts
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4284
fantasai: Certain languages where breakpoint not obvious from
character code. Have to do analysis. If you do not have
the dictionary or rules in the engine you don't break the
text and it'll be long and overflow. I suggest saying if
you don't know how to break then you should break
somewhere. Doesn't matter where but between grapheme
clusters. Have to have break opportunities
myles: Did you mean must?
fantasai: Yeah
fantasai: Proposal to add that. Discussion in issue about where to
break in languages, but this is about what to happen when
UA doesn't have rules.
florian: I think saying you must break somewhere and not middle of
grapheme cluster. If you can do mid analysis with
meaningful unit of breaking do that. But must break and not
break grapheme clusters
myles: How does browser know which scripts?
fantasai: There's a classification, let me see.
<fantasai> http://unicode.org/reports/tr14/#SA
fantasai: Class SA is complex context dependent. If you're one of
these scripts and don't have a resource to tell you where
to break you should break somewhere
myles: As long as spec says that this is fine
fantasai: Okay
astearns: Other concerns?
fantasai: Proposal: If there is a language for which you do not know
the breaking rules. Rather then treating as unbreakable
you treat it as breakable anywhere
astearns: And something about not breaking through grapheme cluster?
fantasai: Yes. If we copy from overflow: anywhere that comes
RESOLVED: If there is a language for which you do not know the
breaking rules. Rather then treating as unbreakable you
treat it as breakable anywhere similar to overflow:anywhere
CSS Grid 2
==========
`grid-template-rows/columns` Computed / Resolved Values for 'subgrid'
values
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4362
fantasai: Just accept Mats proposal
astearns: Opinions?
Rossen: Wish I had time to read it.
Rossen: This doesn't sound like something needed right now. Resolve
next week?
jensimmons: Can fantasai explain and then Rossen you can feel you
understand? I don't want to postpone because we're
trying to ship subgrid
fantasai: Issue is when getting resolved value, value from gCS, what
that value is not well defined. Regular grids resolved
value expands all repetitions so you have number of tracks/
columns. Mats proposal is same for subgrid but don't
include length because that's not valid value.
fantasai: You would say subgrid and then a list of all the line
names.
fantasai: Example in the bottom makes it clear
Rossen: In this way it will be...subgrid columns will be serialized
as part of grid columns?
fantasai: grid-template-columns is property, subgrid keyword.
Optional line names which are matched up. Can use repeat
notation
Rossen: Grid-template-columns would resolve to what he suggests in
very last sentence?
Rossen: Is that the expected behavior?
fantasai: Yeah
fantasai: We do the same thing as for regular grids, but we don't
specify sizes in resolved value. Otherwise same rules for
expanding repetitions
Rossen: Going through examples to figure out if it's lossy for what
you can reconstruct
fantasai: It is lossy in same way as current without subgrid. We
return resolved style, not computed.
Rossen: I'm trying to figure out if it's more lossy, but seems about
same
fantasai: Yeah
Rossen: Doesn't sound bad
fantasai: Alternatives is to fill in all sizes, but then can't read
it back in. Want it to roundtrip
Rossen: Agree
fantasai: Other is to not unwrap but that's inconsistent with
regular grids.
Rossen: Yeah. That would have been my preference but we are where we
are.
Rossen: This seems consistent. Not opposed
astearns: Proposal: Accept Mats' suggestion which preserves
consistency with the rest of grid but allows subgrid
values to roundtrip
fantasai: Proposal: Accept Mat's proposal which is that resolved
value unwraps repeat notations and does not insert track
sizes for subgrid
astearns: Objections?
RESOLVED: Accept Mat's proposal which is that resolved value unwraps
repeat notations and does not insert track sizes for
subgrid
Publication
-----------
fantasai: Related topic, this is only issue on subgrid. I suggest we
go to CR in the next week or two.
Rossen: Yay!
astearns: Alright, fair warning.
astearns: Thanks everyone for calling in.
Received on Wednesday, 9 October 2019 22:28:52 UTC