Learning HTML and CSS

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: Learning HTML and CSS

Postby ahammel » Sat Feb 21, 2015 5:32 pm UTC

styrofoam wrote:Also, you can configure the style for <B> tags anyway. It's considered really weird, but it works exactly the same way as styling <STRONG>.
I think it's idiomatic in HTML5, where <b> and <i> don't necessarily mean bold and italic. But I'm a back end guy, so what do I know?
He/Him/His/Alex
God damn these electric sex pants!

User avatar
Xanthir
My HERO!!!
Posts: 5334
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Learning HTML and CSS

Postby Xanthir » Sun Feb 22, 2015 12:57 am UTC

King Author wrote:Why use <strong> over <b> though? Just because it's CSS-configurable? I don't see the difference or advantage. (Surely, readers for the blind either take into account <b> in addition to <strong> or can be configured to do so. Stuff like user-content on forums like this would be sorely unreadable if <b> couldn't be given the emphasis by reader programs that <strong> is.)

CSS doesn't give a flip whether the element is called "strong" or "b". Both of them are styled by the browser with a "font-weight: bold;" and that's it.

You use <strong> over <b> to communicate the correct semantics. <strong> is strong importance. <b> is "anything else that is typically conveyed typographically with a bold face". Conveying good semantics helps machines understand the page, such as spiders and screen readers.

styrofoam wrote:Actually, double-checking the docs for my friend's screen reader, it ignores all emphasis and just deadpans everything.

That's a pretty crappy screen reader. I know that at least some of them emphasize properly.

It's not intuition, it's experience. When writing the html docs for my personal website, I find it much more cumbersome to use CSS than not, principally, I think, because my site isn't top-down structured, each page is pretty off-the-cuff. So every tiny little thing I want to do I'd have to go edit a CSS file to add something to use it, whereas with inline HTML I can just type whatever I want (a colored word, an underline, what have you).

If every single page you write is totally different and unique, and most of the overall page styling is just the browser defaults anyway, then you do indeed get very little from pulling your style out into some CSS.

I've been a webdev for a long time, though, and even for one-offs I typically find it easier to put most of my formatting into a proper CSS block. It doesn't have to be an external CSS file; an inline <style> element often serves, and in fact that's how I usually handle page-specific styling, as it doesn't benefit from being cached separately from the page content. It's just plain not very common for me to have a bunch of actually uniquely-styled elements, so using CSS saves me some typing, and in the rare cases when I *do* have something unique, it still gives me "cleaner" markup to separate styling and structure.

With CSS, you can't really design-as-you-go, everything has to be rigorously planned out from the beginning.

This is the opposite of true. Virtually all of the CSS I've ever written has been done piece-by-piece as I needed it. With larger projects I'll do some planning beforehand, but that's true in general - you generally design the template before you design the content.

But for me personally, having to go through the CSS rigamarole when I could just <font color="#ff0033"></font> something isn't worth it.

Again, if this is literally a one-off, just a single phrase that you're styling red for unique reasons, sure, do whatever. (Though there might be better element choices to use for better semantics, so you can move the coloring into a style="color:#f03" attribute.)

That's not true for the vast majority of websites, though. Usually it's "I want all my important terms red", so then you can use some CSS to say "strong { color: red; }" and bam, you don't have to think about the styling any more. Or "I want to underline all my <dt>s", so "dt { text-decoration: underline; }" once, rather than <dt><u>...</u> every time.

Yes, if by "clashing" I mean the code looks gross next to each other, which is indeed what I meant. But CSS has the added strike that it's ugly and inelegant.

That's just, like, your opinion, man. ^_^

I'm probably a little biased (I wrote the Syntax spec and one of the few standards-compliant CSS parsers in existence), but CSS is a perfectly elegant language. It's got a consistent, simple tree structure (there are two types of blocks, which can contain either more blocks or a list of declarations, and that's it), and a syntax in the same rough family as JSON and many other languages. Its use of custom grammars for all of its properties/etc makes it a little more complicated to learn, but keeps it much more compact and easier to read/write than if it was more strictly regular.

I read that but I don't understand what you meant. Imagine on my personal website of about two dozen pages, on a single page, in a single paragraph, I want a single word bolded. What's the "proper" way to do that? Because I can't think of how not using <b></b> is anything but hollowly principled.

I... don't understand. The post I was referring to literally said "There is nothing wrong with <b>". That's a direct quote of its first sentence. How did you manage to read the exact opposite?

If the word matches the semantics of <strong>, you should use <strong>, but otherwise, just use <b>. That's what it's there for.

It *is* saying that, for example, if you're defining a list of thing with a <dl>, and want all the terms bolded, you should use "dt { font-weight: bold; }" rather than putting a <b> inside of every single <dt>. The latter is quickly more verbose (7 characters each time, versus 25 for my well-spaced CSS), makes your code uglier (the <b> isn't communicating anything, it's just junking up your content), and makes it more annoying to change styling later, if you ever want to.

Ultimately, though, there's a significant gray area that's up to personal code formatting taste. Some people are totally okay with inconsistent indentation/spacing, or using slightly different declaration styles in different parts of their code, while others prefer keeping their code "cleaner" and more consistent. If you're don't think cleaning things up is worth it, then don't. It's your code, you're the one that deals with it, so it's your call to make. The rest of us will just judge you for it, like I judge everyone who uses spaces for indentation. ^_^
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
King Author
Posts: 736
Joined: Sun Apr 12, 2009 12:30 pm UTC
Location: Pennsylvania, USA

Re: Learning HTML and CSS

Postby King Author » Sun Feb 22, 2015 12:01 pm UTC

I changed my mind, I like CSS now 'cause I realized I could use it for something neat: re-applicable stylization. Like, I could make "newspaper.css" which is configured to make a webpage look like a newspaper, and "dos.css" to make it look like an old DOS screen, and just apply those CSS files to whatever page I'm working on as quick as anything.

I'm still using inline <b> tags, though, because I have yet to be given any good reason not to, and anyone who gives me crap for it can kindly fornicate themselves.

styrofoam wrote:
King Author wrote:Why use <strong> over <b> though? Just because it's CSS-configurable? I don't see the difference or advantage. (Surely, readers for the blind either take into account <b> in addition to <strong> or can be configured to do so. Stuff like user-content on forums like this would be sorely unreadable if <b> couldn't be given the emphasis by reader programs that <strong> is.)


Actually, double-checking the docs for my friend's screen reader, it ignores all emphasis and just deadpans everything. It's the page structure tags that really matter. Use semantic headers (that is, <H1> / <H2> / etc), image ALT text, <TABLE>s for semantic markup only, and proper form element labels (<LABEL FOR=xyz>xxx</LABEL> <INPUT ID=xyz>).

Also, you can configure the style for <B> tags anyway. It's considered really weird, but it works exactly the same way as styling <STRONG>.


Does it mention when a header is a header? Like will the program say, "Headline: My Favorite Bazooka Joe Comics" for <h1>My Favorite Bazooka Joe Comics</h1>? 'cause I hate using header tags but I'll use them for accessability's sake.

I still don't understand why to use strong instead of b.

And what do you mean to use tables for semantic markup only? As opposed to using them for what? Making tables? Formatting?

EDIT: Oh, noooo! I've been using htmldog and it's great, but I just came across THIS abomination...!

http://www.htmldog.com/guides/html/beginner/images/

"A GIF (pronounced “jif”) can have no more than 256 colors [...]"

I thought HTML dog was cool, but he's just another snob. "Jif." Go fuck yourself. It's gif and we all know it, I don't care how the format's inventor wants it to be pronounced, English is a language of common usage, not edicts, and 95% of people say gif with a hard G. Arguing otherwise only reveals you a pedant and a persnickety blowhard.
I have signitures disabled. If you do, too...you can't read this, so nevermind >_>

bittyx
Posts: 194
Joined: Tue Sep 25, 2007 9:10 pm UTC
Location: Belgrade, Serbia

Re: Learning HTML and CSS

Postby bittyx » Sun Feb 22, 2015 1:59 pm UTC

King Author wrote:Does it mention when a header is a header? Like will the program say, "Headline: My Favorite Bazooka Joe Comics" for <h1>My Favorite Bazooka Joe Comics</h1>? 'cause I hate using header tags but I'll use them for accessability's sake.


Just a quick note, since this is a personal pet peeve - please do not confuse headers and headings as they're two different things. A header actually has its own <header> element, which is exactly that - something usually in the top part of a website, that contains a logo, primary navigation, etc. The <h1>-<h6> elements are headings, and it's probably best to think of them as sort of "title" elements (they are also used by clients when building a document outline, which is sort of important for crawlers and screen readers). There's also a <hgroup> which is great for having a sort of title/subtitle element that doesn't mess up the document outline. E.g. if you were writing a blog post, you might have something like:

Code: Select all

<article>
    <hgroup>
        <h1>Learning HTML and CSS</h1>
        <h2>It's really awesome to be able to cleanly separate concerns</h2>
    </hgroup>
    <time datetime="2015-02-19 13:57:53">3 days ago</time>
    <p>In this blog post, we're gonna be talking about how to learn HTML and CSS. Lorem ipsum etc.</p>
</article>


Writing your markup to actually describe the structure of your content, instead of attempting to target some design, makes a lot more sense, has various benefits, and is usually know as "semantic markup" if you want to learn more and need a searchable term. It's a fact that for an arbitrary design, it might be impossible (or unrealistic) to have "pure" HTML, 100% untainted by elements which are there just to be able to match the design, but by writing your HTML focused on your content, you'll get much more maintainable code, not to mention how it will be far more readable and usable by software (such as the aforementioned crawlers and screen readers).

As an example of what separating HTML and CSS enables you to do, you might want to checkout CSS Zen Garden - it's a very old website with a simple premise - "here's some HTML which you aren't allowed to edit, so go write some CSS to make it beautiful". And indeed, when you check out all the different designs that *all have the exact same HTML*, you might begin to appreciate HTML/CSS separation a bit more.

Also, there are quite a few popular CSS conventions regarding how to structure your classes for maximum maintainability - in our company we currently use Medium's class-naming convention, which is a variant of the BEM methodology. This kind of reuse is simply impossible to attain within HTML itself, and the lack of CSS would mean much more repeated boilerplate work on the developers' part, which is awful, because developers hate repetitive tasks (as opposed to writing something new), and it would also raise development costs for clients.

However, if you don't really care about programming itself, or clean code, maintainability, quality, flexibility, efficiency, etc. - you can just do whatever you want.

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: Learning HTML and CSS

Postby ahammel » Sun Feb 22, 2015 3:44 pm UTC

King Author wrote:I still don't understand why to use strong instead of b.
<strong> means "strong empasis", <b> means "bold face" or (in HTML5) "draw attention to this word for reasons other than emphasis".

For instance, if you were writing a textbook-like, site you might want to make all the unfamiliar terms stand out so that the reader knows that they can be looked up in the glossary. You might write something like this:

"CSS is all about <b class=" glossary">separation of concerns</b>. That's a <strong>really</strong> good thing."

At which point you might notice that bold face could, confusingly, mean either a glossary term or emphasis and decide to put glossary terms in short caps or something.

Further reading:

http://html5doctor.com/i-b-em-strong-element/
He/Him/His/Alex
God damn these electric sex pants!

User avatar
King Author
Posts: 736
Joined: Sun Apr 12, 2009 12:30 pm UTC
Location: Pennsylvania, USA

Re: Learning HTML and CSS

Postby King Author » Sun Feb 22, 2015 7:30 pm UTC

bittyx wrote:
King Author wrote:Does it mention when a header is a header? Like will the program say, "Headline: My Favorite Bazooka Joe Comics" for <h1>My Favorite Bazooka Joe Comics</h1>? 'cause I hate using header tags but I'll use them for accessability's sake.


Just a quick note, since this is a personal pet peeve - please do not confuse headers and headings as they're two different things. A header actually has its own <header> element, which is exactly that - something usually in the top part of a website, that contains a logo, primary navigation, etc. The <h1>-<h6> elements are headings, and it's probably best to think of them as sort of "title" elements (they are also used by clients when building a document outline, which is sort of important for crawlers and screen readers). There's also a <hgroup> which is great for having a sort of title/subtitle element that doesn't mess up the document outline.


Noted. However...

bittyx wrote:E.g. if you were writing a blog post, you might have something like:

Code: Select all

<article>
    <hgroup>
        <h1>Learning HTML and CSS</h1>
        <h2>It's really awesome to be able to cleanly separate concerns</h2>
    </hgroup>
    <time datetime="2015-02-19 13:57:53">3 days ago</time>
    <p>In this blog post, we're gonna be talking about how to learn HTML and CSS. Lorem ipsum etc.</p>
</article>


That code doesn't work properly in my test-html doc I'm messing with as I go through the HTML Dog tutorial. I don't think article or time are standard tags, maybe.

bittyx wrote:Writing your markup to actually describe the structure of your content, instead of attempting to target some design, makes a lot more sense, has various benefits, and is usually know as "semantic markup" if you want to learn more and need a searchable term. It's a fact that for an arbitrary design, it might be impossible (or unrealistic) to have "pure" HTML, 100% untainted by elements which are there just to be able to match the design, but by writing your HTML focused on your content, you'll get much more maintainable code, not to mention how it will be far more readable and usable by software (such as the aforementioned crawlers and screen readers).


Thanks for the explanation. For my small little personal website which only I'll ever edit (and likely view, lol), maintainability isn't a concern, though. Though I guess in the future, aiding crawlers might help me if I want visibility. Ugh, but see? That's Google unduly influencing the web -- we all design our HTML to be pleasing to Google's crawlers so we get more visibility and page hits. Google Effect indeed...

bittyx wrote:As an example of what separating HTML and CSS enables you to do, you might want to checkout CSS Zen Garden - it's a very old website with a simple premise - "here's some HTML which you aren't allowed to edit, so go write some CSS to make it beautiful". And indeed, when you check out all the different designs that *all have the exact same HTML*, you might begin to appreciate HTML/CSS separation a bit more.


Neat. But how do they add images? You can add images in CSS? Ooh! And I gotta figure out how this theater one works...
http://www.csszengarden.com/202/
If you disable "allow webpages to choose their own colors" it appears to scroll normally, so clearly the theater thing is an image border stuck around the text and commanded to stay relative to the window rather than scrolling. But I can't decipher how it does that from viewing the CSS file. I guess I am just starting...

Heh, but I gotta say, that HTML file is so super set up to be easily CSS-ed. No real equivalent plain HTML file would have so many ids and roles and such; they're added just to give you more possibilites with CSS. Still neat though.

bittyx wrote:Also, there are quite a few popular CSS conventions regarding how to structure your classes for maximum maintainability - in our company we currently use Medium's class-naming convention, which is a variant of the BEM methodology. This kind of reuse is simply impossible to attain within HTML itself, and the lack of CSS would mean much more repeated boilerplate work on the developers' part, which is awful, because developers hate repetitive tasks (as opposed to writing something new), and it would also raise development costs for clients.

However, if you don't really care about programming itself, or clean code, maintainability, quality, flexibility, efficiency, etc. - you can just do whatever you want.


Lol, the Medium link makes me wonder what kind of company you work for.

*sigh*

Your last sentence did remind me of why I disliked CSS in the first place, though. HTML is simple and easy, anyone can learn it. Bring CSS into the picture and it becomes this whole big thing. Standards? Maintainability? This isn't a programming language, for Jah's sake! I guess I was spoiled by late-90s early-2000s HTML. There wasn't much to it. Now, the sources of websites are as complex and difficult-to-understand as the sources of computer programs!

ahammel wrote:
King Author wrote:I still don't understand why to use strong instead of b.
<strong> means "strong empasis", <b> means "bold face" or (in HTML5) "draw attention to this word for reasons other than emphasis".

For instance, if you were writing a textbook-like, site you might want to make all the unfamiliar terms stand out so that the reader knows that they can be looked up in the glossary. You might write something like this:

"CSS is all about <b class=" glossary">separation of concerns</b>. That's a <strong>really</strong> good thing."

At which point you might notice that bold face could, confusingly, mean either a glossary term or emphasis and decide to put glossary terms in short caps or something.

Further reading:

http://html5doctor.com/i-b-em-strong-element/


Ah, thanks for explaining it.

...

I think Imma keep using <b> stylistically, though. Typing out <strong> every time is too long and obnoxious and code-bloaty.
I have signitures disabled. If you do, too...you can't read this, so nevermind >_>

User avatar
Xanthir
My HERO!!!
Posts: 5334
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Learning HTML and CSS

Postby Xanthir » Sun Feb 22, 2015 11:53 pm UTC

King Author wrote:That code doesn't work properly in my test-html doc I'm messing with as I go through the HTML Dog tutorial. I don't think article or time are standard tags, maybe.

They are, but HTMLDog was written when HTML4 was the standard; those elements are newer.

we all design our HTML to be pleasing to Google's crawlers so we get more visibility and page hits. Google Effect indeed...

No, we design our websites to be friendly to machines in general, because there are multiple types of machines that help people deal with pages. Search crawlers are one of them, yes; screen-readers are another, along with a bunch of other accessibility tools. It's good craftsmanship to build your page with the proper tools so machines can understand it as well as humans with full control of their senses.

But how do they add images? You can add images in CSS?

As an aside, I suggest learning at least the basics of a language before publicly dissing it. ^_^

Ooh! And I gotta figure out how this theater one works...
http://www.csszengarden.com/202/
If you disable "allow webpages to choose their own colors" it appears to scroll normally, so clearly the theater thing is an image border stuck around the text and commanded to stay relative to the window rather than scrolling. But I can't decipher how it does that from viewing the CSS file. I guess I am just starting...

It just uses four extra elements that are position:fixed (so they stay where they are when you scroll) to supply the images around the sides. The rest of the page just has margins/paddings set appropriately to squeeze the content into the area between the images; when you scroll, it scrolls normally, with the fixed-position elements sitting still.

Heh, but I gotta say, that HTML file is so super set up to be easily CSS-ed. No real equivalent plain HTML file would have so many ids and roles and such; they're added just to give you more possibilites with CSS. Still neat though.

Yeah, that's intentional; CSS Zen Garden was last decade's showcase for what cool stuff you could do with CSS, and we didn't have today's panoply of Selectors that would have let people target things precisely, so they had to supply a bunch of classes and IDs.

Your last sentence did remind me of why I disliked CSS in the first place, though. HTML is simple and easy, anyone can learn it. Bring CSS into the picture and it becomes this whole big thing. Standards? Maintainability? This isn't a programming language, for Jah's sake! I guess I was spoiled by late-90s early-2000s HTML. There wasn't much to it. Now, the sources of websites are as complex and difficult-to-understand as the sources of computer programs!

That's because HTML *is* a programming language. It's a simplistic one, but it's still, "<body><p>foo <img></p></body>" is equivalent to "body(p('foo', img()))", just with a different syntax.

CSS just abstracts styling to another layer. Just like you can write all your code in a normal program in one big function, or break it up into more easily maintained small functions that call each other, CSS lets you break up parts of your "display a web page" program into more easily-maintained chunks - you've got a chunk that defines the text structure, and a chunk that defines the styling, rather than munging them together.

I think Imma keep using <b> stylistically, though. Typing out <strong> every time is too long and obnoxious and code-bloaty.

If that's really your reason, please at least use <em> for emphasis. It really does help screen-readers. If you really like bold emphasis, that's a "<style>em { font-style: normal; font-weight: bold; }</style>" away.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6300
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: Learning HTML and CSS

Postby Thesh » Mon Feb 23, 2015 6:39 am UTC

I think CSS does things right(-ish, I have my own problems with CSS, primarily that it's just so damned large and complicated, but only very abstract and incomplete ideas about how to fix it), it's HTML that has the problem. It was originally a combination of overall page structure, styles, functionality (e.g. forms, links), and data, which is just a complete mess. CSS was basically a bolt-on to take the styling out of HTML which took away the bulk of the bloat, and JavaScript significantly extended functionality and while partially replacing forms with Ajax. I think what's left to do is find a third language to take away the rest of what HTML does, and have web designers just interact with abstract data structures (XML, JSON, or YAML).

Personally if I was going to rewrite from scratch, I would have three main languages:

1) Layout language, providing the functionality to define page structure... All of the page structure. This is where I think HTML is bad to mix layout and data, whereas CSS just gets too messy by basically being bolted onto HTML

2) Style language, basically CSS just without any of the layout stuff

3) Scripting language, providing ALL of the functionality, including the links and the form behavior (while the layout language would tell the purpose of something, it would delegate to the scripting language to define how the user interacts with it)

Languages 1 and 3 would both be able to interact with the data structures, language 1 should be able to read information from 2, e.g. scaling to the size of a background image. Again, this is very abstract, and I'm sure there are plenty of accessibility issues I'm ignoring, and I have no clue what everything would actually look like.

Of course, web technologies are so ingrained now, I doubt we will see a significant change in course any time soon.
Summum ius, summa iniuria.

User avatar
PM 2Ring
Posts: 3652
Joined: Mon Jan 26, 2009 3:19 pm UTC
Location: Mid north coast, NSW, Australia

Re: Learning HTML and CSS

Postby PM 2Ring » Mon Feb 23, 2015 9:55 am UTC

Thesh wrote:[...] it's HTML that has the problem. It was originally a combination of overall page structure, styles, functionality (e.g. forms, links), and data, which is just a complete mess. CSS was basically a bolt-on to take the styling out of HTML which took away the bulk of the bloat, and JavaScript significantly extended functionality and while partially replacing forms with Ajax. I think what's left to do is find a third language to take away the rest of what HTML does, and have web designers just interact with abstract data structures (XML, JSON, or YAML).


I like the ideas in this post, Thesh. But I just wanted to say that originally originally HTML didn't really have any style stuff and the philosophy of separating content from style was strongly promoted by Tim Berners-Lee, et al. Virtually all the old HTML style stuff was added on to it during the early Browser Wars between Netscape and Internet Explorer, and as a consequence it became a horrible mess that was rendered differently (or totally ignored) depending on what browser you used.

I'm sure that you, Thesh, are aware of that ancient history, but I just wanted to mention it for other readers of this thread.

User avatar
King Author
Posts: 736
Joined: Sun Apr 12, 2009 12:30 pm UTC
Location: Pennsylvania, USA

Re: Learning HTML and CSS

Postby King Author » Mon Feb 23, 2015 6:51 pm UTC

Xanthir wrote:
King Author wrote:That code doesn't work properly in my test-html doc I'm messing with as I go through the HTML Dog tutorial. I don't think article or time are standard tags, maybe.

They are, but HTMLDog was written when HTML4 was the standard; those elements are newer.


But I mean, I added the code you posted as-is to my test page and it doesn't appear to do anything.

Xanthir wrote:
But how do they add images? You can add images in CSS?

As an aside, I suggest learning at least the basics of a language before publicly dissing it. ^_^

Knowing that CSS can do images wouldn't've stopped me from disliking it. And I still don't have fond feelings towards it.

Xanthir wrote:
Ooh! And I gotta figure out how this theater one works...
http://www.csszengarden.com/202/
If you disable "allow webpages to choose their own colors" it appears to scroll normally, so clearly the theater thing is an image border stuck around the text and commanded to stay relative to the window rather than scrolling. But I can't decipher how it does that from viewing the CSS file. I guess I am just starting...

It just uses four extra elements that are position:fixed (so they stay where they are when you scroll) to supply the images around the sides. The rest of the page just has margins/paddings set appropriately to squeeze the content into the area between the images; when you scroll, it scrolls normally, with the fixed-position elements sitting still.


Neat. I can do my "old-timey computer" page style then :)
Though I suspect I'll have trouble positioning the borders. Man, it's 2015, why is simply putting things where you physically want them on a web page still such a hassle? I'm old enough to remember the days of stretching invisible pixels to get things where you wanted them.

