__checked vs checked? – make syntax without compiler feel friendlier #276

Closed
timoxley opened this Issue Feb 1, 2015 · 22 comments

Projects

None yet

7 participants

@timoxley
timoxley commented Feb 1, 2015

the current __ prefix on boolean attributes makes it feel like I'm a bad person and I'm doing something wrong by opting out of the compile step.

Perhaps the Boolean attribute syntax could be altered to be more friendly and descriptive e.g. append a question-mark instead: checked?.

@timoxley timoxley changed the title from __checked vs checked? – make non-compiled use feel less dirty to __checked vs checked? – make syntax without compiler feel friendlier Feb 1, 2015
@tipiirai
Member
tipiirai commented Feb 3, 2015

I like question mark. Any chance to try whether this special character works consistently across browsers? IE8 in particular.

@tipiirai
Member

Curious: why are you not using the compiler?

I'm thinking of deprecating riot.tag, but I first want to know if there are some serious use cases I'm not aware of.

@timoxley

@tipiirai With frameworks coming in and out of vogue every 18 months or so, developers need to be diligent, avoiding the temptation to drink the kool-aid and be constantly planning to eject their existing toolchain. Having a custom DSL is a great way to keep developers locked into your framework, but not necessarily by choice.

I'm thinking of deprecating riot.tag

That's very imposing. riot.tag is how I keep the Riot lock-in out of my code. The reason Riot initially seemed appealing was that it seemed to be rather humble, embracing the idea that it's just a piece of the puzzle, rather than the usual babysitter-with-delusions-of-grandeur-now-with-bonus kitchen-sink framework. I don't want to change how my app is structured, or how I write my code, or have to install a custom syntax highlighter just to use your tool. I just want to use your API. In other words, using a custom DSL for every tool is too invasive and requires far too much buy in.

@tipiirai
Member

Thanks. Yeah, seems many people want to use riot.tag so I'm keeping it there. This article also convinced me.

Did you try the "?"- mark on IE8? This lovely browser is the sole reason for the __ syntax because it looses the expression value on boolean attributes and always converts them to true.

@atian25
Contributor
atian25 commented Feb 15, 2015

+1 for no deprecating riot.tag.

can we just has a config to __ ? some developer like me will never support ie8 anymore.

@tipiirai
Member

Looks like "?" character works on the attribute name across browsers. Here is my small test page for it.

Leaving out a special character for IE8+ means that I have to detect whether the attribute is boolean on the client side and I don't know if there are any other ways than importing the big list of boolean attribute names to the client. Trying to avoid that. Later perhaps, I can list the most popular ones and the user can add elements to that list manually.

@tipiirai
Member

Going to switch to "?" character on v2.1.0 since this is a backwards incompatible change.

@atian25
Contributor
atian25 commented Feb 25, 2015

why not use the same syntax as riot-src / riot-style, just use riot-checked.

btw, rt-src is short~

@tipiirai
Member

Because src and style are not boolean attributes and behave differently.

@tilleps
tilleps commented Jun 2, 2015

I agree with @timoxley

+1 on keeping riot.tag()

@tipiirai how about riot-is-checked / riot-is-required / riot-is-* instead of ? or __

@tipiirai
Member
tipiirai commented Jun 3, 2015

I prefer ? myself. The -is- notation sounds like an overkill for all the 45+ boolean attributes.

@tilleps
tilleps commented Jun 3, 2015

Not sure why it's considered overkill, as it would be (relatively) consistent with riot-src / riot-style / riot-tag. It just feels more intuitive/consistent to me.

While I understand that markup validation doesn't really matter these days, but I personally would prefer it to be data-is-* / configurable, as it is the only thing is keeping my riotjs markup from being validated.

Also if I'm not mistaken, starting an attribute name with ? is invalid and creates invalid xml/markup.

I understand that riotjs trying to minimize size, but I feel that having this configurable would be a great benefit / portability.

@tipiirai
Member
tipiirai commented Jun 4, 2015

Actually – you are right. I played with various options on my text editor and riot-is-* or data-is-* feels best. I think this is the way to go.

Thanks!

@aMarCruz
Member
aMarCruz commented Jun 4, 2015

I think having configurable attributes adds too many overhead to the analyzer. The code becomes slow and complicated. e.g. see the brackets() function that lets you change the delimiters.

@tipiirai
Member
tipiirai commented Jun 5, 2015

There will be no configurable attributes. We'll choose between riot-is- prefix or data-is- prefix and the compiler just checks for the existence of such attribute.

@web3d0
web3d0 commented Nov 4, 2015

Bumping to look at #853 because Riot is so close to working with SVG as it is now, I don't think these issues are related. All I have to do is mount manually at console and it works with no errors. So why an error on load? This is not a prefix or syntax issue.

@aMarCruz
Member

Regarding boolean attributes, I corrected the list and today we have 29:
https://github.com/riot/compiler/blob/dev/doc/attributes.md.

@tipiirai , expressions in boolean attributes are working fine w/o the __ prefix for IE9 in Windows and Safari 5.1 in Mac Lion/Leopard (the problematic browsers). riot still needs to know when is a boolean to remove it on falsy values, but I think this can be done in the update function with low cost.

@tipiirai
Member

Happy to remove the __ prefix. And indeed, those were there for IE8 only.

@GianlucaGuarini
Member

@tipiirai @aMarCruz I agree but we must be sure that the next riot-tmpl has a method isBoolean to lookup these properties

@tipiirai
Member

Yeah. I hope there is a way to check that without the explicit list of these attributes and it works on IE9 too.

@GianlucaGuarini
Member

@tipiirai it's pretty simple I guess return ~booleanAttributes.indexOf(attribute) am I right @aMarCruz ?

@aMarCruz
Member

@GianlucaGuarini yes. Integrating #1297, this can be something like:

// at this point the attribute was removed
if (value && typeof value !== T_OBJECT)
  setAttr(dom, attrName, ~BOOL_ATTRS.indexOf(attrName) ? attrName : value)

..maybe for non-boolean attributes we need check for zero.

@aMarCruz aMarCruz self-assigned this Dec 2, 2015
@GianlucaGuarini GianlucaGuarini added this to the 3.0.0 milestone Feb 14, 2016
@GianlucaGuarini GianlucaGuarini referenced this issue Dec 1, 2016
Closed

Wrong evalution of checked attr (v3.0.1) #2123

1 of 7 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment