/tech/ - Technology★

Stop being a lazy nigger and write your websites the right way. I don't know a single advantage of only using HTML styling, browsers only render it for legacy purposes

CSS is great but there should be NO dropping of tags. If I want to use <center> or whatever, I should be able to.

>>906344

But why would you want to?

>>906348

Irrelevant, I want to and that's it. You allow them to delete a tag, and before you blink, you can't do <table> anymore (which is NOT AT ALL replaced by display:table).

>>906351

but goy, you can just make a jpg table to embed into your website :^)

>>906353

Man, don't laugh. I've been "convinced" to replace html tables by CSS tables, and spent HOURS trying to do that with display:table, and it doesn't fucking work. In the end I came back to the old, reliable tables, which JUST FUCKING WORK. The OLD STUFF WORKS, leave it alone, "modernizers".

>>906351

>you can't do <table> anymore (which is NOT AT ALL replaced by display:table)

"table" is a broken tag to begin with. It's only two-dimensional. Just as there should be h1, h2, ... h37, h38, ... h7492, there should be no "tr" and "td", but only t1, t2, ... t49, t50, ... t12854. Likewise, "li" should be dropped, because it's synonymous with t1.

>>906351

>you can't do <table> anymore (which is NOT AT ALL replaced by display:table)

"table" is a broken tag to begin with. It's only two-dimensional. Just as there should be h1, h2, ... h37, h38, ... h7492, there should be no "tr" and "td", but only t1, t2, ... t49, t50, ... t12854. Likewise, "li" should be dropped, because it's synonymous with t1.

>>906369

<header level=3>Some Shit</header>

>>906351

If you insist on your own semantic for "center," for instance for some kind of topographical language in which "center" stands generically for "middle location" as in "<center>Building 3</center>," feel free to create one. But do not type documents employing such as HTML; they are not and you are objectively making a mistake doing so. You do not get to determine HTML tags' meanings.

>>906371

This is good, but let me know when they allow me to do four-dimensional tables normally. It's ridiculous to have to use

><tr><td><ul><li>1, 2<li>a, b</ul>...

>>906373

(I can already do this using XML namespaces, display:list-item, and content:, but I want respective elements to be standardized.)

>>906384

Do your formats of choice support standardized markup? If not, then it is a bad choice that hurts operability, such as automated parsing. Please use a standardized format and don't require users to parse linebreaks and indentations on their own.

>>906373

>>906376

Demo:

<what_tables_should_look_like>
<style xmlns='http://www.w3.org/1999/xhtml'>
t { border: .1em solid black; padding: .25em; margin: .25em; }
table > t { display: table-row; }
table > t > t { display: table-cell; }
table > t > t > t { display: list-item; }
table > t > t > t > t:not(:last-of-type)::after { content: ', '; }
</style>
<table xmlns='http://www.w3.org/1999/xhtml'>
<t>
<t>
        <t><t>1</t><t>2</t></t>
        <t><t>1</t><t>2</t></t>
</t>
<t>
        <t><t>1</t><t>2</t></t>
        <t><t>1</t><t>2</t></t>
</t>
</t>
<t>
<t>
        <t><t>1</t><t>2</t></t>
        <t><t>1</t><t>2</t></t>
</t>
<t>
        <t><t>1</t><t>2</t></t>
        <t><t>1</t><t>2</t></t>
</t>
</t>
</table>
</what_tables_should_look_like>

>>906351

Style tags should be dropped since HTML should be purely semantic.

<center>

<table>

If everything is done properly then you can just use your own stylesheet when viewing websites and have it look the way *you* want it. Also works for non standard outputs like TTS because the schema is semantic.

Alas this will never happen again because muh js.

>>906441

><center> should be dropped

That's stupid. It's a span with center as default css when css is enabled. It's pretty useful otherwise people will make a <span class="center"> to make up for the loss which is computationally more unefficient.

I would even propose a <left> and <right> and <block>. The left so you can have it inside the others

Now they make useless shit like <em> which doesn't do anything else then <i> but is "defined after purpose instead of style" which means NOTHING just wasted complexity and less conformity.

That said your page should look nearly the same with CSS disabled and fully working without JS. Install uMatrix and check it.

Also don't ever use button. Just use <input type="button"> instead.

>>906446

You get weird looks these days if you use optical media, and you want people to go back to some 80s networking technology?

>>906384

>I have deprecated the web and will only make new pages for gopher from now on

I'm moving this way too. nroff is the shit for ASCII styling.

Nice webm.

>>906455

So what? People are all over retro game consoles, even old computers to some extent. So it's not that far-fetched. Let's face it: the modern world is full of shit, and people miss the simpler times, when computing was actually fun.

>>906446

>You can use whatever markup you want with gopher, so long as it's ASCII. You could even use HTML but it would be ugly as fuck, because nobody wants to read raw HTML.

This is functionally equivalent to supporting nothing. My question was in hope of a preexistent format, either equipped with a semantic like HTML of merely syntactical like XML, which would facilitate parsing and extraction. If the protocols you mention support any text document at all, then people will probably ignore or misuse formatting, sending whatever at all to users/user agents. This is not a solution. The solution would be a general-purpose semantic format like HTML, only without what ended up being the bane of HTML, namely accepting malformed or invalid inputs on readers' part. Syntactic and semantic validity (incl. schema reading) or screen of death.

>>906448

>otherwise people will make a <span class="center"> to make up for the loss which is computationally more unefficient

This is because 98 % of people are retarded monkeys who cannot conceive of a document being used away from and abstracted from visual representation, in which contexts directions are meaningless: speech generation, as the other anon said, but also general automated structural analysis by programs.

Also,

>>906448

>more unefficient

just say "less efficient." It's more efficient.

>>906476

unefficient < less efficient < inefficient

/2¢

>>906464

I agree, but 99% are conformists who accept whatever is there (lest they become "luddites" and outcasts etc.). How would you operate gopher/bbs services which are actually relevant these days and not just some nostalgic hobbyist thing?

>>906384

I'm not trying to praise the web, but gopher sucks. Why not use something better?

>>906493

Literally what?

Any hierarchical structure is basically web x.0.

Do you propose a different balance between linking and inclusion, different point of split between filesystem hierarchy and in-document hierarchy, intrinsic integration of conditional or loop structures into markup in terms of generating the final document tree, integration with networking resources, better integration with user interface, or what?

Any other changes are just redressing of same old HTML and thousand other formats.

>>906493

>>906496

>better integration with user interface

As by a semantic describing user decision flow, think, off the top of my head,

><choice mandatory='yes' permanence_condition=... between=...

><change severity='major' scope='account,data' ...

>>906448

You are what's wrong with web development.

>>906502

Hey, at least he had the imagination to propose his own elements. This is important; he's not beyond redemption.

>>906502

>use more Javascript and CSS make sure every site can be keylogged with CSS alone

no you

I would probably remove more unused or evil shit only evil people use than I would add.

-WebGL

-WebUSB

-ALL javascript referrer and popups

...

list is nearly endless

>>906504

On wikipedia you wouldn't even need SSL when you're not writing/logging in/logged in since URLs aren't encrypted anyways.

>>906504

>imagination

He wants <left> and <right> tags, but he forgot <float-left> and <float-right> and about 3 dozen more visual semantics. We need to get this web development innovator to the WWW committees immediately so they can learn from his insights.

>>906510

>use more Javascript and CSS make sure every site can be keylogged with CSS alone

You don't understand. Semantic web would be the end of external CSS.

>And usability by sensually impaired people can't really be as big of a factor as they say it is, right?

The modern web can be a nightmare if you're (color)blind.

Dumb fullstack numales make shit that runs on a bigass iMac in San Fransisco and nothing else.

>>906503

>http://textfiles.com/directory.html

This is good website design.

Still looks perfect on my modern monitor.

>>906514

No, it wouldn't and you can't tell anyone that <span class="bold"> is better than <b>

External CSS sucks anyways and the server should put the site together.

>>906503

>Clearly you want a one-size fits all, universal perfect solution that's enforced everywhere

I don't believe you'll ever get everyone on the same page as to what constitutes the ideal markup

No, I definitely don't think a single format (or rather, semantic) would serve everyone. I didn't point this out, but a namespacing solution of one kind or another would be necessary. This doesn't necessarily mean XML, of course; it would only need to provide a mechamism for expression of the general namespace-node-subnodes-parametres model.

Such a model could even allow for representation of binary formats, in fact, cf.

<node namespace='http://saveformat.of.some.obscure.80s.game'>

<field endianness=...>2</field>

<field endianness=...>126</field>

...

>it's just more complication than what I'm looking for

Yes, less complication on your egoistic local part, you disingenuous ass. Your local simplification of your document server software would be easy on you, but will necessitate global redundancy in terms of people having to write their own parsers for every single hand-written document that you host which otherwise could have been formatted consistently and parsed easily. Ethical software does not refer only to its liberty.

>that's great. That's my fucking paradise, man! Halleluyah! No fucking bullshit shackles and all the crap you see in today's world with endless libraries and frameworks and all that shit

This thread is by very virtue of its community about communal, consistent, socially viable solutions to data sharing. If you want to host completely inconsistent data, feel free, but you contribute nothing in the popular sense.

>>906517

>you can't tell anyone that <span class="bold"> is better than <b>

My dude, you don't need to put a fucking class attribute on every element you want styled. The location of the span tag is enough in a well-structured document.

>>906513

To be fair, it would be trivial to make a browser add-on that would understand style wrapper elements.

<text-align='center'><header>Hey!</header></text-align>

being equivalent to

<header style='text-align: center'>Hey!</header>

<display='block'>Hello world!</display>

being equivalent to

<span style='display: block'>Hello world!</span>

etc.

>>906518

Ah, so you think I'm egotistical for not wanting to play by your made-up rules, huh? Everyone must do as you say, because you're the king, all-knowning and wisest of them all.

Protip: you parse text philes with your eyes. Why would we make it easy for the likes of google and other cianiggers to crawl our stuff? Fuck them.

>>906517

>>906520

Worse. <span> tags are literally never necessary. They have no semantic by definition, and even in space-saving sense, they are longer than an XML namespace plus one-letter tag name, eg.

<a:b>foo</a:b>

>>906524

Fuck off to /b/ or whatever the containment board is on this website with this noise.

>>906518

>completely inconsistent data

>because of not using CSS

found the retard.

>>906520

Look at this website. It often occurs mid sentence

>>906513

These are for text. It doesn't make sense to use them for layout. THERE IS NO text-align:float-left

>>906525

>XML namespace

more unnecessary shit. Do you know how over complicated it already is? Don't make it more shit.

>>906526

Right, good day to you too. May you bow forever to the WEB AUTHORITIES.

>>906525

>XML namespaces

Absolutely superfluous for documents that aren't embedding behavior.

>>906527

>It often occurs mid sentence

So? That doesn't change anything I said. You can still use the structure of the document to select it, especially with proper use of the "id" attribute. This is still not a reason to abuse classes.

>>906527

>namespaces

>unnecessary

Okay, you retard. Just don't let the realization hit you as you one day type, off the top of my head, "RMS Titanic" or "New York" and remember that as soon as you type "RMS" or "New" respectively, you are literally using a namespace.

>>906529

>Absolutely superfluous for documents that aren't embedding behavior.

I literally just gave a case in which they prevent superfluity in the most countable of senses.

>>906529

>use of the "id" attribute

That's even more stupid. It would mean the server would have to generate custom CSS for text parts like this: TEXT

>>906530

feels good to not be american

>>906530

>all contextual information must be organized into namespaces

>never flatten your data

Found the over-engineering autist.

>>906534

I said "proper" use of. Nice scarecrow. The fact is, span tags in the middle of text can still be structurally selected in a well formed document.

>>906540

You never defined what "proper use" is and it does not work with user generated content.

>>90653

>>all contextual information must be organized into namespaces

>>never flatten your data

