Yes, the content creator should have the ability to decide how a page is generally divided, if they choose to do so. But the end user should not be restricted from linking to content fragments just because a developer couldn’t be bothered to add id attributes to every element on the page. And that’s besides the fact that it would be a waste of time for a developer to do that or to have to build a CMS that does it automatically.

The simple problem that I see with fragment identifiers is that their existence and functionality relies completely on the developer rather than the browser. Yes, the browser needs to read and interpret the identifier and identify the matching fragment. But if the developer doesn’t include any id attributes in the HTML of the page, then there will be no identifiable fragments. Do you see why this is a problem? Whether the developer has coded identifiers into the HTML has nothing to do with whether or not the page actually has fragments. Virtually every web page has fragments. In fact, sectioning content as defined in the HTML5 spec implies as much. Every element on the page that can contain content can theoretically be categorized as a “fragment”.

So why is it up to the developer (or content creator) to define whether or not a specific portion of the content can be linked to? When any page of content is created, there is no way of knowing which sections of the page are worthy of being identified.

The developer or content creator may have a general idea of how a page’s content might be divided up, but ultimately it will be the linking resource that should have full control over what portion of the page they want to highlight.

This means that, regardless of what the developer has done behind the scenes in the HTML, all HTML fragments on that page should be identifiable by external referrers.

Status: personal view

Editing status: Good enough fo discussion.

There is a fundamental weakness in the name attribute, which the id attribute addresses: the name attribute is not required to be unique. This is OK for forms where you can have multiple elements with the same name, but unsuitable for the rest of the document where you are trying to uniquely identify an element.

Extensions supporting this specification are available for Chrome

Making effective use of this mechanism requires either control of the targeted document or generous creators of targeted documents who have liberally applied id attributes throughout a document.

HTML fragment identifiers, as defined in the registration for the text/html media type [RFC2854] operate on id attributes and (now less frequently) the name attribute of the a, applet, frame, iframe, img and map elements.

[gripe]Email is supposed to be a text-only medium. I can concede a need for rich text - the occasional bold or italic - but background pictures are just needless bloat.[/gripe]

Negative margins are in many cases equivalent to position:relative; with negative position, e.g. position:relative; top:-100px, as in Guffa's answer.

I used to pull stunts like this all the time as soon as tables came. Really ugly, and may seriously embarrass any validator you run it trough: overlapping table cells. Works in most browsers though and even without css.

We haven’t covered this yet, but HEY has another consent-based feature they call the Speakeasy code. When used in the subject line of an email, this code grants the email access straight to the Imbox.

In the earlier example, I used “no-reply@” because this is, unfortunately, a common practice used by many email marketers. As a brand utilizing email, you should never expect a personal experience like email to ever be one-sided.

At its core, we’re all for this concept. For decades, we’ve preached consent and clear opt-ins as best practices for all email senders.

So The Screener really just acts as a second layer of consent—almost like a confirmed opt in.

The difference is that this happens in the email client, not at the subscription step. Why is this a big deal? Because, even though they just subscribed to your email, there’s a chance your email won’t get a thumbs up.

confirmation or refutation would be appreciated

Negative margins get removed by Gmail and others. So, no negative margins.

But in the dark world of HTML email, where the motto is "code like it's 1996" because Outlook uses the rendering engine from MS Word and Gmail removes almost everything, every method for making two elements overlap that I can think of is unsuitable due to poor client support

You can't use negative margin in html email. To mimic this, there are 2 ways to do it, the nested tables way and the more complex rowspan way:

gmail and other mail services are ignoring the negative margin.

You may have noticed your emails looking a little cramped in Hotmail and Outlook.com recently. The culprit? Discontinuation of support for the margin property in these email clients. Rather than honoring your carefully spaced paragraphs and images, Hotmail and Outlook.com are now completely stripping margin from paragraph tags, leaving default values (0 for the top, right and left; 1.35em for the bottom, to be exact) in their place.

