[whatwg] <imgset> responsive imgs proposition (Re: The src-N proposal)
bruno at hexanet.net
Tue Nov 12 02:15:58 PST 2013
On 11/12/13 12:19 AM, "Anselm Hannemann" <info at anselm-hannemann.com> wrote:
>Also the different attributes have very inconsistent
>new micro-syntaxes with different values which is not very good for a
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
>Therefore it gets even harder to understand than the current src-N
>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
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
>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
that regex done by the browser would be slow, is not even a slight remote
The amount of bytes that srcset or src-N will bear onto the download of a
worth way more milliseconds in waiting time, that it is for a couple regex
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.
More information about the whatwg