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)

list-style

list-style: "✓ " outside none;

Games that aren't really like rogue, but tagged roguelike. Lite on rogue elements, they should be tagged as roguelite or genre_roguelike instead. For more info, check out: http://en.wikipedia.org/wiki/Roguelike

Absolutely atrocious controls, with keybinds hardcoded so that only american keyboard users can use one of the most important controls in the entire game. The Z key is in the middle of the keyboard for a huge portion of the world, developers.

Actually, I've decided to stop using labels for a while. A "bug" label gives the impression that someone else is going to fix the problem. We don't have enough volunteers for that (new contributors welcome!). I try to help people working on issues, though. I've spent many hours on this one.

can you remove the not a bug label considering that PaperTrail is creating this empty versions even when :updated_at is an ignored attribute?

It looks like touching objects "manually" versus "in cascade through belongs_to association" does not result in the same behavior.

passthrough

Game Saves After completion of each level

Been seeing this comment copy/pasted everywhere it's pathetic what people will do for thumbs up/awards on reviews, be original and make your own review. If you guys need proof go and look at NVL reviews, I saw it on another game a few weeks ago too.

This game gives me anger issues when i can't complete a level. And doing that over and over again is not good for your health. If you like having anger issues get the game.

It's the king of game that made you wonder how it got approved. $5 for this could almost be called "stealing". I bought it for $1, and it feel way too much for this.

Like a lot of reviews I write, I hope to come back to add on to this and embellish.

Right now it's a matter of getting brass tacks up front and hopefully helping Feel-A-Maze get noticed.

I admit I'm biased, having bought this game for fifty cents at the time I did. I also have a general love of mouse movement-based games, and find other options in the way of gaming, Steam and otherwise, underwhelming in supply.

It's free to play on iOS

We can imagine "CORONA NERVT!" in all languages ​​and countries. Since the card text is targeting topics from Germany and that gives our Game its charm, we didn't want to make a multilingual version. All players should find themselves in the game. So if you want to publish a version for another country, get in touch with us.

$ ./my_script Will end up in STDOUT(terminal) and /var/log/messages $ tail -n1 /var/log/messages Sep 23 15:54:03 wks056 my_script_tag[11644]: Will end up in STDOUT(terminal) and /var/log/messages

That's true although it depends on intentions. My approach is to always create a unique and timestamped log file. The other is to append. Both ways are 'logrotateable'. I prefer separate files which require less parsing but as I said, whatever makes your boat floating :)

exec &> >(tee -a "$log_file")

exec &> >(tee -a "$log_file") echo "This will be logged to the file and to the screen" $log_file will contain the output of the script and any subprocesses, and the output will also be printed to the screen.

>(...) starts the process ... and returns a file representing its standard input. exec &> ... redirects both standard output and standard error into ... for the remainder of the script (use just exec > ... for stdout only). tee -a appends its standard input to the file, and also prints it to the screen.

May be the answer looks the same, but it was not the same question.

Write stderr and stdout to a file, display stderr on screen (on stdout) exec 2> >(tee -a -i "$HOME/somefile.log") exec >> "$HOME/somefile.log" Useful for crons, so you can receive errors (and only errors) by mail

But this answer does do exactly what is needed by some people who googled for this. And for that, we thank you.

I just wanted to point out that the syntax is not supported by the POSIX standard and thus won't universally work in /bin/sh scripts (many people erroneously use bash syntax in /bin/sh scripts)

exec > >(tee "$HOME/somefile.log") 2>&1

Why your original solution does not work: exec 2>&1 will redirect the standard error output to the standard output of your shell, which, if you run your script from the console, will be your console. the pipe redirection on commands will only redirect the standart output of the command.

stunning HD retro-style graphics

Once more we see greedy mobile devs trying to scam PC gamers. On Steam, this is an insane $15 USD, on app stores, it's free. 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.

This gem uses a Rack middleware to clear the store object after every request, but that doesn't translate well to background processing with Sidekiq. A companion library, request_store-sidekiq creates a Sidekiq middleware that will ensure the store is cleared after each job is processed, for security and consistency with how this is done in Rack.

Please do not directly email any Sidekiq committers with questions or problems. A community is best served when discussions are held in public.

I also sell Sidekiq Pro and Sidekiq Enterprise, extensions to Sidekiq which provide more features, a commercial-friendly license and allow you to support high quality open source development all at the same time.