I'm not saying that. I'm trying to talk sense into a guy who considers namespaces unnecessary without qualification.

>>906540

It is good to remember about :first-letter and :first-word, too, which also take away certain uses of <span>.

>>906543

(Quoting >>906536.)

>>906543

>>906544

Unlike namespaces I think those are pretty useful and can be used for those traditional newspaper capitals and stuff like that. Without them the page stays perfectly viewable.

>>906542

Are you asking me for a HTML tutorial?

>>906329 (OP)

No, HTML must be purely semantic, putting presentational tags into HTML is killing usability for people who rely on assistive technology. Tags like <b> or <i> should never be used. What does it mean for text to be italic? Is it emphasized, is it a Book Title, is it a quotation? Italic means nothing. What does it mean for a paragraph to be centered? Is it a quote or do you simply like the way it looks? Using semantic tags allows the interpreter to know what the meaning of the element is, so it can for example be pronounced accordingly by a screen reader for blind people.

While we're at it, all the <h1>, <h2> and so on tags should be deprecated as well. Instead there should be one generic <heading> tag and the nesting of the containing sectioning tag should determine the level of the heading.

Visual styling of the document can be done with CSS. You should not use classes, instead let the CSS style elements based on their parents or siblings. A well structured document can go by without any presentational hacks in the HTML.

>>906557

Hell <b>no</b>.<- How would that be shorter in your proper variant?

I also didn't say you should format all content like this.

>>906562

>Is it emphasized, is it a Book Title, is it a quotation?

Italic means emphasized in a quote sense

Bold means emphasized as in emphasized/important

This is cultural knowledge you retard and can be represented perfectly.

Go back to >>>/reddit/

>>906562

The web is a shitty place for people with no eyesight to begin with.

Pretending it's not and the website authors suck won't help them.

>>906565

I just noticed that a blind person doesn't even need to know what's bold or italic since it rarely offers extra information.

>>906533

>You should not use classes, instead let the CSS style elements based on their parents or siblings.

There is an issue of maintainability here. For a particular document, relational hooks may suffice to style it* fully, but as further documents are added to the site, a certain relational selector may suddenly begin to catch too little, or too much. Then you also need to rewrite the document all of a sudden to add the necessary class attribute after all. Sometimes, proper -- semantic, non-redundant with respect to HTML -- classing is called for for sake of being future-proof.

*Or operate on it in any other automated manner.

tl;dr do not intrinsically avoid classes. Use them when they're, well, justified. Anticipate your users' needs; think if a particular element is likely to need a simple hook that would save users from tedious traversal.

>What does it mean for text to be italic? Is it emphasized, is it a Book Title, is it a quotation? Italic means nothing.

It means it came from Italy you moron.

>>906562

>>906569

(I think I understressed the fact that styling is only one and rather particular application of element addressing. While CSS is certainly ubiquitous, and can be used outside of the web and outsite of XML family in fact, there are countless parsers that need to traverse the tree in more direct ways. Use classes for their sake as well; in their case, the alternative would be really painful.)

>>906571

>can be used outside of the web and outsite of XML family

ROFL, you could say the exact same about HTML and javascript but it makes zero sense.

>>906569

>rewrite the document all of a sudden to add the necessary class attribute after all

No some thing DO NOT CHANGE like this: BOLD because I defined it to be bold. If I definied it to be a quote then a class would be justified.

>>906571

Not even XHTML is XML complient

>>906572

>>can be used outside of the web and outsite of XML family

>ROFL, you could say the exact same about HTML and javascript but it makes zero sense.

What makes zero sense about it? JS, or whatever its standard is, is a general-purpose language. Likewise, it is quite hard to think of syntactical elements of CSS that are tied to the XML family beyond the model of named elements plus named attributes. The only case I can think of is dedicated CSS namespace selector.

>>906573

Please explain.

>>906563

>Hell <b>no</b>.<- How would that be shorter in your proper variant?

I don't know why some programmers are obsessed with the notion that "shorter = better". The semantic, proper way to emphasize inline text is with <em> tags. As a previous anon said, semantic code allows for agnostic consumability e.g. for assistive technology, but beyond that as well.

