- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 4 Jan 2024 19:40:35 -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.
=========================================
CSSOM View
----------
- RESOLVED: Pursue event to make reports more ergonomic to use (Issue
#7693: No event to track window position)
CSS Viewport & Zoom
-------------------
- RESOLVED: iframes will be effected by zoom, device pixel ratio will
reflect it (Issue #9644: Should zoom affect iframes?)
- RESOLVED: Apply zoom to all replaced elements and to background
images (Issue #9442: Zoom and replaced element intrinsic
dimensions)
View Transitions
----------------
- RESOLVED: Go with option 1 for the syntax in creating
view-transition-class (Issue #8319: Creating 'classes' of
transition groups)
CSS Conditional
---------------
- RESOLVED: Add html function for testing both elements and attribute
support (Issue #9746: Need a way in CSS to test for
support of HTML features)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jan/0000.html
Present:
Tab Atkins-Bittner
Elika Etemad
Chris Harrelson
Daniel Holbert
Ian Kilpatrick
Vladimir Levin
Florian Rivoal
Cassondra Roberts
Khushal Sagar
Jen Simmons
Alan Stearns
Brandon Stewart
Regrets:
Rachel Andrew
David Baron
Jonathan Kew
Miriam Suzanne
Bramus Van Damme
Sebastian Zartner
Chair: astearns
Scribe: frances
CSSOM View
==========
No event to track window position
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7693
florian: Window attribute has objects and event when size changes but
not when position changes, proposal to add move event that
works similar to resize event
florian: Nuance while position attribute is on object, browsers are
not required to report or have a global coordinate system
and hide them, not reliably available
florian: If not possible to land html patch, might differ things,
could possibly land them in CSS patch
astearns: Alice's PRs are closed; why?
florian: Suspected glitch of rebasing, sat for a while and appears
closed
khush: Do all OS's have this event? Are we expecting all browsers to
behave similarly?
Florian: Fickle to speak of all OS's, not finite, up to
implementation detail and html loop in rendering, not need
to pull more frequently
florian: There's a limit on how frequently
khush: If window position is changing, how can we minimize wakeups on
the screen and not rely on it in case OS is not giving the
event
astearns: Possibly resize event has timing specified
florian: Specified similarly
khush: Doubt to have the problem on the OS when window is resized
florian: As mentioned, Linux on Wayland does not have OS tell changes
on coordinates, windows are composited, no requirement to
report numbers
florian: up to implementation discretion, numbers are already exposed
astearns: Igalia is possibly looking for an okay and no objections to
adding the event
florian: Possible limited appetite to the event, make it convenient
to not waste energy in actively pulling
astearns: Any other comments or thoughts?
dholbert: Is it set in such a way to detect whether you will ever get
a callback or expect it?
florian: There is nothing on the event itself, possible window
attributes maybe undefined
florian: Spec should give an answer
dholbert: That is my only concern, sort of imperfect, might not
return anything, need to make it ergonomic with the known
limitation
astearns: Put something on the spec such as exposing window position
and does it get updated, put event on the window object or
it shouldn't be there to add the existence of the event
florian: Trying to find part of the spec to find where the
information is, spec says you don't have to report. Does
anyone remember?
astearns: These are details that we can work out
dholbert: Wayland limitation is possibly substantial, might never
work it is an important constraint to be aware of
florian: Important on window object itself
dholbert: We already expose possibly bad information, need to be more
ergonomic
florian: Trying to find the part of spec, possibly open separate
issue to track and detect
florian: Is it relevant to know difference between 0 0 corner? open
issue and track
astearns: Should we land a spec for the event and then ask for a
privacy review or vice versa?
florian: Event doesn't make information worse, need to add way to
report information with privacy considerations
astearns: Information available but hard to use, might make it
detrimented
florian: Might make it inefficient for the programmer
iank: Trivial, not difficult to access
dholbert: Agreed
<vmpstr> this says 0 if not available, not sure if that's the right
spot https://drafts.csswg.org/cssom-view/#dom-window-screenleft
astearns: Let's finish up discussion
RESOLVED: Pursue event to make reports more ergonomic to use
florian: Should pull request wait?
astearns: pull request then work on details
<chrishtr> Agree to land a PR
florian: Move on CSS or pursue html request from get go?
astearns: Do both in both specs directly
florian: Agreed
astearns: No objections
CSS Viewport & Zoom
===================
Should zoom affect iframes?
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/9644
chrishtr: issues are related
PROPOSAL: Have iframes be affected by zoom by affecting
devicePixelRatio in the same way that zooming imposes
constraint on ancestor element
khush: Any concerns on backwards compatibility issues to change
behavior?
chrishtr: Will change behavior on web based browsers because they do
not change, research does not involve iframes, want to ship
in chrome
astearns: Did the research use CSS zoom?
chrishtr: Yes, looked at office 365, none use an iframe in zoom to
recollection.
florian: Very reasonable, if there is a side effect, we'll probably
discover it by shipping?
chrishtr: This aligns with other issue in objects to embed and make
the zoom factor larger
astearns: Any other comments on zoom and iframes?
PROPOSAL: iframes will be effected by zoom, device pixel ratio will
reflect it
astearns: Any objections?
RESOLVED: iframes will be effected by zoom, device pixel ratio will
reflect it
Zoom and replaced element intrinsic dimensions
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9442
chrishtr: Replaced elements in general, zoom is taken in account on
replaced elements and background images
iank: Spec proposed natural size
chrishtr: Zoom of 2 would default to twice the size because natural
size doubled
chrishtr: as an example
<fantasai> +1
astearns: Unspecified?
chrishtr: The current behavior is not a fully specified CSS property,
possibly not a compat risk
astearns: Does Emilio know?
chrishtr: Yes
astearns: Any other comments?
vmpstr: If we are doubling the natural size, be careful in natural
size container and containing the size, possible spec
confusion
chrishtr: Interpret to apply contain size and multiply by 2
florian: Should not do it instead whether first or last
chris: Good point
astearns: Anything else?
PROPOSAL: Apply zoom to all replaced elements and to background images
RESOLVED: Apply zoom to all replaced elements and to background images
View Transitions
================
Creating 'classes' of transition groups
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8319
vmpstr: Have view-transition-name, can be repetitive, introduce
view-transition-class to apply to multiple elements, and
prevent repeating. Separate list of custom items to name the
classes. For the selection, the view-transition
pseudo-element can select the class, few options listed in
the issue on how to select it such as dots in brackets, dots
outside the brackets. No strong preference.
<fantasai> https://github.com/w3c/csswg-drafts/issues/8319#issuecomment-1852207709
vmpstr: The semantics will be the last capture wins. If exit
transition, the old capture will win, if an entry transition,
class overrides old element.
astearns: Any objections?
astearns: Any opinions?
TabAtkins: Use case for class sounds great, good idea. For syntax
lean towards class selector syntax into pseudo elements,
least clumsy, names and classes, syntactically
distinguished
astearns: Which option is it?
vmpstr: Option 1?
vmpstr: Option 1.
<TabAtkins> ::view-transition-group(*.class1.class2)
khush: Second what Tab said, like option 2, if dot class is a prefix,
then will be a subtle difference in class declaration
TabAtkins: True for hover pseudo class in dom class, for CSS selector
syntax, doesn't allow it, prefer option 1
<TabAtkins> :hover::before and ::before:hover are currently both
valid and mean different things in exactly that way
<khush> ^ I +1'd option 1. :)
fantasai: Comment from someone in thread to introduce shorthand for
view-transition-name and view-transition-class, can choose
a syntax that works for both. That would likely be option
4. But I like both.
astearns: Any other opinions?
astearns: Possibly resolve on option 1
vmpstr: Yes
PROPOSAL: Go with option 1 for the syntax in creating
view-transition-class
astearns: Any objections?
RESOLVED: Go with option 1 for the syntax in creating
view-transition-class
CSS Conditional
===============
Need a way in CSS to test for support of HTML features
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9746
jensimmons: Apple recently put together along with the html group,
switch input type, won't use checkbox by default for the
switch, common for developers to want to use native
switch control and use custom styling on it. Great for
developers to use conditional @support statements. Some
work arounds for pseudo-elements, is hacky and not long
term. Make form controls more stylable and test support
for html elements and attributes and put them in support
[missed]
<fantasai> proposed syntax -
https://github.com/w3c/csswg-drafts/issues/9746#issuecomment-1867929357
jensimmons: Mostly the issue is how can it be done technically.
fantasai has more information on the syntax. What in the
browser engine could CSS look at to get accurate results
for this kind of a test?
florian: Implied in what was suggested, is very valuable important
design consideration. Went directly through CSS syntax to
not get out of sync. How to test in a way to not be out of
sync in support?
<iank> Fallback on non-supporting browsers will just be an input vs.
a checkbox if an author writes `<input type="switch">` I
believe. (fallback doesn't work on attributes)
TabAtkins: Same that florian said, use case is valid, would require
registries, might not be workable. Input types have a
handling path to recognize input types, element names are
testable in this way, for outside explicit is fine, a
:input[switch] pseudo-class
TabAtkins: Can do a handful of automatic protections. For broader
case, targeted pseudo class to target exposure. Might not
reasonably be able to do it.
<fantasai> HTMLInputElement.prototype.switch
fantasai: What was mentioned for element support, specific
subclasses, could check whether the prototype exists like
html.prototype.switch exists for internal processing for
the attributes. Might only take valid attributes, browser
doesn't know right now,
iank: Trouble with many attributes, not a simple registry of possible
values. A lot of internal processing in the attributes.
astearns: Could be based off of IDL numbers.
jensimmons: Hoping to create reusable pseudo-elements, not one-offs
<TabAtkins> I mean I'd *like* to have a generic mechanism. Just not
seeing a way to do that that's not registry-based.
astearns: Possibly work for all attributes, compelling use case for
the attribute. Start with the case and then see if we can
come up with a more generic attribute solution in the
future.
astearns: Any other ideas for testing attribute support generally?
florian: Don't know enough about it internally, html parses
everything. Plug in at right level of the parser, will
accept anything to parse, similar to the html. Is there a
layer in the parser that is currently not exposed?
florian: Syntax edit
fantasai: Happening at level above the parser about the elements and
attributes even if they are unknown. Won't know correct DOM
attributes if you don't recognize them. Recognition is
reasonable.
<TabAtkins> Not all valid and processed attributes are reflected as
IDL properties.
TabAtkins: Don't have an example, not all attributes are reflected as
IDL properties, anything can go in the element attribute
set, IDL testing will often work, but there is a bit of a
confusion like input-value. There is going to be some
things that don't work anyway.
astearns: If we go with this, people might find it useful where
elements are not reflected as IDL properties, specified
browser with attributes.
<TabAtkins> I *would* expect it to work all the time, yeah.
jensimmons: @supports add a switch, test popover, do we need to test
and see if it works all the time?
astearns: put it in place for people to use in set of reflected
properties possibly
<fantasai> https://github.com/w3c/csswg-drafts/issues/9746#issuecomment-1867929357
iank: Are all objects defined in the IDL?
fantasai: The backing and question of use of supports hooked up to
IDL level or not. Possibly not have IDL function and stuff
in there. More natural for authors for input values to map.
<TabAtkins> Though remember the request here isn't for "is this
attribute supported" but rather "is this attribute
*value* supported", and that's Ian's larger concern that
many attributes make that more complicated
iank: Possibly test for webGPU device
<fantasai> html(rb)
<fantasai> html([dir])
<fantasai> html(input[type])
<fantasai> html(input[type=color])
fantasai: Scoped to elements, some kind of a function like markup and
a tag name and reflective syntax for it, and test.
fantasai: It is the direction I'd like to go in and be limited to the
support for each attribute in the elements.
florian: Go through IDL later possibly to see if it is matched.
<TabAtkins> Like, `<input type="foo">` is a *supported* value. It's
just treated identically to "text".
<fantasai> TabAtkins, but that returns 'text' if you get it
<fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cinput%20type%3Dfoo%20id%3Dtest%3E%0A%0A%3Cbutton%20onclick%3D%22w(document.getElementById(%27test%27).type)%22%3Eclick%3C%2Fbutton%3E
<TabAtkins> Sure, but if your test is "does this round-trip
identically", then other types of canonicalization of
*understood* values won't work either
jensimmons: A lot of the behavior is not reflected in just HTML,
still need some conditional ability to style and it needs
to move into CSS, not going to use webGPU without
Javascript
iank: Good to investigate in custom elements as well, create some
custom element with API attributes, might not capture some
magical attributes not in the prototype
astearns: any other comments?
PROPOSAL: A straightforward way to check for html element support for
specified elements
astearns: Break into resolvable checks, break into a resolution, and
do elements today, see if we can resolve on attributes as
well later
jensimmons: If we do elements now as a step along the process for the
attributes, yes let's do it, if there is a chance for it
to break, no use case for the elements
PROPOSAL: Check if HTML elements are supported
TabAtkins: Weakly objecting, no use-case has been presented for
testing for element names yet
florian: What do we mean by html elements supported? such as you must
parse, what about deprecated values and elements?
astearns: need to resolve, any objections?
TabAtkins: if we can figure out a way to do it
<TabAtkins> happy for "try to work it out in an ED"
RESOLVED: Add html function for testing both elements and attribute
support
Received on Friday, 5 January 2024 00:41:11 UTC