[all] Can we start ignoring CSSRule.type?

[tabatkins]

The CSSRule interface has a .type attribute, using the old and busted "make it an int, then define some consts associating the int with names" pattern. This is terrible for many reasons, and we've abandoned it in new APIs.

In similar situations, SVG has switched to just having all new things use a single "unknown" value, and specifying the value properly as some string-valued attribute.

Can we do the same thing?

• deprecate CSSRule.type, defining one new value that all new rules will use. (And CSSOM defines that, unless otherwise specified, all rules use that value, so individual specs don't have to worry about it.)
• add a new attribute to CSSRule, provisionally named ruleName, which exposes the name of the rule as a string. Whether it's reflected as "@foo" or "foo" is unimportant, we can decide either way. (I slightly favor "@foo", as that's how most of us seem to refer to the rule in practice.)
• close down the CSSOM Constants page on the wiki ^_^

[css-meeting-bot]

The CSS Working Group just discussed Can we start ignoring CSSRule.type?, and agreed to the following:

• RESOLVED: Do not use .type in the future
• RESOLVED: Don't invent new .type values for future rules; recommend usage of .constructor.name

The full IRC log of that discussion

<dael> Topic: Can we start ignoring CSSRule.type?
<dael> github: https://github.com//issues/4142
<dael> TabAtkins: Was defining @Property rule. I remembered we have to register .type on the wiki page. It's a terrible pattern from the 90s. We just do strings now. Does anyone find it valuable to make the change? We deprecate .type and all new CSS rules us a placeholder value. Add a new property that exposes name of rule as a string
<fremy> +1
<dbaron> sounds like a good plan
<dael> TabAtkins: That's how other things work. SVG now works like this. It's easier to work with.
<fantasai> maybe .typeName
<fantasai> ?
<dael> TabAtkins: Objections? Anyone feel it's worthwhile to do or not and we live with current system?
<dael> emilio: Usually when I do CSSOM stuff I do instance of rather then checking .type. Is new prop really necessary?
<AmeliaBR> .constructor.name works
<dael> fremy: If you go across iFrames it doesn't work. Have to get constructor constrained to a string
<dael> TabAtkins: True
<dael> TabAtkins: Mostly this is just terrible smell and have to keep doing it for new rule types. Would like to stop. If we're okay with instance of and iFrames are awk. I'm okay with just saying we stop using /type and future rules get a placeholder
<astearns> +1 to stop using .type
<dael> emilio: No strong opinion. I'm happy with string API. fremy point is nice
<dael> fantasai: No obj to adding, but do we want everythign else to have same type or maintain pattern going forward and enoughrage string
<dael> TabAtkins: Biggest encouragement is make int not work
<dael> AmeliaBR: Do we have use counter on how often .type are being accessed?
<dael> TabAtkins: No. pretty certain it's non-0. Removing .type isn't needed, just leave as is as a fossil
<dael> AmeliaBR: I support doing what we did with SVG where new things get unknown enum and you have to figure it out with some other way. Knowing how much current enums are used we'd know how many people would lose going forward.
<dael> TabAtkins: They can switch for new values
<dael> myles: Can't you use object.constructor.name and get a string?
<dael> fremy: True. But then you need class for each thing you create
<dael> TabAtkins: We don't right now. Weird thing HTML does. We use a fresh class for new rules
<dael> fremy: Reasonable to me. That works for everybody. Create unknown and stop increment the counter
<dael> myles: RIght now all css rules have own subclasses. WOuld work.
<dael> TabAtkins: Okay with that. Works across iFrames. Would let us drop to tombstone .type and not use in the future
<dael> TabAtkins: Let's ask for resolution on that
<dael> Rossen_: Objections?
<dael> RESOLVED: Do not use .type in the future
<dael> myles: Should resolution say use?
<dael> TabAtkins: I'll clarify in the issue
<astearns> s/in the future/in future specifications
<dael> fantasai: Let's retype the resolution TabAtkins
<TabAtkins> RESOLVED: Don't invent new .type values for future rules; recommend usage of .constructor.name
<dael> AmeliaBR: Do we want to get more specific and say that any rule type that doesn't yet have a declared type value should return 0 which is the unknown rule from DOM2?
<dael> AmeliaBR: And with that are there any specs that declare a value and haven't been impl? Should they be included?
<dael> TabAtkins: The only recent one is feature values. I'm fine with it staying how it is. I don't think any new @rules other then @Property
<dael> fantasai: Might be in future
<dael> TabAtkins: Yeah, but this ask was about new @rules in specs that could be changes to match resolution
<dael> TabAtkins: We'll find them