>>906572

>>906579

(By which I mean, CSS can be used for addressing in any hierarchical named structure.)

>>906579

Using any of them outside the web is stupid even on the server side. Windows help documentation was in HTML but old HTML without CSS or JS

The people which use something like NodeJS are pajeets with low pay producing slow shit websites.

>>906580

<b> means emphasized too <em> does not make it better. IT ONLY MEANS MORE TEXT

>agnostic consumability e.g. for assistive technology, but beyond that as well.

no it doesn't what those people would need is the correct use of <p>s and not endless garbage tags.

>>906563

The proper way is to use <em>emphasis</em> or <strong>hard emphasis</strong>. How you render these is up to the style sheet. Usually it's displayed as italic and bold respectively, but it could also be red text and underline.

>>906565

>>906568

Blind people do know what emphasis is, you pronounce emphasized words differently from regular words. When your markup says "this word is in italics" it doesn't mean shit, but when you say "this word is emphasized" the interpreter can style it accordingly, either by typesetting it in italic or pronouncing it differently.

>>906588

>it could also be red text and underline.

While you are correct generally, you ironically chose the shittiest possible examples for your point. Signifying by color is disapproved of for sake of color-blind people, and underlining is easily confused with links. There is a reason that emphases are signified by slant and boldness; those are two most visually distinct and failproof methods.

>>906588

><em>emphasis</em> or <strong>hard emphasis</strong>

This makes zero difference and if you need hard emphasis you could make a class.

In fact it's better to have a low common denominator! Such as <b> <i> <sub> <sup>

It makes it easy to recognize and interpret with special software

>you pronounce emphasized words differently from regular words

But it's normally unimportant and doesn't give the text a new meaning.

>"this word is in italics" it doesn't mean shit

no it means: "this word is emphasized"

>>906601

If you want to have special red text that would be the best method

It's also used right on this page for red text.

>>906569

>There is an issue of maintainability here. For a particular document, relational hooks may suffice to style it* fully, but as further documents are added to the site, a certain relational selector may suddenly begin to catch too little, or too much. Then you also need to rewrite the document all of a sudden to add the necessary class attribute after all. Sometimes, proper -- semantic, non-redundant with respect to HTML -- classing is called for for sake of being future-proof.

I agree. This is why large websites don't write raw CSS. They use an abstraction layer on top of it which allows for mixins, such as LESS.

https://en.wikipedia.org/wiki/Less_(stylesheet_language)

>>906608

>Less allows real-time compilation via less.js by the browser.

How can we turn bullshit into more bullshit?

The answer is Less.

>>906592

So what if I want to use italic text to style the title of a book like Structure an Interpretation of Computer Programs, is that that supposed to be emphasized as well? You can use italics for different purpose. This is why the distinction of semantics (what it is) and presentation (what it looks like) is important.

>>906590

Then replace red by ALL CAPS. That's a reasonable thing to do if the font lacks a bold typeface.

>>906614

>distinction

The difference between the use cases isn't as important as you think. If the device says its italic it's italic. Then everyone lives in the SAME reality and there are no misunderstandings.

Almost all humans have eyesight. There is no purpose in this. The ones which don't are better off adapting to our reality than the other way around.

>>906612

t. self-taught PHP programmer

LESS can be precompiled. You don't have to use less.js, and if you had actually ever done web development, you'd know how handy dynamic compilation is during debugging.

>>906614

>You can use italics for different purpose. This is why the distinction of semantics (what it is) and presentation (what it looks like) is important.

I humbly suggest that you overlooked a funnier example. Namely, emphases may be nested.

>I really really <em>really really really <em>really</em></em> fucking hate you.

This makes sense. Nesting <b> or <i> (nearly) doesn't.

>>906614

Also, stop replying to bad bait.

>>906625

That's a great example! I'm sure the 90's web dev shitting this thread up with his "sage is downboat" 'sperg out will ignore it though.

>>906624

>precompiled

>fucking documents

This is some retardism it's like the precompiled version of JQuery of CSS.

>>906625

>>906629

>nesting em tags

That's even more horrible and I'm pretty sure there is NO interpreter that can make use of that in existence because tags get turned into generic objects and their kind into "default CSS" and then interpreted from there.

>>906633

>like jQuery

No it delivers static CSS to the browser. It's no different than server-side scripting. Damn, you're not even a PHP programmer, you're like... some sort of retarded techno-LARPer. Just sad.

>NO interpreter that can make use of that in existence

Sad.

>>906633

>I'm pretty sure there is NO interpreter that can make use of that in existence

It's almost like updates to the HTML specs, such as the one that introduced "em" and "strong," move on from limited presentational semantics to expanded functional semantics for specific purpose of encouraging interpreter makers to come up with treatments of all possible configurations of those tags, that are as useful to end user as possible.

tl;dr the fact that interpreters (incl. majority of stylesheets) fail to represent a certain configuration of tags (such ad nested emphases) in an appreciable manner only speaks of the interpreters, not of the specs.

>>906638

(Another example would be, for instance, a hypothetical scenario if nested tables had been forbidden for some reason. Then, allowing them in a subsequent version of the specs would not be useless, but rather encourage markers-up to remember that there are valid reasons for such nesting.)

>>906329 (OP)

The white man uses plain HTML. CSS is nigger technology.

I mean if you want to increase the size of the trusted code base, yeah it makes perfect sense to require CSS in order to do anything useful beyond what can be done with a plain ASCII or UTF-8 file.

>>906343

Because it's easier and more practical to type

<b>kill</b> yourself

than

<nigger thing=css compatability_mode=415761>
.le_emphasized {
font-weight: normal;
.moz_pos: lol;
}
</nigger>
<span class=le_emphasized>kill</span> yourself

And a white man's browser like Links will just ignore CSS anyway (which means every document looks the same, instead of pink and green text with 300mb of fonts and pointless cringly looking laggy animations with screen tearing, input lag, and motion blur), while supporting simple tags like <b>

>>906654

>a white man's browser like Links will just ignore CSS anyway

There are console browsers that support CSS.

>>906637

I wrote: precompiled

I clearly understood but I still think it's overcomplicating the problem

>retarded techno-LARPer

fuck off

>Sad.

It's good you autist. Otherwise people would start designing there website that way because it's "the latest hype"

>>906638

>encouraging interpreter makers to come up with treatments

>fail to represent a certain configuration of tags (such ad nested emphases) in an appreciable manner only speaks of the interpreters, not of the specs.

>making up such retarded excuses

now that's sad

>>906654

Couldn't have said it better.

>>906654

>>906663

>screen reader: emphasis lost

>simple screen: emphasis lost

>simple printer: emphasis lost

>tactile expressor: emphasis lost

>linguistic analyzer: emphasis lost

>search engine: emphasis likely lost

Also: as soon as you say "but <b> has acquired the semantics of emphasis anyway," you literally agree that creation of <em>" was a good idea.

No, you didn't and don't understand. You compared precompiled LESS (server-side) with jQuery (client-side).

>>906669

I don't really follow that subdiscussion, but now I'm looking it up, I see that that Less thing can be interpreted client-side too, and likewise I think there is nothing inherently impossible about a script that would translate jQuery-written scripts to vanilla JavaScript for reuse elsewhere.

>>906670

>I see that that Less thing can be interpreted client-side too

You wouldn't deploy to production with the interpreter, but it's definitely useful while debugging. Propping up a poor use case as reason for denigrating the technology itself is a strawman fallacy.

>jquery to vanilla JS compiler

Why on Earth would you do this? It doesn't eliminate client-side JavaScripting like precompiled LESS does?

>>906666

>wasted dubs

>literally agree that creation of <em>" was a good idea

No I don't it's redundant and reduces compatibility.

>>906669

Precompiled always means server side and I just wanted to say it's horrible by comparing it to JQuery.

Abstracting the abstracts things imaginable is fucking autism. I'm not sure you'll actually save computation on user created content when you have to recompile the css after each post.