Xanthir wrote:
Heh, but I gotta say, that HTML file is so super set up to be easily CSS-ed. No real equivalent plain HTML file would have so many ids and roles and such; they're added just to give you more possibilites with CSS. Still neat though.

Yeah, that's intentional; CSS Zen Garden was last decade's showcase for what cool stuff you could do with CSS, and we didn't have today's panoply of Selectors that would have let people target things precisely, so they had to supply a bunch of classes and IDs.


I didn't realize it was so old. Why's there no newer CSS Zen Garden? I guess 'cause nobody makes stand-alone websites anymore :( Everyone just has a Facebook, Twitter, Blogger, etc. The web has become homogenized and boring :(

I also want a new HTML Dog, because presumably it's too old to have selectors, and I wanna learn how to use those.

Xanthir wrote:
Your last sentence did remind me of why I disliked CSS in the first place, though. HTML is simple and easy, anyone can learn it. Bring CSS into the picture and it becomes this whole big thing. Standards? Maintainability? This isn't a programming language, for Jah's sake! I guess I was spoiled by late-90s early-2000s HTML. There wasn't much to it. Now, the sources of websites are as complex and difficult-to-understand as the sources of computer programs!

That's because HTML *is* a programming language. It's a simplistic one, but it's still, "<body><p>foo <img></p></body>" is equivalent to "body(p('foo', img()))", just with a different syntax.


