You seem to be trying to pit SVG against Flash, though I'm not sure why. My point about indexing SVG has nothing to do with whether Flash or SVG is "better", or even the differences between the formats; in fact, the only reason I mentioned Flash is by way of comparison with relative usage on the Web, and by any metric, Flash is far more widely used currently. If you prefer Flash, by all means use Flash. My blog post was about technical details of indexing SVG in search engines... in that context, I'm only interested in Flash if there are things we can learn from it to accomplish that goal, even negative examples such as the ones you're indicating with the contextless content.
But when I talk about SVG having text-as-text, and metadata attributes and elements, I am specifically talking about the human- and machine-readable content, not about the element and attribute names or geometric values. You may think that doesn't get you very far, but I strongly disagree. Also, the use of ARIA attributes can add an additional semantic layer on top of the structure and textual content, to make it even more accessible and indexible. In most cases, I wouldn't consider an image of an animal as an information graphic (though that depends... an anatomical drawing might be somewhat indexible).
As one of the folks on the SVG Working Group, defining the SVG specification, I can assure you that it is not an abuse of the format to use text content, or metadata; in fact, it's considered a best practice, and encouraged explicitly. It may not be to your taste, but it suits many people very well. HTML is not the only information-rich structured data format, nor often is it the best one... it is almost certainly the most popular, and not just on the Web, but it's not very good at describing graphics, or math, or any number of other areas.
(As an aside, just to clarify your misconception, SVG does have timelines and declarative animation, and SVG Tiny 1.2 for mobile devices also has audio and video; on the desktop platform, we rely on HTML for audio and video, since SVG integrates well with HTML and we don't need to duplicate that functionality. One of SVG's strengths is that it builds on, integrates, and enhances other web standards people already know, like HTML, CSS, DOM, Javascript, etc.)
Scripted dynamic content often injects new content into the DOM, or replaces or removes existing content. In extreme (but common) cases, the majority of content is dynamically inserted into the DOM clientside, which makes it a very poor candidate for indexing. Without existing structure, hyperlinks, and textual content (text, metadata, titles, descriptions, etc.), search engines have little to go on.
The kind of dynamic interactive content you're talking about, using declarative markup or script that merely manipulates existing DOM content rather than changing it, already has the structure and textual content, and is thus more readily and pragmatically indexible.
It's not black and white, but the presence of script is the most simple heuristic I can think of for detecting content which is less suitable to be treated as an image, or which is expected to dramatically change. I would be satisfied if this were used as a first-pass solution on determining which SVG files would appear for image searches and which would be treated more like HTML.
I don't know enough about Flash to speak about its indexibility compared to HTML, but there are an awful lot of HTML applications which are indexed. So, I don't think it's necessarily how "static" a file is that lends itself to being indexed, but how popular and "contentful" the file or service is. The format of the file shouldn't prejudice a search engine toward or away from indexing it; each file format has its own challenges and benefits.
Okay, I'm not in a position to defend Flash (I was trying to be nice by giving it the benefit of the doubt), but SVG was designed from the bottom up as a text format, where visible text is exactly that, and while some SVGs don't contain any text or metadata, many do have a significant percentage of relevant textual data. You presume (I believe incorrectly) that the text in an SVG file is irrelevant, because you're comparing it with Flash. SVG is not Flash, and it's not necessarily used in the same way.
But even for SVG files that don't have indexible internal content, they could be treated on par with the support that Google supplies for images, where the surrounding text informs the indexing and ranking.
As for discerning when a file is an application rather than a static file, that's relatively easy... look for a script element. Many HTML files are just as "meaningless", when HTML is used for an application rather than a documents, for what that's worth.
But I'm not saying that all SVGs, today, are optimized for searching and indexing. I think we would benefit from establishing some best practices, and maybe even changing the format a bit, to make SVG files more indexible, where it makes sense to do so... for static, information-rich graphics and so forth.
The problems are real: we need a way for information graphics to be easily created in an accessible way, and we need for those graphics for be readily findable. How we get there is what I'm interested in.
You raise a good point, but I'm not actually talking about the actual amount of content on the web, I'm talking about how it is indexed and searchable (in this case, by Google). I'm sure that there is a lot more Flash content than my rough study indicates, and I could be clearer about that in my blog post, but for the purposes of discussing the relative representation in search results, I think it's fair to say that the presence (or lack of presence) of content is distorted by how easy it is to find it through the search engine.
Ultimately, it doesn't matter how much Flash or SVG content is on the web... both should be indexed and represented in search results. How we get to that point, and how we can make is fruitful for people searching for the content, is the interesting question.
Re:Don't overestimate Invited Expert status
on
Problems at the W3C
·
· Score: 1
True. But it's not that onerous to apply, from what I understand. In many cases, applying is simply a formality, and is often a procedural follow-on from an informal invitation. You could be turned down, although this would be bizarre if they extended you the invitation in the first place.
But again, being an Invited Expert is not the only way you can have an effect. As others have noted, formal involvement in a Working Group can be a serious time investment, but anyone is welcome to send feedback to the appropriate public list. In fact, a Working Group is required to give a formal technical reply to any comment received on a Last Call draft.
I think that it is a pretty open process in most cases, even though this can be a challenge. It can delay or even cripple the publication of a specification, which means that the W3C can't respond to real-world market pressures as quickly as many would like. Ironically, some of the people who complain that the W3C isn't agile enough are the same ones who hold up specifications on process issues.
It's not easy reaching consensus. I'm sure that's why your own WCAG Samurai initiative is a closed process. In fact, you're pretty extreme about it:
Membership rolls will not be published, and membership is by invitation only. Don't call us; we'll call you.
But as someone deeply concerned with accessibility issues, I applaud your actions in that arena.
With all dues respect, I wasn't referring to Bjoern's email, as I explicitly stated. I was only addressing Mr. Zeldman's claims on his uncommentable blog. And I didn't miss his larger point; in fact, I contrasted it directly with my own personal experiences.
I think it's a shame that you and others have felt locked out of the input process for some specifications. I think this should be addressed. I don't know how much more clearly I can state that. That being said, the Working Groups I'm in (one of them being WebAPIs, with Bjoern and Hixie) are trying very hard to be responsive. Time is at a premium for all of us, but we do take input seriously.
As for publishing standards that other people wrote... many would argue that that is the entire point of a standards body. Some think that *no* language design should take place inside a standards body, only standardization of existing implementations and practices to ensure interoperability. That is almost the entire goal of the WHATWG specs that you cite, in fact. (Back me up here, Hixie?) I prefer a mix of standardization and innovation myself, and that's what I bring to the table.
Also, it's worth noting that the organizations you now look to for innovation and leadership take an active role in the W3C! That's how and why it works.
"Is your argument that it's simply a bad public that doesn't deserve a better set of standards"
Please don't use crappy, simplistic misinterpretations of my statements to spread yet more FUD. I happen to be part of the public, as I already stated, and I wanted better standards, so I took up the task of pitching in a few months ago.
Any design-by-committee process is going to be unpalatable to some percentage of people, even inside that organization (as Bjoern, Hixie, and myself all are). Does that mean that it is fatally flawed, just because it doesn't satisfy everyone? No. But does that mean that we should just throw up our hands and ignore those that are displeased? Also no. Systems change, and I believe that the W3C is changing, even if it's not as quickly as some would like. Bjoern and Hixie are among many individuals working within the W3C who are very vocal about tightening up various specifications, and it is having a positive effect.
Please also remember that the W3C is not a monolithic entity. It is comprised of dozens of Working Groups, hundreds of companies, and thousands of individuals, each with their own set of agendas. Not all groups or people operate in exactly the same way, and it's naive (or duplicitous) to characterize them that way.
Finally, I'm not an apologist for the W3C. I'm just relating my own experiences and my own opinion. I have my own issues about some things within W3C. That's one reason I joined. But I'm all for other standards and forums making the Web better. I just think that the W3C is a key piece of that puzzle.
It would be silly to argue against Bjoern's (and Zeldman's) assertion that these services should be more reliable.
But I wasn't commenting on Bjoern's statements, which stand on their own merits (though he does cite Zeldman on the twin accusations of expense and exclusivity of the W3C). I just don't like to see FUD spread around.
"Some of the best minds working in web standards have been quietly or loudly abandoning the W3C. Bjoern Hoehrmann is the latest."
It's interesting that Mr. Zeldman links to an email in which Bjoern explicitly states that he is only leaving the QA Dev team, and is focusing on the W3C CSS and WebAPI Working Groups, where he is still active.
"Beholden to its corporate paymasters who alone can afford membership, the W3C seems increasingly detached from ordinary designers and developers."
I will note that Bjoern is one of many invited experts in the W3C... you don't have to pay to participate.
"It remains a closed, a one-way system."
As for me, I'm an ordinary developer, and my small consulting company ponied up the dough to join the W3C because we thought that it would be worth it to have a hand in leading standards and having a say in how things are developed. My new workplace, 6th Sense Analytics, will also be joining, because they feel the same way. Oh, and we didn't join at the 50K level, we joined at the reasonable 6K level, and I have never felt like we were treated as second-class citizens. If companies care enough about the standards they wish to adhere to, they can easily get involved in the W3C and mkae the changes... the more hands doing work, the better.
"To be fair, the W3C solicits community feedback before finalizing its recommendations. But asking people to comment on something that is nearly finished is not the same as finding out what they need and soliciting their collaboration from the start."
This statement is predicated on the idea that there is no way to ask for features and present use cases to the appropriate Working Group, a claim that Mr. Zeldman must know is incorrect. The SVG WG, for example, is basing many of its new features on author and user feedback over the last several years (from both the official W3C SVG list and the Yahoogroups SVG-Developers list), as well as taking into account the needs of its member organizations.
Promoting other standards besides those from W3C, like microformats, is great. There's no need to be so disingenuous and inflammatory about it, though. Mr. Zeldman has no talkback on his forum for me to refute his claims, so I had to post this here. I think he's becoming increasingly detached from ordinary designers and developers. Okay, that was a cheap joke... couldn't help myself.
Slashdot Mirror
You seem to be trying to pit SVG against Flash, though I'm not sure why. My point about indexing SVG has nothing to do with whether Flash or SVG is "better", or even the differences between the formats; in fact, the only reason I mentioned Flash is by way of comparison with relative usage on the Web, and by any metric, Flash is far more widely used currently. If you prefer Flash, by all means use Flash. My blog post was about technical details of indexing SVG in search engines... in that context, I'm only interested in Flash if there are things we can learn from it to accomplish that goal, even negative examples such as the ones you're indicating with the contextless content.
But when I talk about SVG having text-as-text, and metadata attributes and elements, I am specifically talking about the human- and machine-readable content, not about the element and attribute names or geometric values. You may think that doesn't get you very far, but I strongly disagree. Also, the use of ARIA attributes can add an additional semantic layer on top of the structure and textual content, to make it even more accessible and indexible. In most cases, I wouldn't consider an image of an animal as an information graphic (though that depends... an anatomical drawing might be somewhat indexible).
As one of the folks on the SVG Working Group, defining the SVG specification, I can assure you that it is not an abuse of the format to use text content, or metadata; in fact, it's considered a best practice, and encouraged explicitly. It may not be to your taste, but it suits many people very well. HTML is not the only information-rich structured data format, nor often is it the best one... it is almost certainly the most popular, and not just on the Web, but it's not very good at describing graphics, or math, or any number of other areas.
(As an aside, just to clarify your misconception, SVG does have timelines and declarative animation, and SVG Tiny 1.2 for mobile devices also has audio and video; on the desktop platform, we rely on HTML for audio and video, since SVG integrates well with HTML and we don't need to duplicate that functionality. One of SVG's strengths is that it builds on, integrates, and enhances other web standards people already know, like HTML, CSS, DOM, Javascript, etc.)
I agree, for some value of the word "dynamic".
Scripted dynamic content often injects new content into the DOM, or replaces or removes existing content. In extreme (but common) cases, the majority of content is dynamically inserted into the DOM clientside, which makes it a very poor candidate for indexing. Without existing structure, hyperlinks, and textual content (text, metadata, titles, descriptions, etc.), search engines have little to go on.
The kind of dynamic interactive content you're talking about, using declarative markup or script that merely manipulates existing DOM content rather than changing it, already has the structure and textual content, and is thus more readily and pragmatically indexible.
It's not black and white, but the presence of script is the most simple heuristic I can think of for detecting content which is less suitable to be treated as an image, or which is expected to dramatically change. I would be satisfied if this were used as a first-pass solution on determining which SVG files would appear for image searches and which would be treated more like HTML.
I don't know enough about Flash to speak about its indexibility compared to HTML, but there are an awful lot of HTML applications which are indexed. So, I don't think it's necessarily how "static" a file is that lends itself to being indexed, but how popular and "contentful" the file or service is. The format of the file shouldn't prejudice a search engine toward or away from indexing it; each file format has its own challenges and benefits.
Okay, I'm not in a position to defend Flash (I was trying to be nice by giving it the benefit of the doubt), but SVG was designed from the bottom up as a text format, where visible text is exactly that, and while some SVGs don't contain any text or metadata, many do have a significant percentage of relevant textual data. You presume (I believe incorrectly) that the text in an SVG file is irrelevant, because you're comparing it with Flash. SVG is not Flash, and it's not necessarily used in the same way.
But even for SVG files that don't have indexible internal content, they could be treated on par with the support that Google supplies for images, where the surrounding text informs the indexing and ranking.
As for discerning when a file is an application rather than a static file, that's relatively easy... look for a script element. Many HTML files are just as "meaningless", when HTML is used for an application rather than a documents, for what that's worth.
But I'm not saying that all SVGs, today, are optimized for searching and indexing. I think we would benefit from establishing some best practices, and maybe even changing the format a bit, to make SVG files more indexible, where it makes sense to do so... for static, information-rich graphics and so forth.
The problems are real: we need a way for information graphics to be easily created in an accessible way, and we need for those graphics for be readily findable. How we get there is what I'm interested in.
You raise a good point, but I'm not actually talking about the actual amount of content on the web, I'm talking about how it is indexed and searchable (in this case, by Google). I'm sure that there is a lot more Flash content than my rough study indicates, and I could be clearer about that in my blog post, but for the purposes of discussing the relative representation in search results, I think it's fair to say that the presence (or lack of presence) of content is distorted by how easy it is to find it through the search engine.
Ultimately, it doesn't matter how much Flash or SVG content is on the web... both should be indexed and represented in search results. How we get to that point, and how we can make is fruitful for people searching for the content, is the interesting question.
True. But it's not that onerous to apply, from what I understand. In many cases, applying is simply a formality, and is often a procedural follow-on from an informal invitation. You could be turned down, although this would be bizarre if they extended you the invitation in the first place.
But again, being an Invited Expert is not the only way you can have an effect. As others have noted, formal involvement in a Working Group can be a serious time investment, but anyone is welcome to send feedback to the appropriate public list. In fact, a Working Group is required to give a formal technical reply to any comment received on a Last Call draft.
I think that it is a pretty open process in most cases, even though this can be a challenge. It can delay or even cripple the publication of a specification, which means that the W3C can't respond to real-world market pressures as quickly as many would like. Ironically, some of the people who complain that the W3C isn't agile enough are the same ones who hold up specifications on process issues.
It's not easy reaching consensus. I'm sure that's why your own WCAG Samurai initiative is a closed process. In fact, you're pretty extreme about it:
But as someone deeply concerned with accessibility issues, I applaud your actions in that arena.I think it's a shame that you and others have felt locked out of the input process for some specifications. I think this should be addressed. I don't know how much more clearly I can state that. That being said, the Working Groups I'm in (one of them being WebAPIs, with Bjoern and Hixie) are trying very hard to be responsive. Time is at a premium for all of us, but we do take input seriously.
As for publishing standards that other people wrote... many would argue that that is the entire point of a standards body. Some think that *no* language design should take place inside a standards body, only standardization of existing implementations and practices to ensure interoperability. That is almost the entire goal of the WHATWG specs that you cite, in fact. (Back me up here, Hixie?) I prefer a mix of standardization and innovation myself, and that's what I bring to the table.
Also, it's worth noting that the organizations you now look to for innovation and leadership take an active role in the W3C! That's how and why it works.
Any design-by-committee process is going to be unpalatable to some percentage of people, even inside that organization (as Bjoern, Hixie, and myself all are). Does that mean that it is fatally flawed, just because it doesn't satisfy everyone? No. But does that mean that we should just throw up our hands and ignore those that are displeased? Also no. Systems change, and I believe that the W3C is changing, even if it's not as quickly as some would like. Bjoern and Hixie are among many individuals working within the W3C who are very vocal about tightening up various specifications, and it is having a positive effect.
Please also remember that the W3C is not a monolithic entity. It is comprised of dozens of Working Groups, hundreds of companies, and thousands of individuals, each with their own set of agendas. Not all groups or people operate in exactly the same way, and it's naive (or duplicitous) to characterize them that way.
Finally, I'm not an apologist for the W3C. I'm just relating my own experiences and my own opinion. I have my own issues about some things within W3C. That's one reason I joined. But I'm all for other standards and forums making the Web better. I just think that the W3C is a key piece of that puzzle.
Hey, Hixie-
It would be silly to argue against Bjoern's (and Zeldman's) assertion that these services should be more reliable.
But I wasn't commenting on Bjoern's statements, which stand on their own merits (though he does cite Zeldman on the twin accusations of expense and exclusivity of the W3C). I just don't like to see FUD spread around.
-schepers
Promoting other standards besides those from W3C, like microformats, is great. There's no need to be so disingenuous and inflammatory about it, though. Mr. Zeldman has no talkback on his forum for me to refute his claims, so I had to post this here. I think he's becoming increasingly detached from ordinary designers and developers. Okay, that was a cheap joke... couldn't help myself.