Develop Reference

Setting (ARIA) role for HTML custom elements without explicit attribute?

I have a web app that displays and passes around user-editable semantic markup. For a variety of reasons, including security, the markup consists entirely of custom elements (plus the i, b, and u tags). For regular rendering, I simply have styles for all the tags and stick them straight in the DOM. This looks and works great.
Now I'm doing screen-reader testing, and things aren't great. I have a bunch of graphical symbols I want to add labels for. I've got divs that I want to make into landmarks. I've got custom input fields and buttons.
It would be easy enough to just add role= to all the different tag instances. But part of the reason for the custom markup is to eliminate all the redundant information from the strings that get passed around (note: they're also compressed). My <ns-math> tag should always have role="math", and adding 11 bytes to what might be tags around a single character is an actual problem when multiplied out over a whole article. I know this because the app started with a bunch of <span class="... type elements instead of custom.
For the fields and buttons, I've used a shadow DOM approach. This was necessary anyway to get focus/keyboard semantics correct without polluting the semantic markup with a bunch of redundant attributes, so it's easy to also slap the ARIA stuff on the shadow elements. Especially since the inputs are all leaf nodes. But most of my custom tags amount to fancy spans, and are mostly not leaf nodes, so I don't really want to shadow them all when they're working so well in the light DOM.
After a bunch of searching, it seems like the internals.role property from "4.13.7.4 Accessibility semantics" of the HTML standard is maybe what I want. I may well be using it incorrectly (I'm a novice at front-end), but I can't seem to get this to work in recent versions of Firefox or Chrome. I don't get an error, but it seems to have no effect on the accessibility tree. My elements are not form-associated, but my reading is that the ARIAMixin should be functional anyway. This is maybe a working draft? If this is supposed to work in current browsers, does anybody have a code snippet or example?
Is there some other straight-forward way to achieve my goal of accessibility-annotating my custom elements without adding a bunch of explicit attributes to the element instances?

So you want the benefit of adding a role or an aria-attribute without actually adding those attributes? The concept of an "accessibility object model" (AOM) has been bantering around a bit that would let you access and modify the accessibility tree directly but it's still in the works. Here's an article from a couple years ago that talks about it. Nothing official. Just one person's thoughts.

Further research shows that, as of this time, the abstracted accessibility options I'm asking for are not yet implemented.
For the time being: eliminating a number of page-owned enclosing divs from the accessibility hierarchy via role="presentation" significantly improved my overall tree. With those out of the way, the majority of my custom tags seem to be simply semantically ignored. This is mostly fine as the majority of my content is plain text.
Since I already mark up the vast majority of even single-character symbols, I've simply added all my symbols to the markup generator. Since everything is already in custom tags, I then use a shadow DOM span with role="img" and a character-specific aria-label to present the symbolic character.
My solution is still incomplete. I wish that I could convey the full richness of the semantic content I have available.

What element type would be best if I want to achieve custom text styles and accept multiline string text without truncating spaces displayed?

So, I am creating a program that will take an uploaded text file, read its text and highlight certain things (through injecting <span> with specific classes) into the file and display on a webpage. What I am having trouble with is how I can show these results.
I was initially using <textarea>, but I found that apparently, it does not recognize those <span> tags I have injected, so it just displayed as plain text. I tried using other approaches like <p> or <span> or <article> but it seems that all of those other ones will either
remove spaces accordingly (the text file uses a ton of spaces to format the text too and that needs to be retained), or
it will not recognize multi-line strings
So, some may suggest that perhaps I can simply inject a <br/> tag at all line breaks, which is a viable option for sure. The problem with the spaces that are truncated still remains if I do that. Not to mention that the tags will mess up a lot of my <span> formatting injection that I was trying to do, which relies on regex currently but that's at least doable.
What would be the best way to overcome this problem? Is there an obscure tag that will work best for the purpose here? Or what you be my best course moving forward?

Just use a <div> and convert all the space characters to if you really want to retain them (although it kind of goes against the way HTML is intended to work, but it's up to you).
And and all the newline characters need to be converted to <br/> - again the way HTML does layout is completely different to how a text file does it.

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.

Javascript - Comparing string environment

I am working on a WYSIWYG editor. As it has to include just some basic functions I want to do it myself and avoid problems. Now it is working perfectly but I want to add a functionality in order to unbold, unitalic...
I know that with execCommand it is an automatic thing, but it does not work in the same way in all browsers so... my idea was the next: When pressing BOLD button, check the environment of the string, and...
If the selection is Between the open and close <b> tags, like <b>ab||selected||cd</b> replace selected with </b>selected<b>.
If the selection starts or finishes with the <b> tag, like <b>ab||selected||</b> replace it by </b>selected<b> (and then strip out all <b></b> groups.)
If the selection starts and finishes with the <b> tag, like <b>||selected||</b> replace it by </b>selected<b> (and then strip out all <b></b> groups.)
But... how can I get into a var the <b>content</b> string when just having the caret/selection IN content? It might be possible...
UPDATE
It is curious that the replacement is always the same. So, should I really get what I am asking for, or just replace it in this way, always?

I am working on a WYSIWYG editor. As it has to include just some basic
functions I want to do it myself and avoid problems. Now it is working
perfectly but I want to add a functionality in order to unbold,
unitalic...
Do not write your own WYSIWYG editor.
Do you really want to "avoid problems"? Then use one of existing good editors (there're only 2... maybe 3 in fact). Creating editor is extremely hard task for which you need a lot of time (I mean... few years), a lot of knowledge and patience (a lot of too :P).
I can myself write that "I am working on a WYSIWYG editor". For more than half of the year I'm a core developer of one of these "good editors". And during this period I implemented only one feature - very important and very complex, but one of tens/hundreds of them.
That problem you have... I don't even want to start answering. It sounds like a piece of cake, but it isn't. It's a piece of brick that can kill you when fall on your head :). I'll only start enumerating important parts of the impl: Selection + range implementations, because native differ and are buggy (~5k LOC + min Nk LOC for tests). Then you need the proper styles handling (applying and removing) impl (min 1k LOC + tests), because you have to take care about styles spanning on many blocks (like entire table bolded) and different selections containing parts or entire styles etc. And you have to avoid native execCommand, because they will break your content. Then you should also think about updating toolbar buttons states and, to make your impl bullet proof, handling different style tags (e.g. pasted). And that's only the tip of an iceberg - you'll have styles handling, but hundreds of other things broken. Things that big editors have fixed.
Anyway - learn config options for one of main editors and customize it as you want. This will take you a few hours, not a few years.

How fast does it take to write a simple, custom editor?

by simple I mean, having buttons:
bold,
italic,
numbered list
bullet point list
indent left
indent right
spell check (obviously supported by ready made js component)
by custom I mean: having custom icons - so really just custom design
no frameworks, written from scratch, lightweight, compatible with major browsers
this is one of the main components of the webapp, so it has to be super lightweight, that's why I don't want frameworks

Unless you are targeting one browser, editors are immensely complicated components to get to work cross browser. There's no reason to do it yourself, unless you want to learn.
Use one of the many available that allow customization:
tinymce,
fckeditor,
wysihat,
others

Writing an editor that works cross-platform can be difficult, but, you should create your own framework as you do it, as it is a large project.
If you just want custom icons, that will depend on how long it takes you to make them, but, to get some basic functionality isn't that hard, probably less than 40 hrs of work if you know what you are doing.
In Unix writing your own shell used to be a rite of passage, in javascript it may be writing your own editor. :)
Where it gets tricky is if I have
<b>some text</b><i>more text</i>
and I decide to remove the tags from this text, then how to fix it will get tricky.
If you want to use only css then it gets to be more of a problem as you are grouping text from span tags, and fixing css classes, while the user is continuing to make changes.
I am dealing with this currently as I want an editor that works in XHTML2.0, and it is not a trivial issue, much harder than it is to do in a desktop application.
I would suggest getting it to work on Firefox 3 and Safari first, then, once it is working, go back and add in the code to get it to work on IE8, and if you want IE7, since MS is pushing IE8 out as a critical update now.

Don't.
Go get something else (any of those Jason mentioned, or e.g. what SO itself uses, WMD). Swap out its images. The end.
Seriously you don't want to write your own editor unless you have a very good reason for it functionally, not just what it looks like.

Read through the first chapters of the emacs tutorial, and you will see that there is not anything like a "simple" editor. But google will give you lots of easy customizable editors.