need help with the discussion since I didn't find the fast answer on that topic through a basic Google search.
I have a project, where I myself did pretty bad CSS architecture, having each website page owning its own stylesheet. It was due to reasons of the MVP and speed, so back then I knew I was doing bad thing, but it was faster than planning everything.
Right now I am refactoring my code, components, and stylesheets. I'm using more general classes and managed almost to clear a few pretty big spreadsheets. Which is good in my opinion.
However, I am in a situation, where for example I need to apply different widths, depending on mobile factor or desktop. And that's basically it.
I have classes like width-100, width-80 - which takes 100 or 80% of free spaces. Have also few for VW just in case.
On desktop I need width-80, on mobile width-100. Create specific class with those specific values for desktop and mobile I don't want (maybe I should). So I use conditional rendering of the classes.
!isMobile ? "width-100" : "width-80"
plus any other classes if needed.
However, I am starting to think which thing is better - conditional class or creating some class with specific values and media queries for mobile?
React doesn't re-render to my knowledge the DOM tree, since V-DOM hasn't changed. Or am I wrong?
What do you think?
Related
When it comes to creating a responsive WordPress Theme, would you say it to be better practice to simply implement something like a Bootstrap feature or would your website perform better if you created separate stylesheets for the different screen sizes and called them accordingly?
Has anyone experimented with both and able to recall any performance differences?
A quick test case shows that Chrome, at least, fetches all the stylesheets no matter what the media query says. This isn't really surprising as users can resize windows. It holds true for device-width as well though.
So there are no savings at all since all the stylesheets are downloaded.
This comes with the additional code of extra HTTP requests.
There are only negative performance implications.
Using feature such as Bootstrap is very useful because it will give you all style-sheets and java scripts and if you want to use another one then you can add them so it will be very useful to you and it also gives many theams which are very good.
I've recently been going over some HTML and CSS stuff to get more into web development, I have been designing sites on and off for a while now and I would love to start actually developing some.
I've seen Bootstrap mentioned so many times all over the internet and I was wondering if someone could help me out and point me in the right direction... I've been learning the fundamentals of HTML/CSS and as I understand it, Bootstrap is a html/css UI framework?
I have my own UI designs in a PSD file, how would I get them to work within Bootstrap?
Is it a matter of slicing up my images and adding custom CSS into Bootstrap?
I know that I am a long way off from this, but this is the type of stuff I want to be doing:
http://heyflat.com/themes/todo/index.html
If you can point me towards the type of stuff I should be learning in order to get there I would much appreciate it, so far I will continue with my html/css stuff but I would love to start using Bootstrap and customizing it seems essential to me for what I would like to be able to achieve...
Thank you for reading :)
Updated
Overall, my process has not changed much except for how I think about converting PSDs to HTML and CSS. I look forward to the day I discover a tool as flexible and comfortable as Photoshop that can output directly to good HTML and CSS. That day has yet to come to me. Here's the process I follow, utilizing Photoshop and Bootstrap.
I find that Photoshop is a great way to imagine, share and iterate over a visual design because it frees me to experiment in ways that are currently either impossible or too time consuming to realize just with HTML and CSS.
Once a design is agreed upon, I begin planning how the target design will be realized with HTML, CSS and JavaScript.
I consider the browsers of my target audience. For example, IE8-, does not support rounded borders. If IE8- users are a large portion of my audience and those rounded borders are critical to the design I may take the time to slice out images and add extra HTML and CSS.
I decide if I am going to use a framework like bootstrap. Browser support must also be considered when deciding on a framework. If a framework has examples like bootstrap then I can checkout those examples in various browsers. If using a framework then I commit to doing it their way. That is, I use their grid system, html and class names for everything. I only add my own when the framework cannot meet a specific need. I do augment their classes as needed using a separate stylesheet but always in appropriate, low risk ways, bootstrap encourages this. I will probably never augment the grid system except perhaps through their customizer, but I have never needed to do that.
Next I implement the design. I may find that some elements need to be sliced out of the PSD, but most, like drop shadows, rounded borders and gradients, can be rendered using CSS. Some aspects of the PSD may need to be tweaked to accommodate responsive behavior or to make implementation simpler. As has always been the case, I target standards compliant browsers first and adjust for the others later. One of the nice parts about a good framework is that there is usually very little that needs tweaked.
I review the document at various resolutions in browsers my target audience use, and consider and implement additional tradeoffs as needed. For example, if it is not critical that those rounded corners show up in IE8- then I will keep it simple, render them using CSS, and let IE8- alone. I still verify that it looks acceptable in IE8 and IE7.
Steps 4 and 5 are generally not sequential but steps I bounce back and forth on. Also, make sure your client is on board or you can get them on board with how you are supporting various (not-so-modern) browsers and your reasons for doing so (shorter load times, less development time, easier maintenance, and so on).
Bootstrap 2 examples: http://getbootstrap.com/2.3.2/getting-started.html#examples
Bootstrap 3 examples: http://getbootstrap.com/getting-started/#examples
There's a general consensus that using tables for layout in HTML should be avoided. But there are exceptions to every rule. I am designing an SPA (single page application)—with pages that resemble the layout used by a desktop application.
Obviously HTML isn't well equipped for these types of pages, but I have little other choice. Implementing these layouts with DIVs is pure hell, requiring a mix of CSS tricks, hard-coded values and even JS calculations on resize events. I've recently asked this question about implementing these layouts using a grid framework.
But then I stopped to reconsider whether a table-based layout might be appropriate. The typical criticisms don't seem to apply to the unique case of an SPA:
Separation of content from layout—Since an SPA is not really content (it's just a skeleton with AJAX filled data), this argument doesn't apply. This is just an interface; I don't expect Google to index it.
Tables are less maintainable—Not in this case. The CSS hell you have to go through to implement this with DIVs has a much higher maintenance cost.
Tables are slower to render—Of course, but the complex layout we would be creating using alternatives would require even more calculations to render than tables. Heck, we usually compensate for the inherent limitations using JS resize events. It would be much more efficient for the browser to do this natively inside the rendering engine.
In light of these arguments, are table-based layouts appropriate in the specific case of SPAs, or am I failing to consider some other important factors? Is there an even better option?
People used to be wrong about tables. Many people, who knew nothing, pushed for non table layout, event though it didn't make any sense at all at that time, especially when there was still ie5+6 to worry about. There were many misconceptions, eg. that google cares about semantic code. It never has, and it never will, because people get it wrong, and you can not account for it.
However, now, finally there is an actual reason not to use tables:
Media Queries and responsive Design
In responsive design, if you have 2 columns, it makes sense to drop one column to the bottom on small screens. For example, several columns can become a single column on a phone screen.
You can not do this with tables.
This, in my opinion, is the single most important problem with tables. Most other arguments are nothing more than mental masturbation.
There are other layouts, like masonry (see e.g. http://masonry.desandro.com/), which I think would be hard to achieve with tables alone. But for the classical problems of full height columns, tables were the right solution, even though most people preferred horrible workarounds, adding a ton of fragile markup and css just to fake a table.
Now, however it's different, as a table doesn't give you the flexibility you need for responsiveness.
What is your preferred approach when creating websites :
Make effort so pages looks exactly the same on every browser ? or
Let the browser apply its default stylesheet on some specific objects like inputs, borders, colors, etc. ?
The first solution is obviously what we would naturally have in a perfect world, but require a lot more work, CSS hacks, browser specific stylesheets and so on.
Is it what webdesigners should tend to do ?
About the second one, I'm thinking about forms, disabled elements, colors sometimes, table's header and footer... It is a lot easier to let the browser handle it and has the advantage of being consistent across websites for the user.
Is it a good practice or I am being lazy ? How to "sell" this solution to a client that don't care about those considerations ?
I'm looking for the pro and the cons of each method.
How to choose between one and another ? Where is the limit ? (How about : stick to the W3C standards and let the browser handle the rest ?)
The art of web design is to work within the constraints of the medium, of which there are many, and still come up with something 100% functional across many different platforms. It is a challenge to make your pages look good and function completely across all browsers at multiple screen sizes, resolutions, cultures, languages, connection speeds, accessibility issues, etc., If you can just accomplish "not broken in IE" that is something.
Of course I want it to look like it did in Fireworks, but that is not a realistic target. Every single machine is different, so every view of your page will be too.
You some CSS framework like Twitter Bootstrap Or Blue print. There are actually Many out there. Then if you are writing custom CSS I would recommend you to use CSS Preprocessors.
List of CSS Frameworks
List Of CSS Preprocessors
http://twitter.github.com/bootstrap/
Since Twitter Bootstrap and many in the list cover responsive designs too so you dont need to rework for Tablets and other Equipments.I hope this list will get you started.
As a developer you would want a consistent look across all browsers. You don't want to have a lazy attitude as you suggested!! That is a terrible habit for a developer and leads to poor quality products.
Familiarize yourself with the different frameworks out there that address cross browser issues. Twitter bootstrap and jQuery are a great place to start. Also get to know the different browsers and understand what they support and what they don't, so that when you are coding you can avoid certain things!
While most web designers desire consistency across browsers, there's nothing inherently "right" about it being so, and in practice it depends on the nature of the web pages you are creating.
In particular, total consistency runs contrary to the principles of Progressive Enhancement and Responsive Web Design. There's no golden rule, do what's right for your client in each situation.
Forgetting about things that pertain exclusively to the developer like code maintainability and religion wars about semantics and what-not, my question is: what real world problems does using tables present to the user? Are there device that cannot understand a tabled layout properly? Does it decrease the page's relevance on search engines?
Of course I'm talking about a reasonable layout where tables are only used for things that in pure CSS/divs require hacks (and for tabular data obviously) -- not things like a hundred nested tables maybe even used instead of ul/li.
User agents (aka browsers) for the visually-impaired may use spoken descriptions of a webpage.
When the layout is done by table, the description of the page contents becomes a description of the table, which is unlikely to help understanding.
Tables are such old technology that they are reliably rendered on every device and in every program I know.
I am not encouraging the use of tables for layout unless really, really necessary (which it is in a few cases), but I do not believe a well done layout using tables for some aspects does automatically affect rendering negatively. Feel free to prove me wrong, though.
There may be problems for text to speech programs when a table is used instead of the semantically correct element, e.g. in ordered/unordered lists. But I believe that any text to speech or other accessibility software has provisions for this, otherwise it would not be usable on today's Internet.
There may also be cases in which a browser that needs to intelligently resize a web page (e.g. a mobile browser) has more trouble with tables than with other layout elements. But that depends very much on the individual layout and situation.
Here's a nice presentation that sums up the problems with tables pretty well: http://www.hotdesign.com/seybold/06problems.html
The main end-user argument I have about it is future-proofing, and page size (which relates to load time, which relates to user experience). If you are designing a page semantically, and using the minimal markup approach, then page sizes w/o table-based layout are almost always smaller than pages that use a table-based layout.
That's more bits on the wire on every request for that page, which (as stated) means longer load times, etc. min-html + external CSS sheet, however, works out to markedly faster load times for most production sites (see Yahoo's YSLOW guidance) due to the fact that there's usually a one to many relationship between CSS sheets and pages, which means that you are taking advantage of browser's caching capabilities (and potentially other intermediate devices caching as well).
The future-proofing comment is related to design changes. It's much easier to effect wholesale visual layout redesign from CSS with a min-markup page than it is to do so in most common table-based designs. See csszengarden.com for examples.
Obviously, YMMV in both cases. If you're really making the minimal use of tables (e.g. one table on a page, one row in that table, three TDs in that row, one for each column), then you probably don't have to worry about those things. That said, ime, it's better to learn the CSS techniques, or pay someone who knows them. Designs quickly become more complex than you think they will up front many times, and using tables as a quick fix soon becomes a slippery slope. Again, all said IME; YMMV.