41–50 of 54 posts
I hate asking to be spoon-fed, but I find it exceptionally difficult to glean anything from context-free slide decks posted to SlideShare. This deck was clearly intended to augment a presentation -- where is that archived?
Earlier quoted context omitted.
I liked the presentation, she clearly knows CSS well, but do count me amongst those that did not buy in to her theory. I've seen plenty of horrific stylesheets and seen some that over time turn into incomprehensible messes, but I didn't see in this presentation any real connection from follow best practices, result in unmaintainable CSS. It just doesn't follow. That some coder come-lately can get in there and instead…
I think it comes down to a workflow thing - the reason the coder-come-lately comes in and messes with css in such an annoying way is because its just scary as heck to 'refactor' css in a way that you can be confident about (ie the exact opposite of working with good application level code, with good test coverage).. So, let's say you (or your team) is tasked with 'add a new calendar widget to the right column'. What…
a) back-end developer who provides the controller, model and a shell view (this could be anything from a basic HTML structure through to raw JSON)
b) front-end developer who has responsibility for building sane markup and clean CSS. It’s in their best interests to keep the styles maintainable: a little extra time writing markup that integrates into the existing styles and refactoring existing CSS to cope with the new modules is worth it in the long run.
She says we shouldn't blame the language, but how much of this is because CSS eschews Composition for (incomplete) Multiple Inheritance? And how much of the extra code is an effort to avoid bugs because layout properties are non-orthogonal? At what point do we decide that it's not that "you're doing it wrong", but that there were actually some design choices that, in retrospect, maybe weren't such a good idea? I'd sa…
"much of this is because CSS eschews Composition for (incomplete) Multiple Inheritance?" Pretty much all of it. I remember being a bit surprised when they first released CSS at just how impotent it was. Over a decade later, I now realize my younger self would have gotten himself stuck in a morass of Turing completeness, but CSS goes too far the other direction. Decoupling styles (which may contain several rules) from…
If you want something accessible with a "modern" JavaScript-based web application, you're almost bound to rewrite most parts of the interface for a pure HTML version, if at all possible and/or desirable. Quite often less effort than jumping through hoops to have something that degrades gracefully.
Now I think this will only get worse. At one point in time, it might be better to regard HTML as the Gopher of its time and consider a next step. Probably won't ever happen, as the sheer ginormous size of the "legacy" web makes any endeavors in this direction almost futile.
Does anybody remember PostScript-based GUIs? We're throwing a lot of barely-connected ideas and syntaxes into a browser to emulate NeWS/DPS -- poorly.
My main rule is: Never write a class that you can't use again. I've other rules too, such as "padding is top, margin is bottom". CSS must be modular, not exception-based.
That's interesting. I've always wondered if some people had conventions on when to use padding and when to use margin, since you can almost always accomplish the desired effect either way.
Earlier quoted context omitted.
That's interesting. I've always wondered if some people had conventions on when to use padding and when to use margin, since you can almost always accomplish the desired effect either way.
You can't really. CSS backgrounds are the main reason you need to use padding (instead of margin): margins exist outside an element, while padding expands within the box itself (beyond the content, but permitting the background to remain visible). To visualize it, http://hicksdesign.co.uk/boxmodel/ is probably the most oft-cited example - certainly the one I find most helpful.
My main rule is: Never write a class that you can't use again. I've other rules too, such as "padding is top, margin is bottom". CSS must be modular, not exception-based.
When you have complex pages, with several nesting levels, this can save much, much time.
I hate asking to be spoon-fed, but I find it exceptionally difficult to glean anything from context-free slide decks posted to SlideShare. This deck was clearly intended to augment a presentation -- where is that archived?
Earlier quoted context omitted.
I liked the presentation, she clearly knows CSS well, but do count me amongst those that did not buy in to her theory. I've seen plenty of horrific stylesheets and seen some that over time turn into incomprehensible messes, but I didn't see in this presentation any real connection from follow best practices, result in unmaintainable CSS. It just doesn't follow. That some coder come-lately can get in there and instead…
I think it comes down to a workflow thing - the reason the coder-come-lately comes in and messes with css in such an annoying way is because its just scary as heck to 'refactor' css in a way that you can be confident about (ie the exact opposite of working with good application level code, with good test coverage).. So, let's say you (or your team) is tasked with 'add a new calendar widget to the right column'. What…
Even if you are not - dont they accomplish the same thing ?
My main rule is: Never write a class that you can't use again. I've other rules too, such as "padding is top, margin is bottom". CSS must be modular, not exception-based.
Another best practice I have is to place a comment on each closing element, referring to the opening one. So,I have: CONTENTCONTENTCONTENT When you have complex pages, with several nesting levels, this can save much, much time.
Now you've got comments saying in correct things, and you risk all sorts of confusion.
The same rule applies to commenting methods in code really, you don't comment what the code does exactly - just what the intention of the code is.