Negative values are mostly unsupported in html email. So is CSS position. For webmail at least, this is so that your email doesn't render outside of the desired window. Imagine Gmail with your CSS or email affecting the interface - they've limited the CSS you can use specifically to prevent this.

Yeah, as many developers will tell you, designing/coding for email is an incredibly hit-or-miss proposition...this is simply one more thing that may work in some email clients. The only consistent behavior in HTML/CSS emails is that nothing is consistent. :-)

Rogues Adventure (Tiny Adventure?) is one of literally thousands of 2D retro pixel platformers infesting Steam. This one has you jumping around maze-like 2D puzzle levels collecting coins etc. The usual. They chose to use obsolete retro pixel "art" as a substitute for contemporary PC graphics. It's unclear if this is due to lack of budget or talent, regardless, the overall visual quality of the game is extremely low as a result. Resolution and controls are locked. These flaws push this game far below minimum acceptable standards for PC. This is such a routine platformer, the only remarkable thing about it is the developers didn't even know what name to call it when they launched on Steam.

My Sweet Ants! is a free mobile app that's been dumped from the iOS app store onto Steam. I got my key from DIG in their latest bundle. Why do I do this to myself? This mobile app is a game where you solve jigsaw puzzles of ants which have had anime girl eyes and mouths photo shopped onto them. Every day we stray further from god's light, I guess.Like all mobile apps, the quality is pretty low here. Resolution is fixed so the game falls below acceptable standards for PC.Once more we see greedy mobile devs trying to scam PC gamers. They want $2 USD for this free mobile app! Mobile devs must learn PC gamers are not here to be gouged, and can't be expected to pay a premium for a free mobile app just because it's been lazily dumped on Steam. This is unacceptable disrespect for PC gamers. I didn't spend thousands on a gaming PC so I could pretend it's an iPhone. I can't recommend anyone buys this when you can play it for free on mobile, not that anyone would want to.

You use the webcam of yours like a VR and you are able to operate the car with your own two hands and arms...it's great!

The game is buggy and unplayable, it crashes on launch most of the time. If you can get it to launch, it crashes as soon as you start moving. It's early access, sure, but despite being early access the developer is already selling it as a complete game in bundle stores like Daily Indie Game. Surely that's just an innocent mistake and not some dodgy attempt from a shady developer/publisher to sell an abandoned game as if it was complete.

A funny thing to note is how all the positive reviews for this game are from accounts with free/no products or VAC bans. Probably compromised accounts or something. Gotta love those fake reviews.

Check the reviews run ralph run Moo mei 2 Moo Mei 1 and this game, why do most of the positive reviews either have a VAC ban or 0 achievements in the game showing they haven't played it.

Anyway it's difficult to write too much about the game because it crashes on launch. Broken games don't get thumbs up. I have a dream that one day I'll play an indie game where they bothered testing it. Either way, don't buy broken games. Impossible to recommend.

Would you rather use a friendly drag-and-drop interface rather than coding? Try Passport, the email builder based on MJML!

MJML comes out of the box with a set of standard components to help you build easily your first templates without having to reinvent the wheel.

Components are the core of MJML. A component is an abstraction of a more complex email-responsive HTML layout. It exposes attributes, enabling you to interact with the final component visual aspect.

nside any section, there should be columns (even if you need only one column). Columns are what makes MJML responsive.

MJML has been designed with responsiveness in mind. The abstraction it offers guarantee you to always be up-to-date with the industry practices and responsive. Email clients update their specs and requirements regularly, but we geek about that stuff - we’ll stay on top of it so you can spend less time reading up on latest email client updates and more time designing beautiful email.

No, most css doesn't work in emails, stick to tables and images.

If you're trying to use flexbox as a responsive way to adapt your mails in different devices, well there's a framework for that called MJML hope it works for you.

HTML in emails is somehow in a forgotten world and is about lots of years behind us.

there's a framework for that called MJML hope it works for you