*shakes head*
HTML is not a programming language. It's just a markup thingy. Huge difference.
http://inventwithpython.com/blog/2013/1 ... -language/
http://infospace.ischool.syr.edu/2012/0 ... -language/
Besides, my point stands -- the pre-CSS web was simple, post-CSS it's a steep learning curve.

Xanthir wrote:
I think Imma keep using <b> stylistically, though. Typing out <strong> every time is too long and obnoxious and code-bloaty.

If that's really your reason, please at least use <em> for emphasis. It really does help screen-readers. If you really like bold emphasis, that's a "<style>em { font-style: normal; font-weight: bold; }</style>" away.


Ugh! I hate <em> and <strong> equally! Hate hate hate! And I'm genuinely dreading that <b> and <i> will become depreciated in HTML6.

Thesh wrote:I think CSS does things right(-ish, I have my own problems with CSS, primarily that it's just so damned large and complicated, but only very abstract and incomplete ideas about how to fix it), it's HTML that has the problem. It was originally a combination of overall page structure, styles, functionality (e.g. forms, links), and data, which is just a complete mess. CSS was basically a bolt-on to take the styling out of HTML which took away the bulk of the bloat, and JavaScript significantly extended functionality and while partially replacing forms with Ajax. I think what's left to do is find a third language to take away the rest of what HTML does, and have web designers just interact with abstract data structures (XML, JSON, or YAML).

Personally if I was going to rewrite from scratch, I would have three main languages:

1) Layout language, providing the functionality to define page structure... All of the page structure. This is where I think HTML is bad to mix layout and data, whereas CSS just gets too messy by basically being bolted onto HTML

2) Style language, basically CSS just without any of the layout stuff

3) Scripting language, providing ALL of the functionality, including the links and the form behavior (while the layout language would tell the purpose of something, it would delegate to the scripting language to define how the user interacts with it)

Languages 1 and 3 would both be able to interact with the data structures, language 1 should be able to read information from 2, e.g. scaling to the size of a background image. Again, this is very abstract, and I'm sure there are plenty of accessibility issues I'm ignoring, and I have no clue what everything would actually look like.