>>906672

>I just wanted to say it's horrible by comparing it to JQuery.

Seems like a backpedal, unless you literally just use jQuery as an arbitrary point of reference for anything that's shitty. As far as LESS use cases, you wouldn't want to use it on every project. Here's a website that uses LESS:

www.uverse.com (I was on the dev team there)

The little tiles representing video content have to appear consistent on many different pages, in many different containers, all of which have their own styling rules. Using LESS let's you do this pretty easily. With pure CSS, it would be a nightmare, with a shitload of duplicate code (and weird rules/workarounds which would stress the browser and cause performance issues).

>>906671

>Propping up a poor use case as reason for denigrating the technology itself is a strawman fallacy.

I don't dislike Less. Calling it "thing" didn't mean disrespect, but my unfamiliarity with it. I was just pointing out it's similar to jQuery.

>Why on Earth would you do this? It doesn't eliminate client-side JavaScripting like precompiled LESS does?

Yes, but it could still remove framework overhead. Don't read too much into that post; I was just stating those tools' likeness.

>>906672

>reduces compatibility

According to your "reasoning," literally any innovation, for instance, introduced to increase usability and reduce ambiguity as in case of b -> em, "reduces compatibility" because of lack of adoption of the updated version at first. Better start campaigning for termination of all software development on that basis.

>>906676

Fair enough, sorry if things are a little heated lol

>>906675

https://en.wikipedia.org/wiki/Less_(stylesheet_language)

#header {
  h1 {
    font-size: 26px;
    font-weight: bold;
  }
  p {
    font-size: 16px;
    a {
      text-decoration: none;
      color: red;
      &:hover {
        border-width: 1px;
        color: #fff;
      }
    }
  }
}
The above code in Less would compile to the following CSS code:

#header h1 {
  font-size: 26px;
  font-weight: bold;
}
#header p {
  font-size: 16px;
}
#header p a {
  text-decoration: none;
  color: red;
}
#header p a:hover {
  border-width: 1px;
  color: #fff;
}

So does it just increase the amount of parentheses? Can't see any advantage over writing CSS directly tbqh fam

>>906676

>spacing

>behaving like spacers do

Nothing I didn't expect.

>>906654

<strong>kill</strong> yourself, <em>Pajeet</em>

>>906683

>&:hover

This is cool.

I would like pure CSS

* & { foo: bar; }

to catch any descendant with a same-named ancestor, for instance.

>>906675

>www.uverse.com

>specifies XHTML

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" version="XHTML+RDFa 1.0" dir="ltr" xmlns:og="http://ogp.me/ns#" xmlns:article="http://ogp.me/ns/article#" xmlns:book="http://ogp.me/ns/book#" xmlns:profile="http://ogp.me/ns/profile#" xmlns:video="http://ogp.me/ns/video#" xmlns:product="http://ogp.me/ns/product#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/terms/" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:sioc="http://rdfs.org/sioc/ns#" xmlns:sioct="http://rdfs.org/sioc/types#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:schema="http://schema.org/" class="js no-touch"><head profile="http://www.w3.org/1999/xhtml/vocab">

>normal html

>more script and style tags then I've ever seen

>8 third party sites embedded

>I'm proud of the site

As expected: all talk

>>906685

<strong>kill</strong> yourself, <i>Pajeet</i>

>>906688

*<b></b>

>>906688

Meant for

>>906684

>>906688

Don't put words into other people's mouths, shitbaiter.

Regretfully, I need to age, not sage, this thread with this post.

>>906688

I was just giving an example of a use case for LESS, but nice try.

http://motherfuckingwebsite.com/

>>907176

I fucking love this.

(Also "skeuomorphic" may be the nerdiest word I've ever seen.)

That said, in terms of markup, it would be even better if the three "It's..." blocks of header plus explanation were simultaneously members of a list, in <li>'s.

>>907176

>>907180

>google analytics

You love it up the ass, right?

>HTML5 tags

>uses two html5 tags (header and aside)

>both of them are useless garbage

shit page fam