Re: Edit: Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
Stephen Stagg wrote: And how, pray tell, would a screen reader know - based on a series of presentational rules - what the meaning of a made-up tag soup is? The same way that they would with normal HTML, by reading the XML, and the stylesheet and guessing, if an element has the font-weight:bold element, then it should be emboldened. Wrong. Screen readers do not look at the CSS and try to guesstimate what is a heading, what's a paragraph, what's a list, etc. Screen-Reader hints are still presentational devices. Screen readers look at the structure of the document, which is clearly defined as it's standardised in the HTML specification. I believe (tho haven't checked) that there are a whole load of CSS properties to do with controlling assistive-technologies output. There are aural stylesheets, which only give hints about how to present something aurally. They do not define purpose or role of the elements they refer to, and THAT is what counts. -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: Edit: Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
On 10 Feb 2006, at 19:14, Patrick H. Lauke wrote: Stephen Stagg wrote: And how, pray tell, would a screen reader know - based on a series of presentational rules - what the meaning of a made-up tag soup is? The same way that they would with normal HTML, by reading the XML, and the stylesheet and guessing, if an element has the font- weight:bold element, then it should be emboldened. Wrong. Screen readers do not look at the CSS and try to guesstimate what is a heading, what's a paragraph, what's a list, etc. Not wrong actually, Good screen-readers DO read the CSS to work out various things, incuding to see if someting has a display:hidden. I do acknowledge that this is an area that would have to be developed in screen-readers but that does not invalidate the idea. Screen-Reader hints are still presentational devices. Screen readers look at the structure of the document, which is clearly defined as it's standardised in the HTML specification. And they PRESENT it to someone with visual impairment, The presentational properties should be set in the presentational layer I believe (tho haven't checked) that there are a whole load of CSS properties to do with controlling assistive-technologies output. There are aural stylesheets, which only give hints about how to present something aurally. They do not define purpose or role of the elements they refer to, and THAT is what counts. As is said, I wasn't sure about the exact nature of the aural stylesheets. Thanks for the info, Perhaps this is something that could be developed to improve the designers' control over output to screen-readers? no? -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: Edit: Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
Stephen Stagg wrote: Screen readers look at the structure of the document, which is clearly defined as it's standardised in the HTML specification. And they PRESENT it to someone with visual impairment, The presentational properties should be set in the presentational layer So by your logic we could even have stuck with using font size=+3This is a heading/font as screen readers could theoretically just have picked that up and magically deduced it's a heading... -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: Edit: Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
Patrick H. Lauke wrote: generic XML + CSS would be meaningless without some third technology that defines semantics (a DTD, XBL, etc) Neither a DTD nor XBL define document semantics at all. A DTD only defines the document syntax and structure. XBL is only a binding language for attaching behaviour to an element, it doesn't define semantics either. The closest thing there is for describing semantics is the XML namespace, but even then it only loosely associates the elements with the semantics defined in the relevant specification (if one exists). See this post for an interesting discussion of why DTDs don't define semantics. http://groups.google.fi/group/comp.text.sgml/msg/c3e53dee2c152a81?output=gplain -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: Edit: Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
Stephen Stagg wrote: I understand that this is already possible in most modern browsers but it will never be used or properly implemented unless HTML is dropped as a language. Worried about screen-readers? I don't see why, the screen-readers would have to parse the CSS to find clues about how to read the content, but then modern ones already do. :) And how, pray tell, would a screen reader know - based on a series of presentational rules - what the meaning of a made-up tag soup is? -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
On Feb 8, 2006, at 4:04 PM, Stephen Stagg wrote: Why do we need an HTML 5? Can't we dispose of HTML and just use styled XML in the future? It would be one helluva way to enforce standards, and we wouldn't have all this wrangling over exactly which element to use. _ Here's a start: http://www.whatwg.org/ As well as I understand, there are dissenting voices about the development of the web: those who want to follow W3C's recommendations towards XHTML, those who want The Semantic Web based on XML, and those who want to extend HTML against the wishes of W3C. Plus those who don't want to change at all. I don't know much more than that, but I'm sure others on the list will fill in the blanks. Best regards, Marilyn Langfeld Langfeldesigns http://www.langfeldesigns.com [EMAIL PROTECTED] ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
On 08/02/06, Stephen Stagg [EMAIL PROTECTED] wrote: Why do we need an HTML 5? Can't we dispose of HTML and just use styled XML in the future? It would be one helluva way to enforce standards, and we wouldn't have all this wrangling over exactly which element to use. HTML in itself is not a good example of an XML doctype because the paragraph markup does not lend itself to proper hierarchic layout. the heading tags should be able to be subsets of a paragraph, for example. Well, it's a question of attaching semantic meaning to the structure of the data. XML has zero semantic meaning for elements. In XML, hdusdlejncy wiakhjsem=blah has exactly the same semantic meaning as a href=blah. That is, no meaning at all. We need some kind of attachement mechanism for semantics. This is provided in two possible ways, either externally by the mimetype or internally by namespaces. XHTML, SVG, RSS, Atom etc. can all be summarised as sets of semantics. And by all means things closer to the heart of XML such as XLink, XInclude, XML Schemas, XLS-FO, XLST etc. too. What we really want to do when we create documents isn't usually just to provide a structure for data to present in a certain way. We want to convey some kind of meaning. The meaning can't be conveyed by CSS. It's possible we could create a semantics attachment model, but semantics on the whole aren't easily representable for computer understanding. A much easier solution is to use specific sets of semantics, which we attach by namespaces or mimetypes. All consumers can then see if they support the mimetype or namespace, and attach the semantics of that set of semantics to the underlying structure. In fact, consumers of XML that don't know the semantic set of a namespace are still able to say that the meaning is described by that namespace, even if they don't know in particular what that meaning is. These sets of semantics are of course the XML applications such as XHTML1 or XHTML5. The focus would then shift to CSS and the different display-types that can be defined for ANY tag. Microformats and Micro-Namespaces could then be used to allow true semantic delivery. But really, you need a namespace to attach meaning in XML. XHTML is a known and widely implemented namespace. Why not use this namespace as base for extended semantics, instead of introducing new namespaces for it? And as for microformats, those are actually just extensions of the semantic set of this very namespace, or extensions of other sets of semantics. You can't attach semantics to XML without these tools, really. Microformats are just semantics attached to normally semantically indifferent constructs in an already existing set of semantics. I take it this has been suggested before, so what are the arguments / counter-arguments ?? Arguments for using plain home made XML is that you might want higher granularity and specificity of semantics than provided by preexisting XML applications. But really, to get that you essentially need to create that set of semantics and assign it to a namespace. Just naming something footnote or navigation doesn't mean it gets the semantic meaning of being a footnote or navigation. Nor does it convey any particular definition of how to handle that if no presentational or behavioral hints exists explicitly in the document, because the defaults on not-strictly-semantical aspects are also part of the semantic sets (In my view, at least. Which isn't neccesarily canon...) Counter arguments against it I think I've already mentioned. -- David liorean Andersson uri:http://liorean.web-graphics.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] [Please don't flame :)] HTML, XML what's the difference.
Hi Marilyn This is far from a perfect world. Before we can have perfectly lovely xml documents, we need to make sure all of the resources delivering content are also delivering perfectly lovely xml. Or... a broken page. Not everyone has the resources to put this together. So, it's good to have a more flexible option out there. Those that can use the better technology will have better sites and will be the stars of their high school reunions. Those of us stuck working with partner content that is questionable will still be in the corner sipping a diet-coke and eating way too many cookies. Ted www.tdrake.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marilyn Langfeld Sent: Wednesday, February 08, 2006 1:46 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] [Please don't flame :)] HTML, XML what's the difference. On Feb 8, 2006, at 4:04 PM, Stephen Stagg wrote: Why do we need an HTML 5? Can't we dispose of HTML and just use styled XML in the future? It would be one helluva way to enforce standards, and we wouldn't have all this wrangling over exactly which element to use. _ Here's a start: http://www.whatwg.org/ As well as I understand, there are dissenting voices about the development of the web: those who want to follow W3C's recommendations towards XHTML, those who want The Semantic Web based on XML, and those who want to extend HTML against the wishes of W3C. Plus those who don't want to change at all. I don't know much more than that, but I'm sure others on the list will fill in the blanks. Best regards, Marilyn Langfeld Langfeldesigns http://www.langfeldesigns.com [EMAIL PROTECTED] ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
Stephen Stagg wrote:
Why do we need an HTML 5? Can't we dispose of HTML and just use styled
XML in the future?
How could you know what style to apply to meaningless content?
Effective styling depends on document semantics. Without semantics, you
may as well be using font elements.
Effectively, it all comes down to this:
div class=hFoo Bar/div
.h { font-size: large; font-weight: bold; }
Would you agree that that is a bad idea? How is that any different from
inventing your own markup language and doing this:
mydocument
hFoo Bar/h
...
/mydocument
Microformats and Micro-Namespaces could then be used to allow true
semantic delivery.
A major factor in the development of microformats is that they reuse
existing document semantics, where possible. They aren't just about
making up new class names and relationship values. Micro-Namespaces
is a term you just made up, it means nothing.
--
Lachlan Hunt
http://lachy.id.au/
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
How could you know what style to apply to meaningless content?That's what the style-sheet is for. We are relying more and more on the display: element of CSS, why not define a well-thought out and extensible set of display types to replace the default behavior of many current tags. Want to include flash on your site? define a CSS rule:flashmovie{ display:flash;} and then your document reads:flashmovie src=""file://a.c.v/me.swf">file://a.c.v/me.swf" /Hell, even I know what that means :))Effective styling depends on document semanticsWrong, I see the point you are trying to make, but Styling is totally autonomous, It takes pre-defined rules and applies them to a list of tags, the CSS processor in modern browsers shouldn't care WHAT the semantic content of its tags are. div class="h"Foo Bar/div.h { font-size: large; font-weight: bold; }Would you agree that that is a bad idea?No (except the h doesn't provide any clue to the content) , but it seems silly to use a DIV element, which REDUCES semantics, having no meaning to anyone. Rather use, similar to that which you suggest:mydocument paragraph headingThis Heading Belongs to this Para/heading contentblah, blah, /content /paragraph/mydocumentThis is not meaningless, It is more readable than HTML, to a human. And when computers start to need to read websites automatically...A major factor in the development of microformats is that they reuse existing document semantics, where possible. They aren't just about making up new class names and relationship values. No, they re-use existing Standard formats, where possible, not Semantics. 'Semantics' means 'meaning'. Take the hCard format, a sample from the specification reads:span class="tel" span class="type"home/span: span class="value"+1.415.555.1212/span/spanHow in any way does a span element have semantic meaning? Then remove it. A sample from my imaginary XML hCard format reads:tel typehome/type value+1.415.555.1212/value/telNow that begins to have real semantic meaning, and is easy to read for a human. "Micro-Namespaces" is a term you just made up, it means nothing.I DID make it up but NO it is not meaningless, If you take the two parts separately, micro means small(ancient greek, µikros = small), namespace is a defined XML feature. My point is that When we get to the stage of using pure XML, the namespace and the format ideas could merge to allow a hCard namespace to be defined, if the hCard is a micro-format, then the xmlns hCard(or whatever) could also have a micro sticked before it. :)I understand that this is already possible in most modern browsers but it will never be used or properly implemented unless HTML is dropped as a language. Worried about screen-readers? I don't see why, the screen-readers would have to parse the CSS to find clues about how to read the content, but then modern ones already do.
Edit: Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
Sorry, it's late in England. I'm gonna go to bed now :)How could you know what style to apply to meaningless content?That's what the style-sheet is for. We are relying more and more on the display: element of CSS, why not define a well-thought out and extensible set of display types to replace the default behavior of many current tags. Want to include flash on your site? define a CSS rule:flashmovie{ display:flash;} and then your document reads:flashmovie src=""file://a.c.v/me.swf">file://a.c.v/me.swf" /Hell, even I know what that means :))Effective styling depends on document semanticsWrong, I see the point you are trying to make, but Styling is totally autonomous, It takes pre-defined rules and applies them to a list of tags, the CSS processor in modern browsers shouldn't care WHAT the semantic content of its tags is. div class="h"Foo Bar/div.h { font-size: large; font-weight: bold; }Would you agree that that is a bad idea?No (except the h doesn't provide any clue to the content) , but it seems silly to use a DIV element, which REDUCES semantics, having no meaning to anyone. Rather use, similar to that which you suggest:mydocument paragraph headingThis Heading Belongs to this Para/heading contentblah, blah, /content /paragraph/mydocumentThis is not meaningless, It is more readable than HTML, to a human. It may not have semantic meaning, but who needs semantic meaning.A major factor in the development of microformats is that they reuse existing document semantics, where possible. They aren't just about making up new class names and relationship values. No, they re-use existing Standard formats, where possible, not Semantics. 'Semantics' means 'meaning in the context of a language'. Take the hCard format, a sample from the specification reads:span class="tel" span class="type"home/span: span class="value"+1.415.555.1212/span/spanHow in any way does a span element have semantic meaning? The micro-format adds semantic meaning to the span elements in the example. Why not remove it. A sample from my imaginary XML hCard format reads:tel typehome/type value+1.415.555.1212/value/telNow THAT also to has real semantic meaning in the context of my (imaginary) proposed hCard format, and is easy to read for a human. Oh and it's lighter on bandwidth also. "Micro-Namespaces" is a term you just made up, it means nothing.I DID make it up but NO it is not meaningless, If you take the two parts separately, micro means small(ancient greek, µikros = small), namespace is a defined XML feature. My point is that When we get to the stage of using pure XML, the namespace and the format ideas could merge to allow a hCard namespace to be defined, if the hCard is a micro-format, then the xmlns hCard(or whatever) could also have a micro- stuck before it. :)I understand that this is already possible in most modern browsers but it will never be used or properly implemented unless HTML is dropped as a language. Worried about screen-readers? I don't see why, the screen-readers would have to parse the CSS to find clues about how to read the content, but then modern ones already do. :)Stephen.
Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
Stephen Stagg wrote:
How could you know what style to apply to meaningless content?
That's what the style-sheet is for. We are relying more and more on the
display: element of CSS, why not define a well-thought out and
extensible set of display types to replace the default behavior of many
current tags. Want to include flash on your site? define a CSS rule:
You seem to want to move the semantics from the markup layer to the
presentation layer. Do I really need to explain why that is not a good
idea?
flashmovie{ display:flash;}
and then your document reads:
flashmovie src=file://a.c.v/me.swf /
This shows that you have very little understanding of how the display
property works; and probably little understanding of CSS in general.
That's already possible with existing css:
flashmovie { content: attr(src); }
In fact, it's already possible with existing markup: object. Why do
you insist on reinventing the wheel? Are you aware of the reason why
applet was deprectaed? Obviously not, because you want to introduce a
flashmovie element.
Hell, even I know what that means :))
You may think you know what it means based on the tag-name, but without
any formally defined meaning that can be understood by a UA,
flashmovie is as meaningless as foobar.
Effective styling depends on document semantics
Wrong, I see the point you are trying to make,
No, you clearly do not.
but Styling is totally autonomous, It takes pre-defined rules and
applies them to a list of tags, the CSS processor in modern browsers
shouldn't care WHAT the semantic content of its tags are.
If there are no semantics, that removes all ability of the UA to do
anything useful with the content of the element, beyond rendering it to
the screen. Without the semantics of being a heading, how could a UA
build a TOC or (like Opera) provide easy keyboard shortcuts/voice
commands to navigate from heading to heading. Or what about hyperlinks?
Or any other semantic element in HTML. Without semantics, how could
Google effectively index your page? How could it determine what the
title of the document is for displaying in search results?
There are many things that can be done with semantics beyond simple
rendering with CSS.
div class=hFoo Bar/div
.h { font-size: large; font-weight: bold; }
Would you agree that that is a bad idea?
No (except the h doesn't provide any clue to the content) , but it seems
silly to use a DIV element, which REDUCES semantics, having no meaning
to anyone. Rather use, similar to that which you suggest:
mydocument
paragraph
headingThis Heading Belongs to this Para/heading
contentblah, blah, /content
/paragraph
/mydocument
Your custom heading element and div class=h have identical
meaning: none at all.
This is not meaningless
In that case, neither is this:
a
b
cThis Heading Belongs to this Para/c
dblah, blah, /d
/b
/a
If you disagree, what could a UA do with your markup that it couldn't
also do with mine? In fact, both are completely meaningless because
both are undefined.
--
Lachlan Hunt
http://lachy.id.au/
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
Lachlan Hunt wrote:
Stephen Stagg wrote:
flashmovie{ display:flash;}
and then your document reads:
flashmovie src=file://a.c.v/me.swf /
This shows that you have very little understanding of how the display
property works; and probably little understanding of CSS in general.
That's already possible with existing css:
flashmovie { content: attr(src); }
Correction, that should have been:
flashmovie { content: attr(src, url); }
--
Lachlan Hunt
http://lachy.id.au/
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
On 2/9/06, Stephen Stagg [EMAIL PROTECTED] wrote: This is not meaningless, It is more readable than HTML, to a human. And when computers start to need to read websites automatically... Humans read content, computers read markup. Humans don't read HTML (excusing, perhaps, the rare breed that inhabit this list and certain other niches of the web) for its semantics, relying instead on visual/aural cues to determine the importance of content. Markup is for computers. Computers need to read websites automatically today... search engine, anyone? RSS/Atom auto-discovery in modern browsers? Copying and pasting semantic web content as rich text into another application? (If you're doing it all with CSS, the default styles of elements are often inherited... with non-(machine-defined)-semantic markup this isn't possible). It IS meaningless for all intents and purposes. Consider a plain text document: humans make a distinction between types of content, computers do not... hence markup. Admittedly, we also use markup to provide communication cues... but that's ancillary to the core of it. Unpopular though this idea may be, web standards (recommendations, whatever) are actually about ensuring that User Agents can do something meaningful with what they're handed. It's the User Agent's job to communicate that to the actual user... so we're catering for machines, not humans. Josh ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
Joshua Street wrote: It IS meaningless for all intents and purposes. Consider a plain text document: humans make a distinction between types of content, computers do not... hence markup. Admittedly, we also use markup to provide communication cues... but that's ancillary to the core of it. Unpopular though this idea may be, web standards (recommendations, whatever) are actually about ensuring that User Agents can do something meaningful with what they're handed. It's the User Agent's job to communicate that to the actual user... so we're catering for machines, not humans. That's almost right, except that in the end, we *are* catering for humans. We just need to do so in a way that allows machines to effectively pass on our messages to the user; and that is what requires well-defined, computer-readable semantics. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] [Please don't flame :)] HTML, XML what's the difference.
Yep... I agree, hence web [...] recommendations are actually about rather than accessibility is actually about. Specs are purpose-agnostic (see pages that validate but are a semantic blight on the face of the web)... ironically, guidelines (human-language, practical documents) are actually more useful for applying technologies than the documents that define the technologies themselves! Josh On 2/9/06, Lachlan Hunt [EMAIL PROTECTED] wrote: in the end, we *are* catering for humans. We just need to do so in a way that allows machines to effectively pass on our messages to the user; and that is what requires well-defined, computer-readable semantics. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