Of course, web technologies are so ingrained now, I doubt we will see a significant change in course any time soon.


Oh yeah, that'd be great. I'd have to learn a third freaking language just to have ahrefs!
I have signitures disabled. If you do, too...you can't read this, so nevermind >_>

User avatar
styrofoam
Posts: 256
Joined: Sat May 08, 2010 3:28 am UTC

Re: Learning HTML and CSS

Postby styrofoam » Mon Feb 23, 2015 10:05 pm UTC

King Author wrote:Man, it's 2015, why is simply putting things where you physically want them on a web page still such a hassle?


Code: Select all

<DIV STYLE="position:absolute;top:15px;left:15px">What hassle</DIV>


It's only complicated if you're trying to do a non-trivial layout that responds to the size of the browser window. You can just absolutely position everything, or just stick to the default wall of text.
aadams wrote:I am a very nice whatever it is I am.

User avatar
ucim
Posts: 6567
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: Learning HTML and CSS

Postby ucim » Tue Feb 24, 2015 3:59 am UTC

King Arthur wrote:why is simply putting things where you physically want them on a web page still such a hassle?
...because you never know how big the window will be.

Let this sink in. The web is not a piece of paper.

Now, you can treat it as a piece of paper, but you will end up with one of those abysmal sites that waste half the monitor space with black bars on either side of a fixed-width column. There may be pretty things in that column, but the rest of the window is thrown away. And then if your monitor is too small, you end up scrolling left and right for every freaking line. (I get a lot of emails in this horrific format. I don't bother to read them.)
Spoiler:
These kinds of layouts have one advantage however - they are often three-column layouts with uninteresting stuff like ads in an edge column. I can widen the window to show all I want to see, and then use the (horizontal) scroll bar to shove the beef by-products out of view. I could not do this if the column widths responded to the window width - I'd have to hang the junk off the edge of my monitor instead.

And while I loathe most cases of scrollbars inside scrollbars (sometimes three layers deep), I have also found a good use for them in one particular instance, within a fluid layout.
There are however two CSS properties I would have really loved to see supported early on. One is an n-column layout:

p {display: ncolumn; width: 80%; colcount: min; colwidth: 20em 50em; overflow: right;}

<p>Bunch of text.</p>

This would arrange the "Bunch of text" in the box as a series of columns as needed to accomodate the viewport height. colcount could be "min" or "max", minimizing (or maximizing) the number of displayed columns, subject to the width parameter (total width of the element) and the range of colwidth. For example, if colcount is "max" then the browser would figure out the maximum number of columns it could create (with columns between 20em and 50em wide), and spill text into these columns evenly one by one until all the text was displayed.

If overflow were set to "right", then additional columns would be created to the right as needed (scrollbar accessible). If overflow were set to "down", then the box would be expanded downward to accomodate all the text within the visible columns. The regular vertical scrollbar would give access to the rest of the (long) column(s), pushing other elements down.

The other I think already exists; It's a way to display a set of elements in boxes that dynamically resize themselves like a table does. Were that built-in early on, it would have saved a lot of CSS fitzjiddling. But now I have to wait for (near) universal support.

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Please help addams if you can. She needs all of us.

User avatar
Xanthir
My HERO!!!
Posts: 5334
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Learning HTML and CSS

Postby Xanthir » Tue Feb 24, 2015 4:52 am UTC

Re: ncolumn, are you aware of Multicol? Been supported by everyone for forever. It's not actually *great* for screen, because you can't limit the height of the columns and generate more *below* once the container has been filled up horizontally; I'm probably going to take over the module next year and make it usable on the real web. (You can just create long balanced columns, but then people have to scroll up and down as they read, which is terrible.)

Re: like a table, have you heard of display:table? Again, been supported by everyone for forever. Or, more useful, Flexbox, which is usable in all modern browsers.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
King Author
Posts: 736
Joined: Sun Apr 12, 2009 12:30 pm UTC
Location: Pennsylvania, USA

Re: Learning HTML and CSS

Postby King Author » Tue Feb 24, 2015 8:18 pm UTC

A VERY IMPORTANT QUESTION!: Why are div and span called "div" and "span?" Two minutes of googling turned up nothing and I'm lazy enough to quit after that. I'm surprised, actually, that it's not a first-page result. I'd think other people would be curious about why they're called that, but apparently, not enough people to get a first-page google result OR a mention on the Wikipedia page. Not even in the Triva section!

(Also, update: I'm done with the HTML Beginner and CSS Beginner sections of HTML Dog.)

styrofoam wrote:
King Author wrote:Man, it's 2015, why is simply putting things where you physically want them on a web page still such a hassle?


Code: Select all

<DIV STYLE="position:absolute;top:15px;left:15px">What hassle</DIV>


It's only complicated if you're trying to do a non-trivial layout that responds to the size of the browser window. You can just absolutely position everything, or just stick to the default wall of text.


Huh, that...actually works. Neat! Thanks ^_^

Although testing, that text (or presumably whatever else is inbetween the tags) is plastered on top of everything else. So for instance, I couldn't use that to place an image in the middle of a big paragraph of text, 'cause it'd just appear over the text, blocking it from view. I think there's a z-position attribute so I could make it appear UNDER the text, but I can't make it shove the text out of the way. Though I assume there's a fairly simple way to do that, now, too.

ucim wrote:And while I loathe most cases of scrollbars inside scrollbars (sometimes three layers deep), I have also found a good use for them in one particular instance, within a fluid layout.[/spoiler]There are however two CSS properties I would have really loved to see supported early on. One is an n-column layout:

p {display: ncolumn; width: 80%; colcount: min; colwidth: 20em 50em; overflow: right;}

<p>Bunch of text.</p>

This would arrange the "Bunch of text" in the box as a series of columns as needed to accomodate the viewport height. colcount could be "min" or "max", minimizing (or maximizing) the number of displayed columns, subject to the width parameter (total width of the element) and the range of colwidth. For example, if colcount is "max" then the browser would figure out the maximum number of columns it could create (with columns between 20em and 50em wide), and spill text into these columns evenly one by one until all the text was displayed.

If overflow were set to "right", then additional columns would be created to the right as needed (scrollbar accessible). If overflow were set to "down", then the box would be expanded downward to accomodate all the text within the visible columns. The regular vertical scrollbar would give access to the rest of the (long) column(s), pushing other elements down.

The other I think already exists; It's a way to display a set of elements in boxes that dynamically resize themselves like a table does. Were that built-in early on, it would have saved a lot of CSS fitzjiddling. But now I have to wait for (near) universal support.


Wait, I'm confused. Are you saying this DOES exist or DOESN'T exist? 'cause it doesn't do anything when I try it out.

Xanthir wrote:Re: ncolumn, are you aware of Multicol? Been supported by everyone for forever. It's not actually *great* for screen, because you can't limit the height of the columns and generate more *below* once the container has been filled up horizontally; I'm probably going to take over the module next year and make it usable on the real web. (You can just create long balanced columns, but then people have to scroll up and down as they read, which is terrible.)

Re: like a table, have you heard of display:table? Again, been supported by everyone for forever. Or, more useful, Flexbox, which is usable in all modern browsers.


Wait...what? You're...part of the W3C?
I have signitures disabled. If you do, too...you can't read this, so nevermind >_>

User avatar
Xanthir
My HERO!!!
Posts: 5334
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Learning HTML and CSS

Postby Xanthir » Tue Feb 24, 2015 9:27 pm UTC

King Author wrote:A VERY IMPORTANT QUESTION!: Why are div and span called "div" and "span?" Two minutes of googling turned up nothing and I'm lazy enough to quit after that. I'm surprised, actually, that it's not a first-page result. I'd think other people would be curious about why they're called that, but apparently, not enough people to get a first-page google result OR a mention on the Wikipedia page. Not even in the Triva section!

"div" is short for "division", and "span" is as "span of text"; both of them are intentionally generic names, since neither of them "mean" anything - they don't impart any additional semantics to the things they're wrapping.

Although testing, that text (or presumably whatever else is inbetween the tags) is plastered on top of everything else. So for instance, I couldn't use that to place an image in the middle of a big paragraph of text, 'cause it'd just appear over the text, blocking it from view. I think there's a z-position attribute so I could make it appear UNDER the text, but I can't make it shove the text out of the way. Though I assume there's a fairly simple way to do that, now, too.

You'll see when you get to the tutorial section about the 'float' property.

Note: a lot of older webdev tutorials teach you how to *misuse* 'float' as a layout tool. It's intended just for floating images and similar things next to text. If you're trying to use it to, for example, lay out a horizontal navbar, you're doing it wrong (though even just a few years ago that was forgiveable, because there wasn't a right way). These days we have Flexbox to solve all the cases that 'float' used to be abused for. Just a heads-up as you learn more.

ucim wrote:And while I loathe most cases of scrollbars inside scrollbars (sometimes three layers deep), I have also found a good use for them in one particular instance, within a fluid layout.[/spoiler]There are however two CSS properties I would have really loved to see supported early on. One is an n-column layout:

p {display: ncolumn; width: 80%; colcount: min; colwidth: 20em 50em; overflow: right;}
<snip>


Wait, I'm confused. Are you saying this DOES exist or DOESN'T exist? 'cause it doesn't do anything when I try it out.

They're conjecturing about something hypothetical that they wish existed. (Though it totally does exist, just under a slightly different name.)

Xanthir wrote:Re: ncolumn, are you aware of Multicol? Been supported by everyone for forever. It's not actually *great* for screen, because you can't limit the height of the columns and generate more *below* once the container has been filled up horizontally; I'm probably going to take over the module next year and make it usable on the real web. (You can just create long balanced columns, but then people have to scroll up and down as they read, which is terrible.)

Re: like a table, have you heard of display:table? Again, been supported by everyone for forever. Or, more useful, Flexbox, which is usable in all modern browsers.


Wait...what? You're...part of the W3C?

Well, I'm a Googler, but yeah, I'm part of several W3C working groups, and edit or contribute to ~half of the CSS specifications. Earlier in the thread I pointed to the fact that I wrote the Syntax spec. ^_^
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
ucim
Posts: 6567
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: Learning HTML and CSS

Postby ucim » Wed Feb 25, 2015 5:22 am UTC

Xanthir wrote:Re: ncolumn, are you aware of Multicol? Been supported by everyone for forever.

No, never heard of it. Thanks, I'll look into it. What happens to the overflow once the container has filled up horizontally?
Xanthir wrote:(You can just create long balanced columns, but then people have to scroll up and down as they read, which is terrible.)
But perhaps better than a single very wide paragraph. I will definitely give it a look. (How does it display in browsers that do not support it?) edit: I looked over the css doc - very cool. Will give it a try! (I hope the column width responds to viewport width; I'll read and experiment further.)

Xanthir wrote:Re: like a table, have you heard of display:table? Again, been supported by everyone for forever. Or, more useful, Flexbox, which is usable in all modern browsers.
I've heard of display:table, but not flexbox. My understanding is that display:table is not supported by "everyone" "forever" though. I need to go way back. (I myself, when traveling, only have an anemic laptop that barely runs win98 and an early version of seamonkey, and can't open a word document at the same time because it runs out of RAM. But I have to be able to access the application and have it be rock solid.)

For my application I need 100% of the group to be able to access it. If even one person is using an unsupported browser (and has no alternative where they are) that group cannot use the application. If there are 40 people in a group and I want 80% of the groups to be able to use the application, I need 99 44/100 % penetration for the technique I'm using. (the fortieth root of .8) If I use techniques that are supported by 95% of the browsers, I lock out 87% of my audience. So, I need a rather high value of "forever" and "everyone". Modern techniques, pretty as they may be, guarantee disaster.

I already require SSL and cookies, and will not make users run scripts (it's too often used for evil, and web users should not be trained to just trust websites).

Nonetheless, I'm glad to see these techniques come in, and will give them a look-see. Thanks.

Jose
(edit to fix quote fail)
Last edited by ucim on Fri Mar 06, 2015 4:37 am UTC, edited 1 time in total.
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Please help addams if you can. She needs all of us.

User avatar
Xanthir
My HERO!!!
Posts: 5334
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Learning HTML and CSS

Postby Xanthir » Wed Feb 25, 2015 5:43 am UTC

ucim wrote:
Xanthir wrote:Re: ncolumn, are you aware of Multicol? Been supported by everyone for forever.

No, never heard of it. Thanks, I'll look into it. What happens to the overflow once the container has filled up horizontally?

It just keeps making more columns to the right, overflowing the container.

Xanthir wrote:(You can just create long balanced columns, but then people have to scroll up and down as they read, which is terrible.)

But perhaps better than a single very wide paragraph. I will definitely give it a look. (How does it display in browsers that do not support it?)

Every browser you care about supports it, but in the ancient browsers that don't, it just lays out like normal text.

Xanthir wrote:Re: like a table, have you heard of display:table? Again, been supported by everyone for forever. Or, more useful, Flexbox, which is usable in all modern browsers.

I've heard of display:table, but not flexbox. My understanding is that display:table is not supported by "everyone" "forever" though. I need to go way back. (I myself, when traveling, only have an anemic laptop that barely runs win98 and an early version of seamonkey, and can't open a word document at the same time because it runs out of RAM. But I have to be able to access the application and have it be rock solid.)

IE8 was the last major browser to add support for display:table; if your users are running IE7, well...

(Your 15-year old system will probably have issues too.)
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
King Author
Posts: 736
Joined: Sun Apr 12, 2009 12:30 pm UTC
Location: Pennsylvania, USA

Re: Learning HTML and CSS

Postby King Author » Wed Feb 25, 2015 4:42 pm UTC

Xanthir wrote:
King Author wrote:A VERY IMPORTANT QUESTION!: Why are div and span called "div" and "span?" Two minutes of googling turned up nothing and I'm lazy enough to quit after that. I'm surprised, actually, that it's not a first-page result. I'd think other people would be curious about why they're called that, but apparently, not enough people to get a first-page google result OR a mention on the Wikipedia page. Not even in the Triva section!

"div" is short for "division", and "span" is as "span of text"; both of them are intentionally generic names, since neither of them "mean" anything - they don't impart any additional semantics to the things they're wrapping.

Oh, okay. Thanks. Man, why isn't that info on the WP page or anywhere? I can't be the only person curious.

That raises an interesting question though -- why not just allow users to create arbitrary tags? The way you can create any variable you want in a proper programming language?
<coolblinkingtext style=blink;>Look how annoying I can be! Good luck reading this, epileptics!</coolblinkingtext>

(I know style=blink isn't a real thing, I just couldn't think of a random example of some random thing to add to a custom tag.)

Xanthir wrote:
Although testing, that text (or presumably whatever else is inbetween the tags) is plastered on top of everything else. So for instance, I couldn't use that to place an image in the middle of a big paragraph of text, 'cause it'd just appear over the text, blocking it from view. I think there's a z-position attribute so I could make it appear UNDER the text, but I can't make it shove the text out of the way. Though I assume there's a fairly simple way to do that, now, too.

You'll see when you get to the tutorial section about the 'float' property.

Note: a lot of older webdev tutorials teach you how to *misuse* 'float' as a layout tool. It's intended just for floating images and similar things next to text. If you're trying to use it to, for example, lay out a horizontal navbar, you're doing it wrong (though even just a few years ago that was forgiveable, because there wasn't a right way). These days we have Flexbox to solve all the cases that 'float' used to be abused for. Just a heads-up as you learn more.


