I'm writing a template page for a personal site I'm designing, and I'm going to be using drop-down DIV tags for the log-in form.
I'm also using Google Chrome as my primary testing, etc. browser, and noticed that all visible Elements appear to have a property called 'hidden' that holds a boolean value.
It works just like you'd expect, becoming hidden when set to True and visible when set to False.
document.getElementById("element").hidden = true;
document.getElementById("element").hidden = false;
Strangely enough, even Firefox 8.0.1 handles this in the same manner.
As my Google-fu hasn't been able to turn up any information on this, does anybody here know why this appears to be working, and how many other browsers support this?
I will add that this website I'm building is for my personal use, so cross-browser-compatibility is not intended, but would be a nice side-effect.
hidden is a new global attribute introduced in HTML5. This means that browser support should be fairly good in modern browsers, though it will not be supported in IE8, and possibly IE9. As an aside, your use of the hidden attribute is probably incorrect.
This Boolean attribute indicates that the element is not yet, or is no longer, relevant. For example, it can be used to hide elements of the page that can't be used until the login process has been completed. The browser won't render such elements.
Your login form is not part of the page that is no longer relevant, but rather simply hidden as part of the presentation. You should therefore be using CSS for this instead. For more information, see:
Relevant MDN article: https://developer.mozilla.org/en/HTML/Global_attributes#attr-hidden
HTML5 specifications: http://developers.whatwg.org/editing.html#the-hidden-attribute
What you are doing is the same as doing:
<div hidden="true"></div>
However I would suggest you just do:
document.getElementById('question').style.display = 'none';
Related
I want to use the autocomplete attribute on a form on a webpage. Specifically, autocomplete="tel-local" and such (i.e. autocompletes that specify what goes in a field)
I'd like to know how widely supported it is, and, if possible, what browsers support it. My attempts to google it have failed...
Also, as far as I can think, even in browsers that fail to support it, using the attribute should not cause problems. Is there any problem that I can cause by using it?
The spec that I intend to use is https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill (which, as far as I know, is the current spec).
The autocomplete attribute as such is well supported, see MDN info on input. However, this only applies to its original design, formally described in the W3C HTML5 Recommendation. Various drafts contained lists of other values, but they were dropped from the Rec due to lack of implementations. Such ideas are retained in the HTML 5.1 draft (work in progress) and in what the WHATWG group calls “Living HTML Standard” (a mutable document that expresses a person’s view of what is “standard HTML” today).
Support to values other than on and off in browsers is obscure. The current version of Firefox surely lacks support, since other values aren’t even reflected in the DOM, i.e. the autocomplete property of an element node cannot have other values (so e.g. autocomplete=tel-local is ignored, which normally means defaulting to autocomplete=on). Chrome and IE let you set the attribute to any value, in the sense of setting the property, but its effect appears to be undocumented. In Chrome, autocomplete=tel-local seems to have some effect, but to me it suggests just some text strings as values (perhaps due to some tests I have made previously).
The problem in support is that it may exist. It is then somewhat unpredictable how a browser implements the attribute.
My question about AngularJs that I can't seem to google my way out of just yet has to do with the way Angular handles forms and form validation.
Ideally I want to make my form cross-browser compatible and use the 'Angular-way' of handling forms. Commonly one would set the novalidate attribute on the form tag because that disables any html5 related form validation the browser wants to do.
But, and this is the thing: does that also mean that Angular handles the way inputs of, say, type="email" and does the browser ignore them? Does Angular guard the fact that the user enters a properly formatted email instead of the browser's implementation of the input type="email" field? And thus does Angular mask the input as well?
I ask because there are several useful types (like email and url) that aren't strictly cross-browser, but I'd really like to make a universal form with Angular's goodies.
The answer depends a bit on what you expect your validation to do. Take the email field as an example. If you look at the quirks documentation you will see the automatic validation for the field type works in most browsers except for IE9 and Sarafi. Bringing angular into the mix doesn't change this at all so your standard validation isn't going to work in all browsers.
That said, Angular actually is binding the value of the field to a variable via model binding. So it doesn't rely on the browser validation entirely but actually provides its own validation. I checked this page, and even on Safari for Mac, the validation works excellently. Even with this in mind, I would still recommend opening the plunker and trying out what fields you need to validate on all browsers you really need to support.
One final thought is that Angular itself is no longer IE8 compatible. Although the team doesn't intend to break IE8, they aren't testing in it any more (See here for details). In other words - if you need really old browser support you are going to have to test that yourself!
Some strange bug I came accross today when creating a generic button class to style everything from divs to inputs. It seems that most browsers use a different box model when it comes down to input[type=submit].
Most modern browsers (ie9+, ff, chrome, etc) use the content-box box model for all inputs except submit which uses border-box if im not mistaken.
Basically, if I set a height of 100 and padding of 10 all around, the height of all inputs except submit would be 120 where as the height of submit would be 100.
This is easily fixed using box-sizing and its browser prefixes. But my problem is with IE6/7 which do the same thing but do not support box-sizing...
so now all my inputs display full height except for submit which is cut in half. What options do i have to force content-box or another fix apart from conditional comments?
IE's old "broken" box model is essentially content-box. In IE>5 the document needs to be in quirks mode for IE to use it. You can trigger quirks mode by doing one of the following (according to wikipedia):
When the document type declaration is absent or incomplete;
When an HTML 3 or earlier document is encountered
When an HTML 4.0 Transitional or Frameset document type declaration is used and a
system identifier (URI) is not present
When an SGML comment or other
unrecognized content appears before the document type declaration
When there are errors anywhere in the document
Now of course, this probably makes more trouble than it's worth because it would make everything use the IE box model (content-box). I could see this being useful, but if your layout wasn't built this way, it's probably too much work to go back and change it.
I did some searching around and didn't find anything that would enable the old box model on certain elements, and not others.
Having dealt with IE6/7 in the past, there's really no way to get around it's buggy behavior without using something like conditional comments or css hacks. It's rendering engine is just fundamentally broken compared to other browsers. Trying to get it to behave without any hacks is just asking for headaches.
The only other thing I can think of is to surround each form element with a span or div, and use them to help size your form elements. This also sucks, but it has the advantage of at least working in every browser.
One of our web applications just went through 508 compliance testing. We use TinyMCE version 3 for content development and I understand it generally has good accessibility. However, one of our pages contains 3 or more TinyMCE instances each preceded by a label indicating what the TinyMCE instance is for but we are being told that these are "implicit" labels when they should be "explicit" labels (i.e. with the for attribute). Problem is, TinyMCE instances are just iframes with a complex assortment of custom html "controls", whereas as far as I know the label/for technique only works with traditional form elements. What's the best strategy for achieving an "explicit" label for a TinyMCE instance?
Thanks!
Edit
Solutions explored using label + for which don't work: pointing the label at the initial textarea, pointing the label at the generated iframe.
One possible solution I am exploring is encompassing each TinyMCE instance with a ledgend + fieldset but testing this out with JAWS 9.0 it doesn't seem to make any difference unless the fieldset contains form elements (e.g. input, type=text) and JAWS is in forms mode.
There is an emerging standard for exactly this kind of problem: ARIA (Accessible Rich Internet Applications). It's still a working draft, but support is beginning to show up in recent screen readers (JAWS 9, recent versions of NVDA) when used with recent browsers (IE 9, Firefox 3.6 (partial) and 4.0, Chrome).
In this particular case, take a look at aria-label and aria-labelledby. These are attributes which would be added to the BODY element in TinyMCE's widget -- or to the IFRAME, whichever of the two actually takes focus when the user is entering data. Thus:
<body aria-label="Edit document">
The aria-label attribute just specifies a string that serves as the label. The aria-labelledby (note the two L's, as per British spelling) works like the traditional LABEL element in reverse. That is, you feed it an ID:
<body aria-labelledby="edit-label">
And then you would have this someplace else in the code:
<label id="edit-label">Edit document</label>
It doesn't necessarily have to be a LABEL element, you could use a SPAN or whatever, but LABEL seems semantically appropriate.
ARIA attributes will not validate under HTML 4, or XHTML DTD's. However, they WILL validate under HTML 5 (itself still in development). If validation is important to you under an older DTD, you can add the attributes programmatically using JavaScript when the page has loaded.
Ideally, if you have a visible label for the widget already, then you should be using aria-labelledby to prevent redundancy. However, I have no idea if it'll work across document boundaries. That is, if the BODY is in an IFRAME, and the visible label is defined in the IFRAME's parent document, I don't know if it'll work. The browser/screen reader may treat the two as separate documents which don't talk to one another. You'll have to experiment to find out. But if it turns out they don't work, try http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden. Thus, in the parent document:
<label aria-hidden="true">Edit document</label>
And in the TinyMCE document:
<body aria-label="Edit document">
The aria-hidden attribute will prevent the label in the parent document from being read, and the aria-label attribute in the child document (which is not visible) will take its place. Voila, a widget labeled both visibly and audibly with no redundant reading.
If you use aria-hidden this way, be very careful that the bit you're hiding (or an equivalent) is always made available for reading someplace else.
This solution will only work for people using web browsers and screen readers that support ARIA. People with older screen readers or browsers will be out of luck, which is discussed at length in the recent article on A List Apart, The Accessibility of WAI ARIA. The author makes a good case for preferring traditional semantic HTML solutions whenever possible; but in your case I don't think you have any other option. At the very least, adding ARIA attributes will let you reasonably claim that you've done your due diligence and made a good faith effort to make it as accessible as possible.
Good luck!
Note to far future readers: The links to the ARIA specification given here refer to the September 2010 working draft. If it's been more than a few months since then, check for more recent specs.
Using the information Will Martin provided regarding the aria-label attribut, I wrote the following line of code which works for TinyCME 4:
tinymce.init({
…
init_instance_callback: function(editor) {
jQuery(editor.getBody()).attr('aria-label', jQuery('label[for="' + editor.id + '"]').text())
}
});
It uses the callback function triggered after initialisation of the editor.
There has to be a label targeted at the original element on which TinyMCE is call upon, in my case a textarea. e.g.:
<label for="id_of_textarea">Shiny wysiwyg editor"</label><textarea id="id_of_textarea"></textarea>
The content of the label (text only) is added as aria-label attribute to the body tag inside the TinyMCE-iframe.
OSX screenreader is propperly returing the label when selecting the TinyMCE
Some inspiration from TinyMCE: How bind on event after its initialized
If I read the specs right, the for property must indeed point to another control on the same page, as you already say.
Therefore, I think the only valid option is to point the for attribute to the <textarea> element that TinyMCE replaces. It makes the most sense, seeing as that element gets sent to the server when editing is finished.
I've seen many uses of rich-text or at least natural-looking text editing being made available with seemingly any of a page's text-containing elements. What are my options to have this for myself?
I think you may be referring to the contenteditable attribute in HTML5. This attribute allows any arbitrary HTML element to literally become editable. It has a fairly wide support, mainly because before its appearance in the HTML5 specs it is actually a proprietary Internet Explorer attribute.
The downside of this is that, like any other form element, the appearance and capabilities of this varies wildly from browser to browser, and the quality of the HTML produced is truly atrocious. Still, if you want to have a look, go ahead and hit some of these links:
http://html5demos.com/contenteditable
http://blog.whatwg.org/the-road-to-html-5-contenteditable
Are you looking some some thing like tinymce ? If so check this