Cocoa WebKit - detecting CSS rollover/hover - css

I have a WebView displaying a HTML page, linking to a CSS file.
The CSS file makes use of the pseudoclasses :active and :hover for rollover effects.
Q. How can I tell, in my WebView, when :active and :hover have been called? I would like to intercept these calls and act on them programmatically within Cocoa.
Thanks.

:active and :hover aren't calls; they're CSS pseudo-classes, for use in CSS selectors. You use them in CSS to select elements to style. They're adjectives, not verbs.
Try adding JavaScript event handlers to the elements instead. You can use a WebScriptObject to project some of your Cocoa methods into the JavaScript space for use from the event handlers.

I'm looking in the 2.2 SDK docs, and I don't see anything in the UIWebViewDelegate protocol. The best hope of accomplishing this maybe the instance method in UIWebView called stringByEvaluatingJavaScriptFromString. Unfortunately that would probably imply some kind of polling, as there seems to be no way to define an Objective-C method that JavaScript could call back on for such an event. I might be wrong, but I don't think it can be done (in 2.2).

Related

Best practice for React. Hover or mouseEnter/mouseLeave?

I'm learning React with styled components and I have a button with a simple hover-effect.
This hover-effect can be created in the styled components file with &:hover, and in my jsx file, I can use onMouseEnter. Both will work.
I have searched google to find what is considered as best practice, but no luck, so I try here. Anyone?
It's very simple choice.
If you need change styles then use ":hover". You can pass props to styled component for change styles in depend of some condition.
If you need realize some logic on hover then use event handler for onMouseLeave, onMouseEnter, onClick and other events.
Use event handler for realize some logic. As example when you have some element and you handle "onMouseLeave", in mouseleave event handler you change something, from what depend other components. For this need use onMouseLeave.
I recommend use styles for simple styling things. Don't use javascript for simple styling thing as example for make blue color on hover, for that simple thing use CSS.

Using react; workflow method for overloading css

I am new to the React javascript framework and have a question about styling using CSS.
Using jQuery, my old workflow was to pick an element on the screen, inspect it in Chrome, note the selector/s that triggered the styling, change the element styling in the browser, and then save it to css/sass etc. If the widget had a hover-state I could make the element visible to see what it looked like.
However using React, and especially for components that someone else has coded, where the component does a 'pop-up' etc, I can't manipulate the DOM to see the component because it is removed from the DOM before I can inspect it.
Now of course I could read the external library code, work out how it works, but CSS inheritance means it would take some time to work out exactly is happening and this seems to be slower than what I was doing before - especially for a simple change.
So my question is, what is the preferred workflow for overloading the CSS for DOM elements that are removed before they can be inspected?

How to reset all styles of a div and decedents back to Chrome defaults

I'm not sure this is possible, but id like to set all user styles back to chrome defaults for div and descendants.
I'm building a Chrome plugin that creates a popup on any web page, however due to the fact every page has a plethora of custom styles, trying to track down every inconsistency and overwrite it with my divs (and descendants) custom style, it is becoming a nightmare.
Every time I think I've covered all bases another site implements something else that needs to be overridden.
What would be the easiest approach to standardize my popup in this situation?
One approach I can think of is to (bite the bullet) and get a hold of the the default Chrome CSS styles and implement them into a series of catch all descendant selectors, however surely there is a better way.
If you want to be absolutely sure that the styling of your elements is not affected by the web-page's CSS, there are 2 possible solutions:
Use an iframe to implement your popup. (This solution is "safe" and simple enough, but based on the kind of interaction between the popup and the web-page it might become cumbersome.)
Utilize the Shadow DOM. (This is probably the "proper" solution, but the implementation might be a little more complicated.)
Some resources regarding the 2nd solution:
An introductory tutorial.
An actual example of incorporating the "Shadow DOM" concept into a Chrome extension:
RobW's Display Anchors extension
There is a third option worth discussing and rejecting, which is to reset all the style properties of the div and its descendents to its default value. Pseudo-code:
#my-div, #my-div * {
#for-every-css-property {
%propertyName: initial !important;
}
}
This answer shows an attempt at such a solution. It uses specific values instead of initial which will work in older browsers without the initial keyword, but will not correctly reset elements which have a different default from the base (e.g. user566245 mentions that textarea elements should have a border).
Issues:
Unfortunately initial is not actually the browser's default value.
If we don't use !important above then there is a risk that the page might have provided a rule with a more specific elector which overrides our own. For example if the page specified properties for table > tr > td then this would be applied over our rule because that selector is more specific than #my-div *.
Since we do use !important, any custom styling we want to do after the reset must also use !important on every property.
If the page happens to inject any additional CSS styles after ours that uses !important then these can override our reset.
It is rather inefficient. We are asking the browser to apply a huge bunch of CSS rules to every element under our div.
Vendor-specific properties should also be reset. (E.g. -webkit-animation-name.)
If new CSS properties come into existence in future, you will need to update your list.
Whilst this solution can be applied to current browsers, it is rather horrible, so roll on Shadow DOM! I would recommend the <iframe> solution in the meantime.
I don't know if anyone has tried this, but a more efficient solution might be to use Javascript to detect what site-defined CSS properties could be problematic, and reset only those.