Thanks for the heads up. Man, you really hate hacks, though, lol.

Xanthir wrote:
Wait...what? You're...part of the W3C?

Well, I'm a Googler, but yeah, I'm part of several W3C working groups, and edit or contribute to ~half of the CSS specifications. Earlier in the thread I pointed to the fact that I wrote the Syntax spec. ^_^


I'll keep that in mind so I can feature-request to you directly when the time comes.
*rubs hands together menacingly*

Edit: I just looked at your personal website, heh. I like to write homepages for myself, and I did one basically exactly like your website, once, made to look like an old-timey DOS mockup, repleat with blinking underscore at the end.

Edit2: Looking at your tutorials. The simple video one says the player will play the first video format it knows how to, and the order is webm, ogg and mp4. My browser can play webm's, I do it all the time, but for some reason, your demo there plays the ogg.

(Love the site btw; my post-HTML Dog mission will be figuring out how your Canvas video stuff works, like the vid-to-ascii.)
I have signitures disabled. If you do, too...you can't read this, so nevermind >_>

User avatar
chridd
Has a vermicelli title
Posts: 829
Joined: Tue Aug 19, 2008 10:07 am UTC
Location: ...Earth, I guess?
Contact:

Re: Learning HTML and CSS

Postby chridd » Thu Feb 26, 2015 2:40 am UTC

King Author wrote:That raises an interesting question though -- why not just allow users to create arbitrary tags? The way you can create any variable you want in a proper programming language?
<coolblinkingtext style=blink;>Look how annoying I can be! Good luck reading this, epileptics!</coolblinkingtext>
Probably because the tag you make up might conflict with some tag that's added in the future with a different meaning. (...although you can make up attributes as long as they start with "data-", so perhaps they could do something similar with tags...) Also, you can, and it works at least in Firefox, but it's not standards-compliant.

Code: Select all

<style>red {color:red;}</style>
<red style="background:yellow">hi</red> there
~ chri d. d. /tʃɹɪ.di.di/ (Phonotactics, schmphonotactics) · she(?)(?(?)(?))(?(?(?))(?))(?) · Forum game scores
mittfh wrote:I wish this post was very quotable...
chridd (on Discord) wrote:
Dummy wrote:Sorry You're Gay Dads
SYG'D
marionic (on Discord) wrote:sleep in grave

User avatar
Xanthir
My HERO!!!
Posts: 5334
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Learning HTML and CSS

Postby Xanthir » Thu Feb 26, 2015 4:23 am UTC

King Author wrote:That raises an interesting question though -- why not just allow users to create arbitrary tags? The way you can create any variable you want in a proper programming language?
<coolblinkingtext style=blink;>Look how annoying I can be! Good luck reading this, epileptics!</coolblinkingtext>

(I know style=blink isn't a real thing, I just couldn't think of a random example of some random thing to add to a custom tag.)

Actually, "text-decoration:blink" was a real thing, but we removed it because nobody wanted to implement it and it was terrible. ^_^

Regarding arbitrary tags, there are a couple points:

  • Using the tags that are defined by the specs helps machines understand your page. Because <ol> is defined as "ordered list", and everyone knows this, screen readers can assume that it's appropriate to read it out as a list, and they do so. This is very very helpful for people with various disabilities. If you invented your own <orderedlist> tag, the screen-reader wouldn't know what to do.
  • We have a secondary technology called ARIA that defines a set of HTML attributes that lets you "upgrade" your markup into commonly-agreed semantics, so you can declare that your <div class='list'> is an ordered list, and the <div class='list-item'> is a list item; this way, screen-readers and similar machines can understand your page again. However, it's clumsy and annoying to sprinkle ARIA attributes all over your page.
  • As chridd says, if you can invent any arbitrary tag, it makes it harder for us to invent new elements in the future, because it means that your "custom" element now has real meaning, and might do something that breaks your page somewhat. Most pages are unmaintained and won't change, so we'd instead have to come up with new names that aren't used yet, and which might be clumsier and longer than they would be in an ideal world.
  • That said, we have a newish spec for Custom Elements, which lets you do precisely this. It requires that your custom element have a dash in its name, and we'll just never make an official element with a dash in its name, so we avoid name collisions between custom and official stuff. It also lets you hook up javascript to run when elements are created, etc, so you can augment them with ARIA attributes as appropriate in script, rather than having to litter your literal markup with them. Right now Chrome implements them, Firefox is working on an implementation, and we're working toward getting the other browsers to support it as well.

Man, you really hate hacks, though, lol.

I learned webdev 8 or 9 years ago, and got really good at it - that meant I had to learn a *lot* of hacks. That's the whole reason I got into the W3C - I wanted to fix some of the things I had to suffer through, and most of the people in the working groups are browser vendors, not web devs, so they weren't focusing on the things I thought were important.

I think I've succeeded pretty well. ^_^ I got Flexbox (done) and Grid (approaching done) to make layout *incredibly* easier than how it used to be, I wrote the spec for CSS gradients, and I've worked on a ton of other smaller things that would have made my life easier back in the day.

I'll keep that in mind so I can feature-request to you directly when the time comes.
*rubs hands together menacingly*

Or just email www-style@w3.org. That's the mailing list for the CSS Working Group; it's an open list, which anyone can subscribe or post to. If you do email us, remember that the most useful thing you can do is *describe a problem you're having*, as well as possible, rather than trying to suggest new ideas; it's likely that your problem is already partially or completely solved by something that exists or that is upcoming, or that one of us has already given a lot of thought to the problem and could just use some help with real-world examples to refine it.

Edit2: Looking at your tutorials. The simple video one says the player will play the first video format it knows how to, and the order is webm, ogg and mp4. My browser can play webm's, I do it all the time, but for some reason, your demo there plays the ogg.

Dunno, man.

(Love the site btw; my post-HTML Dog mission will be figuring out how your Canvas video stuff works, like the vid-to-ascii.)

The code's a pretty good introduction to playing around with canvas; it's a fun example, the code is really quite simple, and it's written with pretty decent JS, appropriate to learn from. The video-to-ascii code's only hairy bit is the math for colorToChar(), which unfortunately had to use some funky stuff for speed.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
King Author
Posts: 736
Joined: Sun Apr 12, 2009 12:30 pm UTC
Location: Pennsylvania, USA

Re: Learning HTML and CSS

Postby King Author » Thu Feb 26, 2015 11:43 am UTC

chridd wrote:
King Author wrote:That raises an interesting question though -- why not just allow users to create arbitrary tags? The way you can create any variable you want in a proper programming language?
<coolblinkingtext style=blink;>Look how annoying I can be! Good luck reading this, epileptics!</coolblinkingtext>
Probably because the tag you make up might conflict with some tag that's added in the future with a different meaning. (...although you can make up attributes as long as they start with "data-", so perhaps they could do something similar with tags...) Also, you can, and it works at least in Firefox, but it's not standards-compliant.

Code: Select all

<style>red {color:red;}</style>
<red style="background:yellow">hi</red> there


Whoa, neat! By not standards-compliant, I suppose you mean if I include code like that in my site, it won't pass the HTML Inspector or CSS Inspector or whatever?

Xanthir wrote:
King Author wrote:That raises an interesting question though -- why not just allow users to create arbitrary tags? The way you can create any variable you want in a proper programming language?
<coolblinkingtext style=blink;>Look how annoying I can be! Good luck reading this, epileptics!</coolblinkingtext>

(I know style=blink isn't a real thing, I just couldn't think of a random example of some random thing to add to a custom tag.)

Actually, "text-decoration:blink" was a real thing, but we removed it because nobody wanted to implement it and it was terrible. ^_^


Actually I knew text blinking was a thing (I've used it to simulate a command prompt), I just knew it wasn't "style=blink."

Xanthir wrote:Regarding arbitrary tags, there are a couple points:

  • Using the tags that are defined by the specs helps machines understand your page. Because <ol> is defined as "ordered list", and everyone knows this, screen readers can assume that it's appropriate to read it out as a list, and they do so. This is very very helpful for people with various disabilities. If you invented your own <orderedlist> tag, the screen-reader wouldn't know what to do.
  • We have a secondary technology called ARIA that defines a set of HTML attributes that lets you "upgrade" your markup into commonly-agreed semantics, so you can declare that your <div class='list'> is an ordered list, and the <div class='list-item'> is a list item; this way, screen-readers and similar machines can understand your page again. However, it's clumsy and annoying to sprinkle ARIA attributes all over your page.
  • As chridd says, if you can invent any arbitrary tag, it makes it harder for us to invent new elements in the future, because it means that your "custom" element now has real meaning, and might do something that breaks your page somewhat. Most pages are unmaintained and won't change, so we'd instead have to come up with new names that aren't used yet, and which might be clumsier and longer than they would be in an ideal world.
  • That said, we have a newish spec for Custom Elements, which lets you do precisely this. It requires that your custom element have a dash in its name, and we'll just never make an official element with a dash in its name, so we avoid name collisions between custom and official stuff. It also lets you hook up javascript to run when elements are created, etc, so you can augment them with ARIA attributes as appropriate in script, rather than having to litter your literal markup with them. Right now Chrome implements them, Firefox is working on an implementation, and we're working toward getting the other browsers to support it as well.


I guess that all makes sense. Neat about the custom tags thing that's in the works. Though dashes are ugly, ugly, ugly. Can't you use tildes or something cute?

That's a frequent problem I have with, well, any and every programming language -- they're eyesores to look at. It makes sense, of course -- programming languages are created by technically-minded people, not artists or aestheticists. And I know any hardcore user of any programming language would defend its appearance with "but it's efficient." I'm not suggesting trading any efficiency for beauty, not at all. The two don't have to collide. But when devising new markup, write some dummy code, step back and just look at it. Don't read it, don't analyze it, just look at it, and ask, "Does this look pleasing to the eye?" If not, are there any symbols or abbreviations or such that you could change to make it look better, without sacrificing readability or efficiency?

Part of me doubts that any writer of any programming language has ever done such a thing.

Xanthir wrote:
Man, you really hate hacks, though, lol.

I learned webdev 8 or 9 years ago, and got really good at it - that meant I had to learn a *lot* of hacks. That's the whole reason I got into the W3C - I wanted to fix some of the things I had to suffer through, and most of the people in the working groups are browser vendors, not web devs, so they weren't focusing on the things I thought were important.

I think I've succeeded pretty well. ^_^ I got Flexbox (done) and Grid (approaching done) to make layout *incredibly* easier than how it used to be, I wrote the spec for CSS gradients, and I've worked on a ton of other smaller things that would have made my life easier back in the day.


I learned around then, too. I mentioned earlier having to stretch invisible pixels to force page elements to where I wanted them, heh. Man that's an old trick.

Well, keep up the good work :]

Xanthir wrote:
I'll keep that in mind so I can feature-request to you directly when the time comes.
*rubs hands together menacingly*

Or just email www-style@w3.org. That's the mailing list for the CSS Working Group; it's an open list, which anyone can subscribe or post to. If you do email us, remember that the most useful thing you can do is *describe a problem you're having*, as well as possible, rather than trying to suggest new ideas; it's likely that your problem is already partially or completely solved by something that exists or that is upcoming, or that one of us has already given a lot of thought to the problem and could just use some help with real-world examples to refine it.


Noted.

Xanthir wrote:
(Love the site btw; my post-HTML Dog mission will be figuring out how your Canvas video stuff works, like the vid-to-ascii.)

The code's a pretty good introduction to playing around with canvas; it's a fun example, the code is really quite simple, and it's written with pretty decent JS, appropriate to learn from. The video-to-ascii code's only hairy bit is the math for colorToChar(), which unfortunately had to use some funky stuff for speed.


Oh dear, maths. Won't be looking forward to that, haha.
I have signitures disabled. If you do, too...you can't read this, so nevermind >_>

