HtmlEditor and increase/decrease font size with Midas commands - javascript

I came across some cross-browser weirdness while trying to integrate the ExtJs HtmlEditor into our project:
If you decrease/increase the font size in Firefox3.6, it wraps the selected text in a '' tag with a size attribute (e.g. 'visitor'). If you do the same in Chrome6 or Safari4, it wraps it into a '' tag with 'style=font-size...' attribute ( e.g. 'visitor'). Therefore, once you change the font size in Firefox, you won't be able to modify it in Safari or Chrome and vice versa.
This is done by the browser's Midas engine (as documented here: http://www.mozilla.org/editor/midas-spec.html). The implementation calls:
document.execCommand('FontSize', false, value); // value is the font size as a numeric value
So, there is not much I can change about it. I was about to write my own implementation of the font size changer, but after I went down the route I recognized that that would be a rather complicated implementation.
Has anyone else encountered that problem? Are there any good solutions for this one?

As long as you will save the source somewhere on a server, i would like to recommend to leave the editor as is.
On the server-side you normally will validate the source, so the validation will be a good time to transform the source to a unique style.

Related

Javascript wrongly decodes unicode

I'm trying to get an id of a font-awesome icon. It is located in ::before style. When i use
window.getComputedStyle(document.querySelector("[id='5']"), '::before').getPropertyValue('content')
to get it, instead of "\f458", "\"\"" is returned.
I assume that JavaScript is trying to convert the code into a char but fails. Is there any way to prevent this?
The decoding works, the problem is the font. If there's no match for this character in a font you use, it'll be mangled or in the form of the unicode value in a box.
Since it's in the private area, depending on the font it might be resolved into a glyph or be mangled or be just empty/space.
Checking in the Font Awesome Cheatsheet it looks like a an icon for quidditch.
Perhaps there's a text to image/svg map somewhere on the internet (and if not, then just copy-paste localy and create one) which you might use if the font itself isn't good or you are decoding in a problematic environment (can't install fonts, etc).

Javascript retrieve linebreaks from dom [duplicate]

I need to add line breaks in the positions that the browser naturally adds a newline in a paragraph of text.
For example:
<p>This is some very long text \n that spans a number of lines in the paragraph.</p>
This is a paragraph that the browser chose to break at the position of the \n
I need to find this position and insert a <br />
Does anyone know of any JS libraries or functions that are able to do this?
The only solutuion that I have found so far is to remove tokens from the paragraph and observe the clientHeight property to detect a change in element height. I don't have time to finish this and would like to find something that's already tested.
Edit:
The reason I need to do this is that I need to accurately convert HTML to PDF. Acrobat renders text narrower than the browser does. This results in text that breaks in different positions. I need an identical ragged edge and the same number of lines in the converted PDF.
Edit:
#dtsazza: Thanks for your considered answer. It's not impossible to produce a layout editor that almost exactly replciates HTML I've written 99% of one ;)
The app I'm working on allows a user to create a product catalogue by dragging on 'tiles' The tiles are fixed width, absolutely positioned divs that contain images and text. All elemets are styled so font size is fixed. My solution for finding \n in paragraph is ok 80% of the time and when it works with a given paragrah the resulting PDF is so close to the on-screen version that the differences do not matter. Paragraphs are the same height (to the pixel), images are replaced with high res versions and all bitmap artwork is replaced with SVGs generated server side.
The only slight difference between my HTML and PDF is that Acrobat renderes text slightly more narrowly which results in line slightly shorter line length.
Diodeus's solution of adding span's and finding their coords is a very good one and should give me the location of the BRs. Please remember that the user will never see the HTML with the inserted BRs - these are added so that the PDF conversion produces a paragraph that is exactly the same size.
There are lots of people that seem to think this is impossible. I already have a working app that created extremely accurate HTML->PDF conversion of our docs - I just need a better solution of adding BRs because my solution sometimes misses a BR. BTW when it does work my paragraphs are the same height as the HTML equivalents which is the result we are after.
If anyone is interested in the type of doc i'm converting then you can check ou this screen cast:
http://www.localsa.com.au/brochure/brochure.html
Edit: Many thanks to Diodeus - your suggestion was spot on.
Solution:
for my situation it made more sense to wrap the words in spans instead of the spaces.
var text = paragraphElement.innerHTML.replace(/ /g, '</span> <span>');
text = "<span>"+text+"</span>"; //wrap first and last words.
This wraps each word in a span. I can now query the document to get all the words, iterate and compare y position. When y pos changes add a br.
This works flawlessly and gives me the results I need - Thank you!
I would suggest wrapping all spaces in a span tag and finding the coordinates of each tag. When the Y-value changes, you're on a new line.
I don't think there's going to be a very clean solution to this one, if any at all. The browser will flow a paragraph to fit the available space, linebreaking where needed. Consider that if a user resizes the browser window, all the paragraphs will be rerendered and almost certainly will change their break positions. If the user changes the size of the text on the page, the paragraphs will be rerendered with different line break points. If you (or some script on your page) changes the size of another element on the page, this will change the amount of space available to a floating paragraph and again - different line break points.
Besides, changing the actual markup of your page to mimic something that the browser does for you (and does very well) seems like the wrong approach to whatever you're doing. What's the actual problem you're trying to solve here? There's probably a better way to achieve it.
Edit: OK, so you want to render to PDF the same as "the screen version". Do you have a specific definitive screen version nominated - in terms of browser window dimensions, user stylesheets, font preferences and adjusted font size? The critical thing about HTML is that it deliberately does not specify a specific layout. It simply describes what is on the page, what they are and where they are in relation to one another.
I've seen several misguided attempts before to produce some HTML that will exactly replicate a printed creative, designed in something like a DTP application where a definitive absolute layout is essential. Those efforts were doomed to failure because of the nature of HTML, and doing it the other way round (as you're trying to) will be even worse because you don't even have a definitive starting point to work from.
On the assumption that this is all out of your hands and you'll have to do it anyway, my suggestion would be to give up on the idea of mangling the HTML. Look at the PDF conversion software - if it's any good it should give you some options for font kerning and similar settings. Playing around with the details here should get you something that approximates the font rendering in the browser and thus breaks lines at the same places.
Failing that, all I can suggest is taking screenshots of the browser and parsing these with OCR to work out where the lines break (it shouldn't require a very accurate OCR since you know what the raw text is anyway, it essentially just has to count spaces). Or perhaps just embed the screenshot in the PDF if text search/selection isn't a big deal.
Finally doing it by hand is likely the only way to make this work definitively and reliably.
But really, this is still just wrong and any attempts to revise the requirements would be better. Keep going up one step in the chain - why does the PDF have to have the exact same ragged edge as some arbitrary browser rendering? Can you achieve that purpose in another (better) way?
Sounds like a bad idea when you account for user set font sizes, MS Windows accessibility mode, and the hundreds of different mobile devices. Let the browser do it's thing - trying to have exact control over the rendering will only cause you hours of frustration.
I don't think you'll be able to do this with any kind of accuracy without embedding Gecko/WebKit/Trident or essentially recreating them.
Maybe an alternative: do all line-breaks yourself, instead of relying on the browser. Place all text in pre tags, and add your own linebreaks. Now at least you don't have to figure out where the browser put them.

How to determine font-weight bold without using getComputedStyle

I'm in the process of making an HTML text parser and I would like to be able to determine when a text node appears as a header (visually, not HTML headers).
One thing that can usually be said about headers are that they are emphasized - usually in one of two ways: Bold font or larger font size.
I could get both corresponding CSS values using getComputedStyle(), but I want to avoid this because the parser needs high performance (has to run smoothly on, for example, Chromebooks) and getComputedStyle() is not particularly fast when looking through hundreds or thousands of nodes.
Figuring out a font size isn't too hard - I can just select the node with range and check its client rects from range.getClientRects().I haven't figured out a smart way to check font weight though, which is why I'm here.
Can anyone think of higher-performance way of doing this than by using getComputedStyle()?
I'm aware this might not be possible - just looking to see if someone can think of an ingenious way to solve this problem.
Edit
This is for a Google Chrome extension only.
What you're aiming to do here is really messy. Since you want to determine if text is bold visually, on some devices, depending on how they render text, the whole system may just break!
A suggestion I have is to use the HTML5 Data atrributes - find out more here - and use it like so:
<div class="header" data-bold="yes">This will appear bold?</div>
Then, using JavaScript you can just go over all div elements with the data-bold attribute.
I hope this helped ;)

Browser Plugin?

I want to design a system where user can give a specific font size from a settings and whole site will be changed and every writing would be of that font size. Now i think I have to develop a browser plugin. however, if any of you can suggest that without using browser plugin i can do that, then definitely I want to know that. [ here user will be able to modify the site from the browser ,user has nothing to do with the existing sites coding what so ever]
Please don't develop a plug-in just for that.
Unless you're working with really old browsers (IE6 and such) that would not scale fonts specified in certain units, all modern browsers have menu and keyboard settings to change the font size. Let the users use those.
You can also use a bit of Javascript to display "bigger/smaller" buttons somewhere and either replace a stylesheet file or adjust the default font size of the <body> element and have the rest of the elements derive percentages from it.
I don't know about other way to do it,but anyway plugin won't help you.
See this excellent article: http://colonelpanic.net/2010/08/browser-plugins-vs-extensions-the-difference/
You mean a browser extension. As you can see in the article- if you want to write an extension to IE use BHO. For Firefox see https://developer.mozilla.org/en/XUL_School

What is the "best practice" for resizing text with Javascript?

What is the "best practice" (accessibility/usability-wise) for resizing text with Javascript?
My current solution is that for when the user clicks the resize link it adds an extra class to the body tag.
It also sets a cookie and then when the page is loaded - onLoad() - it reads the cookie and reapplys the body class tag again if needs be.
The only thing not ideal is that it loads then applys - the previous solution was to edit the CSS file before the page loaded but that threw up security warnings if the CSS file was in a different directory.
So, essentially is my solution reasonable or is there a better way?
Adam
What is the "best practice"
(accessibility/usability-wise) for
resizing text with Javascript?
Best practise is "Don't".
Specify the font size in relative units and let the native browser controls change it if the user wishes.
Attempts to duplicate this functionality rarely give the font sizes that users need (and usually end up offering a choice atomic, microscopic and tiny). Yes, some users need 72pt text (or larger).
The built in browser controls work on most, if not all, sites. You don't need to use up canvas real estate duplicating them.
Your solution sounds fine, with one addition: you can read the cookie as the page loads and add the class to the body element while the markup is generated. Most server-side languages support this: PHP, JSP, RoR etc.
Other than that, you have a solid solution.
Adding a CSS style to HTML via JavaScript
I think your suggestion is an excellent way of doing it.
It means you have the flexibility of being able to add the CSS class to any sub element rather than the body so that you can change the text size of a specific element if you so desire.
Reading the cookie on page load
To get around the issue you describe I would look for the cookie in your server side language (php/asp/ruby etc) and display the content as specified by the cookie on page load.
In PHP your CSS class definition may look like this:
echo '<div class=\"'.($_COOKIE['text_size']!='' ? $_COOKIE['text_size'] : 'normal'). '\">';
What is the "best practice" (accessibility/usability-wise) for resizing text with Javascript?
"Web Accessibility Gone Wild" sums it up quite nicely imho:
If your default font size may be too small for site visitors, then make it an adequate size.
and,
All browsers allow the sizing or scaling of the page content - why duplicate this browser functionality?
Also, Care With Font Size:
The problem here is a basic usability and accessibility issue: a good design should look good without requiring the user to enlarge or reduce the text size.
However, if you have a valid reason - feel free to ignore this.

Categories

Resources