I love Blueprint CSS framework.
But there's something I don't understand about its default form element size.
As you can see at http://www.blueprintcss.org/tests/parts/forms.html , [select] field is considerably smaller than [text] field. I think it's intentional. Do you think it's ok and good? If not, how do you cope with it?
Thanks.
Sam
I put a wrapper around the form elements and set the column size on that, then I set the form elements to be width of 98% of their parent, that gets them just about right with a bit of padding , much more visibly appealing.
Related
I find the concept of atoms and molecules very interesting, but I can't imagin ending up with thousands of atom components, scattered all over the place. Another way of putting the question would be: when is a Vue component getting too big ? Thank you for your input.
Well it depends of a lot things, but if you see the code you're writing will be re-use more than twice i guess, it's a good idea to make as a component.
Additionnally you could think of the fact of clarity, if you're having a lot of html in your component, for readability purpose you could split this component in few pieces.
For example this component i've made, it's a Job offer,
in the blue rectangle we have the acronym of the company hiring
in the dark gray rectangle, the percentage of the the job,
a button to toggle the "card" and show the full job content,
a title of the offer and the deadline for the postulation.
When it's closed
Then when it's toggled
It was kind of a lot of html in the code so beside aving a Job offer component with everything in it, i've splitted it for readibility,
In total there is 5 component inside JobOffers
A button that i re-use everywhere in my website
The JobAcronym (blue rectangle)
The JobMeta (title + deadline + button), the middle of it
The JobPercentage (dark gray rectangle)
The JobContent, (arichtext component),visible when its toggled
Doing so, it could easily be more readable in my code, people knew which part was represented by what just reading the code.
For sure it creates more atoms and molecules, but if you create a directory named JobOffer and you put all your components required intside (appart from the button that is kind of global), it doesn't make your application difficult to read.
Even some component doesn't have a logic behind, like the JobAcronym and JobPercentage, they do contains a lot of html that could make your JobOffer component hard to read if they were inside of it.
To conclude, you really need to choose with your guts, if you see you're having trouble finding where to apply your edit to change some ui, beceause there is a lot of html code, then split it.Even if you won't re-use that component anywhere else.
What's important is the readability of your code, and it's really more easier to maintain.
So when you, or someone else come back in few months to do some updates on it, they won't loose time trying to guess which part belongs where.
I hope it answered your question and cleared some doubts you had :)
I'm new to Office UI Fabric. The Pivot component doesn't seem to behave responsively by default. What would be the recommended way to deal with the Pivot component on small screens? I couldn't find any wrapping features. I tried to figure out if other components like OverflowSet & ResizeGroup could help. However, they don't seem to be the right solution for the Pivot either. Any suggestions are welcome.
I don't think the pivot was ever intended for responsive scenarios (there certainly isn't behavior baked in). But you could use ResizeGroup to modify your pivots if they don't fit. You might truncate text, reduce padding or switch to a dropdown.
Switching to dropdown might be the best idea. Just have a flag in your data that says "renderAsDropdown" and your reduceData just flips 'renderAsDropdown" to true, and your 'onRenderData' just renders a dropdown or a set of pivots. No need to calculate some breakpoint.
In cytoscape.js, I've been using the "breadthfirst" layout and configured it to be directed (the tree is directed downwards).
Here is an example: http://jsbin.com/jekago/1
It works great, however I would like the nodes to be closer together, especially vertically, and if possible without limiting the bounding box.
My node labels can be quite long so I would not mind having them spread apart horizontally.
How can I can achieve this with this layout? If I can't, what are you recommending? Thanks
The layout uses the available space and avoids node overlap. Reduce the available space as desired using the boundingBox, and specify fit: true if you want the graph to take up the entire viewport.
You can alternatively use spacingFactor, but this will not allow for as much control as boundingBox.
You'll have to experiment and see what functions best for your data.
You can use as an example spacingFactor=1.5 to have 1.5x space between the elements regarding to the elements dimension.
The fit:true is also a good idea. This is used regarding the div dimensions.
In conjunction to work nice you have to set properly the minZoom maxZoom of the Cy element. And you can set avoidOverlap: true also .
I explicitly set the line-height property of an <input> element in CSS. But when I check the element in firebug, the line-height value of this element is not what I set in CSS. And it seems that the line-height value has nothing to do with what I set in CSS. What is the possible reason for this?
According to the definition of line-height in the CSS 2.1 specification, it has a specific meaning for block container elements and a different meaning for non-replaced inline elements. I can’t find any statement on replaced inline elements there, and an input element can be regarded as a replaced element, somewhat debatably.
Anyway, odd as it may seem, browsers seem to ignore line-height on input elements. As a workaround, you might consider setting the height property, or setting vertical padding. But the results won’t be consistent across browsers. As a rule of thumb, we should expect the rendering of a text input box to the under the control of the browser, though in some cases some features can be tuned using CSS.
not sure if that was the point but i specified margin, padding and got rid of border, here you got exactly 14px: http://jsfiddle.net/mymlyn/Uq5Tt/2/
if you check the dev tools it is (and was before specyfying the above) exactly 14px:
http://dl.dropbox.com/u/26827941/ScreenShot060.png (chrome dev tools)
http://dl.dropbox.com/u/26827941/ScreenShot061.png (firebug in ff)
the reason in your case might be that your input field has a specified id or class,
<input id="someID"/>
and there is something like
input#someID {line-height: 20px;}
in your css somewhere else, andyou might be trying to change its value by setting
input {line-height: 14px;}
if that was not the case im out of ideas :)
The lineheight wont be rendered in firefox but i think it will be in IE. There's a small trick to do, which is to let lineheight style to be rendered as block elements instead of an inline elements.
For example:
This will not work
span {font-size:12px; line-height:14px}
But this will:
span {font-size:12px; line-height:14px; display:block;}
i guess maybe using javascript im gonna do it.... but if anybody knows a better and faster way to do it .. easily im gonna appreciate any ideas...
thanks!...
this is to make impossible for a user to view badly the page increasing the text or doing something like a zoom in the browsers ...
ive got some QA engineers asking me that .....
thanks!
This is a very bad idea from a usability/accessibility point of view. Please don't do it.
Even if you block that key combination, the user would still be able to increase the zoom level via the "View" menu.
You haven't given a good reason, I doubt there is one, so I agree that you shouldn't do it. It's a fun little challenge though, so I have a possible answer, though I don't really know if it would work.
First, have a font-size: 70% or whatever percent you want in an outermost containing element.
Then, create a dummy testing element with:
display:block;
position:absolute;
visibility:hidden;
font-size:1em;
font-family:Arial;
Find the actual height of the element (say, 25px) and then test it over and over again on a timer (window.setInterval()). If it doesn't match, change the font-size percentage on the outer element until it does.