- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Jan 2024 01:03:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-conditional-4] Need a way in CSS to test for support of HTML features`, and agreed to the following: * `RESOLVED: Add html function for testing both elements and attribute support` <details><summary>The full IRC log of that discussion</summary> <frances_> Alan: next is testing support for html features<br> <florian> q+<br> <frances_> Jen: 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 s[CUT]<br> <TabAtkins> q+<br> <fantasai> proposed syntax - https://github.com/w3c/csswg-drafts/issues/9746#issuecomment-1867929357<br> <frances_> Jen: 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?<br> <astearns> ack florian<br> <frances_> 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?<br> <astearns> ack TabAtkins<br> <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)<br> <frances_> tab: 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<br> <astearns> ack florian<br> <frances_> tab: can do a handful of automatic protections. For broader case, targeted pseudo class to target exposure. Might not reasonably be able to do it.<br> <astearns> ack fantasai<br> <fantasai> HTMLInputElement.prototype.switch<br> <frances_> 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,<br> <frances_> Ian: trouble with many attributes, not a simple registry of possible values. Alot of internal processing in the attributes.<br> <frances_> Alan: could be based off of ideal numbers.<br> <astearns> s/ideal/IDL/<br> <frances_> Jen: hoping to create reusable pseudo-elements, not one-offs<br> <TabAtkins> I mean I'd *like* to have a generic mechanism. Just not seeing a way to do that that's not registry-based.<br> <frances_> Alan: 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.<br> <frances_> Alan: any other ideas for testing attribute support generally?<br> <frances_> 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?<br> <frances_> florian: syntax edit<br> <frances_> 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.<br> <TabAtkins> Not all valid and processed attributes are reflected as IDL properties.<br> <khush> q+<br> <frances_> tab: Don't have an example, not all attributes are reflected as ideal properties, anything can go in the element attribute set, ideal 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.<br> <TabAtkins> s/ideal/IDL/<br> <frances_> Alan: if we go with this, people might find it useful where elements are not reflected as IDL properties, specified browser with attributes.<br> <TabAtkins> I *would* expect it to work all the time, yeah.<br> <frances_> Jen: @supports add a switch, test popover, do we need to test and see if it works all the time?<br> <frances_> Alan: put it in place for people to use in set of reflected properties possibly<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/9746#issuecomment-1867929357<br> <frances_> Ian: Are all objects defined in the IDL?<br> <frances_> 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.<br> <TabAtkins> Tho 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<br> <frances_> Ian: possibly test for webGPU device<br> <fantasai> html(rb)<br> <fantasai> html([dir])<br> <fantasai> html(input[type])<br> <fantasai> html(input[type=color])<br> <frances_> fantasai: scoped to elements, some kind of a function like markup and a tag name and reflective syntax for it, and test.<br> <frances_> fantasai: It is the direction I'd like to go in and be limited to the support for each attribute in the elements.<br> <TabAtkins> Like, `<input type="foo">` is a *supported* value. It's just treated identically to "text".<br> <frances_> florian: Go through ideal later possibly to see if it is matched.<br> <khush> q-<br> <frances_> Jen: alot 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<br> <frances_> Ian: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<br> <fantasai> TabAtkins: but that returns 'text' if you get it<br> <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<br> <frances_> Alan: any other comments?<br> <fantasai> s/TabAtkins:/TabAtkins,/<br> <TabAtkins> Sure, but if your test is "does this round-trip identically", then other types of canonicalization of *understood* values won't work either<br> <frances_> PROPOSAL: A straightforward way to check for html element support to specify elements.<br> <frances_> for specified elements*<br> <frances_> Alan: break into resolvable checks, break into a resolution, and do elements today, see if we can resolve on attributes as well later<br> <frances_> Jen: 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<br> <frances_> PROPOSAL: Check if HTML elements are supported<br> <frances_> tab: there is no reasonable use case for attribute values<br> <frances_> florian: what do we mean by html elements supported? such as you must parse, what about deprecated values and elements?<br> <TabAtkins> s/there is no reasonable use case for attribute values/weakly objecting, no use-case has been presented for testing for element names yet/<br> <frances_> Alan: need to resolve, any objections?<br> <TabAtkins> happy for "try to work it out in an Ed"<br> <frances_> tab: if we can figure out a way to do it<br> <frances_> RESOLVED: Add html function for testing both elements and attribute support<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9746#issuecomment-1876171765 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 January 2024 01:03:10 UTC