On 09/12/11 04:18, David Seikel wrote: > As I understand it, text tags are entirely up to the developer using > the API to define for themselves. They are completely free to use what > ever works for them. They are opaque tags, and could be any damn thing > the developer wants. > > XML should not be encouraged, it's a solution in search of a problem > that has yet to find any problems it's actually a good match for. In > the mean time, it's been applied to many things it should never have > been used for, coz people think it solves the most important, top > priority, bugger anything else "problem" of being "human readable". > Most XML data never has humans read it. Lots of XML is not human > readable anyway. Most XML just takes up more space, takes more time > and resources for computers to parse, takes more time and uses more > bandwidth travelling from one computer to the next, and generally just > wasting every ones resources. > > On the other hand, being somewhat similar to HTML might be a good thing > for text tags. It's a similar sort of thing that lots of people are > familiar with for a similar sort of job. HTML is not XML. It looks a > lot like XML, there is a subset that tries to be XML compatible, but > HTML is not XML. > > In the end though, it's up to developers using the API to decide for > themselves what text tags they will use in their own projects, isn't > it? They may choose to use completely human unreadable symbols, with > zero similarity to XML, for their text tags, for their own reasons, > secure in the knowledge that for their own app, their odd choice of > symbols is of no consequence. That's certainly the way I read the > documentation when I was using the edje API that wraps evas for my own > application. Then again, that documentation left me guessing a few > things. > > I certainly don't think XML should be forced on people. Or HTML for > that matter.
I completely agree with everything you said, and I also dislike shoving XML everywhere. This patch adjusts textblock's markup to support "empty" tags. Why is it supported? because of the way that textblock works, that you can insert formats without tags (legacy syntax) using direct function calls, thing got a bit to ambiguous. For example, the format \n if inserted through format_append would have caused a <\n> tag to be created when markup was retrieved. Thus, when re-inserted, it would have been interpreted as "+ \n" i.e open a new format, newline, which is incorrect (esp. since it was an empty tag before). One way of solving it, could have been, just matching against all the formats we know to be the empty and handle those as such, but that didn't feel as correct as doing what everyone know and use. Generally, this makes the markup more strict which in turn will let us handle markup in a faster, more defined, and nicer way. :) Thanks a lot for your comments, and I hope you share my opinion. Daniel: Leif is right, it's an empty tag and should be used as such. -- Tom. ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
