Setting the width of a quote <q> tag

[JonnoW]

Cheers for the info, I've made a few changes, still working on it.

1) Blockquote MUST have a block level child around inline level or cdata elements...

2) I meant the CITE tag, though the CITE attribute isn't a bad idea either.

3) that last one probably shouldn't have a div around it -- though that depends on where in the code it ends up.

4) You're attempting to use the same ID more than once -- remember ID's are supposed to be unique on a page... NOT that there's any reason for those inner ID's.

5) if you have to say ../ or even / from your markup or CSS, there's probably something wrong with your directory structure...

6) You could REALLY do yourself a favor and forget that HTML 5 garbage even exists. It is NOT ready for real world deployment and does NOT offer any real improvements over what came before it, while it DOES loosen the structural rules and introduce redundancies to the point of undoing ALL of the progress STRICT (4 or X 1.0) had given us the past decade.

7) might 'suck' from an accessibility standpoint, but EM's auto-enlargement means you can't predict how many lines OR how tall your text will end up -- I hate to say it but a switch to PX would be more predictable (though broken for geckotards who still use it's broken/outdated text-only resize). Besides, 24px (150% of a default 16px "small fonts/96dpi") is big enough it's unlikely anyone will plotz over it.

8) TITLE should probably go on the Anchor to say where the A goes, not the image where it serves no purpose.

@DeathShadow60 Thanks for the feedback that's been really helpful.

1)In it's current form, the HTML5 spec allows BLOCKQUOTE for "short snippets" without the need for P elements inside.

2)Good call, added both.

3)Dropped that Div, thanks.

4)yeah I noticed that I'd left in the second ID call as soon as I'd replied

5) That's the organisation's directory structure, not something I've set up. What is the issue with this structure though?

6) Without meaning to sound contentious: I understand that HTML5 is still in draft form and that it might not "offer any real improvements", but it's here and it's not going to go away. The spec may change but will it really change that much as to make things completely redundant? Probably not, more likely that more browsers will support that changes in the coming years. So long as the page is accessible, logical, and degrades gracefully I don't see that this is a massive problem.

That said, I completely agree that HMTL4 or X1.0 are here now and clearly defined and the reasons to stick with them...for now.

8) Thanks, I was wondering about that. Am I correct in thinking that the title should be used to describe where the link is taking you?

[deathshadow60]

1)In it's current form, the HTML5 spec allows BLOCKQUOTE for "short snippets" without the need for P elements inside.

Which is why HTML 5 is HTML 3.2 based and NOT HTML 4 strict based, and why not only do I see no legitimate reason to use it, I see legitimate reasons to STAMP OUT IT'S USE! Nothing like that trip in the wayback machine to 1997. God forbid we have rules and structure in our documents...

5) That's the organisation's directory structure, not something I've set up. What is the issue with this structure though?

Usually it means it's not portable from where you test it or it breaks when you deploy. It also means there's little logical structure to it. As a rule of thumb it's usually best to have things you are calling be in subdirectories of the page location -- NOT sibling or subdirectories of parent locations... that way you're only going 'down tree' for files instead of 'up tree'.

6) Without meaning to sound contentious: I understand that HTML5 is still in draft form and that it might not "offer any real improvements", but it's here and it's not going to go away.

Well, it's not actually here yet -- and here's hoping we can convince people NOT to waste their time with it and stamp out this idiotic nonsensical half assed garbage I can't believe ANYONE is DUMB ENOUGH to even TRY to use. But then again it seems carefully crafted NOT for the people who bothered embracing clean code, minimalist code, separation of presentation from content, or any of the dozen other improvements of the past decade, and instead is meant for the people who until recently were just sleazing out HTML 3, slapping a tranny doctype on it, and going "eh, close enough".

Well, and to sell books and seats at lectures to nubes who don't know any better; HTML 5 - nube predation at the finest you'll find this side of a marketing dweeb talking about Web 2.0 or a SEO scam artist talking about how their pages rank on what boild down to 'perfect match phrases'.

But you'll always have the people who go "ooh, shiny" without taking the time to notice it's inferior to what came before it.

8) Thanks, I was wondering about that. Am I correct in thinking that the title should be used to describe where the link is taking you?

