Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-viewport-1] [all?] Figure out if / how we want to integrate with webdriver and other similar specs. #11282

Closed
emilio opened this issue Nov 27, 2024 · 4 comments

Comments

@emilio
Copy link
Collaborator

emilio commented Nov 27, 2024

In #11137 we have a PR for adding webdriver integration to one of our specs.

As far as I can tell there's no precedent for that so it's unclear whether that (just stash that in the CSS specs) is the right way to go.

Much like segments, media queries and other things might benefit from this.

So I'd like to agree on how to do this kind of stuff for all CSS specs. Should we:

  • Stash them in the relevant spec.
  • Put them somewhere specific (some automation spec?)
  • Don't.

What do people thing? @fantasai @tabatkins

@emilio emilio added the Agenda+ label Nov 27, 2024
@darktears
Copy link
Contributor

darktears commented Dec 3, 2024

Adding again my comment from the original PR since it could be relevant to the discussion.

WebAuth, Device Posture, Compute Pressure, Generic Sensors, Web Bluetooth for example define the automation/testing story in their respective main specs.

Some specs like WebUSB are defining them into a dedicated spec, some specs into an explainer like WebXR.

So, I don't think there is a W3C guidance around that however there is a guidance around landing WPT tests, and many specs or features do need hooks in WebDriver.

I think the WebDriver folks have said that they want to keep the WebDriver spec to specify the core aspect of WebDriver not every hook from every specs. Also let's be honest it's better to specify these hooks as close as possible from the feature so that if the feature is extended/modified it's likely that authors will also update the testing aspect of it.

@bramus
Copy link
Contributor

bramus commented Dec 30, 2024

I think the WebDriver folks have said that they want to keep the WebDriver spec to specify the core aspect of WebDriver not every hook from every specs. Also let's be honest it's better to specify these hooks as close as possible from the feature so that if the feature is extended/modified it's likely that authors will also update the testing aspect of it.

This seems reasonable. After all we have spec such as scroll-animations-1 that are adding things like named ranges to that spec instead of the web-animations-1 spec.

So a +1 from me on keeping things in the spec that defines the feature.

@astearns astearns moved this to FTF agenda items in CSSWG January 2025 meeting Jan 22, 2025
@astearns astearns moved this from FTF agenda items to Regular agenda items in CSSWG January 2025 meeting Jan 22, 2025
@astearns astearns moved this from Regular agenda items to Wednesday morning in CSSWG January 2025 meeting Jan 29, 2025
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-viewport-1] [all?] Figure out if / how we want to integrate with webdriver and other similar specs., and agreed to the following:

  • RESOLVED: WebDriver extensions for CSS features go into the corresponding CSS spec, in an appendix.
The full IRC log of that discussion <TabAtkins> alexis_menard: issue came up when working on viewport-segment and the segments JS property
<TabAtkins> alexis_menard: issue was, how do we test this?
<TabAtkins> alexis_menard: the feature is dependent on hardware
<TabAtkins> alexis_menard: we usually use webdriver and emulate the hardware
<TabAtkins> alexis_menard: here, i needed webdriver extensions to simulate screen topology
<TabAtkins> alexis_menard: i have a PR to add these extensions
<TabAtkins> alexis_menard: got reviewed by the webdriver people, they were happy with the change
<TabAtkins> alexis_menard: but question is, where to put them?
<TabAtkins> alexis_menard: seems CSS has never put webdriver details into specs
<TabAtkins> alexis_menard: Looks like there's no official guidance anywhere
<TabAtkins> alexis_menard: some specs like posture, webbluetooth, etc all define webdriver in their spec
<TabAtkins> alexis_menard: webusb define in a separate spec
<TabAtkins> alexis_menard: webxr defines in an explainer
<TabAtkins> alexis_menard: so we thought it might be good to have a decision for all of css
<TabAtkins> alexis_menard: more cases will arrive in the future
<TabAtkins> alexis_menard: so where do we put the extensions?
<TabAtkins> q+
<TabAtkins> TabAtkins: Yeah let's jsut put them in the spec, an appendix is fine
<bramus> +1
<TabAtkins> astearns: contrary opinions?
<kbabbitt> sgtm
<TabAtkins> astearns: so proposed resolution is allow webdriver extensions in our specs, in appendixes.
<TabAtkins> RESOLVED: WebDriver extensions for CSS features go into the corresponding CSS spec, in an appendix.

@darktears
Copy link
Contributor

Close this issue per resolution above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Wednesday morning
Development

No branches or pull requests

4 participants