WCAG-AAA
| JackP wrote: |
| Bill, I'd be interested in your take on the way the W3C have used <code> in the document I'd referenced. Do you think that's reasonable or do you still think <code> should be used in all cases? I'm not necessarily going to change my interpretation, but I would like to hear your opinion! |
I personally wouldn't hold much stead in how the W3C themselves mark things up.
From the page in question…
| Quote: | ||
|
Although, as noted, they do consider even tag name references to warrant semantic change…
| Quote: | ||
|
Being an inline, phrase element, I honestly see no problem with marking up every direct reference to code using the code or samp elements. Being that both are inline elements, neither interupts the flow of a sentence and yet does add some semantics to the word, or phrase.
If you wish it not to 'appear' differently, then you could use to inherit the various font characteristics from the parent paragraph.
My underlying point wasn't so much in favour of code above all others, but that code should be marked up as such. Whether that means using the code element or the samp element is a question in itself.
That said, given that you're using the element names in the raw, I'd be inclined to use the code element, rather than the samp element which the W3C has used on that page.
But then, W3C is a great one for 'Do as we say, not as we do', somehow managing to be amongst the very worst at willfully ignoring its own guidelines.
(I consider that the W3C is more than capable of making bad decisions, even as far as some of their recommended standards go.)
Share: 
| Bill Posters wrote: |
|
I disagree with the notion that they convey nothing. The context of the surrounding content will (read: should) convey precisely which coding language is being discussed. e.g. How often do you see an article on javascript that doesn't actually make it clear that the article is about javascript, either via the title element, heading elements or introductory text? |
Fair enough, but that's semantic in the sense that a human being will understand it from context. It's not semantic in the sense that a piece of software, such as a web browser, can extract useful meaning from it. I thought you were referring to it in the latter sense. Have a look at Tim Bray's article on this from 2003:
http://www.tbray.org/ongoing/When/200x/2003/04/09/SemanticMarkup
| Bill Posters wrote: |
| I don't feel that the code element should convey specifically which code language is being discussed. |
It would have to if it's to be understood semantically by a user-agent. Otherwise software has to extract meaning from surrounding context, which means the tag is more presentational or descriptive than semantic - useful to humans but not to software.
Share:
My understanding was that <code> tags are mainly for rendering that text differently from the text around it, making it clear to users that this is not regular text. As EYG says, that might be a visual difference but it could also be interpreted by audio or Braille devices, or even by search engines and other system. For example, screen readers might ignore punctuation within <code> tags or provide a user preference for doing this.
Here's another example, discussing an error on a web page which uses a CSS background image:
| Code: |
| <p>The problem might be due to the background getting processed incorrectly.</p> |
| Code: |
| <p>The problem might be due to the <code>background</code> getting processed incorrectly.</p> |
Another thing to bear in mind is that people tend to skim-read pages they visit online. By highlighting references to code, citations of major works, keyboard shortcuts and so on, users can scan for these specific things more quickly. For example, if a user wants to know the access keys provided by a website, they could scan the accessibility statement more easily if these are highlighted via the <kbd> element.
When making a general reference to an element, you can often improve the sentence by making it an explicit reference to the elemeent and using <code> tags to reinforce this.
I think making good use of the inline phrase elements is a very practical thing to do. UAs can only do useful things with phrase elements if our pages already contain them. They add very little filesize and can also make pages look more decorative (and it's useful decoration!).
Last edited by Ben Millard on 11 Jul 2006 12:50 pm; edited 2 times in total
Share:
| eatyourgreens wrote: |
| Fair enough, but that's semantic in the sense that a human being will understand it from context. It's not semantic in the sense that a piece of software, such as a web browser, can extract useful meaning from it. |
I feel that it is. It's at least as semantically meaningful as em or strong and surely as semantic as the plethora of custom elements which the X in X(HT)ML affords us.
The fact that most GUI UAs don't currently distinguish it beyond giving it monospaced font doesn't mean that it has no real semantic use to machines.
As the 'semantic web' starts to take shape, I believe we'll see such elements as code becoming more influential in the way machines search documents and understand and categorise their contents.
| Quote: | ||
It would have to if it's to be understood semantically by a user-agent. |
Again, I disagree. The UA doesn't have to use or parse the code text, just classify it. The code and samp elements are capable of facilitating that.
As the semantic web grows, we may see the introduction of language identifiers similar to those used to indentify an inline passage of foreign text.
It's not presentational, it's descriptive.
| Quote: |
| Otherwise software has to extract meaning from surrounding context, |
That's nothing which se-bots don't already do and is quite possibly the model of how machines will engage in future.
Still, if it's felt by the author/developer community that more detail is desired, then we may well see the introduction of optional attributes along the lines of…
<code lang="php">strtolower()</code>
It seems to me that your argument actually supports the removal of the code element completely from the spec.
Share:
| Bill Posters wrote: |
|
It seems to me that your argument actually supports the removal of the code element completely from the spec. |
Not at all. As Ben says, it could be useful for people who are reading/listening to your web page to present code in a different style. Just don't kid yourself that you're adding some hidden extra meaning to the page for computers to understand. If the former point is important to helping people use your web page, then you should definitely use <code> tags.
Have a look at the Tim Bray article on semantic markup, specifically the code example which is semantic to people but not to software. He explains this far better than I can.
Share:
I was going to ask for a link but I thought I could always just look for it myself. I presume http://www.tbray.org/ongoing/When/200x/2003/04/09/SemanticMarkup that's what you meant?
[ot]It's always nice to start a thread that keeps going for a while. It shows you all love and adore me. Or possibly that you strongly disagree with me, but I prefer option 1.[/ot]
Jack Pickard The Pickards Information Services| Blog | Twit
Share:
| eatyourgreens wrote: | ||
Not at all. As Ben says, it could be useful for people who are reading/listening to your web page to present code in a different style. Just don't kid yourself that you're adding some hidden extra meaning to the page for computers to understand. |
I'm not kidding myself about anything I've said.
Like I say, just because it doesn't yet carry much weight at the moment, that doesn't mean that it won't be used to a fuller potential when UAs really get to grips with the notion of parsing a semantic page.
Again, like I say, it carries as much semantic use as other inline phrases such as em, strong, etc… as well as heading elements.
I'm not saying that it's going to fundamentally change the web, but it certainly has the potential to play a significant role within a more semantic web.
You seem to be stuck on the notion that it's largely meaningless because current UAs don't do much with it beyond a presentational switch.
That's a limitation of UAs, not a limitation of the code and samp elements.
| Quote: |
| Have a look at the Tim Bray article on semantic markup, specifically the code example which is semantic to people but not to software. He explains this far better than I can. |
I skimmed it, but will give it a proper read later.
(He seemed a little too interested in putting across how ahead of the curve he's been throughout his career and, frankly, I found it tedious and off-putting regarding listening to his pov.)
Share:
| Bill Posters wrote: |
|
I'm not kidding myself about anything I've said. Like I say, just because it doesn't yet carry much weight at the moment, that doesn't mean that it won't be used to a fuller potential when UAs really get to grips with the notion of parsing a semantic page. |
But HTML isn't a semantic markup language and the tag only has meaning to people, not machines.
| Bill Posters wrote: |
| Again, like I say, it carries as much semantic use as other inline phrases such as em, strong, etc… as well as heading elements. |
No, it doesn't. Headings have unambiguous meanings, for both machines and people. Hence you can do neat things like generating a table contents from the headings embedded in a web page. The code tag, on the other hand, adds meaning for the reader of a web page (which can be good for accessibility), but adds nothing for a machine that reads the page.
| Bill Posters wrote: |
| You seem to be stuck on the notion that it's largely meaningless because current UAs don't do much with it beyond a presentational switch. |
Feh. Now you're just putting words in my mouth.
| Bill Posters wrote: |
|
I skimmed it, but will give it a proper read later. (He seemed a little too interested in putting across how ahead of the curve he's been throughout his career and, frankly, I found it tedious and off-putting regarding listening to his pov.) |
As you wish, but he makes the point that there are two definitions of semantic markup - basically markup that adds meaning for people vs. markup that can be used in some meaningful way by software. HTML generally falls into the former camp. Hence the semantic web, which addresses the deficiencies of the web by adding semantic technologies (RDF, anyone?) on top of HTML. Thus allowing machines to make dentist's appointments for you in some magical future.
Share:
| eatyourgreens wrote: | ||
But HTML isn't a semantic markup language and the tag only has meaning to people, not machines. |
We use certain tags and give them meaning as a means to then convey characteristic differences for use by humans.
em and strong are meaningless to machines. They don't really 'understand' what emphasis and strong emphasis mean, they're just triggers to bring about an effectation in how a UA rates and delivers the enclosed content.
It's precisely the same with headings. An SE bot doesn't really understand that a page with a heading about cars is actually about those four-wheeled machines queued up in slow-moving lines around the roads of most countries. It's just a string to be matched and compared against other sites containing that string.
Until we reach a point of thinking machines, no 'semantic' elements have any real meaning to machines.
| Quote: | ||
No, it doesn't. Headings have unambiguous meanings, for both machines and people. Hence you can do neat things like generating a table contents from the headings embedded in a web page. The code tag, on the other hand, adds meaning for the reader of a web page (which can be good for accessibility), but adds nothing for a machine that reads the page. |
It seems to me that you're stuck thinking in terms of what UAs currently do with code elements - which isn't very much.
iIf there were no semantic difference between marked-up code content and the text surrounding it, why do you believe it's there in the spec?
Or do you believe that it's a presentational tag which has no place in the spec?
| Quote: | ||
Feh. Now you're just putting words in my mouth. |
I don't think so. That's genuinely what's coming across in the points you're making.
| Quote: |
| he makes the point that there are two definitions of semantic markup - basically markup that adds meaning for people vs. markup that can be used in some meaningful way by software. |
Setting aside that it's an opinion piece and that what is meaningful to machines typically results from that which we tell machines to consider meaningful…
Anything can be made to be used in some meaningful way by software. It's all down to the instructions you set out in that software.
Whether or not something more useful can be done with the code element remains to be seen, but there's no inherent reason why it can't play an equal role to more 'traditionally accepted' semantic elements in that magical future.
But, anyway…
Share:
| eatyourgreens wrote: | ||
|
In the case of <code>, this usually takes the form of rendering it differently from the surrounding text because it has a different meaning. In graphical browsers, they normally choose to apply a monospace font. This is an historical reference to the code view of early operating systems and a cultural reference to the commonplace association of these fonts with computer code. That's a machine making a cultural reference because it is made by people who understand the semantics of HTML.
Specifically:
- The element is parsed from the markup.
- It is styled according to its semantic meaning.
- This conveys that meaning to the user visually.
The semantics of HTML are well defined (there's more detail throughout the main spec pages). In fact, they are so well defined that XHTML 1.x uses the semantics of HTML. The semantics are defined in the specification; how UAs want to handle them is their choice (although the specs sometimes make recommendations about this).
| eatyourgreens wrote: | ||
|
Semantics are only ever used by people, either programmers or users. A screen reader doesn't understand that creating a page summary from the <h*> tags will please it's user; it does this simply because some humans wrote some code which causes this effect.
This is how the <code> example above works: programmers (i.e. people) make the machine to convey meaning from the markup to the users (i.e. people) by presenting it differently than the surrounding text. The machine never thinks.
| eatyourgreens wrote: | ||
|
In the example you've given here, the machine will make the appointment based upon judgements made by the people who programmed it. It will choose which dentist based on information entered by people either directly into it or via an external database. It will choose a time based upon the human user's schedule. It will also accomodate the human dentist's schedule. At no point does the machine exercise any judgement or have any concept of what it is doing. It simply process the data exactly as it was programmed to do by people.
The idea that there are machines which can understand or think about the meaning of data is laughable. It's all done by people. Three cheers for us!
Share:
| Cerbera wrote: |
|
The idea that there are machines which can think about the meaning of data is laughable. |
Sorry, I was making a flippant reference to the example that Tim Berners Lee used in his introduction to the Semantic Web in 2001 - he refers to intelligent desktop agents in the first few paragraphs.
http://www.sciam.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21&catID=2
I don't know, you might want to look at this too
http://semantichumanities.wordpress.com/2006/02/16/authoring-born-tei/
I'm coming at this from a background of having worked in LaTeX and TEI, which can be very rich languages, as well as HTML, and now trying to write code which infers meaning frrom structured text and sets of structured data - MARC 21, for example, which no normal human being could find semantic meaning in.
I think the word semantic as used by the semantic web people might not mean the same thing as the word semantic when used by web design people.
Things were a lot simpler when web people talked about structural HTML
Share:
| Bill Posters wrote: |
| If there were no semantic difference between marked-up code content and the text surrounding it, why do you believe it's there in the spec? |
To aid accessibility? To make your web pages easier to read by people? That's my point, it's there to help you present your content to people, regardless of how they browse the web. Not to feed meaningful information to search engines, or Tim Berners-Lee's intelligent agents in a future Semantic Web.
| Bill Posters wrote: |
| Or do you believe that it's a presentational tag which has no place in the spec? |
You've kind of lost me here. Why would a presentational tag have no place in the HTML spec? Then you'd have to get rid of <b>, <i>, <br>, <hr>, <object> and <img> too. And they're very useful. Without <object> we'd never have youtube
| Bill Posters wrote: |
| I don't think so. That's genuinely what's coming across in the points you're making. |
Sorry if I'm not being clear. That's not the point I was trying to make at all.
I just get nervous about the way the word 'semantic' gets used so freely by the web design community at the moment, particularly if a document is held to be semantic in order to be judged accessible. I can see arguments for creating well-structured documents, for using HTML tags as they were intended to be used, so as not to exclude people from using a page. But 'semantic' and particularly the Semantic Web gets into meaning - can machines (eg. search engine bots) read the code and derive meaning from it and things like that. Which is cool, but kind of outside what HTML is designed to do and more what RDF is for. And OWL, apparently, but I don't know a huge amount about OWL.
Speaking of the Semantic Web, the UK museums and galleries Semantic Web thinktank launched last week. There's an announcement here:
http://www.24hourmuseum.org.uk/nwh_gfx_en/ART38281.html
and some Semantic Web info here:
http://culturalsemanticweb.wordpress.com/
The real sci-fi, intelligent-agents-that-browse-the-web-as-we-zip-about-in-flying-cars stuff is here:
http://evolvingtrends.wordpress.com/2006/06/26/wikipedia-30-the-end-of-google/
Share:
The machine still isn't thinking about data in the TBL article. There is an illusion of intelligence, but in practise they are simply running code written by a people on data produced by people.
Machines cannot understand the meaning of TEI or RDF elements any more than HTML elements. Even the machines proposed on the Evolving Trends blog would simply be running code written by humans (albeit very sophisticated code) on formats devised by humans (albeit very sophisticated formats). They still wouldn't have any concept of what the data actually meant, they'd just be crunching the numbers in the sophisticated way their human programmers built them to.
The upshot of this is that HTML is a semantic markup language. HTML's semantics are certainly limited compared to the detail available in things like TEI, but it does have some because humans defined them in the spec. It's up to the programmers of UAs and search engines to do useful things with them (like is already done with headings in screen readers). Web authors must use them in the first place for this to happen.
(And this is a world record for off-topicness, but it must be because we enjoy chatting in Jack's company so much!)
Share:
| Cerbera wrote: |
| (And this is a world record for off-topicness, but it must be because we enjoy chatting in Jack's company so much!) |
I think my having been in some dull but necessary database training for the past two days might have something to do with my eagerness to do anything that stretches my brain too.
Totally off-topic - I'm working on something at the moment using an archive which has reasonably rich, semantic metadata stored in a bunch of structured ascii text files. I've been sticking the data in a relational database and I ran the word 'Nile' through my code today. It came back with "North Africa: Egypt", "Lord Admiral Nelson", "L'Orient" and "Vanguard" as things that are somehow connected to the word "Nile" (the last two were the flagships at the Battle of the Nile). Anyway, I was impressed - I haven't programmed it to know that the Nile is in Egypt or that Nelson commanded the Vanguard there. It inferred that from relationships in the original ascii text data. Which is pretty cool. No AI, just some convoluted SQL aggregate functions built on top of a free text search.
Software that can make inferrences is around but a lot of that Semantic Web stuff is still pie in the sky, and the intelligent agents have been promised to us for five years now. I still wouldn't let the computer order pizza for me.
And this is just mad. Cool, but mad:
| Evolving Trends wrote: |
| Once machines can understand and use information, using a standard ontology language, the world will never be the same. It will be possible to have an info agent (or many info agents) among your virtual AI-enhanced workforce each having access to different domain specific comprehension space and all communicating with each other to build a collective consciousness. |
Share:
Sorry to bump; just ran into the thread...
| Bill Posters wrote: |
|
That said, given that you're using the element names in the raw, I'd be inclined to use the code element, rather than the samp element which the W3C has used on that page. |
According to the HTML specs, samp is for *sample output* from programs, scripts, etc., so it seems wrong to mark up small bits of code with samp.
Share: