December 15, 2011
On 2011-12-14 10:55:26 +0000, Robert Clipsham <robert@octarineparrot.com> said:

> On 14/12/2011 10:12, Andrei Alexandrescu wrote:
>> On 12/12/11 7:46 PM, Stewart Gordon wrote:
>>> On 06/12/2011 05:44, Andrei Alexandrescu wrote:
>>>> http://d-p-l.org
>>>> 
>>>> Andrei
>>> 
>>> Why does it have an HTML 4.01 doctype but then go on to use XHTML
>>> syntax???
>>> 
>>> Stewart.
>> 
>> I wouldn't know. What needs to be done?
>> 
>> Andrei
> 
> http://validator.w3.org/check?uri=http%3A%2F%2Fwww.d-programming-language.org%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

( 
> 
> http://goo.gl/pxtQE - the same link, just in case the above one gets wrapped and doesn't work)
> 
> Basically, xHTML uses <foobar />, html uses <foobar> or <foobar></foobar> depending on the tag.
> 
> The rest of the issues are with non-standard tags, eg <nobr> and <font> I think.

HTML 5 says <foobar /> and <foobar> are equivalent and both valid for elements that are not expected to have a closing tag. What happens in practice, with any HTML version, is that browsers just ignore the "/". Maybe using the HTML 5 doctype will make the validator happier (although it might start to complain about other things):

	<!DOCTYPE html>

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

December 16, 2011
On 14/12/2011 10:12, Andrei Alexandrescu wrote:
> On 12/12/11 7:46 PM, Stewart Gordon wrote:
>> On 06/12/2011 05:44, Andrei Alexandrescu wrote:
>>> http://d-p-l.org
>>>
>>> Andrei
>>
>> Why does it have an HTML 4.01 doctype but then go on to use XHTML syntax???
>>
>> Stewart.
>
> I wouldn't know. What needs to be done?

Are you saying someone else put that doctype there behind your back?  Or that you found it on a lot of webpages and just copied it without any clue of what it means?

Since what you've obviously learned is a mishmash of old-fashioned HTML, modern HTML and XHTML, the first step would be to learn the differences between them.  This will get you started:
http://www.w3schools.com/html/html_xhtml.asp

My preference nowadays is to use XHTML Strict

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

though I may still use other doctypes while maintaining sites that have been around for a long time, like XHTML Transitional

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

The main difference between Strict and Transitional is that Transitional includes legacy presentational elements and attributes whereas Strict doesn't.  The proper way to do things nowadays is to write the content and structure in (X)HTML and use CSS for the presentation.

But whatever I try to validate it as, there are errors.

A good plan would be to change it to XHTML 1.0 Transitional and fix the handful of validation errors that still show up.  I can help you to do this.  Once you've got your head around these, you could consider migrating to XHTML 1.0 Strict.

Stewart.
December 16, 2011
On Friday, 16 December 2011 at 13:33:06 UTC, Stewart Gordon wrote:
> But whatever I try to validate it as, there are errors.

Does validation make any positive difference at all?

I used to do it, but it prohibits things that are useful
and work fine in practice* without offering much, if anything,
in return.

I've found that checking for well-formedness - that your tags
are closed, attributes quoted, and entities encoded - is worth
it, but the structure imposed by the doctype offers almost no
help.

* An example being custom attributes. The html5 validator will
allow some of them, but the other ones won't.
December 16, 2011
On 12/16/2011 5:33 AM, Stewart Gordon wrote:
> Or that you
> found it on a lot of webpages and just copied it without any clue of what it means?

You can blame me for that, not Andrei.
December 16, 2011
"Adam D. Ruppe" < destructionator@gmail.com> wrote in message news:virlzxfnfkylbbccepoz@dfeed.kimsufi.thecybershadow.net...
> On Friday, 16 December 2011 at 13:33:06 UTC, Stewart Gordon wrote:
>> But whatever I try to validate it as, there are errors.
>
> Does validation make any positive difference at all?
>
> I used to do it, but it prohibits things that are useful
> and work fine in practice* without offering much, if anything,
> in return.
>
> I've found that checking for well-formedness - that your tags are closed, attributes quoted, and entities encoded - is worth it, but the structure imposed by the doctype offers almost no help.
>
> * An example being custom attributes. The html5 validator will allow some of them, but the other ones won't.

I've come to figure the same thing. I like to keep things as compliant as I can within reason, but I've been wondering more and more how strict it's really worthwhile to be.

For example, I have an articles section on my site that (currently) uses TangoCMS. I neither know nor care what doctype TangoCMS is sending out (and I have even less interest in mucking with it's internals to change it), and yet when I want to bold or italicize something in a post, I've started going back to <b> and <i>. Why?

A. They're not as insanely verbose as <span style="font-weight: bold; font-style: italic"> (And they're much, MUCH easier to remember: Is it "text" or "font"? Is it "-bold", "-weight", "-italic", "-style", "-slant", "-skew" or some nonstandard made-up term like "text?/font?-decoration: line-through"? Who has *ever* called that anything but strikeout?). Or even <span class="bold"> (And even at that I'd have to go out of my way to go grab and mess with the CSS files).

B. It works. On everything.

C. Let's face it, it's always going to work.

D. I don't give a rat's ass about the purity of HTML "content" vs style. (X)HTML *is* presentation if you ask me: the content is in the model, and that's stored in a DB, not XML files. And it all renders the same anyway. And seriously, who's going to be applying a custom stylesheet to my pages? (and if they do, they can just change the defined styles for b{} and i{}).

E. The W3C can kiss my ass ;)


December 16, 2011
On Friday, 16 December 2011 at 18:28:07 UTC, Nick Sabalausky wrote:
> I've started going back to <b> and <i>. Why?

I find this generally sane, but I can't agree with D. (lol)

> And seriously, who's going to be applying a custom stylesheet to my pages?

My work D project recently brought on a new designer. Unlike
the old designer who would mock it up and send me a picture,
the new guy actually edits the site himself.

But, he doesn't have access to all the html, and what he does
have access to, I don't want him to edit anyway.

He restyles the whole site through css; applying a custom
stylesheet to my page. (He, and the boss, fought this for
a while, but I think they are seeing the benefits of my
approach since I pushed back on it.)


It works quite well - the html I output doesn't have to change
for each client, so adding new content doesn't require any
repetition. We just do another stylesheet adjustment. The
same html can be dropped in many places too.

When they wanted the news added to the sidebar, I just said
document.requireElementById("sidebar-new-holder").appendChild(
 getNews().toHtmlElement());

and the sidebar css adjusted it; I didn't have to write new
queries or templates. Very convenient.




The important thing though is to make sure the html describes
the data well. Once you put in any kind of presentation in there,
you break this approach.

class="red" no no, what if it's a blue theme?

class="brand-name" there we go.

class="grid" no no, what if we want it in a linear column?

class="news-item" there we go.

and so on; the html describes the data in as much detail as is
reasonable and the css makes the rest work.
December 16, 2011
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:anfqlbdugtkomnzbuqxf@dfeed.kimsufi.thecybershadow.net...
>
> The important thing though is to make sure the html describes the data well. Once you put in any kind of presentation in there, you break this approach.
>
> class="red" no no, what if it's a blue theme?
>
> class="brand-name" there we go.
>
> class="grid" no no, what if we want it in a linear column?
>
> class="news-item" there we go.
>
> and so on; the html describes the data in as much detail as is reasonable and the css makes the rest work.

In many cases I do agree, but there are some problems:

A. While CSS is acceptable for styling (though I would change some things), it's pure shit for layouts.

CSS3 doesn't change my mind on that. And beyond that, I have zero faith in W3C's ability to ever contrive "(X)HTML and CSS" into a real "model and view". No matter how much we *want* (X)HTML to be purely data-description, it just *isn't* and likely never will be.

B. When you're talking about *inside* an article or posting, etc, all of that *is* the content. If the author intends something to be bold, italic, red, green, blue, whatever, then they should be able to specify it as such and not some vague psuedo-equivalent like "emphasis", "comment", "string literal", etc, that may or may not exist in the site's CSS and may or may not always even be what the author really wanted anyway.

C. You may be operating with a workflow where the web designer is CSS-only, but that's not always the case, and I think reasonable argments can be made for doing it differently (point "A" above, for example).


December 16, 2011
On Friday, 16 December 2011 at 21:19:27 UTC, Nick Sabalausky wrote:
> A. While CSS is acceptable for styling (though I would change some things), it's pure shit for layouts.

I wouldn't say that, completely. I do use a html template,
but only for the outer layouts; it's a frame of sorts that
I can put content into.

The content itself gets by pretty ok with css as long
as you group it. Sometimes the order of appearance matters
(ugh ugh ugh, I hate css float especially) but it's not
bad most the time. Not perfect, but it gets the job done.

> B. When you're talking about *inside* an article or posting, etc, all of that *is* the content.

Yes, for the most part. I'd still say specify only what
needs to be specified for the content, so then it fits
in better with the user's environment. (In this case,
it's perverted in that the user is the web designer, but
it's the same idea.)

So <i>is cool</i>, but <body color=""> is probably bad.

> C. You may be operating with a workflow where the web designer is CSS-only, but that's not always the case, and I think reasonable argments can be made for doing it differently (point "A" above, for example).

Yeah, that's why I do the hybrid thing, but when they tried to
make the arguments to get more access to the html, I reject them
and so far I think I'm right. (The designer hasn't actually needed
to edit any of the html files I gave him access too!)
December 16, 2011
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:dxjkyeeqrhsgsknfhexb@dfeed.kimsufi.thecybershadow.net...
>
> So <i>is cool</i>, but <body color=""> is probably bad.
>