User avatar
ucim
Posts: 6567
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: Learning HTML and CSS

Postby ucim » Thu Feb 26, 2015 8:21 pm UTC

King Arthur wrote:Though dashes are ugly, ugly, ugly. Can't you use tildes or something cute?
Dashes are easy to type. The tilde requires a shift.

If you like, you could find (or create) a font that uses a wiggly glyph for a dash. In fact, you could do all your programming in Zapf Chancery.

Xanthir wrote:It also lets you hook up javascript to run when elements are created, etc, so you can augment them with ARIA attributes as appropriate in script, rather than having to litter your literal markup with them.
Is this on the user side when they view the page (thus training internet users to trust scripts and encouraging web developers to require them)? Because this would be painful. Already I can't access a lot of sites without letting {who knows what} run {who knows what} scripts against my computer.

Anyway, mongo cool that you are on W3C, and sharing your time with us.

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Please help addams if you can. She needs all of us.

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: Learning HTML and CSS

Postby ahammel » Thu Feb 26, 2015 9:24 pm UTC

King Author wrote:Though dashes are ugly, ugly, ugly.
What? Why?
He/Him/His/Alex
God damn these electric sex pants!

User avatar
King Author
Posts: 736
Joined: Sun Apr 12, 2009 12:30 pm UTC
Location: Pennsylvania, USA

Re: Learning HTML and CSS

Postby King Author » Fri Feb 27, 2015 10:57 am UTC

I'm following the HTML Dog tutorial and can't figure out what the citation inside a blockquote tag actually does.

http://htmldog.com/guides/html/intermediate/text/

Code: Select all

<p>So I asked Bob about quotations on the Web and he said <q>I know as much about quotations as I do about pigeon fancying</q>. Luckily, I found HTML Dog and it said:</p>

<blockquote cite="http://www.htmldog.com/guides/html/intermediate/text/">
    <p>blockquote and q are used for quotations. blockquote is generally used for standalone often multi-line quotations whereas q is used for shorter, in-line quotations.</p>
</blockquote>

When I put that on my test webpage, the citation doesn't appear visually anywhere, nor does it appear when I hover over the text. So...what is it doing and why is it there?

ahammel wrote:
King Author wrote:Though dashes are ugly, ugly, ugly.
What? Why?

I should clarify -- ugly when used in markup. As for why, just look!

Nice, pretty camelCase...

Code: Select all

var keysDown = {};
addEventListener("keydown", function (e) {
keysDown[e.keyCode] = true;
}, false);
addEventListener("keyup", function (e) {
delete keysDown[e.keyCode];
}, false);

Look how ugly dashes make it!

Code: Select all

var keys-down = {};
add-event-listener("keydown", function (e) {
keys-down[e.key-code] = true;
}, false);
add-event-listener("keyup", function (e) {
delete keys-down[e.key-code];
}, false);

It's like they're stabbing my eyeballs! And using them doubled-up at the beginning of a custom tag, as the spec suggests? Bleck! Imagine if we used double dashes instead of the dot selector in CSS.

Code: Select all

