3 ms·

Looks fun, happy to see a great usage of CSS custom properties, but a little baffled and let down that it seems to use invalid HTML attributes :/ When writing

by err4nt 7y ago

Looks fun, happy to see a great usage of CSS custom properties, but a little baffled and let down that it seems to use invalid HTML attributes :/ When writing HTML you can invent any custom attribute you want so long as it begins with `data-` [0], and in JavaScript there's even a special dataset interface that makes working with these custom data-* attributes simple and easy [1]. This could be improved without changing any of the design at all - just by updating it to not rely on writing invalid HTML. 0: https://html.spec.whatwg.org/#embedding-custom-non-visible-data-with-the-data-*-attributes https://html.spec.whatwg.org/#embedding-custom-non-visible-d... 1: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...

James0x57 7y ago
I gave this a lot of thought. I used to be a stickler for valid markup. augmented-ui had a data- prefix as an option up to right before initial release. Here are my reasons for not including it (yet): 1) data- isn't a great fit for it. It's not specifically data, it is visible, and I didn't want to clutter the dataset property for people using it with database output 2) invalid attributes are used everywhere, constantly. Even google.com uses them a few times. (this is the reason I'm not a stickler for it any more - if you get to the point where you're using js frameworks to build scalable web apps, chances are you're going to use invalid attributes in every single viewmodel file, or your coworkers will) 3) "data-" adds 5 extra characters to clutter and type on every single element and each selector in the main project css file. People who use augmented-ui are likely to use it on many many elements, and it adds up fast when you're building something big. 4) The only likely reason an invalid attribute might break is if the spec expands to use that exact same attribute. In the unlikely event that "augmented-ui" becomes a standard attribute, I will happily write the (grunt or w/e) script to patch every file in a project since this is very very easy to detect with regular expressions. (I've written large scale migration scripts and dozens of code parsers for work AND for fun) 5) I didn't want to split the userbase, especially at launch, with different options that can't be interchangeable. (interchangeability comes at a cost of exponentially large selectors in the fallback css because of Edge - the 5 layers of fallback support for Edge becomes over 30 selectors with just 2 different options) In the future I will have a dist folder that has a safely minified option at least. I may also have data- prefixed versions as a mutually exclusive option in the dist folder at that time if there is demand for it. 6) The first few commits were using class names instead of the attribute but even that was annoying to use because the class names were prefixed to avoid stepping on toes and the class list got way too cluttered. The "augmented-ui" attribute saved typing characters, looked cleaner, and felt cooler to use. (subjective, I know) I understand and respect if you choose not to use it because of wanting valid attribute markup. Hopefully though this at least gives you perspective into my reasons and careful considerations that ultimately lead me to choose not to include it.

by err4nt 7y ago

James0x57 7y ago

I gave this a lot of thought. I used to be a stickler for valid markup. augmented-ui had a data- prefix as an option up to right before initial release. Here are my reasons for not including it (yet): 1) data- isn't a great fit for it. It's not specifically data, it is visible, and I didn't want to clutter the dataset property for people using it with database output 2) invalid attributes are used everywhere, constantly. Even google.com uses them a few times. (this is the reason I'm not a stickler for it any more - if you get to the point where you're using js frameworks to build scalable web apps, chances are you're going to use invalid attributes in every single viewmodel file, or your coworkers will) 3) "data-" adds 5 extra characters to clutter and type on every single element and each selector in the main project css file. People who use augmented-ui are likely to use it on many many elements, and it adds up fast when you're building something big. 4) The only likely reason an invalid attribute might break is if the spec expands to use that exact same attribute. In the unlikely event that "augmented-ui" becomes a standard attribute, I will happily write the (grunt or w/e) script to patch every file in a project since this is very very easy to detect with regular expressions. (I've written large scale migration scripts and dozens of code parsers for work AND for fun) 5) I didn't want to split the userbase, especially at launch, with different options that can't be interchangeable. (interchangeability comes at a cost of exponentially large selectors in the fallback css because of Edge - the 5 layers of fallback support for Edge becomes over 30 selectors with just 2 different options) In the future I will have a dist folder that has a safely minified option at least. I may also have data- prefixed versions as a mutually exclusive option in the dist folder at that time if there is demand for it. 6) The first few commits were using class names instead of the attribute but even that was annoying to use because the class names were prefixed to avoid stepping on toes and the class list got way too cluttered. The "augmented-ui" attribute saved typing characters, looked cleaner, and felt cooler to use. (subjective, I know) I understand and respect if you choose not to use it because of wanting valid attribute markup. Hopefully though this at least gives you perspective into my reasons and careful considerations that ultimately lead me to choose not to include it.