{"action":"created","issue":{"url":"https://api.github.com/repos/marko-js/marko/issues/90","labels_url":"https://api.github.com/repos/marko-js/marko/issues/90/labels{/name}","comments_url":"https://api.github.com/repos/marko-js/marko/issues/90/comments","events_url":"https://api.github.com/repos/marko-js/marko/issues/90/events","html_url":"https://github.com/marko-js/marko/issues/90","id":89054375,"number":90,"title":"Proposal: Replace HTML parser with a new parser that recognizes attribute types","user":{"login":"patrick-steele-idem","id":978214,"avatar_url":"https://avatars.githubusercontent.com/u/978214?v=3","gravatar_id":"","url":"https://api.github.com/users/patrick-steele-idem","html_url":"https://github.com/patrick-steele-idem","followers_url":"https://api.github.com/users/patrick-steele-idem/followers","following_url":"https://api.github.com/users/patrick-steele-idem/following{/other_user}","gists_url":"https://api.github.com/users/patrick-steele-idem/gists{/gist_id}","starred_url":"https://api.github.com/users/patrick-steele-idem/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/patrick-steele-idem/subscriptions","organizations_url":"https://api.github.com/users/patrick-steele-idem/orgs","repos_url":"https://api.github.com/users/patrick-steele-idem/repos","events_url":"https://api.github.com/users/patrick-steele-idem/events{/privacy}","received_events_url":"https://api.github.com/users/patrick-steele-idem/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":38,"created_at":"2015-06-17T15:46:12Z","updated_at":"2015-08-13T16:54:26Z","closed_at":null,"body":"Currently, Marko is using an HTML parser. An HTML parser treats every attribute value as a `String` type regardless of how it is written.\r\n\r\nFor example, with an HTML parser the following lines are all equivalent:\r\n\r\n```xml\r\n<my-component foo=123/>\r\n<my-component foo=\"123\"/>\r\n<my-component foo='123'/>\r\n```\r\n\r\nAs a result of this limitation, Marko relies on custom tag schemas to associate a type with an attribute value or the developer must use the `${<javascript-expression}` syntax. Tag schemas are great for documentation but they are a pain to maintain and they make usage of a custom tag ambiguous. Not to mention, the `${<javascript-expression}` syntax can only be used with attributes that have a `string` type (not `expression`, `boolean`, etc.).\r\n\r\nThe author of the `<my-component>` tag can separately declare the type for an attribute and developer viewing a template wouldn't know the attribute type unless you consulted the tag schema:\r\nIt would be great if the parser used by Marko treated _all_ attribute values as _JavaScript expressions_. Spaces will end an attribute value unless the space is in a quoted string or within a parenthesis/square brackets/curly braces block. Finally, we would support `${<javascript-expression>}` usage within [ES6 Template strings](http://tc39wiki.calculist.org/es6/template-strings/) (i.e. strings \"quoted\" using backticks). The following illustrates what is being proposed.\r\n\r\n```xml\r\n<my-component number=1/>\r\n<my-component variable=name/>\r\n<my-component complex-expression=1+2/>\r\n<my-component complex-expression-with-spaces=(a + b)/>\r\n<my-component simple-string=\"hello\"/>\r\n<my-component simple-string='hello'/>\r\n<my-component dynamic-string=`hello ${name}`/>\r\n<my-component string-concatenated=(\"hello \"+name)/>\r\n<my-component boolean=true/>\r\n<my-component array=[1, 2, 3]/>\r\n<my-component object={hello: 'world'}/>\r\n<my-component function-call=data.foo()/>\r\n<my-component complex-function-call=(data.foo() + data.bar())/>\r\n```\r\n\r\nNow that we are using a custom parser, we can also improve the syntax for conditionals and looping as @onemrkarthik suggested:\r\n\r\n```xml\r\n<div if(x > 5)>\r\n   Do something\r\n</div>\r\n\r\n<ul>\r\n   <li for(color in colors)>\r\n       ${color}\r\n   </li>\r\n</ul>\r\n\r\n<ul>\r\n   <li for(color in colors; status-var=loop)>\r\n       ${loop.getIndex+1}) ${color}\r\n   </li>\r\n</ul>\r\n```\r\n\r\nThoughts? Concerns?"},"comment":{"url":"https://api.github.com/repos/marko-js/marko/issues/comments/130759304","html_url":"https://github.com/marko-js/marko/issues/90#issuecomment-130759304","issue_url":"https://api.github.com/repos/marko-js/marko/issues/90","id":130759304,"user":{"login":"kristianmandrup","id":125005,"avatar_url":"https://avatars.githubusercontent.com/u/125005?v=3","gravatar_id":"","url":"https://api.github.com/users/kristianmandrup","html_url":"https://github.com/kristianmandrup","followers_url":"https://api.github.com/users/kristianmandrup/followers","following_url":"https://api.github.com/users/kristianmandrup/following{/other_user}","gists_url":"https://api.github.com/users/kristianmandrup/gists{/gist_id}","starred_url":"https://api.github.com/users/kristianmandrup/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kristianmandrup/subscriptions","organizations_url":"https://api.github.com/users/kristianmandrup/orgs","repos_url":"https://api.github.com/users/kristianmandrup/repos","events_url":"https://api.github.com/users/kristianmandrup/events{/privacy}","received_events_url":"https://api.github.com/users/kristianmandrup/received_events","type":"User","site_admin":false},"created_at":"2015-08-13T16:54:26Z","updated_at":"2015-08-13T16:54:26Z","body":"My gut reaction to this proposal was: \"OH NO, NOT ANGULAR 2 SYNTAX!!!\"\r\n\r\nBut reading a bit further on, I fully understand the reasoning. More power, less limits!!!\r\nHowever I don't think it should be \"all or nothin\", breaking existing templates etc. \r\nMy proposal: \r\nAllow the HTML \"flavor\" described above, but also allow/enable it while keeping in full HTML attribute compatibility mode, ie `x=\"y\"`.\r\n\r\n`<div x=(5-2*sqr(2))/>`\r\n\r\nAND\r\n\r\n`<div x.e=\"(5-2*sqr(2))\"/>`\r\n\r\nWhere the `.e` means that the internals should be *evaluated* as pure javascript and returned as:\r\n\r\n`<div x=(5-2*sqrt(2))/>`\r\n\r\nThen evaluated as javascript to finally render `<div x=\"12\"/>`\r\n\r\nIt think this combines the best of both worlds (and would allow me to keep using jade to marko compilation!). The same principle would apply for string interpolation etc., ie. simply having `.e` attribute name postfix means a first \"compilation\" phase, basically just stripping the `\"`s and understanding the intention as javascript evaluation :)"}}