Yea, I totally agree.

>> C. You may be operating with a workflow where the web designer is CSS-only, but that's not always the case, and I think reasonable argments can be made for doing it differently (point "A" above, for example).
>
> Yeah, that's why I do the hybrid thing, but when they tried to make the arguments to get more access to the html, I reject them and so far I think I'm right. (The designer hasn't actually needed to edit any of the html files I gave him access too!)

It's an interesting problem that's not too dissimilar to what game developers have wrestled with the last so many years: Programmable rendering piplines (pixel shaders) allow phenomenal control over how a surface looks...and that's clearly within the realm of "artist"...but it's actually done with code: the programmer's realm. Artist's can't code. Coder's can't draw. So who does it? And how? A combination artist/coder? Where do you find them? And if you do, how can hope to you afford them?

They've found ways to get by, and have gotten better at dealing with the issue, but it was never an easy problem and it's still not entirely solved.

The problem here is very similar. There are designers who come up with the "look", but their medium is code-based ((X)HTML and CSS), and it's tightly integrated with the full-on code of the programmer's realm. (Personally, I think the real solution here is abandon (X)HTML/CSS in favor of some unified thing that's actually *designed* to be a real presentation layer, and not a hacked up document format, and then create RAD-style editors based on it.)


December 16, 2011
On 16/12/2011 18:26, Nick Sabalausky wrote:
<snip>
> For example, I have an articles section on my site that (currently) uses
> TangoCMS. I neither know nor care what doctype TangoCMS is sending out (and
> I have even less interest in mucking with it's internals to change it), and
> yet when I want to bold or italicize something in a post, I've started going
> back to<b>  and<i>. Why?
>
> A. They're not as insanely verbose as<span style="font-weight: bold;
> font-style: italic">
<snip>

But you shouldn't be using <span style="font-weight: bold; font-style: italic"> anyway. You should be looking at what the boldness or italicness _means_, and either using the appropriate semantic HTML element or (if one doesn't exist) defining a CSS class named after this semantic.

This is also about making code self-documenting.

Stewart.