CSS3 Selectors in IE8?

Alright, so I recently found this script called "Selectivizr" and I was really excited, but I plugged it into my project, set it up just as it said, and it didn't work.
So, what I am looking for is any sort of JavaScript library/script that will allow me to use CSS3 selectors (especially :checked) in IE8.
Selectivizr seems broken, and hasn't been updated in over a year. Has anybody else had luck with it?
Does anybody know of any other scripts that will allow for use of CSS3 selectors in IE8?
Not looking for CSS3 stylings like border radius, shadows, etc. Just looking for the selectors, like :before, :after, :checked, etc...
Dean Edward's IE9.js is pretty solid, though I have heard of some incompatibility problems when using other libraries as well. Never experienced them myself, but haven't used the library too often in the wild for a long time. Plug it and play, and if it doesn't break then you're all set.
Link: http://code.google.com/p/ie7-js/
Demos: http://ie7-js.googlecode.com/svn/test/index.html
With jQuery code, you can use these few lines to toggle a class on all your checkboxes (or on it's container) any time it's checked or unchecked. This then lets you use regular CSS code in all browsers.
$("input[type='checkbox']").click(function() {
$(this).parent().toggleClass("checked", this.checked);
});​
Working example here: http://jsfiddle.net/jfriend00/7jA5r/.
If you dynamically create checkboxes, then you could use the dynamic form of .on() to make sure to catch them.
I would personally rather use a solution with a few lines of code like this than use a heavy library that tries to add CSS style file capabilities. If you were going to use that, make sure you understand what's really going on under the covers before you adopt it.
If you just wanted a selector libraryby itself, the Sizzle selector library works across a wide variety of browsers including all the way back to IE6. It will adapt to the capabilities of the host browser, using as many built-in capabilities as are present and using it's own code when the host browser does not support an explicit capability.
You can use just the selector library itself from here or it is also the selector library inside of jQuery.
It's extremely simple to use. You just do something like this:
var items = Sizzle(":checked");
and you will have an array of DOM elements that match the selector.

Performance of jquery selectors vs css3 selectors

I am fairly new to css3 using selectors (or simple css selectors in general) and am curious about the performance comparison of these css selectors vs jquery or javascript selectors?
Say you have something like this:
css version
#someID > div:nth-child(2n) { some css .... }
jquery version (edit)
$("#someID").children(":nth-child(even)").css({ some css ....});
Is it often faster to use the css selectors whenever you can, or use jquery selectors to adjust the css involved with an element or set of elements? Mainly when the set gets rather large. I would assume there wouldn't be much performance difference with only a handful of items?
Thanks!
jQuery's selector engine shares most of the same syntax as CSS, effectively extending the selector standard. This means you can pass most valid CSS selectors (with some exceptions) to jQuery and it'll handle them just fine.
jQuery optimizes valid CSS selectors for modern browsers that support the selectors API by passing them directly to document.querySelectorAll(). This means your jQuery selector will have almost equal performance with the equivalent CSS selector, with the only overhead being the $().css() and the selectors API calls.
For browsers that don't support the selectors API, well, it's pretty obvious that jQuery will be really slow as it has to do all the heavy lifting on its own. More importantly, it will simply fail on the exceptions that I link to above as well as any other CSS selectors a browser doesn't support.
However, with all that said, jQuery will invariably be slower, as the browser has to run through a script and evaluate it before getting a chance to apply and compute your styles.
And after all this, honestly, it's not much even if you had hundreds of items — chances are the browser is going to take longer to fetch the markup than to render the styles. If you need to do styling, and CSS supports it, why not use CSS? That's why the language was created in the first place.
Pure CSS will always be faster since it's done within the browser and optimized!
The downside is that some selectors might not be supported by the browser you're on. See http://caniuse.com/#feat=css-sel3
For me if I use jquery means that I want to put some effect on it, say like
$("#someID:nth-child(even)").css({ some css ....}).fadeIn('slow');
Apart from that you better use CSS itself, but we are barely to see the difference of it anyway, at least for a small scope system.
I've found this web that compare selector capability from different javascript framework and jquery does it quite well.
javascript framework selector test

Resources