Closed megawac closed 11 years ago
True. This happens because for html parsing I use innerHTML
property of internal div
element. Simple fix is just to wrap your html with <table>
. Does such fix work for you?
BTW the same could be achieved using shorter emmet expression: DOM.create("table>tr>td{hi}")
True those emmet strings are beautiful! Just got a surprise when I was testing your library with some templates. Its a bit of pain to have to remember to wrap them in a table... Could you not just do the test most libraries do:
var match = text.match(/^\s*<(t[dhr]|tbody|tfoot|thead)/i); if(match) return tableFix(match,text);
function tableFix(match, text) { ... }
I fully understand your suggestion just have one concern about the idea in general. The problem is that there are examples where you can't fix html parsing in this way. For instance you can't determine parent for li
(could be ol
or ul
), td
(could be tr
or th
) etc. Therefore I decided to get rid of tag guessing.
Could you describe your use case in more details? How do you manipulate tr
's after creating? I feel like we can fix your problem in a different way.
Sorry! I was playing around with some MVC frameworks and just testing automatic compilation. This really is a non-issue for 99% of use cases so I agree no need to change.
Cool, glad that we've came to convention.
Parsing:
var tr = "tr"
var td = "td"
DOM.create("<" + tr + "><" + td + ">hi</" + td + ">/<" + tr "> => "hi"
Sorry about the formatting