In my app there's a page where I am showing several snackbars depending on results from server.
There can be several triggered by the server's result. They are also triggered from different components, so I don't have a single controller that could render them where I want.
So, they all display at once and overlap each other. I linked the official Vuetify docs page because the problem is clearly visible there. Just click on two of the buttons in short enough succession.
Is there any way I could render them such that they would stack one above the other instead of all bottom-centering over each other?
I was thinking I'd need a way to tell them the component that would be their rendering parent. But I can't seem to find a way to do this. Slots don't seem to be much help with this either since I can't declare global ones.
Is there any way I can do this?
My problem is the next:
I have a table in which I store information, by clicking on a row there will be a window in which I show that information in a certain format.
The problem I have when I try to make the table responsive because when trying to see it on small devices I have to do side scroll. I tried to hide columns with "display: hidden" but the data I can not retrieve, beacuse it not exists.
How can i do this?
Do yourself a favor - do not reinvent the wheel and use a specialized library, for example Datatables. At the very least, take a look at how datatables makes the table responsive.
You have not mentioned it, so I assume you are ok using jQuery, Bootstrap 3 or 4, Semantic UI or Foundation. For React / Angular there maybe other options.
Here is my problem:
I typically have a paginated datagrid with a lot of rows. I want to be able to edit the data for each row of course but I have 2 constraints on this:
I need the edition form to replace the content of the page (I don't want a popup, modal dialog or side panel)
I don't want to lose the state of the datagrid: maybe I navigated down 5 pages in the datagrid and I don't want to be reloaded on the first page. And actually, I'd rather not reload the data I already had (the edited data will be updated automatically by my persistence layer anyway).
Ideally, I would have liked to have some kind of subrouter but I'm not sure how it would fit the first requirement. Otherwise, I could have a component that would be hidden by default and positions itself on top of the datagrid view when necessary but that feels quite hacky and forces me to have everything in the same template. And I will have to handle a stack of these components if I have several different 'full-screen panel'...
Any idea on a correct way to implement this?
Thanks!
I tried different solutions to no avail unfortunately. I had a long discussion with #Kukks on gitter and we agreed that using subrouters and viewports might be a bit overkill for my use case.
I reverted to my original idea of using absolutely positioned components to hide the previous one in a kind of "deck layout". This is not ideal as I would have liked completely separated views and using components forces me to declare them in the main view but it works well and is very easy to implement...
So: not as clean as I would have liked but much easier to implement and less convoluted.
Consider using Router View Ports
http://aurelia.io/hub.html#/doc/article/aurelia/router/latest/router-configuration/9
We have implemented checkbox in popover. There we are using checked.bind , but in the view model its not reflecting its value on change of the checkboxes.
Sample Gist Run Provided below:
Gist Run
Thanks in Advance
Programmatically injected HTML needs to be compiled manually
The integration with bootstrap I provided to you earlier cannot do this. The bootstrap plugin assigns the innerHTML property of the popover and it does this outside of aurelia's rendering pipeline. The HTML is therefore not compiled by aurelia, which is why bindings (and other aurelia behaviors) will not work.
The templating framework takes care of this for you automatically as long as you are following conventions (such as custom elements). In any other case you'll need to manually work with the ViewCompiler.
In case you're interested, you can see an example with programmatically generated HTML in this gist. Also see this question if you want to know more about it. I do not recommend it in this scenario however.
Use aurelia-dialog
A tooltip (or popover) is just that: a tip on how to use the tool. It should not need more than some plain markup, text and styling (of course this is subjective to some degree, and some people may disagree)
For collecting user input in-between pages or screens, I'd argue a modal dialog is a better fit because of its property to "pop out" more and to de-emphasize the rest of the screen until the user either proceeds or cancels.
More importantly, by using aurelia-dialog your bindings and behaviors will simply work because, well, it's an aurelia plugin :-)
I am new to HTML5 and am wondering which HTML5 tag should be used on a Call to Action div that sits in a column next to the main content on the home page.
Option 1:
<aside>
//call to action
</aside>
Option 2:
<article>
<section>
//call to action
</section>
</article>
The reason I ask is because I don't see either option as being a perfect fit. Perhaps I am missing something. Thanks!
My HTML for the Call to Action:
<section class="box">
<hgroup>
<h1 class="side">Call Now</h1>
<h2 class="side">To Schedule a Free Pick-Up!</h2>
<ul class="center">
<li>Cleaning</li>
<li>Repair</li>
<li>Appraisals</li>
</ul>
<h3 class="side no-bottom">(781) 729-2213</h3>
<h4 class="side no-top no-bottom">Ask for Bob!</h4>
</hgroup>
<img class="responsive" src="img/satisfaction-guarantee.png" alt="100% Satisfaction Guarantee">
<p class="side">We guarantee you will be thrilled with our services or your money back!</p>
</section>
This is a box on the right column of a three column layout. The content in the large middle column gives a summary of the company's services. If you wanted to use those services, you would have to schedule a pick-up, hence the call to action.
Does anyone object to this use of HTML5, or have a better way?
My take is that the best practices for the new HTML5 structural elements are still being worked out, and the forgiving nature of the new HTML5 economy means that you can establish the conventions that make the most sense for your application.
In my applications, I have separate considerations for markup that reflects the layout of the view (that is, the template that creates the overall consistency from page to page) versus the content itself (usually any function or query results that receive additional markup before being inserted into the various regions in the layout). The distinction matters because the layout element semantics (like header, footer, and aside) don't really help with differentiation of the content during search since that markup is usually repeated from page to page. I particularly favor using the semantic distinctions in HTML5 to describe the content the user is actually searching on. For example I generally use article to wrap the primary content and nav to wrap any associated list of links. Widget wrappers are usually tied to the page layout, so I'd go with the convention of the template for that guideline.
Whenever I have to decide on semantic vs generic names, my general heuristic is:
If there is a possible precedent already in the page template, follow that precedent;
If the element in question is new part of the page layout (vs a content query that is rendered into a region in the layout) and there is no guiding pattern in the template already, div is fine for associating that page layout behavior to;
If the content is created dynamically (that is, anything that gets instanced into the layout at request time--posts, navigation, most widgets), wrap it in a semantic wrapper that best describes what that item is (vs how you think it should appear)
Whenever authoring or generating content, use semantic HTML5 markup as appropriate within that content (hgroup to bracket hierarchical headings, section to organize chunks within the article, etc.). This is future-proof enrichment for search.
According to all this, div would be fine as a wrapper for your widget unless your page template already establishes a different widget wrapper. Also, your use of heading elements for creating large, bold appearance within the widget is using markup for appearance rather than for semantics. Since your particular usage is appearance-motivated, it would be better to use divs or spans with CSS classes that can let you specify sizes, spacing, and other adornments as needed for that non-specific text rather than having to override the browser defaults for the heading elements. I'd save the heading elements for the page heading, for widget headings, and for headings within the primary content region of the page. There can be SEO ranking issues for misuse of headings that are not part of the main content.
I hope these ideas help in your consideration of HTML5 markup usage.
So far as the semantics of the markup go, Don's advice makes sense. (As you said your CTA was visually beside the main content and secondary to that content, I would favor aside, but there's no single correct answer.)
However, you've tagged your question with "seo," so I take it you're interested in the SEO benefits of using the right markup. At this time, Google doesn't give special weight to having nice, semantic markup---they don't care about the difference between things like aside, section, and div. This may be partly because the meaning of these tags is still being defined (by the practice of Web devs), but they even seem to ignore tags that are clearly relevant search results (like nav, which will almost always be irrelevant to a page's description in the search results).
Instead, they heavily favor using microdata for marking up rich semantics. In the short term, marking your page up using the Schema.org WebPage microdata will likely provide greater benefit. You can mark your CTA as a relatedLink or significantLink, and keep it outside the mainContent of the page. If you're looking to optimize your page for search, this is a great way to do it---in my experience, Google very rarely shows text outside of your mainContent block in the search results description.
Proper markup depends on the actual content, which you have not provided.
That said, wrapping everything in a div is fine (although perhaps unnecessary) no matter what your content is as the <div> tag has no semantic value. Your two examples are probably not correct, unless your "call to action" is literally an entire article (which I doubt is the case).
The call to action might occur within an <aside>, but it's not likely that the call to action is the aside itself. Once again, that depends on the content (what it is) and context (where it is in relation to other content).
Typically "call to action" is a link somewhere, so the obvious answer to me is using an anchor, <a>.
It's just a link to another page. Use a div.