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
Related
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.
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.
Is RactiveJS compatible with JSX?
I'm guessing some of the mark-up is not compatible. I like the thought of strong typing and being able to cleanly write the templates in JavaScript source. Maybe this is considered bad design?
No. React.js and Ractive.js have many similarities (for example, both work by constructing a lightweight virtual DOM in memory), but they have one very major difference - React completely rejects the idea of templates.
Which is to say that JSX isn't a templating language, it just looks like one! In React, if you have something like this...
<h1>Hello world!</h1>
...it gets converted to something like this by the JSX pre-processor:
React.DOM.h1(null, 'Hello world!');
In other words JSX describes functions, rather than templates. In Ractive, by contrast, Mustache templates are parsed into tree-like structures that can be transported as JSON.
Now, in the case of that example it doesn't really matter what process the original string goes through - it's still going to end up as an <h1> element in a browser somewhere. But it gets a lot harder when you start introducing arbitrary JavaScript which refers to this.state and this.props - things that can alter the fundamental structure of a component in React, but which have no meaning in Ractive.
Ractive might support templating languages other than Mustache in future, but JSX is unlikely to be one of them because they have such different approaches and design goals.
However there's a related issue here, which is being able to fully describe components in a single file. There's some ongoing work happening there - the most likely scenario is that we'll be able to describe components in an .html file (since you can use JavaScript and CSS inside HTML) rather than writing the template into your .js file.
my premise was wrong. while AngularJS was certainly slowing things down, it was not due to the problem I describe below. however, it was flim's answer to my question - how to exclude an element from an Angular scope - that was able to prove this.
I'm building a site that generates graphs using d3+Raphael from AJAX-fetched data. this results in a LOT of SVG or VML elements in the DOM, depending on what type of chart the user chooses to render (pie has few, line and stacked bar have many, for example).
I'm running into a problem where entering text into text fields controlled by AngularJS brings Firefox to a crawl. I type a few characters, then wait 2-3 seconds for them to suddenly appear, then type a few more, etc. (Chrome seems to handle this a bit better.)
when there is no graph on the page (the user has not provided enough data for one to be generated), editing the contents of these text fields is fine. I assume AngularJS is having trouble when it tries to update the DOM and there's hundreds SVG or VML elements it has to look through.
the graph, however, contains nothing that AngularJS need worry itself with. (there are, however, UI elements both before and after the graph that it DOES need to pay attention to.)
I can think of two solutions:
put the graph's DIV outside the AngularJS controller, and use CSS to position it where it's actually wanted
tell AngularJS - somehow - to nevermind the graph's DIV; to skip it over when keeping the view and model in-sync
the second option seems preferable to me, since it keeps the document layout sane/semantic. is there any way to do this? (or some, even-better solution I have not thought of?)
Have you tried ng-non-bindable? http://docs.angularjs.org/api/ng.directive:ngNonBindable
<ANY ng-non-bindable>
...
</ANY>
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.