--html, --javascript { color:#000 }
--css { color: #c60 }
--html --qwer { color: #999; }
--css --cbrackets, --css --punctuation { color: #999; }
--css --property { color:#009 }
--css --selector { color: #090 }
--html --tag { color: #909; }
--html --attribute { color: #090 }
--css --ccomment, --html --ccomment, --javascript --comment {
        color:#999;
        font-style:italic;
}
--html --string { color:#009 }
--html --doctype { color:#099 }
--javascript --string { color:#090 }
--javascript --keywords { color:#c00 }
--javascript --global { color:blue }
--javascript --brackets { color:#999 }

Barrrrf!
I have signitures disabled. If you do, too...you can't read this, so nevermind >_>

User avatar
PM 2Ring
Posts: 3652
Joined: Mon Jan 26, 2009 3:19 pm UTC
Location: Mid north coast, NSW, Australia

Re: Learning HTML and CSS

Postby PM 2Ring » Fri Feb 27, 2015 1:20 pm UTC

Dashes in names are evil and should be killed with fire. They make it a PITA when you want to interface with a sane language that interprets the dashes as minus signs.

User avatar
Carlington
Posts: 1588
Joined: Sun Mar 22, 2009 8:46 am UTC
Location: Sydney, Australia.

Re: Learning HTML and CSS

Postby Carlington » Fri Feb 27, 2015 1:34 pm UTC

Just use em-dashes in the names so that a regular dash can be interpreted as a minus sign. Problem solved!
Kewangji: Posdy zwei tosdy osdy oady. Bork bork bork, hoppity syphilis bork.

Eebster the Great: What specifically is moving faster than light in these examples?
doogly: Hands waving furiously.

Please use he/him/his pronouns when referring to me.

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: Learning HTML and CSS

Postby ahammel » Fri Feb 27, 2015 2:54 pm UTC

King Author wrote:
ahammel wrote:
King Author wrote:Though dashes are ugly, ugly, ugly.
What? Why?

I should clarify -- ugly when used in markup. As for why, just look!
...

Were you beat up by a gang of hyphens one time, or what?

I mean, if it makes it inconvenient for parsers, or hard yo figure out what the code is doing that's one thing, but if you just hate looking at hyphens in the names of tags, I think that's your personal bugbear.
He/Him/His/Alex
God damn these electric sex pants!

User avatar
King Author
Posts: 736
Joined: Sun Apr 12, 2009 12:30 pm UTC
Location: Pennsylvania, USA

Re: Learning HTML and CSS

Postby King Author » Fri Feb 27, 2015 3:36 pm UTC

I'm continuing with the HTML Dog tutorial and have another question. Even though it's getting ahead of myself.

What's the difference between declaring the font(s) of your page using "body{font-family}" and using the @font-face rule? And is it possible to use fonts from a URL using body{} or do you have to use the at-rule to link to a font on the web?

PM 2Ring wrote:Dashes in names are evil and should be killed with fire. They make it a PITA when you want to interface with a sane language that interprets the dashes as minus signs.

Also if you use Ctrl+Left/Right to move through text, it stops at every. Freaking. Hyphen.

Carlington wrote:Just use em-dashes in the names so that a regular dash can be interpreted as a minus sign. Problem solved!

Oh yeah, em dashes! 'cause I love using Alt-Codes! Or better yet, those things you have to prefix with an ampersand in HTML.

Edit: I found a weird quirk. If you use <h> instead of <h1> for a header, when you assign thingies to it in CSS, some will assign and some won't. For example...

Code: Select all

h {
background-color: red;
font-size: 24px;
}

...works just fine, however...

Code: Select all

h {
background-color: red;
font-size: 24px;
text-align: center;
}

...will NOT center the text. If I change the <h> in the HTML file to <h1> and the above h's to h1's, the centering will work just dandy. Weird.
I have signitures disabled. If you do, too...you can't read this, so nevermind >_>

User avatar
hotaru
Posts: 1042
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: Learning HTML and CSS

Postby hotaru » Fri Feb 27, 2015 5:12 pm UTC

King Author wrote:Edit: I found a weird quirk. If you use <h> instead of <h1> for a header, when you assign thingies to it in CSS, some will assign and some won't. For example...

Code: Select all

h {
background-color: red;
font-size: 24px;
}

...works just fine, however...

Code: Select all

h {
background-color: red;
font-size: 24px;
text-align: center;
}

...will NOT center the text. If I change the <h> in the HTML file to <h1> and the above h's to h1's, the centering will work just dandy. Weird.

there is no h tag. h1 is usually styled with "display:block;" by default, and unrecognized tags are usually styled with "display:inline;" by default. that's why "text-align:center;" doesn't seem to do anything..

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

User avatar
chridd
Has a vermicelli title
Posts: 829
Joined: Tue Aug 19, 2008 10:07 am UTC
Location: ...Earth, I guess?
Contact:

Re: Learning HTML and CSS

Postby chridd » Fri Feb 27, 2015 6:49 pm UTC

King Author wrote:What's the difference between declaring the font(s) of your page using "body{font-family}" and using the @font-face rule? And is it possible to use fonts from a URL using body{} or do you have to use the at-rule to link to a font on the web?
body {font-family:"Arial"} changes the font of the webpage (except for parts where you specify a different font, of course) to whatever font you name (in my example, Arial). @font-face doesn't change the font of the webpage; rather, it tells the browser where to find a font with a certain name.
If you want to use a font that's already on the user's computer, just use font-family and don't use @font-face. If you want to the browser to download a font to use, use @font-face to tell it where to find the font, and then use font-family to tell it where to use the font:

Code: Select all

/* this does not change the font, but rather tells the browser that the font called "My font" is in the file my-font.ttf in the current directory: */
@font-face {
    font-family: "My font";
    src: url(my-font.ttf);
}
/* this tells the browser to use the font that I just told it about: */
body {
    font-family: "My font";
}
~ chri d. d. /tʃɹɪ.di.di/ (Phonotactics, schmphonotactics) · she(?)(?(?)(?))(?(?(?))(?))(?) · Forum game scores
mittfh wrote:I wish this post was very quotable...
chridd (on Discord) wrote:
Dummy wrote:Sorry You're Gay Dads
SYG'D
marionic (on Discord) wrote:sleep in grave

User avatar
Xanthir
My HERO!!!
Posts: 5334
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Learning HTML and CSS

Postby Xanthir » Fri Feb 27, 2015 8:54 pm UTC

ucim wrote:
King Arthur wrote:Though dashes are ugly, ugly, ugly. Can't you use tildes or something cute?
Dashes are easy to type. The tilde requires a shift.

If you like, you could find (or create) a font that uses a wiggly glyph for a dash. In fact, you could do all your programming in Zapf Chancery.

Also, the important bit is that dashes are already allowed in the parser for element names, so it doesn't break old browsers. (It's just that HTML never used any dashed names, and SVG and MathML, the other web markup languages, only have a very small number of them, which can be hardcoded into the parser.)

Xanthir wrote:It also lets you hook up javascript to run when elements are created, etc, so you can augment them with ARIA attributes as appropriate in script, rather than having to litter your literal markup with them.
Is this on the user side when they view the page (thus training internet users to trust scripts and encouraging web developers to require them)? Because this would be painful. Already I can't access a lot of sites without letting {who knows what} run {who knows what} scripts against my computer.

Yes, it's javascript, so it's run when you look at the page, and it's required to make the page display properly.

Stop being paranoid about Javascript, it's ridiculous. Webpages are the safest execution environments you have on your entire computer.

King Author wrote:When I put that on my test webpage, the citation doesn't appear visually anywhere, nor does it appear when I hover over the text. So...what is it doing and why is it there?

The <blockquote cite> attribute does nothing; it's stupid legacy crap and you shouldn't use it. Just put the link in visible text after the <blockquote>, or inside of it at the end.

King Author wrote:Imagine if we used double dashes instead of the dot selector in CSS.

Double dashes are, in fact, the marker of custom things in modern CSS, such as custom properties.

Also, you're wrong, dashed names are far better than camel-cased names. Lisp knew what was up, all you people with inline math are wrong and crazy. (When CSS does math, in calc(), it requires spaces around the + and - signs precisely to avoid these kinds of parsing issues.)

King Author wrote:What's the difference between declaring the font(s) of your page using "body{font-family}" and using the @font-face rule? And is it possible to use fonts from a URL using body{} or do you have to use the at-rule to link to a font on the web?

The 'font-family' property takes a font name. By default, the fonts available are the ones installed on the user's computer.

@font-face lets you reference fonts by url, and give them a name. You can then refer to them in 'font-family' like normal.

Also if you use Ctrl+Left/Right to move through text, it stops at every. Freaking. Hyphen.

That's because text editors are biased towards camel-case languages. Use one that's better suited for dashed languages. (I don't know of any.)

King Author wrote:I found a weird quirk. If you use <h> instead of <h1> for a header, when you assign thingies to it in CSS, some will assign and some won't.

1. Don't do that. Headings are *very* important for machines; they help assistive tech navigate around the page, and help Google figure out what your page's structure actually is. You're allowed to use only <h1> if you combine it with proper use of <section> and <article>, but DON'T just up and use an unknown element, because you're screwing with other people for no real benefit to yourself.
2. The default value of 'display' is "inline", so any elements that aren't styled otherwise by the browser's stylesheet are inline. Inlines are very different from blocks.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
ucim
Posts: 6567
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: Learning HTML and CSS

Postby ucim » Sat Feb 28, 2015 2:22 am UTC

Zanthir wrote:Stop being paranoid about Javascript, it's ridiculous. Webpages are the safest execution environments you have on your entire computer.
I'm not afraid of javascript. I just despise what a lot of web designers do with it.
  • They use it for basic navigation. This makes the page inaccessible for those who have it disabled for any reason.
  • They use it to load tons of stuff I don't care about (like twitter feeds).
  • They use it to tell other sites I don't care about where I am (like facebook).
  • They use it to follow what I'm doing (such as forms that are coded in javascript, depending on the way they are scripted the website can see what I typed and then deleted. I don't want the website to see my forming thoughts, just my final posted statement.
  • They use it to disable browser features (like the back button) and bypass others (like the indicator of where a link leads, where a click will take you)
  • Their use of it overloads small browsers and slow connections.
  • They use it to cause actions to happen that I didn't want (like slideshows that run at their own speed).
  • They source it from places I'm not familiar with, and thus hide the code itself. I have no idea what it's doing, and who it's telling.
Now, not all javascript is bad. A lot of it is quite neat (such as popup date pickers and such). But it has been co-opted by seedy commercial interests, and even less savovy ones. I run noscript so that I can see who wants in on my system. Now, there is no reason for me to want facebook, pinterest, baidu, google, oin.ee, travelocity, amazon, aata, advertising.com, adserver, cliktrak, or any number of others I've never heard of to run commands on my system, unless I am on their site. They have no business knowing what I'm doing. And if I allow them one by one for a specific page, they call in their friends and I have to allow ten or fifteen more unknown servers to have access to my system.

It's too bad, but my default position is to not trust the internet. [/rant]

edit to add: I've been playing with multicolumn CSS; it does not seem to be supported very well. Seamonkey (2.32.1) does not support it (but it supports the -moz- version), same with Firefox (v 36.0). Seems from comments that IE doesn't support it until you get to v. 10, (I don't have IE to test with). When it works, it's really nice.

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Please help addams if you can. She needs all of us.

Story
Posts: 78
Joined: Wed Aug 26, 2009 9:03 pm UTC

Re: Learning HTML and CSS

Postby Story » Mon Apr 06, 2015 11:39 pm UTC

If you don't like a site, don't visit it. You could apply the same argument to almost anything.

Anyway, I saw mentiond of w3schools earlier and MDN is way better. Unlike w3schools, it actually provides all the detail and has up to date information on modern features like html5 and es6 as well.


King Author wrote:Thanks for the explanation. For our wee little personal website which only we'll ever edit (and likely view, lol), maintainability isn't a concern, though. Though we guess in the future, aiding crawlers might help us if we want visibility. Ugh, but see? That's Google unduly influencing the web -- we all design our HTML to be pleasing to Google's crawlers so we get more visibility and page hits. Google Effect indeed...


How dare they encourage quality websites!

User avatar
jestingrabbit
Factoids are just Datas that haven't grown up yet
Posts: 5967
Joined: Tue Nov 28, 2006 9:50 pm UTC
Location: Sydney

Re: Learning HTML and CSS

Postby jestingrabbit » Sun Jan 17, 2016 5:57 pm UTC

Thought I would ask the folks with more experience: is brackets a good tool? Would you use it to learn, if you were just starting on html5 and css today?
ameretrifle wrote:Magic space feudalism is therefore a viable idea.

User avatar
Flumble
Yes Man
Posts: 2076
Joined: Sun Aug 05, 2012 9:35 pm UTC

Re: Learning HTML and CSS

Postby Flumble » Sun Jan 17, 2016 7:24 pm UTC

Note that I haven't tried brackets nor that I have professional experience with web development. Then again, there are so many on-par/decent HTML/CSS editors that it won't really make a difference which one you use. The larger differences appear in the quality of learning material. Do search for the "5" in "html5" tutorials, as it has introduced quite some tags that have a semantic meaning (particularly useful for screen readers and web crawlers) as opposed to the old tutorials advising to use <div>s for everything.

As a plain HTML (with interactive elements) editor it looks to be a good tool, especially considering the vast number of extensions that may aid in giving you feedback about your code. (heh, just one sentence about the tool itself)

After learning the basics of HTML and CSS/LESS (and possibly JS), you're highly encouraged to move to a web framework in another language anyway; see Ruby on Rails, Django for Python, NodeJS, you name it. They abstract from HTML (or at least provide templating) to reduce redundant text and they provide meaningful interaction with the server (if you have 5 bananas on your name on one computer, you want to have 5 bananas on another computer when using the same name).

User avatar
jestingrabbit
Factoids are just Datas that haven't grown up yet
Posts: 5967
Joined: Tue Nov 28, 2006 9:50 pm UTC
Location: Sydney

Re: Learning HTML and CSS

Postby jestingrabbit » Mon Jan 18, 2016 7:58 am UTC

One of the reasons I'm currently using Brackets is that its written for and with html5, CSS and javascript, and its clear to me that those are the desired skills atm, as well as understanding the stack and being able to make it work. I really was just enquiring about the tool itself, whether other people had better ideas about editors and environments to write and design in. I understand that all the stuff from 2008 in this thread isn't even worth worrying about at this point, responsive design was barely a thing, and html5 wasn't a thing.

I genuinely just want someone with actual current experience to give me a yay or nay on brackets at this point.
ameretrifle wrote:Magic space feudalism is therefore a viable idea.

DaveInsurgent
Posts: 207
Joined: Thu May 19, 2011 4:28 pm UTC
Location: Waterloo, Ontario

Re: Learning HTML and CSS

Postby DaveInsurgent » Fri Jan 22, 2016 4:16 am UTC

I switched from Brackets to Atom. They are very similar, but Atom felt more polished and has thus far (6+ months) been more stable, had less plugin problems and so on..

The Brackets codebase is already kinda .. :|


Return to “Coding”

Who is online

Users browsing this forum: Yahoo [Bot] and 11 guests