Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using plain Markdown syntax for (responsive) images #172

Closed
nhoizey opened this issue Aug 27, 2015 · 9 comments
Closed

Using plain Markdown syntax for (responsive) images #172

nhoizey opened this issue Aug 27, 2015 · 9 comments
Milestone

Comments

@nhoizey
Copy link
Contributor

nhoizey commented Aug 27, 2015

I have a silly dream to be able to use Jekyll Assets for images without needing a specific syntax in Markdown content.

Writers use tools that understand the default Markdown syntax for images (![alt text](/image/file.png)) and are able to build a live preview. I'm using Macdown for example. But these tools don't understand Jekyll Assets specific syntax, of course.

I would like to let writers use their tools and preview their articles with included images, but also deal with responsive images (see #157).

Default settings in my _config.yml would say that I want 3 versions of each image (say 320, 640 and 1024 pixels wide), and writing ![my hero image](/path/to/images/whatever.jpg) would make Jekyll Assets generate this:

<img
  src="whatever-320.jpg"
  srcset="whatever-320.jpg 320w, whatever-640.jpg 640w, whatever-1024.jpg 1024w"
  sizes="(min-width: 960px) 960px, 100vw"
  alt="my hero image" />

This is the "hero" example from #157 (comment)

I still have to imagine how writers would decide a specific image in the content has to use another set of dimensions, as for the "gallery" example in #157 (comment)

Please tell me if this dream is really silly, or if there's hope… ;-)

@larryhynes
Copy link
Contributor

It's not exactly what you're describing, but have you looked at jekyll picture tag?

@nhoizey
Copy link
Contributor Author

nhoizey commented Aug 27, 2015

@larryhynes I'm currently using it on http://nicolas-hoizey.com and indeed, it's not what I'm describing, exactly what I want to avoid in fact… ;-)

@envygeeks
Copy link
Owner

It's a dream and it's not a dream if that makes sense. For 2.0.0 it is a dream. For 2.1 it might not be but it also depends on the markdown processor people use, some of them allow us to insert ourselves into their parsers and do special things without needing our own parsing (like Redcarpet, it has that concept) but others don't (which requires work and would just anger people on JRuby.)

@envygeeks envygeeks added this to the v2.1.0 milestone Aug 27, 2015
@nhoizey
Copy link
Contributor Author

nhoizey commented Aug 27, 2015

I love this v2.1.0 milestone! ;-)

Kramdown is the default markdown processor in Jekyll 3, but I didn't find in the doc how it could deal with this…

@envygeeks
Copy link
Owner

Kramdown is the default for Jekyll3.0 only because we want to avoid compiling C gems so people can get started quickly and we can reduce the number of tickets asking us why their C compiles fail. However support all of them and there are thousands of legacy installs that still use Redcarpet probably.

@nhoizey
Copy link
Contributor Author

nhoizey commented Aug 27, 2015

ok

@nhoizey nhoizey changed the title Using plain Markdown syntax for images Using plain Markdown syntax for (responsive) images Aug 27, 2015
@envygeeks
Copy link
Owner

This is shifting to 2.2.0 because 2.0.* ended up being 2.1.0 because of a necessary API change.

@envygeeks envygeeks modified the milestones: v2.2.0, v2.1.0 Dec 8, 2015
@nhoizey
Copy link
Contributor Author

nhoizey commented Dec 10, 2015

Now waiting for the 2.2.0 then… ;-)

@envygeeks
Copy link
Owner

In theory, this will be possible with the 3.0 release, we now parse <img asset> into the Jekyll Assets system, and spit out the stuff (including proxies.) So once <img srcset> stuff is complete, this will be entirely possible, not in the way expected, but with <img asset='srcset srcset scrset'>

I'm closing this since the major piece is done, and another ticket tracks the other piece.

@envygeeks envygeeks modified the milestones: Someday, v3.0.0 Nov 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants