December 16, 2011 Re: New homepage design of d-p-l.org is now live. <eom> | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Adam D. Ruppe | On 16/12/2011 15:09, Adam D. Ruppe wrote: > 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? Yes: - it's a useful step in diagnosing problems with a webpage - it helps with cross-browser compatibility - it helps syntax-highlighting and code-folding editors - it enables code-manipulation tools to work correctly - it's good for your public image > I used to do it, but it prohibits things that are useful > and work fine in practice* without offering much, if anything, > in return. What are these "things that are useful" to which you refer? <snip> > * An example being custom attributes. The html5 validator will > allow some of them, but the other ones won't. Are custom attributes distinguished from standard attributes in some way, in order to keep attributes invented by different browser manufacturers from clashing with each other and with attributes that become part of a later HTML standard? Stewart. | |||
Permalink
ReplyDecember 17, 2011 Re: New homepage design of d-p-l.org is now live. <eom> | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Nick Sabalausky | On Friday, 16 December 2011 at 22:25:27 UTC, Nick Sabalausky wrote:
> *snip*
I agree pretty much entirely, but meh, when web 2.0 gives
you a turd, you make a shit sandwich and you LIKE it!
| |||
December 17, 2011 Re: New homepage design of d-p-l.org is now live. <eom> | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | On Friday, 16 December 2011 at 23:41:19 UTC, Stewart Gordon wrote: > Yes: I'll agree that some of the validator's things help with that, but not all of it. If you write <a href="#"><div>block in inline</div></a>, the validator will reject it, but it works... and that's a useful thing when doing drag+drop applications (since older IE doesn't let you drag other elements). Though, I can see your point with cross-browser compatiblity, to an extent, as that code sometimes (not always... it can change across refreshes of the same page...) brings out bugs in Firefox 3.6. Anyway, though, the specific doctype still isn't terribly important, since, in practice, tools tend to ignore it anyway. Browsers see it's presence as an on/off switch with standards compliance mode vs quirks mode; declaring the wrong one doesn't break anything. (Indeed, HTML5 has agreed to use the common, previously wrong, shorthand of <!DOCTYPE html> as the new standard!) Stuff like improperly closed tags or bad entity encoding can break, but that's pretty well independent of doctype validation. That's simply a matter of the document being well-formed. > What are these "things that are useful" to which you refer? There's the drag and drop issue from above, the custom attributes thing from below, and sometimes, using certain tags or generally accepted shorthand. (For instance, <script> used to require a type, but it worked without it anyway. Again, the html5 folks decided to adjust the standard to fit the practice - something I actually like about them. This is a really minor thing, though.) > Are custom attributes distinguished from standard attributes in some way, in order to keep attributes invented by different browser manufacturers from clashing with each other and with attributes that become part of a later HTML standard? They are in html5 - the data- prefix is allowed and reserved for the user. In older versions of the html standard, there weren't allowed at all, whether prefixed or not. (They did work in practice, though.) I like custom attributes a lot, since they add a richness that Javascript (and CSS too) can exploit in interactive pages. They're the main thing I miss if I validate with one of the other DTDs. | |||
December 17, 2011 Re: New homepage design of d-p-l.org is now live. <eom> | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Adam D. Ruppe | "Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:xhaizhcmeybruijmptls@dfeed.kimsufi.thecybershadow.net... > On Friday, 16 December 2011 at 22:25:27 UTC, Nick Sabalausky wrote: >> *snip* > > I agree pretty much entirely, but meh, when web 2.0 gives you a turd, you make a shit sandwich and you LIKE it! lol, how true :) | |||
December 17, 2011 Re: New homepage design of d-p-l.org is now live. <eom> | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:jcgkhi$2ohd$1@digitalmars.com... > 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. > If it's actually part of some <span class="concept">ui element</span>, or <span class="concept">widget</span>, or some <span class="concept">standard recurring concept</span>, etc, then yes, I would agree in that case, <span class="person">Stewart</span>. But if it's <i>just</i> ordinary text that simply needs to be <b>bolded</b> or <i>italicized</i>, then handling it in any roundabout way like that is just <i>ridiculous</i> (and "self-documenting" would be completely inapplicable). In such a situation, replacing hardcoded bold or italic with some vague concept of "emphasis" (old-school example: the <em> tag) or "extra-emphasis", etc, is not only a useless abstraction merely for the sake of abstraction, it <b><i>can</i></b> subtly change meaning/interpretation of the actual <i>content</i> because only the <i>author</i>, not the stylist, is able to look at the final result and know whether the result <b><i>correctly</i></b> depicts the amount/type of emphasis intended. Additionally, how does the stylist know if a given styling is going to cause too much visual noise? Or be too visually monotone? They <i>can't</i>, because it's <i>completely</i> dependent on the text that the <b><i>author</i></b> writes. It might be too much visual stuff for one article and just right for another. Only the text's author can know what's appropriate, not the stylesheet. | |||
December 17, 2011 Re: New homepage design of d-p-l.org is now live. <eom> | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On 17/12/2011 06:35, Nick Sabalausky wrote: <snip> > But if it's<i>just</i> ordinary text that simply needs to be<b>bolded</b> > or<i>italicized</i>, then handling it in any roundabout way like that is > just<i>ridiculous</i> (and "self-documenting" would be completely > inapplicable). You miss the point - why would you need to bold or italicise "ordinary text"? If the point is to illustrate what bold looks like, or what italics look like, _then_ it might make sense to use presentational markup.... > In such a situation, replacing hardcoded bold or italic with some vague > concept of "emphasis" (old-school example: the<em> tag) <em> isn't really an old-school example. It's the proper semantic markup for emphasis. > or > "extra-emphasis", etc, is not only a useless abstraction merely for the sake > of abstraction, it<b><i>can</i></b> subtly change meaning/interpretation of > the actual<i>content</i> because only the<i>author</i>, not the stylist, > is able to look at the final result and know whether the result > <b><i>correctly</i></b> depicts the amount/type of emphasis intended. It seems to me that the essence of what you're saying is that the choice of <em> and <strong> is too coarse-grained for your purposes. I'm not sure how best to deal with this either. Moreover, what markup are you going to use so that it looks/sounds/feels right in non-graphical browsers? > Additionally, how does the stylist know if a given styling is going to cause > too much visual noise? Or be too visually monotone? They<i>can't</i>, > because it's<i>completely</i> dependent on the text that the > <b><i>author</i></b> writes. It might be too much visual stuff for one > article and just right for another. Only the text's author can know what's > appropriate, not the stylesheet. If the author is overusing emphasis, manually setting font weights and stuff to compensate seems to me to be trying to fix the wrong problem. Stewart. | |||
December 17, 2011 Re: New homepage design of d-p-l.org is now live. <eom> | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On 17/12/2011 03:10, Adam D. Ruppe wrote: > On Friday, 16 December 2011 at 23:41:19 UTC, Stewart Gordon wrote: >> Yes: > > I'll agree that some of the validator's things help > with that, but not all of it. > > If you write <a href="#"><div>block in inline</div></a>, > the validator will reject it, but it works... and that's > a useful thing when doing drag+drop applications (since > older IE doesn't let you drag other elements). What built-in support does HTML/JS/CSS have for dragging of elements? I always understood that it had to be explicitly implemented in JS in terms of onmousedown/onmousemove/onmouseup or something like that, and therefore cannot in itself be something that some browsers support and others don't. Moreover, dummy hrefs are an abomination. Not just compatibility when JS is disabled - this link is also the one followed when you open a link in a new window/tab. This regularly bites me. <snip> > Anyway, though, the specific doctype still isn't terribly > important, since, in practice, tools tend to ignore it > anyway. Browsers see it's presence as an on/off switch > with standards compliance mode vs quirks mode; declaring > the wrong one doesn't break anything. (Indeed, HTML5 > has agreed to use the common, previously wrong, shorthand > of <!DOCTYPE html> as the new standard!) Strange. I don't recall ever seeing <!DOCTYPE html> before HTML5 came along. But I am made to wonder why. What will happen when HTML6 comes out? Or have they decided that validators are just going to update themselves to the new standard rather than keeping separate HTML5/HTML6 DTDs (or whatever the HTML5+ equivalent of a DTD is)? PNG's reason for not including a version number in the file is to avoid the scenario where a program knows only of PNG up to version 1.2, and rejects a file as being in PNG 1.3 even though all the critical chunks conform to the PNG 1.0 spec. See http://www.libpng.org/pub/png/spec/1.2/PNG-Rationale.html#R.Chunk-naming-conventions But I have trouble believing anybody would make a web browser that rejects HTML files as being in too new a version of HTML. > Stuff like improperly closed tags or bad entity > encoding can break, but that's pretty well independent > of doctype validation. That's simply a matter of the > document being well-formed. No, because in order to determine whether it's well-formed, one must know whether it's meant to be in SGML-based HTML, HTML5 or XHTML. <snip> >> Are custom attributes distinguished from standard attributes in some way, in order to >> keep attributes invented by different browser manufacturers from clashing with each >> other and with attributes that become part of a later HTML standard? > > They are in html5 - the data- prefix is allowed and reserved > for the user. In older versions of the html standard, there > weren't allowed at all, whether prefixed or not. (They did > work in practice, though.) <snip> So it's something that web authors can use to store custom data in an element for scripting purposes, but browsers aren't supposed to have any built-in handling of them? Stewart. | |||
December 17, 2011 Re: New homepage design of d-p-l.org is now live. <eom> | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | On Saturday, 17 December 2011 at 13:09:40 UTC, Stewart Gordon wrote: > What built-in support does HTML/JS/CSS have for dragging of elements? http://dev.w3.org/html5/spec/dnd.html It started as an IE5 feature, and is now being expanded to everyone else. In the old IE, it only worked on some text, links, and images, but the new standard says you can set it on whatever you want. Still, if you want to support them all, <a> is the way to do it. > Moreover, dummy hrefs are an abomination. Not just compatibility when JS is disabled - this link is also the one followed when you open a link in a new window/tab. This regularly bites me. Yea, I hate them too. In practice, I try to put them somewhere useful, if I can. (In my app with the drag drop, the links lead to the contact profile page; this is a mailing list/CRM app.) > But I am made to wonder why. What will happen when HTML6 comes out? I guess the idea is there won't be a html6; instead they'll just keep <s>breaking</s> evolving the current thing and expect everyone to keep up. > No, because in order to determine whether it's well-formed, one must know whether it's meant to be in SGML-based HTML, HTML5 or XHTML. Meh, it works anyway. One reason is websites tend to be so poorly written that if you tried to be strict, you'd just break most of them! Anyway, this said, if dpl.org wanted to validate, I don't think it'd be a *bad* thing. (I'd say go with xhtml; I feel dirty saying this, but I almost.... like..... xml for this kind of thing.) > So it's something that web authors can use to store custom data in an element for scripting purposes, but browsers aren't supposed to have any built-in handling of them? Right. You aren't even supposed to use them with other third party tools; the idea is that area is completely open for the page author and his scripts to do with as he pleases. | |||
December 17, 2011 Re: New homepage design of d-p-l.org is now live. <eom> | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:jci2bj$225s$1@digitalmars.com... > On 17/12/2011 06:35, Nick Sabalausky wrote: > <snip> >> But if it's<i>just</i> ordinary text that simply needs to >> be<b>bolded</b> >> or<i>italicized</i>, then handling it in any roundabout way like that is >> just<i>ridiculous</i> (and "self-documenting" would be completely >> inapplicable). > > You miss the point - why would you need to bold or italicise "ordinary text"? To be clear, I didn't mean that as in "plaintext"...if that's what you meant...? I meant like the examples in that paragraph (not all of which were literal examples of bold/italic). > If the point is to illustrate what bold looks like, or what italics look like, _then_ it might make sense to use presentational markup.... > Only "might"? ;) >> In such a situation, replacing hardcoded bold or italic with some vague concept of "emphasis" (old-school example: the<em> tag) > > <em> isn't really an old-school example. It's the proper semantic markup for emphasis. > Ok. It was a dedicated HTML tag instead of a span/div with class attribute. Seems like most of those are non-kosher these days. >> or >> "extra-emphasis", etc, is not only a useless abstraction merely for the >> sake >> of abstraction, it<b><i>can</i></b> subtly change meaning/interpretation >> of >> the actual<i>content</i> because only the<i>author</i>, not the stylist, >> is able to look at the final result and know whether the result >> <b><i>correctly</i></b> depicts the amount/type of emphasis intended. > > It seems to me that the essence of what you're saying is that the choice of <em> and <strong> is too coarse-grained for your purposes. Yes. Well, too vague, really. > I'm not sure how best to deal with this either. It's easy to deal with: You just say "Fuck dat 'purity' booshit, I'm usin' <b> and <i>!!" :) And as far as inferring semantic meaning, I think it's pretty obvious that <b> and <i> imply "this text is emphasised". (Not that I can imagine any realistic use for being able to identify what text is emphasised.) > Moreover, what markup are you going to use so that it looks/sounds/feels right in non-graphical browsers? > Non-graphical browsers are going to result in a *lot* of difference from the original style/layout anyway. There's a lot of stuff that's going to be wrong. If you're using one, it's just understood that you're merely viewing an approximation. >> Additionally, how does the stylist know if a given styling is going to >> cause >> too much visual noise? Or be too visually monotone? They<i>can't</i>, >> because it's<i>completely</i> dependent on the text that the >> <b><i>author</i></b> writes. It might be too much visual stuff for one >> article and just right for another. Only the text's author can know >> what's >> appropriate, not the stylesheet. > > If the author is overusing emphasis, manually setting font weights and stuff to compensate seems to me to be trying to fix the wrong problem. > Not necessarily. Imagine a paragraph that uses a fair amount of italic, but not quite an overuse of italic, so it still looks fine. If that's done with, say <em>, and the stylist changes <em> from italic to either bold or bold+italic, it's suddenly going to look like shit. It'll *become* an overuse, and the only way for the stylist to fix it is to just let the author choose bold/italic/etc on their own. Maybe I'm just atypical as an author, but when I write something and use emphasis, I take into account things like bold/italic and how it'll look when I decide what to emphasise, how, and how much. If I *do* use things like <em>, I inevitably end up choosing them based *not* on "level of emphasis" but on whether they end up being bold/italic/underline/etc...Which obviously defeats the whole damn point of <em>, etc. I'd be surprised if most people do it any different from that. Heck, I almost always end up changing my emphasis/bold/italic/etc after writing+previewing it because it never looks right until I've tweaked it *taking into account* the final presentation. Honestly, I can't imagine how anyone could do it effectively without having direct control over such things (even if it's by abusing levels of emphasis as euphamisms for more specific stylings). I think there's good reason wiki markups invariably have syntax for "bold" and "italic" rather than "emphasis". There's two basic problems with the idealistic separation of presentation from content: 1. (X)HTML and CSS are just simply not very good as "(X)HTML is content" and "CSS is presentation". You can get by in *some* cases, but in general they're just poorly suited for it. I think that *part* of the problem may be that it's like ColdFusion: A mediocre Model and a mediocre View hooked directly together with basically no Controller. 2. Content and presentation *are not always separable*. There *is* interplay. And this makes a strict and complete separation of content and presentation nothing more than yet another example in programming's long history of idealistic dreams (like Java's "everything must be OO" purity, Haskell's "everything must be functional" purity, etc.) As always, puritism sucks and needs to tempered with pragmatism. | |||
December 17, 2011 Re: New homepage design of d-p-l.org is now live. <eom> | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | "Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:xjikejblvuxulhoqxbim@dfeed.kimsufi.thecybershadow.net... > On Saturday, 17 December 2011 at 13:09:40 UTC, Stewart Gordon wrote: >> But I am made to wonder why. What will happen when HTML6 comes out? > > I guess the idea is there won't be a html6; instead they'll just keep <s>breaking</s> evolving the current thing and expect everyone to keep up. > And why not? That's what they've been doing all along. *cough* <object> *cough* ;) >> No, because in order to determine whether it's well-formed, one must know whether it's meant to be in SGML-based HTML, HTML5 or XHTML. > > Meh, it works anyway. One reason is websites tend to be so poorly written that if you tried to be strict, you'd just break most of them! > > Anyway, this said, if dpl.org wanted to validate, I don't think it'd be a *bad* thing. (I'd say go with xhtml; I feel dirty saying this, but I almost.... like..... xml for this kind of thing.) > Yea, HTML looks, acts and feels like XML so it may as well actually *be* XML. Plus, tranformations to/from HTML is one of the main reasons for XML anyway. So they *should* be compatible. ('Course there's *technically* SGML too, but honestly, HTML is the only reason anyone's ever cared about or even known about SGML. It may as well not exist.) | |||
Copyright © 1999-2021 by the D Language Foundation