101–110 of 120 posts
So, I’m an experienced backend dev, who only occasionally dabbles in frontend. And whenever I do, my CSS experience is basically: https://media1.giphy.com/media/13FrpeVH09Zrb2/giphy.gif I’d like to fix that, and learn CSS well. I’m not looking for a quick zine like this, more of an in-depth course, say roughly 5-10 hrs. Ideally free, but I’d pay if it’s good. Anyone have any favourites?
While I haven’t read this one just yet, I’ve found all of the author’s previous zines incredibly useful. They’re densely packed with information, presented in a way that makes them great quick reference material. My only wish is that someone could print and bind them into a book.
in case you haven't seen it: No Starch Press published a box set of all my free zines called "Your Linux Toolbox". I have some links to places you can get that here: https://jvns.ca/blog/2019/10/21/print-collection-of-my-first...
Earlier quoted context omitted.
But HTML doesn't say anything about how things need to be rendered / presented. It was never intended to do that. All it does is mark the structure in a document. "This is a header", "this is a paragraph", "this is a quote". That's basically it. The "hypertext" part of HTML refers to the notion that it uses URI's that can be used to identify resources, and dereference them. It's entirely up to the consumer of a HTML…
HTML absolutely used to “say how things needed to be rendered”: with tags like B, I, FONT and so on. It was developed when documents were expected to be WYSIWYG-style markup (Word/WordPerfect, Latex, etc). CSS was designed to strip that away only after people decided the future of hypertext should look more like XML. In doing so, they added the constraint that you should be able to get completely different outputs de…
Yes, those tags do exist. However, their story is more complex, and intertwined with the rocky road towards standardization. And their importance gets easily overstated, even though they were a boon for budding website builders dabbling with HTML in the late 1990's. [0]
These didn't exist in the original HTML document as drafted by TBL. They were tacked on in what we know as HTML 2, which wasn't an W3 recommendation but an IETF RFC. [1] They were kept in HTML 3.2 which is the first formal W3 recommendation recognized as a standard in january 1997. [2]
HTML 4.01 deprecated FONT, CENTER, U and STRIKE in december 1999, barely 2 years later. [3] At the same time, HTML 4.01 introduced and promotes the use of stylesheets for presentational purposes to overcome the limitations of HTML. [4]
> Style sheets represent a major breakthrough for Web page designers, expanding their ability to improve the appearance of their pages. In the scientific environments in which the Web was conceived, people are more concerned with the content of their documents than the presentation. As people from wider walks of life discovered the Web, the limitations of HTML became a source of continuing frustration and authors were forced to sidestep HTML's stylistic limitations.
> ... Style sheets solve these problems at the same time they supersede the limited range of presentation mechanisms in HTML.
Moreover, the use of the elements that weren't deprecated - I, B, BIG,... - was discouraged by the HTML 4.01 specification itself in favour of stylesheets. That's since December 1999. [5]
> The following HTML elements specify font information. Although they are not all deprecated, their use is discouraged in favor of style sheets.
Also, I would have to disagree with this:
> CSS was designed to strip that away only after people decided the future of hypertext should look more like XML.
The development on XML happened at the same time as HTML and CSS. XML was first published in February of 1998, well after HTML 3.2 and before HTML 4.01.
However, XHTML 1.0 was based of HTML 4.01 and was basically a transposition of HTML 4.01 using XML. XHTML 1.0 only became a W3 recommendation in January 2000, well after HTML 4.01 and XML were first published. [6]
Moreover, CSS 1 was first published in 1996, CSS 2 in May 1998. The first draft of XHTML only was published in December of 1998, well after CSS was established. [7]
My point is that all of these technologies were developed by committee. In separate Working Groups, which didn't necessarily align their efforts. That's basically why the road towards convergence was - and to a degree still is - this rocky.
And all of that is discounting the browser wars with vendors such as Microsoft applying their own interpretation of the specifications in their engine.
[0] http://www.martinrinehart.com/frontend-engineering/engineers... [1] https://www.ietf.org/rfc/rfc1866.txt [2] https://www.w3.org/TR/2018/SPSD-html32-20180315/#body [3] https://www.w3.org/TR/html4/appendix/changes.html#h-A.3.1.2 [4] https://www.w3.org/TR/html4/present/styles.html [5] https://www.w3.org/TR/html4/present/graphics.html#h-15.2 [6] https://en.wikipedia.org/wiki/XHTML#XHTML_1.0 [7] https://en.wikipedia.org/wiki/CSS#Variations
hey, author here. I always find it weird to see HN posts where you have to pay to read what it says (what's the point?) so here are 6 sample pages from the zine if you're interested in seeing more of what's in it: * CSS isn't easy: https://wizardzines.com/comics/css-isnt-easy * Inline vs block: https://wizardzines.com/comics/inline-vs-block/ * Specificity: https://wizardzines.com/comics/css-specificity/ * Centering:…
I wrote a (much shorter) article in a similar vein a few years ago: https://css-tricks.com/css-is-awesome/ I find it fascinating (saddening, but fascinating) that so many programmers are so turned-off by CSS and find it so unintuitive. I almost want to set out on a research project to figure out why that is. My experience with it couldn't be more different. Here's one way of looking at CSS (which I didn't think of un…
I'll bite. I'm not a fan of CSS. I learned it well enough to build a decent UI toolkit (draggable modals, collapsible, etc.) I hate how CSS tries to mix layout and style. A million articles about not using tables for layout, and it took 20+ years to get a grid. I tried to do some fancy text and element alignment with CSS, and it was not having it (and, yes, I know about display: table). In the end I reverted to a tab…
I find that designers who create their own CSS are pretty rare. Most times I've seen frontend developers slice up designs. I think you need to have a workflow to do this properly. I needed someone to show me how to do it and I often preferred to just use an open source CSS lib like Bootstrap.
So, I’m an experienced backend dev, who only occasionally dabbles in frontend. And whenever I do, my CSS experience is basically: https://media1.giphy.com/media/13FrpeVH09Zrb2/giphy.gif I’d like to fix that, and learn CSS well. I’m not looking for a quick zine like this, more of an in-depth course, say roughly 5-10 hrs. Ideally free, but I’d pay if it’s good. Anyone have any favourites?
- browser incompatibilities (Last bug I fought: top/left/right/bottom behave differently in Chrome vs. Firefox when `position: sticky`. Fantastic.)
- messy refactorings: Sure, CSS3 variables are nice but you can still tell that they were bolted onto the language. Moreover, elements and their rules can interact in lots of ways and CSS code (especially code by other people haha) often doesn't make these interactions immediately clear. Besides, everything is global state and IDs and classes are the only way modularize CSS code.
- the fact that it's impossible to use HTML only for semantics and do all the layouting in CSS. (Wrapper divs, I'm looking at you!)
- weird precedence of CSS rules / specificity (https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity)
- missing type separation and missing type checks. All CSS properties live in the same namespace and may or may not interact with one another. For instance, top/left/bottom/right, margin etc. behave completely differently depending on what you set `position` and `display` to.
Things are getting better with web components now but I'm still not sure I'll ever be entirely happy with CSS.
Earlier quoted context omitted.
For layout?? Burn the heretic! [1] The real reason we don’t use tables for layout (and only for the occasional tabular data) is because a table layout doesn’t work really well on the screen of an iPhone or Android phone, especially when they are vertically aligned. So, the workaround is to use media selectors: Desktops, laptops, and tablets get a table layout; phones get a simpler one-column layout. I believe grid an…
I think the don't-use-tables argument is from way before mobile devices were something web developers cared about. I recall it as being mostly about semantics, i.e. tables should only be used for tabular data, not setting up the layout of your entire page.
I wrote a (much shorter) article in a similar vein a few years ago: https://css-tricks.com/css-is-awesome/ I find it fascinating (saddening, but fascinating) that so many programmers are so turned-off by CSS and find it so unintuitive. I almost want to set out on a research project to figure out why that is. My experience with it couldn't be more different. Here's one way of looking at CSS (which I didn't think of un…
Them: CSS is unintuitive. You: Learning CSS is like taming a wild horse. I think you are in agreement.
The idea is that to some people, having total control and building something up piece by piece comes totally naturally, while understanding and then selectively guiding a thing that has a will of its own does not, even if in some since it's more "elegant"
hey, author here. I always find it weird to see HN posts where you have to pay to read what it says (what's the point?) so here are 6 sample pages from the zine if you're interested in seeing more of what's in it: * CSS isn't easy: https://wizardzines.com/comics/css-isnt-easy * Inline vs block: https://wizardzines.com/comics/inline-vs-block/ * Specificity: https://wizardzines.com/comics/css-specificity/ * Centering:…
PS Separately, if you ever felt like it, it would be lovely to have a poster (or similar short thing in your style) about CSS Selectors specifically, to give to our customers. (To use our stuff, it's good to know about selectors but don't need to know about styling/positioning and such.)