I am trying to extract background-url from a div using Nokogiri but am not able parse background-url of it.
While Searching on StackOverflow I found this link
Parsing: Can I pick up the URL of embedded CSS Background in Nokogiri?
but the solution given there doesn't work.
Nokogiri is not a web browser. It stands on top of libxml2 to provide fast and excellent parsing of XML and HTML, and manipulation and extraction of data from this.
It only deals with the HTML in a web page. It does not run any JavaScript. It does not apply CSS to the DOM. There is no way to use Nokogiri to find a CSS style applied to an element unless it is directly on the style="..." attribute on that element. (And even then you would need to use something else, like regex, to parse the CSS therein.)
You will want to use something else, like a headless browser controlled by Ruby, e.g. Watir or Selenium, if you want to process a web page and treat it like a web browser does.
Related
Why are .html file parsed rather than compiled when open them in browser such as Safari? From the internet, I learned that parser is a component of a compiler. People say .html is parsed to a web page, but why not compiled to a web page? .html file contains code that needed to be compiled so that it becomes a webpage, right?
Some possible reasons: Maybe when we say something is compiled, it has to be compiled into machine language but .html does not?
HTML does not get compiled - it simply describes how the website should be rendered.
And that is then interpreted by the browser - it doesn't end up as machine code.
It's like a map or blue prints telling the browser's rendering engine how to build the website.
The W3C defines how these "plans" should be written and the browser vendor should make sure they interpret the plans in the correct way.
Developers should make sure they use the HTML elements properly so that the HTML files make sense and the browser can construct the web page properly.
What difference does it make? You have not described a problem you are having.
The parsing of HTML is application-dependent. Each browser/parser decides how to do it.
HTML however must be dynamically modifiable. Since HTML is not executed, it is not clear what the difference is between compiling and interpreting but typically compiled code can't be easily modified.
JavaScript is by definition interpreted.
I have a large rails application that I am wanting to split out into smaller applications. The one piece of this application that will be universal to all smaller applications is the mast and footer. I would like to extract the html, javascript and css for the mast and footer into it's own package that each app can load and render.
The main issue I'm running into is that the apps will likely not all be written in rails. Some will be rails, some will be expressjs, some written in Go, and some may end up being written in other languages, so my solution needs to be language agnostic.
My thought is that I can extract the html, css and javascript into it's own git repo, use mustache templates for the html, and then use grunt or a similar build tool to build a gem, a package.json structure and a golang module. Possibly each in it's own git submodule.
I'm curious if there is a more standardized way of doing this. Or if anyone knows of a simpler way of achieving this goal.
Sounds like the technology in common is HTML/JS/CSS.
Wouldn't it be better to export the mast and footer as a self contained JS library, or more precisely, as widgets?
So whatever the application server tech stack would be, you could always generate the HTML in the form of:
<script src="your_widgets.js"></script>
<script>new Footer.render('id_of_dom_element_to_render_to');</script>
By doing so, whether you want the widget library to load the template or you want to embed the template into the widget library or whether you want to simply just construct it using HTMLFragment will not be limited by the server tech choice.
I have created a custom XBL component that includes very little markup. It primarily consists of CSS, JavaScript and a <div>. The JavaScript then writes the markup to the DOM, inside the <div>. Its CSS specifies styles for a lot of specific element IDs. This works just fine in Form Runner, but not with the Server Side Embedding API.
The Server Side Embedding API appears to be rewriting the CSS file. It prefixes all the CSS selectors for specific IDs with o0. For example #MultiMousePosition-cwm is changed to #o0MultiMousePosition-cwm. This might work fine if the markup of the elements were included in the XBL component. Then it could be rewritten. But since the markup is generated by JavaScript after the page is loaded, this doesn't happen.
Is the rewrite of CSS and element IDs done in case the API is used to include multiple forms in the same page?
Is there a way to prevent the CSS from being rewritten? Or is there some other way to deal with this problem?
I tried to use <xxbl:global> but it looks like that won't work for CSS resources.
The JavaScript is a complex library created by another developer and rewriting it to avoid this issue would take a significant amount of work, if it is possible.
The rewrite of ids is done to prevent id conflicts in the resulting HTML page. That can include supporting multiple forms, but also possible conflicts with other content on the page.
Currently there is no way to disable rewriting. It wouldn't be hard to add as a configuration property, possibly on the XBL components (though some things would need to be rewritten on some not, which might make the configuration more difficult), or globally, for users who know for sure they won't have id conflicts.
I am using jquery mobile and custom i18n functionality. When the user changes the language from the settings I want to remove the existing pages and put them again into the DOM (I am using Handlebars.js so the new pages will be shown in the new language).
What is the proper way to accomplish this? Simply removing the pages with .remove() and then appending them to the DOM is definitely not the way to go - the history gets broken, the pages don't get enhanced and I'm not even sure if it is possible to change the current page this way.
Is this even possible or should I consider refactoring my i18n so it doesn't require refreshing the whole DOM?
I am relatively new to Rails, having recently completed Hartl's Rails Tutorial, and am now embarking on my first full fledged project. What I am interested in adding to my web app is something similar to the text input feature in SO, where you could type, and see directly how your text will turn out. After some digging around on SO, I have decided on using the gem bluecloth, which is Markdown implemented in Ruby, but now have the following questions:
I am unsure about how to tie what bluecloth outputs to the form_for helper. My understanding was that you could convert to strings via the function html = BlueCloth.new(str).to_html(), but I am unsure what to do when you have a text field as part of form_for, where I should plug in the bluecloth part? In other words, I am still a bit confused about the magic of typing in one box and seeing the item show elsewhere on the page.
Are the WMD bar button items and functions included Markdown editors (such as bluecloth), or would this be something I have to build manually? If so, how would I get something like the bold button to show "** **" in the editor as you type?
Thanks for your help!
As comments have noted, Markdown is a markup language like HTML, so its not easy to do WYSIWYG.
There are probably two approaches to getting this kind of functionality.
Server side
Post your markdown text to a server and get the server to return HTML. I've done this a lot in Python, but for Ruby this SO answer suggests maruku. The disadvantage of this approach is that it requires a server request every time you want to view the preview, and then some way to integrate that back into your UI without disrupting the user. Stackoverflow uses this approach with the WMD editor and some C# on the server.
Client side
Another option is to use a client side library to take your markdown "code" and generate html which you can then integrate into your page using javascript. An example of this is dillinger. This uses a textarea and something like showdown to render the HTML in the browser. I'm taking this approach one step further in a WYSIWYG Markdown editor I'm developing called demarcate.js
Or... ditch Markdown
The comments have already suggested alternative WYSIWYG editors... most of these are not markdown editors but rich text editors which produce HTML at the end. TinyMCE and wysihtml5 are good options and I've also used CKeditor before with some success - it has a cool "in-place" feature in the latest version which inspired my Markdown editor above.