There is a lot of variation in styling support among different mail clients

For now though, you're stuck with <table> and CSS2 support for your layouts.

Write in Markdown

So even if it works for you, you won't know where it breaks.

Honestly, even without flexbox support, most of the layout problems would be solved with simple-basic CSS3 support that is standard in all clients.

With every other change I make, I have to test in a dozen clients and make sure it looks fine. Why is there so much variation in email style implementation amongst different clients?

I'm coding an email for a project and man! it's such a pain. Every other client has it's own implementation and supported rules. Some don't allow even simple properties like background-image while some support most advanced rules like media queries

Anyway... take a look at this framework is basically a responsive framework for emails. Haven't tested it yet but seems to be a very good one.

I haven't done much e-mail templating luckily, but like you said it's a PITA... It would be great if there was some kind of standard though, but that's not going to happen anytime soon

Why are there so many programming languages and frameworks? Everyone has their own opinion on how something should be done. Some of these systems, like AOL, Yahoo, etc... have been around for a decade, and probably not updated much.

Simple fact is that HTML support is different in them because mail clients are so old, or others are allowed to operate in browsers where not all CSS or even HTML can be applied in a secure manner. Older clients have outdated browsers that you'll likely NEVER see brought up to standards; what with Opera's standalone aging like milk, and thunderbird lagging behind the firefox on which it's even built. Don't even get me STARTED on older clients like Eudora or Outlook.

But more so, external style cannot be applied to a subsection of a web page unless they force it into an iframe, which has all sorts of issues of it's own which is why external CSS is usually ignored. Inline CSS is often stripped by the tag strippers who don't want you turning things on or off... and media queries shouldn't even play into it since the layout should be controlled by the page it's being shown inside (for webmail) or the client itself, NOT your mail.

Whilst I realize the artsy fartsy types get a raging chodo over their goofy PSD based layout asshattery

That's what's supported, and is all that is EVER likely to be supported... and even then be DAMNED sure you send multipart with a plaintext copy or a great many mail servers will flat out reject it on the assumption that no legitimate e-mail has any damned business even having HTML in it in the first place!

