I'm developing a desktop software application which looks for errors in web pages and can highlight them in the browser. Highlighted areas are somewhat arbitrary. They could be one word in a p tag, an entire a tag or an img.
In the past I've done this by rewriting the html and adding styled span tags around the highlighted area. The downside is that quite often the highlights can be obscured. For example where in image is in a div exactly its size with no overflow, any applied border, background etc. will be obscured.
What's the best way to approach this? Are there any good examples of this being done in popular software / webapps?
Limitations: I can't use JS (files are local and browsers often block this). I can however user the latest standards. The output doesn't have to validate, as long as it works on common modern browsers.
Since background colors and borders can't be used, I think you'll need to place something on top of the offending element or text. Perhaps you can use an absolute or fixed position <div> element with a partially transparent background.
Of course, this could get tricky with getting the coordinates. But you might be able to use the same thing you used to do with the span and add some dummy elements within it to trick it into thinking that 0,0 is right where your span element is.
Related
I am trying to replicate a design element and remove the image and hopefully replace it with plain HTML/CSS. Essentially I have a header > h1 that has a title in it. For example we'll say this title is "Stack Overflow", like so..
<header>
<h1>
Stack Overflow
</h1>
</header>
In my current CSS, the text-indent is pushed off the screen and a background is applied to the h1.
To replace that I'm using the -webkit-text-stroke: rule which works fine, albeit not being fully supported across all browsers. The problem with it is one that many Photoshop users come across when applying stroke to text and that is the position of stroke.
Let me demonstrate with a badly put together image: https://i.imgur.com/eQC9B5v.jpg - the top text shows stroke that is "outside" of the text, the bottom one uses what Photoshop calls "center".
It seems that -webkit-text-stroke based it's stroke on that "center" variant in Photoshop. I'd very much like it to replicate the "outside" option.
I can't see anywhere I can set this, and I'm guessing I can't but I'd be interested to know if..
a) there is a method, and if so what is it?
b) if there isn't a method, has anyone found a different way of achieving this?
Now I should say, I found this: https://www.petercarrero.com/examples/stroke which in turn came from a post posted on here in 2013 (CSS- webkit-text-stroke but stroke covers font-color)
On caveat here is that I believe SVG can control the stroke type and I would be interested to see any solutions that use it, but ideally I am not targetting an SVG solution.
Thanks in advance.
I am just learning to code and have been looking everywhere for an answer on this one and for some reason cannot find anything.
I noticed that it seems to be common practice to put an image inside of a container or wrapper. For instance, rather just having:
<img src="url"/>
Everyone seems to be in agreement that it needs to be this way:
<div class="container">
<img=src"url"/>
</div>
What is the purpose of wrapping the img inside of a div in this way? It seems to have something to do with "responsive design", but I'm not 100% sure. Is it just so that we have something to size the image relative to, rather than using definite sizing like pixels on the image selector in css? The more I think about it as I write this, the more it seems to be the right answer, but I'm not sure if there's something else I'm missing on this one.
Any insight would be very much appreciated. Thank you.
unfortunately there is no "single" correct answer for this.
There can be many reasons as to why one would wrap any element in another element, it is not specific to <img /> tags :)
In your question I read something like this (converted to real world example):
I see that it is common practice to put a frame around a photo.
Where the "frame" would be the wrapper element, and the photo would be the <img />.
Looking at it this way might make it seem more clear. The photo is the most important part, technically speaking you don't need a frame to show the photo. If you have just a photo, you won't be able to hang it on your wall without damaging it by driving a nail through the top or applying some tape. If you have a frame though, you can make that photo take up any amount of available space within it, you can use the clip to hang it on a wall and if you put multiple photo's in the frame, you can move them all at once since they are in the same frame.
The reason most people put that image in a "container" is because they get some sort of advantage out of it over using an image alone, this could range from aspect-ratio locks to relative positioning. In some cases, a wrapper is required to achieve certain (notably more complex) animations as well.
Websites are built out of "logical" pieces that, together, form a website. The individual pieces are all "frames" that "flow" together to create any page layout you see on every website.
It is merely a structural way of thinking, if the purpose of that image was to be used as a background image for the entire page, a better alternative would be to use CSS background-image property on the <body> tag and not use the image at all. But if the image is meant to be part of a smaller part of your website, it should probably be contained as appropiate.
This answer is in no way a guide to go by, nor a ruleset or anything like that, they are just the thoughts of another developer. There are countless reasons for wrapping an element and this answer doesn't even cover 0.0000001% of those cases. I'm just saying -- there's no specific reason to do or don't here.
I've been working with contenteditable recently within a HTML5 page and encountering bugs when using it with certain elements, and I'd like to know where and how I can actually safely use it.
I've discovered that making a span element contenteditable results in some buggy behaviour in both Firefox1 and Chrome2. However, making a div or section contenteditable appears completely safe3.
A guideline a couple of people have mentioned is that only block-level elements should be made contenteditable. However, the Mozilla Developer Network lists the heading elements h1 through to h6 as block-level elements, and making a heading element contenteditable is buggy in Firefox4 and can crash the page in Chrome5.
I'd like to be able to use more than just divs and sections, but I'm not clear on what elements I can actually safely make contenteditable. By safely, I mean that using the element under normal conditions, I should be able to perform normal editing tasks without it doing unexpected or buggy things. I should be able to write in it, delete content, cut, copy, paste, and move my text cursor about and highlight text without unexpected or strange behaviour.
So, which elements can I really make contenteditable safely? Is there a specific category? Are there certain criteria the safely-contenteditable element must match?
Bug notes:
Firefox 21 w/ span: Element loses focus if the text cursor is brought to the beginning or end of the element, but not if it got there by deleting content. Highlighting part of the element, cutting and then pasting will split the element in two at that point then insert a blank element between the two parts - without actually putting the text you were trying to paste anywhere.
Chrome 27 w/ span: If the span covers multiple lines e.g. by being wordwrapped, cutting and pasting content will often insert a linebreak after the pasted content.
Unless you make the div display:inline, in which case it can still lose focus as in 1, but apparently only if you bring the text cursor to the end. I don't consider this "normal" usage of the element though.
Firefox 21 w/ heading: Selecting part of the content then cutting and pasting will, similarly to 1, split the heading element in half at that point, and insert a third heading element between the two halves. It will, at least, have your pasted content inside it, but now you have three heading elements where there was originally one.
Chrome 27 w/ heading: Select some content and cut and paste. The page crashes. You get an "Aw snap!" message. That's it.
Demo code
Here's a demo for reproducing the above. It's pretty simple, though at the moment the only thing it isn't reproducing is the lose-focus bug.
[contenteditable=true] {
border: 1px dotted #999;
}
<article style="width: 100px">
<h1 contenteditable="true">Heading</h1>
<p>
<strong>Some adjacent content</strong>
<span contenteditable="true">Span! This is long enough it will spread over multiple lines.</span>
</p>
<div style="display: inline" contenteditable="true">An inline div also with multiple lines.</div>
</article>
In my opinion, I'd say div is the safest bet across the board. Any element you wish to truly edit (be it a span, header, etc), you can place inside the div and edit as if it were just that element. Also, to account for the display:inline issue you mentioned, you could always use float:left or float:right on your editable div to give it an "inline feel" without having it actually be inline.
Hope that helps!
Since this is an evolving feature with, apparent, low priority from the browser vendors support has been sketchy and regressions not uncommon. The current state of affairs is evolving, so check the Googles, CanIUse etc and make sure support is there for your sites visitors, everything else is moot ...
Support in Firefox seems to be solid, at least for some elements, now https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
It works well in Chrome as well as far as my testing goes.
And CanIUse looks good: http://caniuse.com/#feat=contenteditable
There are a number of different bugs related to the feature in the different browsers though, but for simple use cases it should be ok now, as of August 2016.
i'm solving a problem to make select inputs look the same in all browsers (Chrome and Safari on Mac renders them differently) how to do that ?
The ONLY way to make them look the same right now would be to hide the original inputs, and replace them with appropriately styled html equivalents (of god forbig Flash objects), which would act as proxies, passing the functionality over to the hidden inputs.
That may be automated with JavaScript. But that would be WRONG. You are not supposed to force a different look on to OS styled elements of the webpage. It conflicts with a lot of usability and accessibility practices.
So, the only way is to make your design flexible enough to support differently looking control elements on a web page, and also use different stylesets for different browsers, to ease the adjustment of the styles (at the moment there are no inputs that would look and act the same on all browsers with the same style rules applied).
Unfortunately, life just kinda sucks on this one. Just wait till you need to style a file input...now that's some fun!
if you dont mind using js you can simply design your own look (a jpg img it can even be the same img as the original select element or if you wish you can model parts of it in css)
Then place a div on top of that image that div will contain the text which select element would usually contain
<div id="selectTxt" >
then set another div on top of that with the select element inside it.
<div id="transparentSelect" class="transparent">
<select id="selectCar" name="selectCar">
<option>Volvo</option>
<option>Saab</option>
<option>Mercedes</option>
<option>Audi</option>
</select>
</div>
Now the trick is to set the select element opacity to zero
you can do this by adding by adding a class transparent
and then applying the class to the div
.transparent
{
filter:alpha(opacity=0);
-moz-opacity: 0;
opacity: 0;
}
now the element is hidden but when you click on it the list will still show up.
So the list will always look like the default list in the browser
now use js to extract the select value every time you click on the select
and set the inner html of selectTxt div to its value.
This way you get the text of the select on top of an image you want
you can make the image animated with the hover effect in css or with js
I also make a select that looks the same in all browsers but it doesnt work when you click directly on the arrow...
so its an inferior version but if you wish to look at it here it is
http://jsfiddle.net/fiddlerOnDaRoof/LM73V/
it also lacks the arrow image but you can print screen that from your browser
good luck
You should apply a CSS to reset the styles (not just for the inputs, this is a highly recommended practice for all element so that your page looks almost the same in all browsers) there are many, just google a little, for example this one, and then apply your desired styles (border color and width, background, etc...) take a look at this tutorial on how to style form elements
For an iPhone ebook application I need to break arbitrarily long HTML documents up into pages which fit exactly on one screen. If I simply use UIWebView for this, the bottom-most lines tend to get displayed only partly: the rest disappears off the edge of the view.
So I assume I would need to know how many complete lines (or characters) would be displayed by the UIWebView, given the source HTML, and then feed it exactly the right amount of data. This probably involves lots of calculation, and the user also needs to be able to change fonts and sizes.
I have no idea if this is even possible, although apps like Stanza take HTML (epub) files and paginate them nicely. It's a long time since I looked at JavaScript, would that be an option worth looking at?
Any suggestions very much appreciated!
update
So I've hit upon a possible solution, using JavaScript to annotate the DOM-tree with sizes and positions of each element. It should then be possible to restructure the tree (using built-in XSLT or JavaScript), cutting it up in pages which fit exactly on the screen.
Remaining problem here is that this always breaks the page on paragraph-boundaries, since there is no access to the text at a lower level than the P-element. Perhaps this can be remedied by parsing the text into words, encapsulating each word in a SPAN-tag, repeating the measurement procedure above, and then only displaying the SPAN elements that fit onto the screen, inserting the remaining ones at the front of the next page.
All this sounds rather complicated. Am I talking any sense? Is there a simpler way?
You should look at the PagedMedia CSS module: http://www.w3.org/TR/css3-page/
CSS3 also support multicolumn layouts (google for "css3-multicol". I don't have enough Karma to include a second link here :-)
About your update: how about doing the layout of one single page, then use a DIV with overflow:hidden for the text part. Next thing would be to overlay a transparent item on top of that, that would programmatically scroll the inner content of the DIV PAGE_HEIGHT pixels up or down according to some navigation controls (or gestures).
The other option is to have a parent <div> with multiple css3 columns: link1, link2.
This works on Android:
<style type='text/css'>
div {
width: 1024px; // calculated
-webkit-column-gap: 0px;
-webkit-column-width: 320px; // calculated
}
p {
text-align: justify;
padding:10px;
}
</style>
The CSS multicol suggestions are very interesting! However, and I hope it's ok to respond with another question: how would you go from splitting one or more long <p> elements into columns to having one particular of these columns being rendered in a WebView? The DOM hasn't changed, so you can't pick out an element and render it. What am I missing?