-
Notifications
You must be signed in to change notification settings - Fork 694
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
Comments
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. |
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. |
The CSS Working Group just discussed
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. |
Close this issue per resolution above. |
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:
What do people thing? @fantasai @tabatkins
The text was updated successfully, but these errors were encountered: