When I type the command eww and enter the url google.com it just loads the front page of Google nicely just the way it should be loaded.
But when i search for YouTube on this Google front page and hit search, a new buffer starts but nothing gets loaded on it. Just nothing.
Only the cursor remains still at the beginning of the buffer for the whole time.
I believe this is also your question?
https://old.reddit.com/r/emacs/comments/vc3zxs/the_eww_doesnt_display_my_html_file_like_it/
Both questions can be answered thus:
eww is not a fully-featured web browser. Not by a long shot. It handles much of the basic markup, which is entirely sufficient in certain cases; but it is absolutely not a full replacement for the likes of Firefox as far as the web in general is concerned.
Of particular note1:
Stylesheets are not supported (which seems relevant to the other question).
Javascript is not supported (which is relevant to this question).
That all said, there is experimental work for handling <video> elements in eww if you have built Emacs from the master branch with xwidget support. See https://lars.ingebrigtsen.no/2021/11/09/finally-videos-in-eww/ for more. This will (probably) be included in Emacs 29.
1 In an ideal world, most web sites would function acceptably in the absence of both these things. In reality, that's not even close to accurate. The web developers who care about users without javascript have been on the losing side of that battle for about 15 years, and it's only getting worse as time goes on.
On the positive side, I think the CSS situation is actually improving slightly on account of the Accessibility requirements which various governments have introduced in recent years, as these requirements always have "use correct semantic markup" at their core. That still doesn't help you when a lack of javascript results in a blank page, but it's something...
I'm trying to find a solution for high Max Potential First Input Delay on a website I'm auditing. I'm evaluating all the Long Tasks once FMP is triggered. While most are being marked as Recalculated Style, I'm not getting the exact code location of where that is, as shown in the attached screenshot.
Anyone has a recommendation of how to better evaluated the exact code causing the bottleneck
Chrome DevTools Performance Long Task Missing script line
Reply to wOxxOm:
OK so to understand you are referring to the Reveal feature as opposed to the to Bottom-up view.
I have a hand-me-down WordPress site (passed down from one dev to another, to another, and so on), which is more or less a garbled mess. I'm on the fence between wanting to optimize it and starting fresh. After checking the current state of CSS files with Chrome's Code Coverage, it seems that a lot of the rules (98%, according to the Code Coverage tool) are unused.
Other than testing different resolutions and checking if anything is changing, is there a better (more efficient) way for me to know whether the CSS rules are truly unused? I've been resizing the browser window, and reloading the page (just one out of many), but the number of unused bytes was always the same.
Short version: see topic
Detailed version:
I want to use a specific 3rd party theme for Windows. I'm already using an open source solution which I've compiled myself to disable Window's restriction on Themes.
In the past, when using 3rd party theme related mods that come with DLLs (for example authui.dll for the login ui, or imageres.dll for modding system icons), I avoid using unknown DLLs by simply copying the unknown DLL's theme related resources (such as Bitmaps, Icon groups or UI scripts) unto it's virgin MS Dll counterpart. I call this resource grafting, where resource are changed but the executable elements of DLLs or exes are left alone.
Going back to the theme I want to install, I used sha256 hashing to determine that only aero.msstyles which is also modifiable by resource hacker. So I did the same thing I usually do and transferred resources from the third party theme to Window's own aero.msstyles. Problem is that I ran into a type of resource that I am unable to read or know the contents of. It's called VARIANT. From some experiments done in a VM, it seems to be some kind of binary UI script that resource hacker is unable to decompile. I usually like to be able to read any UI scripts that I transfer but I am unable to do so with this one.
Would this constitute any real security risks? Can UI scripts be side-loaded with some kind of exploit? Seems unlikely to me since the function of a theme file (msstyle) is to coordinate the appearance of the system UI but I don't know enough about the inner working of the whole theming system to be sure. I thought I'd get some other point of views before I take the theme out of the Virtual Machine.
I used vBinDiff to compare the hex code the altered VARIANT/NORMAL binary to that of the original theme. You can also copy the binhexes and save them to two text files which you would compare with WinMerge.
vBinDiff and WinMerge will highlight what modifications and what additions/substractions were made to the binaries, displaying them side by side. I read through the differences, 90% of them were no larger than 4 octals (4bytes), typically what you would expect to see when modding colors using a hex editor. The biggest divergence was an added 32bytes of code.
There are two possible explanations for the such an addition: (1) the author added extra image resources and added the entries necessary to reference them, (2) there is some kind of unwanted code that has been slipped in.
To address the possibility of 2, I did a search to see how small trojan code can get. How likely is it that a trojan has been stuffed into 32bytes if compiled UI scripts? I found a few mentions of an old 17byte virus from the DOS era called trivial which I disegarded right away because it would become apparent very quickly given it's known behavior. As far as full fledged trojans with backdoor and downloading abilities, the smallest I found was 20kb (trojan tinba), discovered in 2012. There is also Catchy32 which is still considered a Trojan but with simpler and very specific functionalities and that one's about 580 bytes (reference). Based on this info, I established that it is highly unlikely (if not impossible) to slip any code in 32bytes of code and established that the resource in question is clean.
Mind you, this doesn't answer the question I asked (can binary UI script resources in a theme carry mal-code) but it does solve my dilemma. Thought I'd share it.
The challenge:
Provide dynamic web fonts that render acceptably across all major browsers, devices and Operating Systems
The story:
So I had used cufon or sifr in the past and had since abandoned both in favor of #font-face. After using #font-face in production for some time, I made a horrifying discovery. Many fonts (most?) look like crap in Windows XP, regardless of browser. Even in google chrome, XP renders the fonts unacceptably jagged and ugly.
I am aware of why this is happening. After reading many excellent posts on ye olde stack overflow, I understand the issue is NOT of font hinting, but of XP having clear-type set to off be default. So ALL fonts are jagged in XP by default regardless of application.
So... if #font-face works great everywhere BUT XP with clear-type off, and is still superior to cufon what should we be doing?
Possible solutions:
#font-face as default, Cufon with user agent sniffing for windows XP.
(currently using, and very much not loving it)
#font-face alone with yet unknown method of forcing clear-type
Cufon alone :(
Another paradigm all together
Failed solutions:
Adobe Typekit (jagged in XP on their own website!, even though they show a smooth specimen jpeg)
Google Webfonts (same problem with XP)
#font-face alone (same problem with XP)
Cufon so far works everywhere, but just sucks, and offers additional challenges if you are animating anything, or wish to update the text after the fact.
Do you have a solution that works completely cross browser and cross OS? What is the best way to handle this?
I'm pretty sure the web-fonts, which look ugly, are missing some hinting (edit: Nope, even though hinting is still required to make a font look good on windows, the real problem here was the disabled ClearType in XP. However, this answer has a solution anyway).
Unlike font renderers on other operating systems the windows engine relies on hinting information shipped with the font. If the hinting is missing, bad or broken the font will look ugly - simple as that. Luckly there's a way to add some automatically generated hinting to a ttf-font using ttfautohint. After adding the hinting you can generate the different web-font-formats (eof, woff, etc) you need from the enhanced TTF. Additionally you should try to use SVG fonts if font-smoothing is disabled, since they are always rendered with antialiasing.
I've written an article on how to create web-fonts on Pixels|Bytes, which explains how to add hinting to a font and how to use my Font Smoothie script to enable SVG fonts when necessary. Hope this helps :)
PS: I'm aware that linking to my own blog won't be appreciated here, but I think my post describes a good solution to the problem, so I posted it anyway. Please leave a comment if you want me to remove the link and I'll do so.
http://www.useragentman.com/blog/2009/11/29/how-to-detect-font-smoothing-using-javascript/
This is what I have found works so far. This solution detects jagged fonts, so then we can do something like this: #font-face as standard, and Cufon as fallback.
In my case, I found that the answer does not in fact center on enabling Clear Type in WinXP. Whether Clear Type is enabled or disabled, I find that some of my #font-face English fonts (especially BLACK, SANS-SERIF) look bad in IE7 and IE8. It's sometimes more than just being jagged or having bad anti-aliasing. The big problem I see is that the shape of the font itself (some fonts, not all) seems to squish into something quite unattractive. I found an acceptable solution by following the advice of Torben. Font Hinting was all I needed, and again, that solution has nothing to do with Clear Type being enabled. To get the font hinting app up and running, read the instructions here:
https://gist.github.com/davelab6/3783491
(I used the "ttfautohint-0.95.tar.gz" file here): http://sourceforge.net/projects/freetype/files/ttfautohint/0.95/
You should also review the documentation, and you need to also install MacPorts (or you will get an error in the Terminal during your build), but since my rep score prevents me from posting more than two URLs, you'll have to Google for that.
Better hinting doesn't mean your #font-face fonts will now look as perfectly smooth and great on IE in WinXP as they do on Macintosh browsers. But I found that the font hinting prevents nasty distortions in the shape of some fonts within IE7 and IE8. To me, that is an acceptable solution.
I can only add that it's rather troublesome to build the ttfautohintGUI on OSX. You have to installed hundreds of MB of software, downloading from multiple locations too, just to build the GUI app. But once done, the app allows you easily to hint your #Font-Face fonts and resolve many WinXP display issues. Just be sure to tick "Windows Compatibility" in the GUI (it's unticked by default). I also unticked the "Add ttfautohintinfo" and "Pre-hinting" options, leaving everything else as their defaults. Click "Browse..." to add your Input File (the font you want to hint), and then copy and paste that path in the Output File, changing the filename to whatever you want it to be. You won't enable the "Run" button unless there is something in both the Input File and Output File fields.
Best wishes.