What's the benefit of using emojis in CSS? - html

I've noticed a trend of using emojis for CSS classnames.
.πŸ––πŸΎ-Vg{color:#ff4040}
.πŸ––πŸΎVDe{padding:.75rem 0;font-size:1rem}
It makes certain things more difficult. e.g. writing Selenium tests over these pages.
Is there a real benefit to using them? Security? Filesize?
Or are developers just doing this for kicks?
Edit: For the "Close (Opinion Base)" voters. I genuinely want to know if there's a development reason for doing this. I'm not looking for people's opinions here.

Im going to tenatively answer this while trying to not to be too 'Opinion based'
The 'emoji' support is a feature of supporting all Unicode characters, this was to support Chinese charachter support, which makes perfect sense.
As Emojis have been mapped to the Unicode chars, they came out of the wash too.
I have trouble finding legitimate references to bytes saved with emojis in-lieu of another method. So if someone could correct me that would be helpful.
The closest I found was a gitLab document from 2018 which moreso speaks to the performace improvements they saw implementing the native Unicode emojis.
GitLab Emoji Unicode
Appart from anything else though, I have seen some companies throw them into CSS files to attract some 'UI' enthusiasts while browsing the source of a site, for hiring purposes.
Opinion Spoiler - If I saw this in a company content, the last thing I would be doing is applying to work with that.
Final Note
This really is not useful in any practical way, if you are working as part of a team, ask them yourself how they would feel about searching through a source base using an emoji/unicode instead of some readable class/reference.
πŸ₯‘
Reading Material
Browser Support SO Question
CanIUse Unicode
Unicode Release with Emoji Support

From what I have read from a forum, the reason people use emojis is because it can shave bytes off of files and it is easy to understand.
As far as I know this is not a security thing.

Related

Rules to pull reader-view like content from website?

I'm trying to implement my own little reader view app (an app that would do the same thing as reader-mode on safari), and there are a few things I find asking myself:
Is there a technical term for this feature (reader-view doesn't really cut it)?
Is there a standard that websites are supposed to follow in order to indicate the content they would like to have in their reader views
Is there an open-source set of HTML parsing rules to pull the "readable" content from a website?
Is the effort to implement such a thing simply too big for a single person in a few weeks and if so should I opt for services such as Instaparser?
I believe the original to be implemented by arc90, and they called it readability. You can check out their page here.
It's been ported to many different languages over time, so you could take a look at the different implementations to learn more about it, how it's done etc.
Python readability
JReadability
JavaScript
Ruby
This is just a small sample here, there's many more examples if you would like to find more.
Edit: Oops, after some more Googling I found this question with an answer that explains it very well.

AlivePdf Unicode character

It's possible using alivepdf to write a Unicode pdf?
I see a Unicode.as class, but when I try, the pdf created cannot be opened by adobe reader.
Could you please suggest me some code snippet to create a unicode string?
[EDIT]
I have made some investigations. I think the problem is on putcidfont0 method on UnicodePDF.as class.
The problem is that I think the font metrics are not parsed well and many characters are displayed with the default font width.
I cannot say how to fix this...
Try delcaring a new UnicodePDF() or setting the isUnicode bit to true (see documentation)
I dealt with this a month or two ago. My issue was that certain characters I would pass to AlivePDF would result in a broken PDF.
In my case I still had issues and my research turned up no promising results, although someone else had a strikingly similar issue that may be worth reading in your case.
The AlivePDF library hasn't been updated in a few years, and with my experience it seems like it doesn't play entirely well with unicode / other languages, although I have used it for English content without issue.
Since my target was desktop Flash and I was generating the PDF content from an external XML file, I eventually just wrote a helper utility app using C# and PDFSharp, which may or may not be an option in your case.
There was a big discussion here
Also I noticed that online PDF to Doc converters read UnicodePDF() files well.
Hope it helps.
It seems that some characters, as greek accented, some polish and many other characters are not available trough cid fonts, so the only way is to embed font in pdf.

Using <object> to Display PDF's As Opposed To One Of the Many SaaS Libraries

I have been developing a web application which has many documents (.pdf format) which must be embedded on the site. After doing a little research, there seem to be many "services" and/or "libraries" which allow the same functionality as the <object> tag combined with an Adobe Reader plugin.
Some examples include Crocodoc.com as well as PDFobject. Although, I will admit, a side by side comparison of these two SaaS, Crocodoc would take the lead.
It has been well known for awhile now that <embed> coding is outdated, and the best methodology for .PDF implementation is the <object> tag, in a previous discussion located here on SO.
However, one does not dispute that from a basic implementation approach of having standard-pdf bookmarks, links, and a 'table of contents', it appears that the browsers built in (downloaded, whatever...) Adobe Reader plugin provides the same functionality as one of the many plug-ins or extensible libraries provided on the web.
I would like to approach all the wonderful experts here on SO to provide an objective approach to the pro's and con's of using such methodology. Feel free to use subjective opinions, but please back them with facts and a well researched answer. Thank you.
Edit
After being approached on the topic that subjective answers are not suitable for StackOverflow, please keep in mind any subjective opions must be backed by a fully endowed, truthful basis behind any possible conclusion. Every programmer and web designer implements in their own ways because of experiences as well as pros&cons, so in order to provide the best suited answer.... "When In Rome"....

Why shouldn't professional web developers use Microsoft FrontPage?

I have a workmate with access to a very good IDE. He wants to use Microsoft FrontPage to write his jsps.
I know exactly what I want to say to him, but what would you say? I need a concise reason why a professional web app developer would never consider FrontPage.
It's an unnecessary abstraction for professional web developers, who need very tight control over the HTML and CSS generated.
It would be like rally car drivers using an automatic transmission. They need to know exactly what their car is going to do, and web developers need to know exactly how their code is going to act.
#1 reason:
FrontPage was discontinued in late 2006.
Personally, it bugs me seeing the extra bloat (unnecessary HTML structure, non-semantic use of HTML tags, embedding CSS directly in HTML) that Frontpage generates. I also dislike use of proprietary, non-standard HTML and CSS. Frontpage's code bloat is bad enough to have inspired such programs as Frontpage Code Cleaner. Here's another Stack Overflow question that deals with removing Frontpage bloat: FrontPage tags - Pain in da HTML.
You might also check out Why I do not use Frontpage by Greg Moreno.
Frontpage leads to bad habits for some of the same reasons Sarah Vessels lists. I used to use it myself. I was one of those who liked to design in design mode and refine in HTML. The problem was that switching between "design" and "html" views would cause FrontPage to change my precious HTML. And at some point I got fed up with it destroying my markup (something the newer tools are better about not doing).
When I began hand coding every site I worked on from scratch I learned so much more about HTML and CSS in general and how to make lightweight, efficient pages. And at that point I also realized that the markup FrontPage would generate was really old-fashioned with lots of tables and inline CSS. As I learned to do it right I also learned how to make my sites cross-browser compatible on the first try. In the end this allows me to design and build a better site, faster.
Professional web developers should really avoid Frontpage and use Microsoft Expression Web instead. It's the replacement for Frontpage and is fairly good, actually.
Frontpage itself has been discontinued. Using it simply as an HTML editor with syntax highlighting is a bit silly given how heavyweight it is.
That being said, if he's producing good code and delivering on time, it doesn't really matter what he uses.
It's intentionally dumbed-down
Great web developers build sites that:
Look good in all browsers
Degrade gracefully when Javascript or CSS or a plugin is not available
Have semantic HTML that makes sense to screen readers
Use AJAX, content compression, and caching to minimize bandwidth use
Have lovely, pixel-perfect graphics
If any GUI can do all that reliably, great. But I haven't seen it yet. And by the time you build one, the competition will be hand-coding capabilities that the GUI doesn't know about yet.
For one, FP isn't really supported anymore. The FP extensions honestly suck, they break quite often on the server side. But just as HTML editor, when the latest FP version is used and the settings are right (correct browser version and no server-side FP extensions), it's quite OK.
However (if staying on MS products), I'd rather use Visual Web Developer 2008 (o1 2010 when it gets out), it's free and has more recent technological support.
This is going off topic, but when FrontPage first came out, it was groundbreaking in how easy it was to create websites at a time when the web designer title was nowhere near fruition, but of course, FP has (de)volved into producing bloat.
The original company that created it was named Vermeer, after the Dutch painter and the story of how FP was built and how Vermeer got bought out by Microsoft is an interesting read, giving you insight into startups and Microsoft buyout tactics back then.
The same person who founded the company produced the movie, "No End in Sight", a documentary about the escalation into Iraq. Interesting segue, from software company to documentary movies.
Anyways, I think the name is Charles Ferguson. You can probably find a used version of the book on the cheap in Amazon. Definitely a worthwhile trip in the way back machine.
Because it's supposed to be catered to the crowd that isn't familiar at all with web development, mostly novices. To an experienced web developer it's fairly restrictive and limited, as is any WYSIWYG editor.
I haven't used it lately, but it used to rewrite a file with it's own garbage, even if you didn't save the file.
The same reason a professional artist doesn't use a coloring book. You're being paid to bring your skill and expertise into creating a product β€” using only FrontPage is essentially shirking that duty. I'm not saying it's never OK to touch it, but you need to take responsibility for the code you ultimately produce.
I personally haven't used Frontpage all that much, but I feel that you should really learn to use HTML and CSS and not rely on an application to do it for you. You really learn how things work and you have more control over what goes on.
It's Microsoft's
...the same company that brought you IE 6. I bet your site will work with IE 6, but will it work with Safari and Firefox and Opera equally well?
And if it doesn't, what are you going to do about it? You didn't want to dig into the code, remember?
Frontpage produces terrible code that won't be maintainable by other developers not using frontpage, meaning almost all web developers with common sense - especially since Frontpage got discontinued.
As mentioned - FrontPage became Expression Web. I hated FrontPage, but I think Expression Web is fantastic. I'm a programmer with deliverables, I don't have time to mess arround writing HTML code myself.
I suppose it depends what market your friend is in. If he wants to make shiny, glossed up websites with custom features & CSS - use a HTML/CSS syntax editor.
If he just wants to make quick, nice looking, clean corporate sites and have a high turn-over of generic sites, Expression Web is great. (The HTML isn't very 'pure' thought - but honestly what client would care?)

How do I create "accessible" PDFs from HTML?

Does anyone have any suggestions on how to generate accessible PDFs (including images) from HTML?
The PDFs need to look like the original HTML, including positions of images etc.
Any special HTML structure required to help make the final PDF accessible?
I've seen questions about creating PDFS none of them specifically address the important issue of accessibility.
My poison of choice is Perl but references to any program, language or library will help.
I have a more in-depth question at TypeDoc if anyone has more general information to offer.
http://doctype.com/TiB
Also,
I, and others, would find it useful if users with accessibility problems could comment if they find the "usability experience" of using PDFs better or worse than reading from Plain Old Semantic HTML (POSH).
Thanks
Mike
Look into PrinceXML. Through CSS you can control margins, page breaking and orientation. While not open source, you can try it for free, but it places a small water mark in the upper right corner.
The Adobe ColdFusion server product does a really fine job of this, not surprisingly. But it's not free, and the open source implementations of the language (Smith and BlueDragon) don't support the pdf stuff.
Developer licenses to Adobe ColdFusion are free, and you can download it.
I've done this thing on a small scale but scripting Safari to print to PDFs. I don't recommend it for large-scale projects though.
By far the most capable PDF publishing tool I've ever come across is reportlab. There is an open source library written with Python and a proprietary system that allows you to construct a document using RML, a custom xml spec. The latter is easier for more complex docs. They tend to be very flexible (and reasonable) with pricing.
Not strictly an answer to your question as it doesn't handle html-to-pdf conversions, but perhaps of use to you.