Is there a way to prevent errors display while still adding the error classes from the js (not with the attribute)? If I use uiEnabled: true I get neither.
This issue solves the problem with attributes, but not from js code.
Why don't you simply hide the error messages with CSS?
Indeed, that's exactly what CSS is for.
Parsley generates error messages and classes, it's then up to you to provide the CSS for the display to match the look what you want. If that's display:none on the error messages, that's fine.
Realize that when designing a library like Parsley, the priority is to add features for things are difficult to achieve without it and fairly common. Hiding messages is neither difficult (it's one line of CSS) nor common, so it shouldn't be surprising that there isn't an option for it.
Related
This has happened to me a couple times. Using something like an <img> tag, or <br>. Basically any HTML void element. Just today I attempted to use a <br>, and when saving got this:
Am I missing something?
Is there a reason for this?
Are void elements not intended for use in visualforce pages or components?
Or is this just flawed syntax checking?
Can be very frustrating at times, I ended up adding a false tag the other day because I realized it wouldn't be rendered and it was the only way to save my page...
P.S. I'm sorry if this has an easily accessible answer. I think I looked a reasonable amount, but not as much as usual before posting a question. Just couldn't even find search terms to get me close to something relevant.
Visualforce must be a valid XML document. Not HTML (which permits <img> without closing), not XHTML (because if you add any <apex:... tags not defined by W3C officially it's not a html document anymore, at least until it gets compiled and output becomes pure html0.
So you need <img> ... </img> or self-closing version, <img />.
In a way Lightning Web Components are even worse, self-closing doesn't work. Has to be explicit "end tag".
As to why... probably for easier ability to parse it as a valid document? I suspect they did it also for easier PDF generation.
This isn't exactly same topic but close enough I could find in reasonable time: https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_styling_doctype.htm
ESlint seems to be very clear; it wants a valid link to be used inside the anchor tag. But I want to use it this way and I don't want to replace this anchor with a button or something else.
Also, the warning is not persistent. Sometimes it disappears. What I want to know is why is this happening? What is wrong with using an anchor without a reference actually ?
Warning comes from the following piece of code.
<a
key={randKey}
className="list-icons-item"
data-action={this.props.headerElements[i]}>
</a>
How can I disable this warning or what is the best practice ?
The question poses a simple example of a complex problem. If the intent of the code is to focus this.props.headerElements[i], then give this.props.headerElements[i] an ID and reference that id in the href of the link. Let the default behavior do its job. No further script logic is required.
If there is no navigation involved, then, as #Andy points out, the anchor is not suitable. Use a button as the documentation for the rule emphatically recommends.
When a control looks like a link and navigates off the page or changes focus on the page, a link is the semantically correct choice, per WAI ARIA specifications. If what you need to focus will be shown as part of your click handler logic, then you may find the ESlint jsx-a11y anchor-is-valid warning counterproductive. In that case, you are best served using an anchor with explicit role and tabindex attributes and suppressing the rule or turning it off in your .eslintrc file as #Andy also mentions above.
<a
role="link"
tabIndex="0"
key={randKey}
className="list-icons-item"
data-action={this.props.headerElements[i]}>
There are costs when semantics diverge from appearance. Consider a blind user calling your web application's help desk and being directed to click a link but hearing only a button announced in the screen reader. Consider a user who has only partial sight encountering a control which looks like a link and functions like a link but is marked up as a button. The user will hear one thing announced in the screen reader and see something else.
These trade offs need to be considered early in life cycle of your project so you can be consistent with your treatment throughout your application.
Are there any simple ways to patch React to autoprefix styles, such that the rendered HTML doesn't differ on the client and server?
For example, is it possible to get
<div style={{display: 'flex'}}/>
to render to (ignoring data-reactid):
<div style="display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;"/>
In the specific case you posted, you may have to make a function in which you pass your style and it creates the correct styles. In cases where a simple prefix will work, you could use something like react-prefixr which just adds ms,Webkit,etc. to the style structure. If display:flex is not handled properly by react-prefixr, you can probably submit it as PR.
I've had the same issue and wanted an easy way to mixin styles. So I created a library that lets you use less/sass style mixins https://seogrady.github.io/style-mixin.
I've just today created a simple prefixing tool, react-prefixer. This handles prefixing possibilities for relevant browsers.
I say relevant because you call out display:-webkit-box syntax, which is basically Safari 5.1, its pretty non-existent these days. Additionally, it only adds the syntax needed, meaning you won't see the full string of styles as you showed ... based on browser support, it will either provide the prefixed version or the spec version, no need to clog up the markup with useless styles.
It's still pretty young (I coded it this morning), but maybe it can help.
I have an issue with angularjs and the email input type.
I want to create dynamic inputs with a directive, but the input type validation might be buggy.
Here is the jsfiddle of my test
http://jsfiddle.net/NPCHr
To avoid some trouble I have to use this trick
element.find('input')[0].type = input.type;
When I had a second character in the input the model field disappears (In the html panel)
I don't know why is this a bug or am I doing something wrong ?
The problem with your directive is not that e-mail validation doesn't work but the fact that dynamic type attribute is not supported by AngularJS (and jQuery BTW). This is due to the fact that IE doesn't allow changing input's type on-the-fly (Changing the <input> type in IE with JavaScript).
This topic was discussed in great details on the AngularJS mailing list, here is the reference: https://groups.google.com/forum/#!topic/angular/Itl-fYzeF18 where someone had exactly the same problem as yours.
The way out of this situation is to manually compile a template using the $compile service. Unfortunately this is not trivial, you can see evidence of some experiments here: https://github.com/angular-ui/angular-ui/pull/191
An alternative, simpler approach is to use ngInclude directive to include different inputs based on their type. Yet another possibility is to use the compile function and manually transform template's markup. But yes, all of those techniques require several lines of non-trivial code.
Ui:include and xhtml based tag (the one with source elt) seem to be much the same for me. Both allow to reuse piece of markup. But I believe there should be some reason for having each. Could somebody please briefly explain it? (I guess if I read full facelets tutorial I will learn it, but I have not time to do it now, so no links to lengthy docs please :)
They are quite similar. The difference is mainly syntactical.
After observing their usage for some time it seems the convention is that fragments that you use only in a single situation are candidates for ui:include, while fragments that you re-use more often and have a more independent semantic are candidates for a custom tag.
E.g.
A single view might have a form with three sections; personal data, work history, preferences. If the page becomes unwieldy, you can divide it into smaller parts. Each of the 3 sections could be moved to their own Facelet file and will then be ui-include'ed into the original file.
On the other hand, you might have a specific way to display on image on many views in your application. Maybe you draw a line around it, have some text beneath it etc. Instead of repeating this over and over again you can abstract this to its own Facelet file again. Although you could ui:include it, most people seem to prefer to create a tag here, so you can use e.g. <my:image src="..." /> on your Facelets. This just looks nicer (more compact, more inline with other components).
In the Facelets version that's bundled with JSF 2.0, simple tags can be replaced by composite components. This is yet a third variant that on the first glance looks a lot like custom tags, but these things are technically different as they aren't merely an include but represent true components with declared attributes, ability to attach validators to, etc.