[css-values] attr()'s type system is inconsistent with other things #10437
Comments
|
Agenda+ on behalf of @tursunova. |
|
#3702 was already closed, since it doesn't bring extra functionality and attr() is easier to read, compare #3702 (comment). Even if it will be decided to add a conversion function, as per #6408, I don't think we would like to remove |
|
The CSS Working Group just discussed
The full IRC log of that discussion<kbabbitt> moonira: in attr() grammer we define without angle brackets which is inconsistent with other custom property syntax<kbabbitt> ... we have a prototype of attr() in Blink which we are going to ship <kbabbitt> ... propose to resolve this issue by making attr() consistent with @Property using angle brackets <kbabbitt> TabAtkins: want to make sure all the places use consistent syntax; attr() was designed before we came up with this other stuff <kbabbitt> astearns: and this is ocnsistent ewith type decision we made earlier <kbabbitt> TabAtkins: yes <lea> +1 seems like an obvious win to me <kbabbitt> astearns: questions? <chrishtr> q+ <kbabbitt> Proposed: Use the <syntax> production that we hae defined in the mixins spec, consistent with what we will be allowing in registered custom properties <flackr> +1 sgtm <kbabbitt> lea: (missed) <fantasai> +! <astearns> ack chrishtr <fantasai> s/!/1/ <astearns> s/(missed)/consistent with custom properties etc. <kbabbitt> chrishtr: question, this is new syntax for attr() and there's no compatibility risk with existing websites? <kbabbitt> moonira: I don't think it should be a problem <kbabbitt> chrishtr: attr exists, but it's just not exposed <kbabbitt> moonira: existing attr() version doesn't include type syntax <kbabbitt> chrishtr: what you're planning to ship will have type syntax? <kbabbitt> moonira: correct <kbabbitt> chrishtr: so because it's new syntax, there will not be a compat concern? <kbabbitt> moonira: yes <kbabbitt> astearns: other commments or questions? <kbabbitt> hober: you're right, everyone has simple attr() that's it, should be good. but... <kbabbitt> ... older spec has had other syntax for a long time, authors do like to do the cool thing they hope will work eventually <kbabbitt> ... so there is potentially a compat risk, there may be things that were invalid before and would have been ignored <kbabbitt> chrishtr: good point, it's possible but it seems worth trying to me <kbabbitt> dbaron: I think it might even be less scary to change it just because suddenly implementing a feature if authors have been trying to write it and not test it for a long time is scary <TabAtkins> we don't *usually* account for people writing invalid stuff ahead of the spec unless we're pretty sure there's actually a problem <kizu> +1 <kbabbitt> ... changing the syntax right befor eit ships helps with that <kbabbitt> chrishtr: are there other older features that have not been shipped with similar conditions? <kbabbitt> tabatkins: no additional locations, just @Property, @function, attr() <TabAtkins> @Property @function and @tr <kbabbitt> astearns: objections? <kbabbitt> RESOLVED: Use the <syntax> production that we hae defined in the mixins spec, consistent with what we will be allowing in registered custom properties <matthieud> q+ <astearns> ack matthieud <lea> q+ <kbabbitt> matthieud: for @Property we need to put the syntax in quotes, but for attr() and @function we don't need uqoes? <kbabbitt> tabatkins: no, @Property will be updated <kbabbitt> lea: the string versio will strictly be more powerful because you can still do quantifiers and htings like that? <kbabbitt> tabatkins: no, you'll be able to use th enew syntax prodyction <kbabbitt> lea: can you use quantifiers, e.g. 0-5? <kbabbitt> tabatkins: I don't think that's in the grammer but it's not supported for the string version either <kbabbitt> ... (missed0 <TabAtkins> like <number [0, 5]> |
tabatkins
added a commit
that referenced
this issue
Oct 25, 2024
…x up its parsing/substitution rules as a result. #10437
|
Edits checked in, including moving the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As briefly discussed with @tabatkins during CSS Day:
@property, we have"<length>", and similar.<length>directly. (https://github.com/andruud/csswg-drafts/pull/2/files). EDIT: This now exists, but only for css-mixins-1.Why doesn't
attr()use the same way of specifying types? I.e., shouldn't we doattr(data-foo <length>, 0px)instead ofattr(data-foo length, 0px)?EDIT: I accidentally posted the issue template.
The text was updated successfully, but these errors were encountered: