On 11/12/13 12:19 AM, "Anselm Hannemann" <i...@anselm-hannemann.com> wrote:
>Also the different attributes have very inconsistent >new micro-syntaxes with different values which is not very good for a >webstandard. The attributes I have presented are not necessarily set in stone. They can be inlined or improved. I am only introducing a new early logic of implementation. > > >Therefore it gets even harder to understand than the current src-N >approach. >Please never forget to think about that this has to be writable by every >normal web developer. I am normal web developer myself. It so much easier to me than having to repeat a path again and again in a very long endless 'value', that keeps repeating the same logic over and over for every image,especially in the case of a gallery of images. I think the way it segments concerns into separate parts actually makes it much legible. You can discern right way how many set of images you have. Say a plugin which introduce its new image definition within the platform, is identifiable right way. The css breakpoints themselves could be tokenized, but I didn't get to that part. >Introducing RegEx not only >slows down a browser but also will make this unusable for a lot of people >who donĀ¹t understand this. Regex is already part of the HTML5 form validation syntax. It's not any more unusable or slow than the 'pattern' attribute for the input element. I very much dislike the use of regex in an interpreted language, but the argument that regex done by the browser would be slow, is not even a slight remote concern. The amount of bytes that srcset or src-N will bear onto the download of a page is worth way more milliseconds in waiting time, that it is for a couple regex to execute in c++... Any normal web developer who suck at regex rules (myself included) does not really need to understand regex either. Good examples on stackoverflow would be sufficient for that.