that garbage has ZERO damned business in an e-mail which is why a great many places use HTML only e-mail as a trigger for spam detection! (if you send multipart as both text/html and text/plain, you're fine)

That's something that has been bugging me too. I mean, it's fine if not everything is supported, but if everyone could agree on what is or should be supported then that would make a huge difference. But until then, it's going to be a struggle.

I've worked with people at companies where this was their only responsibility. Setting up emails for clients, making sure they pass a battery of tests and look great in all browsers and clients. It's an incredible PITA and it's not a set it and forget it thing. Clients can change month to month; spam filters change, etc...

Email is Hard: learn how MJML will help you.

Write less code, save time and code more efficiently with MJML’s semantic syntax.

Also cross-compatibility with mail clients can be hairy, so you should see what the industry experts are doing.

I hate to be the guy who will destroy your day but... Tables. You need to work with nested tables/cells. If you think Gmail is annoying you will cry in agony if you also need Outlook support.Work with the good old HTML from the early 2000's. That's the only way to be sure everything will work as intended.Anything else will mostly result in a horrible mess, broken design and incompatible layouts.

(And please, no "use a different email design service" answers, I don't have control over that)

iOS 9 and 10 support @supports. Make sure your ESP is not stripping it, or feel free to share your code so we can help you.

As a conclusion, I’d say that Flexbox in an email unfortunately causes more troubles than it helps solving.

This post was originally published on my blog in french and on the Litmus forums in June 2015. It was updated with information about support in the new Outlook Web App in January 2016.

We’re a small team of four people, and we intend to keep it that way. We can focus on doing what we want to do: web and email development.

We’re the ones who code. The people you talk to are the people who work on your project. When you have a question, we know what we are talking about.

also for our closed ones.

Here’s a really neat editor for those from Mads Stoumann (which works for circles and ellipses as well):

/* referencing path from an inline SVG */ clip-path: url(#c1);

While support certainly isn’t universal, many of the leading email clients support HTML5 and CSS3. In fact, about 50% of the total market and 3 out of the top 5 email clients support them. Support may be even bigger for your particular audience.

“You can’t use HTML5 or CSS3 in email.” Due to their “limited” support, the idea that using HTML5 and CSS3 in email is “impossible” remains a commonly-held notion throughout the email design industry. However, we’re calling it a complete myth.

Approaching email development this way transitions more of the quality assurance (QA) process to the browser instead of the email client. It gives email designers more power, control, and confidence in developing an email that will render gracefully across all email clients.

This approach also splits email development for modern email clients and older clients in two. You can use Safari/Chrome to test and develop modern techniques for WebKit-supported clients while using Firefox for your baseline experience for older clients like Outlook.

Testing your designs is also crucial step during this process.

Do it for your subscribers. For our craft. For the love of email.

Perhaps the most impressive part of the entire email is the fallback it used for non-WebKit emails —a beautiful grid layout of the carousel that didn’t hide or duplicate any content!

Remember, even the email clients with better HTML and CSS support have their own individual quirks and still require testing to see what’s possible.

Build a baseline email experience for subscribers using email apps with limited support for HTML and CSS—such as Outlook and Gmail—before enhancing your email for other clients. Progressive enhancement should not create suboptimal experiences for other users.

This media query only targets WebKit-supported email clients—which have incredible support for HTML5 and CSS3. This media query allows you to use of modern techniques like HTML5 video, CSS3 animation, web fonts, and more.

An escalator is a great example of progressive enhancement and graceful degradation in real life. The late comedian Mitch Hedberg joked, “An escalator can never break: it can only become stairs. You should never see an Escalator Temporarily Out Of Order sign, just Escalator Temporarily Stairs. Sorry for the convenience.” Regardless of its environment, an escalator maintains its functionality.

The main focus of his talk was on progressive enhancement, which involves providing advanced functionality in environments where its supported. He also emphasized the importance of graceful degradation. Graceful degradation means that if your subscriber’s email client doesn’t support a certain functionality, you’ll still provide them with a pleasant experience.

However, this doesn’t mean that your email has to look the same across every client—it just needs to be easily accessible for all of your subscribers.

Only a small number of known sites can be annotated.

More importantly, using a plain email would save lots of time and effort. As a goal-driven-lazy person, that’s a good enough reason to start experimenting.

They don't look like advertisements. The second the recipient interprets your email as an ad, promotion, or sales pitch—and it does take just a second—its chances of being read or acted upon plummet towards zero. A plain email leads people to start reading it before jumping to conclusions.

They feel more personal. It's no handwritten note, but it's much more personal than an over-designed email with the recipient's first name crammed somewhere inside.

The plain, unstyled emails resulted in more opens, clicks, replies, and conversions, every time.

They're less likely to go into the "Promotions" tab in Gmail (used by ~16% of all email users), for the same reasons above. From my testing, the plain emails typically end up in the Updates tab and some times even in the primary tab. Of course, the text in the email also affects this.

You can use a free spam checker to validate this by testing plain and designed emails.

The plain email—which took no time to design or code—was opened by more recipients and had 3.3x more clicks than the designed email.

If you ever had to go through the hair-pulling process of designing emails, then you understand. If you haven’t, here’s why it’s such pain:

Email tools/clients are inconsistent in how they render HTML and CSS. A designed email might look great in Gmail, broken in Outlook, and unreadable in Apple Mail. Half of all emails are opened on mobile devices (according to one study). Email looks good in different clients? Great, now make it work on a 4" screen just as well as on a desktop.

Email require their own flavor of HTML and CSS. Want to have rows or columns in your layout? You'll have to use <table> tags—a method long buried by web developers. There's also no support for external stylesheets, element position styling, and so on...

You'll have to use <table> tags—a method long buried by web developers

I used to dread setting up email automation and email campaigns.

A common practice in email marketing is to use images for everything in the email: graphics, illustrations, copy, links, and buttons. Although this can be efficient (slice, dice, and send it on its way), it’s another huge problem for subscribers relying on screen readers. The typical image-based email has a lot of information that can’t be parsed by a machine. What’s more is that a lot of email clients disable images by default, too.

However, since we’re using tables purely for structural purposes, we need screen readers to ignore those tables. This is where ARIA roles can help us out. By applying the role="presentation" attribute to a table, we can instruct the screen reader to skip over those elements and move straight into the content.

Although a lot of email development is stuck in the past, that doesn’t mean we can’t modernize our campaigns right along with our websites. Many of these tips can be baked right into your email boilerplate or code snippets, allowing you to create more accessible HTML emails without too much thought.

I hate making newsletters, but absolutely love reading them.

Please have a look at (in same order)

Some people disagree. “Studies” about html emails are often sponsored by mailchimp

I hate making newsletters, but absolutely love reading them. Because of this, and on a semi-related note (apologies if this is off-topic/not allowed), I am in the process of creating a newsletter directory, allowing users to browse and find newsletters to sign up for.

A beta can be found here: https://lettrs.email/

Despite what some email marketers and developers will tell you, semantics in email do matter. Not only do they provide accessible hooks for navigating an email, they can provide fallback styles that help maintain the hierarchy of emails in the unfortunate event CSS isn’t loaded or supported.

The element that we are going to apply the shape to with the shape-outside property to has to be floated. It also has to have a defined width and height. That's really important to know!

Apple Mail remains the most popular email service. Roughly 40% of people use it to read their emails. That’s followed by Gmail at around 20%.

And what’s more, a growing number of email readers are even voluntarily turning off images in their emails to reduce load time and improve email speed. Google recently revealed that 43% of Gmail users actually don’t read emails with background images on.

Embedded CSS: This style is becoming more popular with the rise of mobile and responsive emails. Embedded CSS codes are determined in one place of an email, generally in the <head> section as a <style>. Some email servers still strip the information out of this section, which can cause display problems.

Just because there can be issues with CSS in HTML emails doesn’t mean you should abandon efforts to use it. It all comes down to determining which codes are absolutely needed and how to style them so they can be rendered by email platforms.

Disclaimer If this tool works, great! However, no guarantees are made that it won't hasten the heat death of the universe through the spontaneous combustion of your CPU.

You might even consider a Raspberry Pi to power a lightweight media center or server. These ARM-based systems aren’t as powerful, but they’re inexpensive, customizable, and use a very small amount of power.

I would try designing your mail-template as "normal" as possible. Tables help a lot for example (yuck).

Using margin is better ! If you use position:relative position:absolute You need understand correlative with div outside

there are bugs aplenty with ie's, the way to address them is by complimenting your otherwise sound html/css with fail safe code, rather than degenerating your sound html into hacky html for ie's sake.

While it’s not quite completely table-free, I’ve managed to get The Intermittent Newsletter down to a single table—one that’s not even visible to non-Microsoft email clients. Along the way, I made an effort to make The Intermittent Newsletter accessible to more readers.

And that just leaves the Word Outlooks (and their ever-aligning web based equivalents), and a few lesser used (for us) regional clients. Here, our div based layout reverts back to every story being on a new line. For #EmailWeekly, we’re ok with that.

We’re big proponents of the idea that Email doesn’t have to look the same everywhere — if it looks different, but not broken, that’s fine.

From now just use url instead of asset-url

10th Gen Intel Dual-Core i3-1005G1 (Beats i5-7200U)

i5-1035G1 (Beat i7-8550U)

Why, you ask? Simple, because they can’t stop distributing the program, users have come to rely upon it to read their email and edit their documents! Read the debian-user mailing list sometime and see how many times users of other distributions scream “Ahh! where’s Pine and Pico, my life will end without them!” The users are not at fault, their old “Open Source” operating system included Pine and Pico, so why shouldn’t Debian? The programs are “Open Source” after all, aren’t they?The thing is, they aren’t. The Pine license is not a Free Software license, nor does it meet the Open Source Definition. Why is it included in the distribution, then?

Large regions of memory can be allocated without the need to be contiguous in physical memory – the IOMMU maps contiguous virtual addresses to the underlying fragmented physical addresses. Thus, the use of vectored I/O (scatter-gather lists) can sometimes be avoided.

Premailer will be shutting down

Use this tool to do to convert internal and external style into inline for you: http://inlinestyler.torchboxapps.com/styler/

Rather than be dealt a hand, the cards are placed on the table between the players and the cards for the next turn are drafted into their hands instead.  There will be few surprises since the players will know what cards are in play for the turn.  When picking cards, players will have to decide whether to take an advantageous card or select a card to deny an opponent a specific event.

First is that the two players are not the typical Cold War sides, Americans vs. Soviets.  They are not the focal point of the game.  Instead, 1979: Iran in Revolution pushes them to the periphery.  Instead, the two players represent Iranian royalists and reformers.

There are two aspects of 1979: Revolution in Iran which make it different than many other CDG about events of the Cold War era:

NEGATIVESThe interface between the game and the Steam Client denies you the ability to take screenshots. I also could not capture play footage.

A bit of a tour through the Ruby source code seems necessary as the documentation is a bit thin.

That should make for interesting puzzles, except they're timed, your guys never stop moving (why not?), and the camera and controls mean it's very hard to translate intent into the game world.

DISCLOSURE: I feel it's fair to let everyone know that Rolling Seas has been signed by a publisher and should see a full retail version available in 2-3 years. I had already planned this Crowd Sale before signing with the publisher and have their approval to run this sale. This Crowd Sale will be one of the last opportunities to get Rolling Seas before full publication (it will be taken down from The Game Crafter within a few months).

0.1 hrs on record Early Access Review Posted: February 18 This game is amazing. I don't even speak russia but I got the full in depth story. I have sunk countless hours into all of the nuances in this game. Thank you, sincerley, thank yiou Narod for chaning my life.

:structured - Lumberjack::Formatter::StructuredFormatter - crawls the object and applies the formatter recursively to Enumerable objects found in it (arrays, hashes, etc.).

The main difference is in the flow of how messages are ultimately sent to devices for output. The standard library Logger logic converts the log entries to strings and then sends the string to the device to be written to a stream. Lumberjack, on the other hand, sends structured data in the form of a Lumberjack::LogEntry to the device and lets the device worry about how to format it. The reason for this flip is to better support structured data logging. Devices (even ones that write to streams) can format the entire payload including non-string objects and tags however they need to.

Lumberjack::Logger does not extend from the Logger class in the standard library, but it does implement a compantible API.

The logging methods (debug, 'info', 'warn', 'error', 'fatal') are overloaded with an additional argument for setting tags on the log entry.

There is a similar feature in the standard library Logger class, but the implementation here is safe to use with multiple processes writing to the same log file.

logger.tag_formatter.default(Lumberjack::Formatter.new.clear.add(Object, :inspect)) logger.tag_formatter.default(Lumberjack::Formatter::InspectFormatter.new) logger.tag_formatter.default { |value| value.inspect }

These example are for Rails applications, but there is no dependency on Rails for using this gem. Most of the examples are applicable to any Ruby application.

There are several built in classes you can add as formatters. You can use a symbol to reference built in formatters. logger.formatter.add(Hash, :pretty_print) # use the Formatter::PrettyPrintFormatter for all Hashes logger.formatter.add(Hash, Lumberjack::Formatter::PrettyPrintFormatter.new) # alternative using a formatter instance

# This will register formatters only on specific tag names logger.tag_formatter.add(:thread) { |thread| "Thread(#{thread.name})" } logger.tag_formatter.add(:current_user, Lumberjack::Formatter::IdFormatter.new)

Lumberjack 1.0 had a concept of a unit of work id that could be used to tie log messages together. This has been replaced by tags. There is still an implementation of Lumberjack.unit_of_work, but it is just a wrapper on the tag implementation.

You don’t see a lot of them, but there are a number of “super trucks,” that people build custom. They’re essentially RVs built onto a stretched truck and used like a truck. These trucks, depending on how built, often have the same facilities RVs have, including private showers, toilets, and other plumbing essentials. They dump and refill at rest areas and rv parks that have these facilities, and live the best of both worlds - trucking without the hassle.

There's nothing to stop you from doing initializer code in a file that lives in app/models. for example class MyClass def self.run_me_when_the_class_is_loaded end end MyClass.run_me_when_the_class_is_loaded MyClass.run_me... will run when the class is loaded .... which is what we want, right? Not sure if its the Rails way.... but its extremely straightforward, and does not depend on the shifting winds of Rails.

The story is rich with the oppressive mood and ironic humour that Orwell and Kafka are famous for, and the style draws from Expressionism and Absurdism as well as cyberpunk dystopias.

First, no joypad support. It's not a big deal because you can still use big picture emulation or joy2key

The game is not too bad.. sweet graphics yet minimalistic.. but why the heck 1,5k achievements? I can barely concentrate on the levels because all the freaking achievements pop up all the time. One per level would have done the job just fine.. i love achievements.. but getting 1,5k for nothing is hideous.

The core idea of the game is fine, but the implementation is poor.

All in all, get this game when it's not on sale so you can pay full price for this gem!!!

Actually a very interesting concept allthough not perfectly executed (even considering it's based on a board game)

The saddest part is that almost every one of these problems could be fixed with a decent patch. Don't expect one from this developer though(look at their website, this game came out in 2010 with no updates.)

It's a nice idea but godawful implementation.

Unfortunately, it’s in the execution where “US and THEM” starts to fall apart. The game’s major problems stem from the user interface and some design choices range from questionable to downright horrible. For starters, the world map that takes up more than half of the screen can be neither scrolled nor zoomed. In a game where your interaction heavily relies on clicking various nations, this becomes a problem. While larger countries like Canada, the US and Russia are easily accessible, smaller nations require pixel perfect accuracy to interact with. Try clicking on Cuba, Ireland or Hungary and you’ll find yourself maniacally clicking shades and outlines and a handful of visible pixels in the area of these countries in vain hope that the game will acknowledge your actions.

The Gamemaker lite watermark in the screenshots says all. The 'game' is like someone's first attempt ever at making a game. It should never be sold on a respectable site but steam stopped being one of those years ago. It has many problems like easily getting stuck on walls so it just isn't enjoyable to play.

They are much easier to put together because they are photographs so the secondary title "Challenging Journey" is a misnomer.

The responsiveness of the controls is terrible. It's nowhere near consistent, and the delay/lag between button presses and action on the screen is frustrating. It is nearly impossible to consistently jump while in motion, and if you can't do that in a platformer, you're better off not playing at all.

I'm of the opinion that there shouldn't be a platformer in today's market that doesn't include native controller support

The second thing I noticed was that of the very few who have posted on the page, I'm not the only one with this issue, yet no real help or even acknowledgement of the problem exists from the developer.

wrote this review initially to accommodate a requirement for the Summer Sale 2019 event

You can use asset helpers if the erb is only for referencing assets:

I don't believe the sprockets and sprockets-rails maintainers (actually it's up to the Rails maintainers, see rails/rails#28430) currently consider it broken. (I am not a committer/maintainer on any of those projects). So there is no point in "waiting for someone else to fix" it; that is not going to happen (unless you can change their minds). You just need to figure out the right way to use sprockets 4 with rails as it is.

This is definitely not the place to report bugs related to sass, rails, or sprockets. Each project has it's own issue tracker (not on SO)