but after four or so years, it just feels like it ought to be better.

Eine wunderschön in Szene gesetzte Geschichte mit abwechslungsreichen Puzzle-Elementen in einer liebevoll gestalteten und mit grandioser musikalischer Untermalung verfeinerten Spielwelt. Leider nur in Englischer Sprache (deutsche Untertitel), diese aber in sehr guter Qualität. Ein Bisschen kurz vielleicht, aber in seiner Umsetzung so rund und geschliffen, dass die Spieldauer meines Erachtens nur ein geringes Manko darstellt. Wer Spiele im Graphic-Novel-Stil mit individueller Graphik und herzerwärmenden Geschichten mag, darf Figment nicht verpassen.Definitive Empfehlung! (ggf. im Sale)

What will you do if your country would be under attack by bandits? You will surely transform into a super robot , isn't it?

Sorry that the site is slow/unstable right now! I'm working on fixing it! -Michael

Don’t replace words with emojis One thing you definitely don’t want to do is have your emojis get in the way of people being able to comprehend your subject lines. Emojis should be a complement to the words in your subject lines – they should never replace words themselves. It’s when people leave out words, right?

The use of U+212B 'Angstrom sign', which was encoded due to round-trip mapping compatibility with an East-Asian character encoding, is discouraged, and the preferred representation is U+00C5 'capital letter A with ring above', which has the same glyph.

It should be defined inline. If you are using the img tag, that image should have semantic value to the content, which is why the alt attribute is required for validation. If the image is to be part of the layout or template, you should use a tag other than the img tag and assign the image as a CSS background to the element. In this case, the image has no semantic meaning and therefore doesn't require the alt attribute. I'm fairly certain that most screen readers would not even know that a CSS image exists.

They cause completely different behavior for auto margins. If you have a fixed element for example with top/bottom/left/right set to zero and you stick an image in it you want to center wrapped in a div, then in order to center that div with auto margins, you MUST specify a CSS width/height, because specifying an HTML attribute width/height has no effect and the margins remain zero. I have no idea why the difference exists.

Whether to specify in html or css is best judged on individual circumstances. A large number of images of the same size would probably be best served with css, a single image with html. That said, if you are specifying other styles for the image (border colour, style or radius, float etc) it would make sense to add width & height to the css.

From a practical point of view it's highly desirable to specify them to prevent page reflows as mentioned above. However those suggesting it should be in the html because of this are missing the fact browsers use css when building the page initially. If they didn't the page would have to be redrawn for floated elements, specified padding, margins etc.

Obviously there are practical reasons for using px for images. However keeping images in px would seem to negate the argument for not using them.

I think that depends on HOW you are using the attribute. If you're styling multiple images within a list or table so that they lay out correctly, then put the width/height in your CSS to avoid the need to add another set of tags to every image in the list. Use something like ul.gallery img: { width:117px; } On the other hand, if you are inserting an image into some content and it needs to be a certain size to make the document flow properly, then put it in the HTML. That way you don't have to muck up the style sheet for each different image in the html. And this way, if you change the content to a different image, of remove the image all together, you don't have remnants of code scattered in your CSS to remember to delete.

Neither question nor answer appears to understand the notion of semantic HTML. Height and width are presentational attributes regardless of where you put them. For semantics we establish what the image means to content in the alt tag. I don't remember why it was so important to width/height in the HTML but I suspect it was in case you hit browsers without CSS rendering. It's not a semantics issue. If anything it thwarts separation of concerns to a degree.

If anything it thwarts separation of concerns to a degree.

It's not a semantics issue.

Ah yes, excactly the right answer. Img tags are for information, css backgrounds are for layout.

CSS seems like the right place to put visual information. On the other hand, few would argue that image "src" should not be specified as an attribute and the height/width seem as tied to the binary image data as the "src" is.

What's the "correct" semantic way to specify image height and width? In CSS... width:15px; or inline... <img width="15" ?

(Yes, I realize from a technical, end-user perspective this really doesn't matter.)

the double bind faced by every politician: responding to scurrilous charges only gives them unwarranted publicity; not responding to such charges is often interpreted as an admission of guilt

You should always specify the height and the width of an image if only to help the browser lay the page out even before the image has been downloaded.

use the width (and the height) attribute....to identify the intrinsic height of the image file, not to specify the desired layout size

According to Google (not that they are the end all of browser knowledge)