An alternative proposition to picture and srcset, with wider scope
Managing responsive designs is hard, so let’s use our <head>
Here is what I believe is the best proposition yet for managing our responsive designs. This includes managing our CSS, JavaScript, and inline <img>’s.
<head> <meta name='case' data='breakpoint1' media='min-width:350px' /> <meta name='case' data='breakpoint2' media='min-width:1000px' /> </head>
Deconstructing the case for breakpoint management in <head>
To re-cap our current problems with breakpoint management; we write our Media Query’s dozens of times in CSS files, we write the same tests in our JS files, and we will soon write them inside every <picture> element too. The same tests, in every case, but with a different “do something if true” instruction. That’s wasteful in terms of repetition, becomes very hard to manage, requires continuous re-processing of a test that never changes, and is future unfriendly. Read more detail here.
So why does that code up there solve all these issues?
At first glance, that code is going to cause many people a few frowns. We are not used to seeing this sort of thing – meta elements are supposed to describe a property of the URI aren’t they? Well, no. We already set meta elements that do not describe a property of the loaded URI – all of us do. Every time we set <meta name=”robots” content=’index,follow’ /> or any associated instruction. Or when we tell Google Translate to not run on the page. Or when we tell IE not to use its picture menus. These are all examples of using a meta tag to control the behaviour of some software that’s consuming the URI’s HTML, and not to describe properties of the page itself.
What the code above does is set ‘case’ to equal a particular value, when a media query expression is matched. And if that’s done in the HTML <head> we know that absolutely everything else can rely on it – the <head> is the very first thing parsed by a browser, even before anything inside <body>. Anyone familiar with working on the ‘responsive images’ problem should at this point be getting very excited. It means that the browser can be aware of the need to adapt before any pre-fetch behaviours have been triggered by finding an <img /> element in the mark-up. That is a major advantage and is how this solution solves the problem of image pre-fetch.
Some people will be uncomfortable with having the queries in the head, but I’d say putting the queries into the CSS is, most of the time, backward – it’s just that we’re used to doing it that way so it makes a certain kind of sense. Remember that the order we actually build a site goes like this:
1) Consider a device size
2) Create a design for that size on paper or in Photoshop
3) Write the code to implement it
4) Increase device size and goto 1
All of our code is actually hanging off the same media query breakpoints, because they’re the design breakpoints. So why re-define the same tests in each technology rather than do it once in HTML and have the CSS and JS just reference them? We could still do specific tasks in the “old” way, if desired.
How would we use these <meta> elements?
In HTML
Addressing first how we might use it to control <img/> in our mark-up:
<body>
<img src='/content/images/{case}/photo.jpg' alt='' />
</body>
What has this bought us?
- Well, we have a single image element with no custom properties or other code, which will adapt to any number of breakpoints you want to declair, without ever adding another character to the image code.
- We have something that is backward compatible right now: either create a directory called “[case]” so that a file exists there, or if you want to be cleverer about it, set your server to alias [case]’s path to an already existing path.
- The image is cachable by proxies and CDNs because the source for each version of the image has a unique URI.
- UPDATE: By using {} instead of [] this solution is actually complying with the URI Template too (See the RFC) – thanks Brett!
Are there any drawbacks?
None that I can see. Even with the current proposal, we should never change the alt attribute because all resources are supposed to have the same semantic meaning.
In CSS
Rather than writing endless clauses like this, where a test must be performed each time:
@media only screen and (min-width: 700px) { ... }
We could write this instead:
@media (case: breakpoint1) { ... }
What has this bought us?
- We are abstracting the test itself away from the block of code that defines a response. This means if we decide to change the breakpoint condition, we do it once in the <head> and everything else works automatically.
- We reduce the number of tests required of the browser. It’s not re-running a test, it’s instead checking the value of case – which has already been computed.
- We have smaller code. Yeah, i know, it’s a tiny point but it’s a benefit non the less.
Are there any drawbacks?
Not that I can see, because you can still carry on using existing syntax if you like, this is just an additional capability we may want to take advantage of. It can also be used in all the same ways you use any existing media-query.
In the case of JavaScript
It’s largely the same as for CSS. Instead of doing its own tests, it can just use whatever value is stored in the ‘case’ node. There is prior art for this: the behaviour here would be exactly the same as the wonderful shiv that a lot of people are now using Conditional CSS, but it’d check against the meta element and not the body:before pseudo element.
So why might this not work?
I’ve only analysed this from the perspective of an author. I do not know how much effort it might be for a browser vendor to actually implement, and whether they would be willing to do so. For me, this is the only potential downside to the whole idea – it needs the vendors to implement it. In terms of functionality and benefits of the approach, i can see no downsides to the idea itself.
I think vendors may object initially to the idea of browsers having to do this:
1) detect the existence of a specific meta tag
2) if it exists scan all src=”” properties for the variable string to replace with the variable value
If no meta tag was there, it wouldn’t have to do anything with the src strings.
How likely are variables?
There is a history of our core technologies not supporting Variables, but there is a trend of adding them recently:
1) We now have variables in CSS ( http://dev.w3.org/csswg/css-variables/ )
2) We now have variables in URIs ( http://code.google.com/p/uri-templates/ )
3) We’ve always had variables in JS
So, HTML’s the last one standing without support for variables.
———–
N.b., This post is a re-post from a blog entry I wrote, it was suggested on Twitter that the Community Group should see it. Source: http://mattwilcox.net/archive/entry/id/1091/
The suggestions here are a mix from an older suggestion of mine which worked with <picture>, and the ideas of Denis LeBlanc
———–
UPDATE: Philip Ingrey has written a polyfil for this soultion!
Great idea Matt,
It makes a lot of sense to establish a hi-res image directory upfront in the header based on the screen size, rather than testing & loading hi-res images for every asset.
Hope to see something like this implemented!
Hm, I don’t like to deal with variables in the elements’ URL. Can’t we just define all the settings in head and just use the settings in the attributes then?
Can you expand on what you mean, and why you do not like the idea of a variable in the URL?
I think variables in HTML are too complex for most developers. I personally would love this but won’t imagine what a normal developer would say about this.
Why? Normal developers use CSS and JS. Both have variables. In what way is this harder?
– CSS do not have variables as a required markup.
– JS has but who actually of the normal devs works with variables in JS? I think not many… we are but we are not the normal developers.
Why are CSS preprocessors so popular? They allow variables in CSS. There is also work being done to make CSS variables work natively.
Who doesn’t use variables in JS?
Every plugin I’ve seen, either jQuery or raw JavaScript, the developer used variables. You also use variables in PHP all the time.
Maybe you don’t personally use variables in your projects, but I can guarantee a vast majority of us do use variables in the web stack, CSS/JS/PHP we work with everyday. I think a native way to use them in HTML would be a great benefit that would help keep implementations of responsive images DRY.
Whilst I’m glad to see suggestions outside of and surfacing, I’m unsure about bringing variables into markup. As a document essentially, I am unsure of the chances of variables being implemented at all.
That’s cool, but please can you elaborate on *why*? Is it just because it’s different and that’s uncomfortable, or is there a genuine practical reason why variables would be bad?
Apologies.
I guess you could say it is different, and yes, a bit uncomfortable.
If variables/meta variables had some sort of purpose within a HTML Document, I would think they would have been implemented by now. It would be incredibly handy for one thing for multiple purposes, images aside.
The reason why variables do not exist already is the reason why I am a bit sceptical as to why they will not be implemented.
That crappy attitude aside, I think its an excellent approach, certainly cleaner that the srcset approach. I would imagine easy polyfills could be created to maintain this approach in legacy as well.
Would there be any room for mis-use of meta variables? What strict contexts would you propose? They would be a string of course, thats a given.
I suppose what I’m really battling with is that if this idea is seriously considered to put in place for implementation, what is stoping other aspects of markup applying some sort of variable.
I’m a moan, I know 🙂 Good work so far sir!
On the plus side – there is already a polyfil for it, would you believe!? http://jsbin.com/3/ecifaf/latest/
I agree that we have a history of “there aren’t variables” to contend with here, but there is a trend of adding them:
1) We now have variables in CSS ( http://dev.w3.org/csswg/css-variables/ )
2) We now have variables in URIs ( http://code.google.com/p/uri-templates/ )
3) We’ve always had variables in JS
So, HTML’s the last one standing without support for variables.
What’s stopping other aspects? Nothing – are there reasons why this would be bad in other cases?
It’s a really simple, elegant solution. It answers all of the problems of previous proposals and leaves minimal, backwards compatible and easy to maintain, markup. I’m really excited about this. It’d be great to get some input from browser vendors to say whether it’s feasible or not.
Good work, this feels like it really could work.
I really like this solution.
Advantages over <picture> :
– more concise
– easily backwards compatible
– more readable (and more readable that srcset)
Points I’d make:
– The square bracket syntax would need looking at as some CMS’s use that already (little point)
– allowing css to reference the breakpoints set in html breaks the content/style separation. (I’m not saying variables in css is a bad idea, just that this cross-over probably is)
– where would using these breakpoints stop? Any URL? Any text leaf? Could I switch which css file I load based on these breakpoints? Or, more extreme, change from using javascript to coffesript?
e.g.
<head>
<meta name='lang' data='text/javascript' media='min-width:350px' />
<meta name='lang' data='text/coffeescript' media='min-width:550px' />
<meta name='loc' data='file.js' media='min-width:350px' />
<meta name='loc' data='file.cs' media='min-width:550px' />
</head>
<script type="[lang]" src="[loc]">
No sure why you want to do this, it’s just adding meta variables into html will have other consequences.
But all in all – a really good idea.
I should point out that this is a first draft idea. I think we’d also need a way to delimit the variable an author could choose. e.g.,
<meta name="variable-pattern-start" value="[" /><meta name="variable-pattern-end" value="]" />
Philip – i don’t think it does break anything in terms of seperation of concerns. Please see http://mattwilcox.net/archive/entry/id/1081/ for why the tests themselves should not be separate. And remember that this is an optional syntax – people can continue to use the standard CSS/JS as they do right now and not take advantage of the centralisation of response points if they so wished.
meta variables could be restricted? I don’t know, I’m not sure how much of a problem they might be. I am sure there’s a pretty big problem without them though – it’s why we keep banging our heads against other solutions which all have their downsides as outlined above.
Sorry, I don’t think I explained myself well with the css point.
I agree that the test’s shouldn’t be separate, however it seems a little off to define a variable in the html and be able to use it in the css. I personally wouldn’t feel so bad if it was the other way around, e.g.
CSS
MQ {
smallscreen: only screen and min-width(300px),
bigscreen: only screen and min-width(600px)
}
HTML
<head>
<meta name="size" value="small" media="case: smallscreen"/>
<meta name="size" value="large" media="case: bigscreen"/>
</head>
That way you could manually define the queries in the HTML, or use the CSS set ones but not vice-versa, however this does require a change to both CSS and HTML specs!
Ah, i see. I do disagree though. Media Queries are already being baked into HTML via <picture>, <video>, <audio>, and of course <link> so they’re already there and often in use in the mark-up rather than the HTML ( for an example see http://enochs.co.uk where the media query selecting which CSS to use is in the HTML, not the CSS ).
It also makes more sense to have them in the HTML because they can be guaranteed to have been executed before any other assets are requested. That is a major advantage and exactly how this solution solves the problem of image pre-fetch. Putting the queries into the CSS is actually backward – it’s just that you’re used to doing it that way so it makes a certain kind of sense.
Remember that the order we actually build a site goes like this:
1) Consider a device size
2) Create a design for that size
3) Write the code to build it.
4) Increase device size and goto 1
All of our code is actually hanging off the same media query breakpoints. It doesn’t actually make sense to have them separated into their respective technology stacks and implemented in those stacks. It’s just that’s how it’s evolved.
Ok, whilst not totally convinced, you may have slightly won me over with the guaranteed first execution – well played!
This method does lack <picture>’s ability to easily support different file formats, but on the whole I much prefer this, meta-variable, suggestion.
Cool 🙂
Hmm… I wonder if we could address that with another variable? I.e., make it a variable-pair. There’s no real reason why we have to have one variable for one matching case.
With that said, I’m not sure how often I’d need to change file format for a different response point, and that may be seen as over-complicating the issue – but it would be nice to have the option.
This (Denis Leblanc’s?) idea of “meta variables with Media Queries” looks very promising!
I love how it indeed solves problems with a wider scope, in a way it is similar to what Jeremy Keith described as Conditional CSS as it prevents the duplication of media queries throughout our code.
I do wonder about prefetching however. Theoretically the (supporting-) browsers pre-fetching behaviour would not be triggered because the ‘variable’ is set in the HEAD, but this remains to be seen/tested.
Also, the variable ‘test’ is run on every page load (a marginal performance issue?) and, obviously, the media queries must be re-evaluated with every resize/oriëntation change, etc.
So, I guess until we would see some initial implementation there remain a few questions. Promising idea nonetheless…
I am not sure about what triggers the pre-fetch behaviour, so you may be correct. We’d need a browser vendor to tell us if this is workable or whether they could make it work.
As for the “test” – this is actually far more efficient than current code. Remember that your argument of re-testing holds true for any media query in use already; so every one in your CSS, JS, and HTML. In the case of the picture element, it’s re-run *for every picture element*. Doing this in the head is actually much more efficient than currently.
Matt, it seems the pre-fetching behaviour differs between browsers. (‘Speculative’) ‘look ahead pre-parsing’ seems to not be described/specced so that’s an issue.
Hopefully someone knowledgeable (browser vendor) can chime in.
As for the “tests”: I did not word my remark well. I know MQ’s are, obviously, currently re-evaluated in CSS, JS etc.
It’s a bit of a hack, but I’ve put together a jQuery plugin of the proposal for people to kick around:
http://pci.github.com/metavar_polyfill/
Currently it won’t work with dynamically inserted images (but it shouldn’t be too hard to add)
I think Denis Denis LeBlanc’s idea was maybe the best thing to come out of the whole src-set vs. picture element post. I really like the idea of meta media tags, it keeps the markup simple and DRY which has been a concern of mine.
For those who are concerned about using variables in their URIs, a URI template could be used. The URI Template RFC was recently published.
Here is an example of what using a URI template might look like with the meta media tags.
lt;body>
<img src=’/content/images/{case}/photo.jpg’ alt=” />
</body>
URI templates use { } brackets wrapped around the variable. You can see the only difference from Matt’s example are the { } brackets instead of the square [ ] brackets.
This would alleviate the issue Philip Ingrey brought up about the square bracket syntax having issues with CMS’s, I believe he is referring to WordPress’s shortcodes.
In regards to using the active meta media variable in CSS, I think this is a great idea and is something that could be explored more and should be included with the CSS variables proposal.
Lastly, if prefetching does seem be in issue with using this with the image element, I think moving forward with the picture element and adding meta media tags to it would be the best solution, where any img tag defined inside of a picture element would not be downloaded if the picture element is supported, similar to how the noscript tag works when wrapped around an img tag if JS is enabled. This would also keep the door open for an element that supports new image formats with fallbacks.
Meta media tags + URI templates just seems like the best solution I’ve seen so far.
This is the best solution so far. However it does seem breakpoints could pretty quickly get overwhelming.
Perhaps a nicer alternative would be a seperate file for breakpoints. Then import it like you would a css file.
EDIT: This is unfortunately not possible due to requiring the extra HTML request… which would break img-prefetch (as Matt Wilcox pointed out to me on Twitter).
EDIT2: Thinking about it in more detail I have come to the conclusion that the only part of it I do not like is including the case in the image src url. It works in some situations but I think it would make more sense for when images are uploaded through a CMS or similar to have an attribute targeting the case.
Ie.
I expect it would be a lot more efficient since it does not have to search the url and also seems to make more sense from a developer point of view.
Can you elaborate on the last part please? I’m not understanding your objection to having a variable in the URI or quite how you’re meaning to address that in a different manner 🙂
WordPress stripped my code (under ie.)! Basically what I was saying is change:
src=’/content/images/{case}/photo.jpg’
to
src=”path/to/any/random/image.jpg” case=”breakpoint1″
You could possibly even have the case attribute as a list of breakpoints it should work for.
It is no where near as complicated as srcset but means you do not have to worry so much about the name or url of the image. I believe it would also be more efficient.
Doing this removes the advantage of minimal code and future flexibility that is part of the appeal of the proposed solution.
Doing it the way you suggest means needing to add a ton of code into each image element; that is no better than the existing picture proposal.
Matt,
The only explanation I can come up with is old browsers with javascript disabled.
Of course, then you can argue that you can use server-side rewriting, or symlinks, but that’s hackish to me.
Basically that there is a use-case where we’d have to keep another duplicate set of files.
The other thing is this removes the possibility of changing the alt text. I know that’s no better than now, but it is a boon and a burdon with picture.
The other disadvantage is it doesn’t then open up a way for new file formats to start coming through. Having picture with source would allow for things like a more responsive aware image format or other creative changes to happen, which could be very interesting.
Indeed, my argument is that this is *already* fallback valid – create a folder on the server with the same name as the variable and it’ll be treated as a normal URL, or simply alias the directory. Those would both work and I think that’s a perfectly valid thing while we wait for browsers to implement the new feature. Nothing is broken and nothing is arduous to do. You fix an entire site with one action on the server, and it’s not even something dynamic.
Changing Alt text should never happen, and is something Picture does not allow either. All resources are suuposed to be the same semantic meaning.
The file format is a false argument: picture can’t do this either, because picture does not offer file-format detection, so it can’t supply a fallback. I did argue that Picture should have a mechanism for doing so, but it was not an idea that caught on.
Ok. Well, that leaves my complaint about it to some sort of weird ‘code smell’ type issue.
I can’t pin down why I think there’s an issue with the variable solution.
Gut feeling, really.
Which is frustrating, because it’s very elegant (aside from the whole weird folder name on the server issue). I wish I knew why I wasn’t 100% happy with it.
In which my ego reminds the court I suggested this 3 hours before Denis LeBlanc:
http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/#comment-699
http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/#comment-709
Aside, there is a very specific reason my method is better. You can’t always control the file system. So many CMSs have patterns that are locked in. It doesn’t make sense to place the matched media reference inside the src=”” attribute. A separate attribute does this cleanly without requiring any specific server configuration.
See: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/#comment-732
True, this mandates a more verbose
picturesyntax, but it’s a more universal solution and that’s what we need I think.Using the same syntax in the <head> here is an example of both solutions.
<head>
<meta name='media' var='mobile' media='max-width:599px' />
<meta name='media' var='large' media='min-width:600px' />
<meta name='media' var='large_1.5x-res' media='min-width: 600px, min-device-pixel-ratio: 1.5' />
</head>
Picture element example:
<picture alt="">
<source src="mobile.jpg" />
<source src="large.jpg" media="large" />
<source src="large_1.5x-res.jpg" media="large_1.5x-res" />
<img src="mobile.jpg" />
</picture>
Meta media tag example:
<img src='{media}.jpg' alt='' />
Using the picture element solution you proposed requires 6 lines and does not allow for new media queries without adding to the picture element markup which, IMHO, would be a maintenance nightmare. In LeBlanc’s solutioin, there is only 1 line of code, and if we want to add new media queries, we only need to add them in one place, the head of the document, which seems to be a lot easier to maintain and more DRY. In either solution, you will need the 3 different images, mobile.jpg, large.jpg, and large_1.5x-res.jpg.
Just here to echo what Brett said.
The advantages are DRY, future flexibility, and not falling to the image-prefix problem. As soon as you use new properties in the manner you’re describing, you lose all those benefits.
After thinking about this some more today, my only issues with this idea are naming conventions. I’ll admit, I’m probably being anal about it, though I’d prefer using media for the variable name in place of case as well as var in place of data.
Here is an example of what I’m thinking of:
<head>
<meta name='media' var='small' media='min-width:320px' />
<meta name='media' var='medium' media='min-width:600px' />
<meta name='media' var='large' media='min-width:1000px' />
</head>
<body>
<img src='/content/images/{media}/photo.jpg' alt='' />
</body>
The media query is really what is being used in the meta tag, so it makes sense in my mind to name it a media meta tag. As far as declaring the variable, I think using var makes sense because it keeps it inline with what is going on with CSS variables
With the proposed CSS variable syntax, you would declare a css variable like so:
:root {
var-header-color: #06c;
}
h1 { background-color: var(header-color); }
I think it would be best to try and match the variable naming similar to the CSS variable naming syntax especially if the one of the goals is to have meta media variables accessible in a CSS file like so:
<head>
<meta name='media' var='small' media='min-width:320px' />
</head>
In your CSS file you might have:
@media var(small); {
/* Styles for min-width:320px go here */
}
Well the thing is you can use any variable name you like really. You set both the assignment and the reference, so it doesn’t matter – whatever you use will pull the appropriate value.
I’m not fussed about whether the value operator is called var or data or contents or whatever, as long as it makes sense they all do the same job 🙂
“Well the thing is you can use any variable name you like really. You set both the assignment and the reference, so it doesn’t matter – whatever you use will pull the appropriate value.”
As long as that’s the case, no pun intended, I’m ready to see this get some feedback from WHATWG and some browser people and get on the fast track to a native implmentation.
I’m definitely a fan of this approach and am feeling better about how it is evolving, but I’m not sure about the repetition of the
meta name. What about following the Dublin Core model:<meta name="var:breakpoint1" media="screen and (min-width:350px)"/>For what it’s worth, I do think moving to variable substitution does make sense and it seems like that piece would be immediately available (being in the head) and shouldn’t cause any performance issues in terms of rendering.
Out of curiosity, what do folks think of using the mustache templating syntax (double curly braces) instead of single ones? It seems like that may help with polyfill authoring as well (if we wanted to test it out).
I prefer the single curly brackets { } as this is more inline with the URI template syntax. Also, Philip Ingrey has created a polyfill using single curly brackets – http://pci.github.com/metavar_polyfill/
I am interested in the Dublin Core model you mention, can you elaborate on this concept?
I’d be in favour of a way of declaring media query “cases” in the head and using them anywhere a media attribute can go, like this example (assuming we have defined a case called “medium” in the head):
<link rel="stylesheet" media="case:medium" href="medium.css" />So that could be used:
– on style elements
– on link elements
– on picture elements
– on video elements
– on audio elements
There could also be a simple JS call for testing against a case dynamically, like:
if (window.matchMediaCase('medium')) {// do stuff}This would be a snap to polyfill.
I’m less sure about doing the sort of find-and-replace of the case name in the image path. Not sure why, will think about it some more.
I would prefer defining variables in a separate head-tag:
Because it is no meta-data we are defining there but a very own specification.
This is almost perfect, but there’s a major drawback – it’s not search engine friendly. Whilst UA’s may implement this, I don’t think search bots will, they’ll likely simply ignore these kinds of images. With images, that’s not such a huge deal, but it could be enough of a deal for some.
I know it’s adding code again but what about
<head>
<meta name='case' data='breakpoint1' media='min-width:350px'>
<meta name='case' data='breakpoint2' media='min-width:1000px'>
</head>
<body>
<img src='/images/standard/photo.jpg' tmpl='/images/{case}/photo.jpg' alt=''>
</body>
That’d suit me, but only if vendors also disable pre-fetch for such images. Which is one of the major sticking points.
Here is a little update to your markup. I used a data-* attribute in place of tmpl.
<head>
<meta name='case' data='breakpoint1' media='min-width:350px'>
<meta name='case' data='breakpoint2' media='min-width:1000px'>
</head>
<body>
<img src='/images/standard/photo.jpg' data-tmpl='/images/{case}/photo.jpg' alt=''>
</body>
To be most efficient, the standard photo in the img src should be a mobile photo.
I like this approach a lot, and I don’t think there is need to bring in complicated data-tmpl patterns. As already mentioned there would be no problem is using the variable is such a way that was compatible with whatever platform you are developing on.
Assuming {var_name} was "large"
Are both valid examples.
However, could it become an issue if all meta tags were parsed (performance or any other issue)? eg:-
Perhaps it would be best to stick to the current “standard” that a lot of other meta tags are using, but define an additional property to allow it to be referenced. Perhaps variable=”true” like this:-
{foo} _bar_ [[baz]]
I’ll try that one again…
I like this approach a lot, and I don’t think there is need to bring in complicated data-tmpl patterns. As already mentioned there would be no problem is using the variable is such a way that was compatible with whatever platform you are developing on.
Assuming {var_name} was "large"
<img src="/blah/{var_name}/picture.jpg"/>
<img src="/blah/picture_{var_name}.jpg"/>
Are both valid examples.
However, could it become an issue if all meta tags were parsed (performance or any other issue)? eg:-
<img src="/blah/{keywords}/picture.jpg"/>
Perhaps it would be best to stick to the current “standard” that a lot of other meta tags are using, but define an additional property to allow it to be referenced. Perhaps variable=”true” like this:-
<meta name="default-variable-pattern" contents="{VALUE}" />
<meta name="foo" contents="hello" variable="true" />
<meta name="bar" contents="there" variable="true" pattern="_VALUE_" />
<meta name="baz" contents="world" variable="true" pattern="[[VALUE]]" />
<p>{foo} _bar_ [[baz]]</p>
I think a variable attribute would greatly help browsers know which meta tags needs to be evaluated on re-size rather than re-parsing each meta tag.
Another option might be to re-purpose the old HTML param> tag. and use it in the head.
Both ways would allow the browser to know which tags it needs to evaluate/re-evaluate on page load/re-size.
Meta tag example:
tag example:
@Paul – I think a variable attribute would greatly help browsers know which meta tags needs to be evaluated on re-size rather than re-parsing each meta tag.
Another option might be to re-purpose the old HTML <param> tag. and use it in the head.
Both ways would allow the browser to know which tags it needs to evaluate/re-evaluate on page load/re-size.
Meta tag example:
<head>
<meta name="media" content="large" media="min-width:1000px" variable="true" >
</head>
tag example:
<head>
<param name="media" value="large" media="min-width:1000px" >
</head>
Credit aside, it’s nice to see the community coming together on this idea.
Quite personally, I’d much rather use this method over anything else proposed so far, even if that requires using a polyfill. (The thought of using media queries on ever single img tag makes me want to scream out the window)
Great work on pushing the idea Matt.
Hey Matt,
I really like this, it would be a very elegant solution. Great work.
I agree with others in that it’s the best solution proposed so far. I really hope it’s at least looked at by some browser vendors to gauge how feasible it is.
What is the general state of play right now, is the src set proposal going ahead? I really hope not, it’s bonkers to say the least.
I wrote a library called ‘metaquery’ that implements the strategy that Matt has outlined above.
https://github.com/benschwarz/metaquery
Probably worth checking out if you feel that a declarative interface is what you’ve been looking for all along.