Correct. Title on a image rarely if ever makes sense (unless you REALLY feel the need for the incorrect use of it as a tooltip) -- but on a anchor to tell you where the anchor goes when the content inside it does not (like when there's no content or just an image) makes a LOT of sense.

So long as you aren't doing stupid nonsense like

<a href="/" title="Home">Home</a>

You're fine. (seriously, I want to backhand every developer who insists on that stupidity in their CMS -- Right Wordpress?) -- the only reason to put a title on an anchor that says the same thing as it's contents is if you are mapping accesskeys for accessKeyMenus in browsers like Opera. Otherwise it's just a waste of bandwidth.

Though you should always ask yourself "If I have to use TITLE on an A, doesn't that mean there's something wrong with the content of the anchor?"

There are lots of little questions like that people forget to ask themselves -- see headings; "Is this H3 the start of a subsection of the H2 before it? No? Then why is it a H3 and not a H2?" -- Same with alt text on an image; "If this image doesn't warrant alt text, why is it in the markup as a IMG tag?"

Lots of little questions that can lead to better pages.

[JonnoW]

5) Now that you mention it, yes, I have seen that happening. I'll take a note of that for future projects.

8) Very good point, links should be descriptive.

Back to HTML5 though (this is probably due it's own thread unless there already is one);

When you say it's half-assed garbage, what do you mean? (genuinely asking the question).

[Stomme poes]

and why not only do I see no legitimate reason to use it

Not only does HTML5 allow <blockquote>inline foo</blockquote>, but it also allows
<form>
inline foo
</form>
and I think also
<body>
inline foo
</body>

Maybe because they couldn't remember any legitimate reasons to require block children inside those elements.

A p makes sense in a blockquote when there would be multiple paragraphs inside, which you would get from an extended quote. But plenty of elements allow either blocks or inlines (the spice must %flow?) as direct children without the world bursting into flames like a sparkly vampire in the sun, so I might agree with the WHATSIT people here, if you
- don't have multiple paragraphs in the quote
- aren't using a fieldset because it's a one-input search form (or similar)
- I actually can't think of a good argument for the body really

I think their insane new ruleset about <blockquote> esp regarding <cite> (yeah, the tag) are retarded and should be put out of its misery behind the old barn.

HTML5 <blockquote> now has additonal conformance requirements - http://dev.w3.org/html5/spec/the-blo...kquote-element diff tracker - http://html5.org/tools/web-apps-trac...m=6987&to=6988

11 Feb 2012

Also http://lists.whatwg.org/htdig.cgi/wh...ead.html#34822

[deathshadow60]

When you say it's half-assed garbage, what do you mean? (genuinely asking the question).

Well, first up is the loosening of structural rules -- some of the things that were done to tighten it up I do like -- kicking much of the fancier and rarely used SGML structural stuff like shorthand tags to the curb makes sense; but destroying backwards compatibility by flat out attempting to remove the distinction between block and inline-level (and which can go inside which) not only removes one of the keys to making good content, it breaks things for no good reason and basically advocates coding practices that over the past decade we've been told to move away from.

But that's minor stuff compared to once you get into the new tags and attributes.

One of the biggest bits of bull are the new redundant tags undoing the reduction of redundancies in strict -- new tags for AUDIO and VIDEO aren't the answer, FIXING OBJECT IS. Like it would have killed them to simply apply control hooks to object and for browser makers to implement their favorite pet codecs in the EXISTING tag we were already using for it? No, have to make new tags when most coders can't even use the existing tags properly... completely forgetting that the entire point of object was to allow for more file format supports and for no one format to have full sway over content -- to the point even IMG was on the chopping block to be replaced by OBJECT -- something we could have done if Microsoft didn't drag their heels on it. (If they hadn't, we could probably be using jpeg2k by now!)

HTML 4 strict didn't just remove tags and attributes for being presentational, it removed them for being redundant as well. MENU and DIR were redundant to UL. APPLET and the unofficial/proprietary EMBED and BGSOUND were to be replaced by OBJECT. (with IMG on the slate for the next version of HTML they abandoned for the WhatWG bull). STRIKE and S were removed NOT for being presentational, but as being redundant to DEL.

But no, not only is MENU back for christmas only knows what reason (It still appears we aren't supposed to use it for actual menus), they add a whole slew of pointless redundant tags. SECTION for example is the king of pointless, since a DIV (aka division) is there to DIVide the page into sections... we have numbered heading tags to divide the page into sections, we have horizontal rules to divide the page into sections when a heading isn't needed or wanted -- so what in blazes do we need SECTION for exactly?!?

Then we have HEADER, which is either pointless, or just plain redundant to numbered heading tags... NAV, which for all the TALK about accessibility seems to more exist just to add extra elements to your page's DOM for no reason like the idiotic "put a div around every UL" nonsense that became normal practice. (Besides, isn't every blasted anchor on a page 'navigation'? I thought <div class="nav"> was uselessly vague... now it has it's own blasted tag. ASIDE makes sense if you know what an aside is, but since nobody is bothering to use it for asides and instead just slaps it around sidebars and other elements that really shouldn't have extra semantics applied to them, that's just as pointless... about the only new structural tag that makes ANY sense is FOOTER... and to be honest I'm not sure that's something that REQUIRES more semantic meaning than a horizontal rule before it to indicate it's the start of a headerless section.

... and then there's the elements like CANVAS, which to be frank shouldn't even NEED A TAG IN THE FIRST PLACE -- since it's USELESS without javascript, it should be added BY javascript to existing elements instead of having some stupid tag in the markup for no good reason. AT MOST a div with an ID should be overkill for that.

While certainly some of the web form stuff is cute, and harmless -- much of it feels to me like the javascript asshattery people are doing on forms; where it boils down more to this rampant crazy paranoia about how pageloads are evil and slow -- MAYBE if one practiced separation of presentation from content so that style is cached, used minimalist markup and didn't bloat out the forms with pointless bull like wrapping tables or lists around elements that already HAVE semantic meanings, that page load wouldn't take the 'crazy' amount of time people think it does. OF course clearly labeling and explaining the inputs so people don't make mistakes before hitting submit is just plain crazy-talk it seems; maybe it's because I dealt with forms in print where you only get one chance, but given that you STILL have to verify ALL the user input server side AGAIN anyways, I just don't see the point to it.

... whcih is why they have to throw a bunch of UNRELATED technologies under HTML's banner, because if all you look at is the MARKUP part of this alleged markup alleged specification, the emperor has no clothes.

[Stomme poes]

but destroying backwards compatibility by flat out attempting to remove the distinction between block and inline-level (and which can go inside which)

Partially because all browsers' parsers were already dealing with this... because the errors were so common, everyone already had their default ruleset to use when someone wrapped anchors around heading tags and divs. Since this also sounded much much more useful (wrapping anchors around large blocks of content) than having three anchors to go inside each of the elements in there (considered a usability issue and hideously redundant) so they figured, let's fix this. Of course, they couldn't fix IE, so it's still silly to use...

I mean, look at this: http://john.foliot.ca/aria-hidden/
The example there only has two anchors, but often you see three or more. The heading, image, and content is often clickable. This is to increase usability for sighted mouse users: They have a large clickable area, and people have been taught through long web experience that images on blurbs can be clicked to the full articles somewhere else, or to a larger image.
Tell me playing around with two ARIA roles on each involved element AND using the (illegal in HTML4) negative tab index is a better idea? Crap, it's not. And screenreaders have shown that even they can deal with anchors wrapping block content (though there have been hiccups).

new tags for AUDIO and VIDEO aren't the answer, FIXING OBJECT IS.

I'd like Object to be fixed, but I don't know any way to semantically say what the object is calling in. Audio is different from video... whereas the difference between a gif and a png is lost on most housewives. img really does only call an image, object calls damn near anything. Though then I suppose one could take my argument and say "Then why isn't there a <game> tag etc?" since object can hold a Flash game... or any other strange thing.
If that's a good idea for content you're calling in as separate files, why not do that with content who is text? P's for everything!

If they hadn't, we could probably be using jpeg2k by now!

Oooh, sounds too bearded and hippy and flossy for you : )

But no, not only is MENU back for christmas only knows what reason (It still appears we aren't supposed to use it for actual menus)

Not navigation menus, application menus. That or mangle the hell out of navigation menus so they can act like Desktop stuff. Making a whole new tag ended up being easier (there was still a place for the old MENU in most parsers too, easier to rewrite that than mess with unordered lists, which currently suck as application menus).

SECTION for example is the king of pointless, since a DIV (aka division) is there to DIVide the page into sections...

The huge ginormous difference being, div means nothing. I throw a bunch of stuff into a div because I want to be able to make the background colour pink, I can, and it doesn't mean that information somehow belongs together in any way.
Stuff lumped together in a <section> is a related group, content-wise. You can stuff anything in a div and it shouldn't mean anything. Can't do that with <section> (or <article>).

(of course, today no browser or AT sees any difference between divs and sections and articles, I'm just saying what the great plans for the future are supposed to be. That browsers manage to show a document outline isn't the same as the promised semantic honey and gold sitting in the blueprints in the WHATSIT's war room)

NAV, which for all the TALK about accessibility seems to more exist just to add extra elements to your page's DOM for no reason like the idiotic "put a div around every UL" nonsense that became normal practice.

I personally like just putting the navigation role on the primary navigation ul, which gives us all the semantics promised by <nav> tags anyway (since AT is the only part that attaches any semantics to the new tags... browsers sure as hell don't, yet).

Maybe screen readers and ARIA will pull the rest of the promised semantics of the new tags to all other browser users...?

[JonnoW]

Just before we go completely off topic and this becomes an all-out HTML5 debate; I'm working on another page (mockup image below). The bit next to the image is my quote, a citation (student name and course), and potentially two links that at this stage are images. There is also a third button that is not related to the quotation but will need to be inline with the other two buttons.

myImage (1).png

Would this code be correct?

<blockquote cite="address of interview">
        "The staff have been very helpfull and welcoming, regularly aranging social events with games and pizza"
        <cite>Camilla dsajhdkajsh, third year Computer Science</cite>
        <a href="#" title="View the case study">
            <img src="button" alt="Read more button" />
        </a>
        <a href="#" title="Watch the video">
            <img src="button" alt="Read more button" />
        </a>
</blockquote>
<a href="Key information set" title="Jump to the Key information set data">
    <img src="KISButton" alt="KIS button" />
</a>

What would the best way be to style this so the buttons line up? I'm thinking wrap the whole quote/image/video part (Under the Computer Science heading and before the "Why Study Computer Science....") in it's own <DIV> and float the KIS button (third button along) right, then have the large image/video following that e.g:

[CODE]
<div id="sectionQuoteGubbins">
<blockquote>
...
<cite>
</cite>
<a...></a>
<a...></a>
</blockquote>
<a...>KIS link</a>
<img /><!--Large right hand video/image-->
</div>

[Stomme poes]

Img not approved yet, but I see some semantic problems:

<blockquote cite="address of interview">
"The staff have been very helpfull and welcoming, regularly aranging social events with games and pizza"
<cite>Camilla dsajhdkajsh, third year Computer Science</cite>

IF you are using HTML5, THEN you may have that quote text inside the blockquote without the necessary child block element (this is what Crusty was complaining about earlier: in HTML4, XHTML1, blockquote elements may NOT have plain inline loose anonymous thingies as direct children).
<blockquote cite="foo">
<p>your quote here...</p>
</blockquote>

But, IF you are using HTML5, then your <cite> tag is wrong: HTML5 changed the loose meaning of <cite> to the point now where it can ONLY mention... titles of works. Yeah, retardation, since often we are quoting random crap people say and not "works" with titles, but there you have it.

So, your current code is mixing stuff. If you want HMTL4, you can have author/speaker name in your <cite> but then you'll need a <p> inside your blockquote... or if you want HTML5, you don't need the <p> but your <cite> can't have the speaker's name in there. Sad, I know.

Second, a quote (whether block or inline) is generally agreed to only have the actual quote in it. That is, someone didn't claim they made a quote, they just made a quote. You wouldn't do, in a book,
"I can haz cheezburger, --Cheezburger cat"

you would do
"I can haz cheezburger," --Cheezburger cat

See, who said it doesn't belong inside the quotes, only what they said. Same goes for <blockquote>, and <q> too. Your cites (except the cite attribute in the top) have to be outside.

So then how do the attributions get semantically attached to the quote? Answer: they don't, because HTML is screwed up there and nobody's fixed it.

You can see from HTML5doctor's page that they first thought, hey, we can use <footer> to hold the cite! Nope Chuck Testa. Footer not allowed :(
http://html5doctor.com/blockquote-q-cite/

Ultimately I'm going to say, don't worry too much about it, because the sematics here, even if you get them "right", will be wrong (because the spec is in a state of retardation).