Re: [whatwg] add html-attribute for responsive images
Am 06.09.2011 um 08:36 schrieb Ashley Sheridan: On Tue, 2011-09-06 at 07:15 +0200, Karl Dubost wrote: Le 5 sept. 2011 à 15:07, Anselm Hannemann - Novolo Designagentur a écrit : Why should we use inline-styles once again? Why should we load content images with CSS? What about accessibility? Where to add alt-attribute / title / ARIA etc.? Not exactly what is happening. There is a URI with an image without a javascript and/or CSS activated. The CSS changes the image dynamically depending on the user experience context controlled by mediaqueries. Yes, but the point is, the alternative images you may want to display for visitors on a smaller screen/resolution could be completely different from the original image (cropped shot not showing all the detail, etc). Ergo, you lose the accessibility because you now can't textually represent it in the alt tag. Right you hit the nail on the head. And, by the way, how should we work with your solution, Karl, and a CMS or CSS files from a static domain? Is no one building a dynamic site?
Re: [whatwg] comment element
On Tue, Sep 6, 2011 at 2:10 AM, Shaun Moss sh...@astromultimedia.com wrote: One reasonable alternative is *cmnt* This certainly has a better legacy compatibility story than comment. :) Back to the main point of marking up comments, I offer youtube as an example. http://www.youtube.com/watch?v=BRG5VNNUq_E Here we have the item being commented on (the video) in a full-width block, with the lower half of the page divided into two sections, comments on the left. If user-submitted comments must be article tags inside article tags, then virtually the whole page would have to be inside an article tag, or, of course, the user-submitted comments are marked up as now, using class=comment. Can you express this in terms of the problems it causes to end-users? As far as I can tell, it's not a problem. The problem I am trying to solve is a perceived error in the HTML5 spec, which specifies that comments should be marked up as articles inside articles. I believe this to be an error for several reasons: 1. Articles and comments are different, and should therefore use different elements (otherwise the reference to marking up user-submitted comments as articles within articles should be removed). [S]elf-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication is a concept that includes comments, blog posts, and news stories. So there's no contradiction in the spec here. I grant article is a potentially confusing name for this concept. One could bikeshed about the name; I suspect if you consult the archives such bikeshedding has already happened. 2. Comments are a unique type of content, since they are submitted by users, not site developers or content managers. This is not unique to comments. For example, some sites feature user-submitted stories, blog posts, etc. Even if it were unique to comments, I don't see how it creates a user problem we'd need markup to solve. 3. Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. What user problems do the existing solutions to these tasks cause? e.g. RSS/Atom feeds, hAtom, old-fashioned scraping for extraction, syndication of comments. e.g. class for styling. Why do you think we could get enough systems to use the comment element correctly enough to support the creation of new solutions using the comment tag instead? 4. Comments often apply to things other than articles, such as blog posts, forum topics, social network status updates, images, videos, links, and other comments, which should not have to be marked up as articles just so the comments can be marked up as articles within articles. a) A lot of those things are appropriately marked up with article as self-contained composition[s]. In particular, blog posts, forum topics, social network updates, and comments should all be marked up with article per HTML5. In some contexts, that would also be appropriate for images and videos. Nothing in the definition of the element implies it's restricted to text content. b) Since a comment is just a self-contained composition, it can be marked up with article whether nested inside another article or not. So there isn't a problem here. 5. Comments sometimes appear in a different region of the page than the item that they are referencing, hence the markup for comments should not have to be contained within the markup of the item. a) No user problems have been identified that would be created by not having the comment article's nested. That would just be the most common pattern. b) Do you have an example of what you're talking about? It sounds like the comments could still be nested under the article, with intervening matter placed there by CSS - including future features that allow rearrangement of the order of block content, for example: http://www.w3.org/TR/css3-content/ We generally don't want to introduce markup features for problems that can be solved through better styling features. -- Benjamin Hawkes-Lewis
Re: [whatwg] add html-attribute for responsive images
Ashley, Anselm, Le 6 sept. 2011 à 08:36, Ashley Sheridan a écrit : Yes, but the point is, the alternative images you may want to display for visitors on a smaller screen/resolution could be completely different from the original image (cropped shot not showing all the detail, etc). Yes already happening with background images with not text alt at all. So let's say it is progress. Le 6 sept. 2011 à 09:07, Anselm Hannemann - Novolo Designagentur a écrit : by the way, how should we work with your solution, Karl, and a CMS or CSS files from a static domain? Is no one building a dynamic site? could you clarify? -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
[whatwg] Detached elements and delaying the load event
I'm going to use the img element as an example here, but the same thing applies to other elements such as iframe, video, audio. I'm going to assume that the user agent obtains the images immediately, given that seems to be what most browsers do. If an img element is created and given a src attribute (but not necessarily attached to the tree) then, according to HTML5, we need to update the image data and therefore delay the load event. I guess this means we should lock the image element in a similar fashion to XMLHttpRequest objects, otherwise the image could be garbage collected before it has been loaded and therefore block the load event indefinitely. Firefox, Opera, Chrome and Safari do seem to implement this behaviour, IE does not. I would prefer not to implement this and just say detached elements do not delay the load event, but I'm not sure if that will always work. Can we please get a clarification in HTML5, either to say that these detached objects must not be garbage collected while they are delaying the load event, or to say that they do not delay the load event. Thanks -- Andrew Oakley
Re: [whatwg] comment element
6.9.2011 12:40, Benjamin Hawkes-Lewis wrote: [S]elf-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication is a concept that includes comments, blog posts, and news stories. So there's no contradiction in the spec here. We probably understand the words self-contained and independently very differently then. I cannot see a typical comment as self-contained, as it by definition implies the context created by the document being commented on. So how could it be *independetly* reused and syndicated? A typical comment might be a bit more than Me too! or I especially like the second paragraph or Gruntmaster 6000 is the best! But it's seldom written to be self-contained or reusable independently (if at all). What user problems do the existing solutions to these tasks cause? e.g. RSS/Atom feeds, hAtom, old-fashioned scraping for extraction, syndication of comments. e.g. class for styling. Such arguments could be used against _any_ new markup elements (and almost any existing elements - do we really need much more elements than a when we can use metadata, styling, and scripting? :-)). Why do you think we could get enough systems to use thecomment element correctly enough to support the creation of new solutions using thecomment tag instead? That's the question I've been asking since the start of this discussion, and I am getting _less_ pessimistic. b) Since a comment is just a self-contained composition, it can be marked up witharticle whether nested inside anotherarticle or not. If comments are generally self-contained compositions, what would be an example of a composition that is _not_ self-contained? -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] comment element
6.9.2011 18:43, Tab Atkins Jr. wrote: If comments are generally self-contained compositions, what would be an example of a composition that is _not_ self-contained? A section of an article, for example. I see no reason why a section of an article could not be self-contained. For example, in any lengthy presentation, there should be an introductory part, and it had better be self-contained. So should a summary, and quite often many appendix-like parts. Besides, referring to markup as defined in HTML5 (which is, no matter whether you think of it as a living standard or a sequence of drafts, something that hasn't been seriously implemented and widely used in this respect) is at a wrong category level. The question what would be an example of a composition that is _not_ self-contained really calls for examples of content, no matter what its markup might be. You seem to think (and the living standard's current manifestation / the current draft may well be based on such thinking too) that self-contained means not part of any other composition. That's not my understanding of self-contained. Rather, being self-contained means that the presentation is complete, not implying some external content or requiring the recipient to get part of the information from elsewhere. Self-contained presentation is, to me, something that you can read in a bus without any Internet connection or books to consult, without requiring that have read some specific prerequisites. Here's what Webster's Encyclopedia Unabridged Dictionary of the English Language says about self-contained: containing in oneselfor itself all that is necessary; independent. I don't that this message of main is self-contained, and typical blog postings are even clearer examples. My message contains a reference to and a quotation from the message being commented on, but it's still very far from being self-contained. One needs to know or learn quite a lot about the topic area, the specific issue being discussed, and the previous discussion to understand this message. And this applies a bit stronger to, say, comments like Bullshit! :-) -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] comment element
Normally I just lurk here, but have been observing this conversation as I think it's bringing up some important concepts about the web and the role of HTML. For example: article id=interesting-article Interesting article article id=self-contained-article a href=http://www.example.org/interesting;Interesting article also here/a /article /article While #self-contained-article is self-contained in that it gives a user agent everything it needs, and given an internet connection, transfers it to the user, it's not self-contained in the traditional, dictionary sense. Because its content is simply not there in this document. Additionally, this example points out that in its dependence on #interesing-article, #self-contained-article *should* retain that information if it's to be semantically rich enough. While #interesting-article in fact is an element of the document obtained at its URL, #self-contained-article exhibits two relationships, one which is specified by the link it contains, and another, unspecified, by the URL of the document it lives in AND the #interesting-article in that doc which contains #self-contained-article. Just some food for thought... Aaron -- Aaron Miller Co-founder, BookGlutton/ReadSocial Senior Developer, Netgalley.com
Re: [whatwg] comment element
Browsing the web with user-submitted comments hidden sounds like a good use case. There are extensions that do that in various browsers: https://addons.mozilla.org/en-US/firefox/addon/commentblocker/ https://chrome.google.com/webstore/detail/ckdphbkdjpkpjabcnfogjmlddegeoenc http://userscripts.org/scripts/show/74340 Even if we agree that a nested article can be a comment, there is no guarantee that every nested article is a comment. Thus browsing with comments hidden cannot be implemented by hiding nested article elements (there's no indication whether nested articles are comments, or nesting was done with other purpose in mind). Therefore I suggest we paint this shed with: article type=comment -- regards, Kornel Lesiński
Re: [whatwg] comment element
On Tue, Sep 6, 2011 at 4:28 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 6.9.2011 12:40, Benjamin Hawkes-Lewis wrote: [S]elf-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication is a concept that includes comments, blog posts, and news stories. So there's no contradiction in the spec here. We probably understand the words self-contained and independently very differently then. I cannot see a typical comment as self-contained, as it by definition implies the context created by the document being commented on. So how could it be *independetly* reused and syndicated? For example, a system might aggregate a user's comments across multiple comment-points. http://wordpress.org/support/topic/show-only-comments-by-specific-registered-user A typical comment might be a bit more than Me too! or I especially like the second paragraph or Gruntmaster 6000 is the best! But it's seldom written to be self-contained or reusable independently (if at all). Human communication is never entirely context-free. What user problems do the existing solutions to these tasks cause? e.g. RSS/Atom feeds, hAtom, old-fashioned scraping for extraction, syndication of comments. e.g. class for styling. Such arguments could be used against _any_ new markup elements (and almost any existing elements - do we really need much more elements than a when we can use metadata, styling, and scripting? :-)). Certainly, but that doesn't reduce the force of those arguments one iota. If the claim is we need to solve a user problem, and we have existing tools/features that solve that problem, then we should ensure any features proposed would solve it significantly better than those existing tools/features. b) Since a comment is just a self-contained composition, it can be marked up witharticle whether nested inside anotherarticle or not. If comments are generally self-contained compositions, what would be an example of a composition that is _not_ self-contained? I agree with Tab's answer. -- Benjamin Hawkes-Lewis
Re: [whatwg] comment element
6.9.2011 21:38, Benjamin Hawkes-Lewis wrote: On Tue, Sep 6, 2011 at 4:28 PM, Jukka K. Korpelajkorp...@cs.tut.fi wrote: [...] We probably understand the words self-contained and independently very differently then. I cannot see a typical comment as self-contained, as it by definition implies the context created by the document being commented on. So how could it be *independetly* reused and syndicated? For example, a system might aggregate a user's comments across multiple comment-points. How would that be *independent* reuse and syndication? A comment does not become any more self-contained when considered as a member of the set of one user's all comments. A typical comment might be a bit more than Me too! or I especially like the second paragraph or Gruntmaster 6000 is the best! But it's seldom written to be self-contained or reusable independently (if at all). Human communication is never entirely context-free. Human communication usually fails, except by accident, as prof. Wiio has taught us. But anything that applies to all human communication is not particularly relevant when considering markup for some specific types of messages. Self-containedness is relative. But this does not mean it is empty concept. And if it were, why use it at all? Surely there is a difference between, say, a blog entry or a newspaper article carefully crafted to stand on its own, so that you can read it as such and take a position on it, and a typical blog comment or a comment in an online news system where nobody expects your comments to be in any way understandable outside the context. Such arguments could be used against _any_ new markup elements (and almost any existing elements - do we really need much more elements thana when we can use metadata, styling, and scripting? :-)). Certainly, but that doesn't reduce the force of those arguments one iota. It does. An argument that would, if it were relevant, apply to all new proposals and even most existing elements is not interesting. If the claim is we need to solve a user problem, and we have existing tools/features that solve that problem, then we should ensure any features proposed would solve it significantly better than those existing tools/features. Which user problem in that sense does _any_ of the new elements in HTML5 solve? I could list down a few, but elements like footer do not solve any user problems. Or author problems; introducing footer.../footer just as shorthand for div class=footer.../div is worse than pointless - especially since the latter actually works well, whereas footer needs extra tricks even to get the styling going. The only excuse for adding footer is the expectation that some day some browsers, indexing robots, or other relevant software will do something useful with it. I haven't seen any specific arguments saying why such expectations are realistic. And I don't ask for them. So why would all the other suggested elements need better motivation? There is absolutely no user problem that footer solves. Or section or article for that matter. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] comment element
2011/9/6 Kornel Lesiński kor...@geekhood.net: Browsing the web with user-submitted comments hidden sounds like a good use case. There are extensions that do that in various browsers: https://addons.mozilla.org/en-US/firefox/addon/commentblocker/ https://chrome.google.com/webstore/detail/ckdphbkdjpkpjabcnfogjmlddegeoenc http://userscripts.org/scripts/show/74340 @class=comment seems to solve this problem fairly well. https://addons.mozilla.org/en-US/firefox/files/browse/130567/file/chrome/content/application.jsm#L28 An official bit of vocabulary might solve it a bit better, but increase the complexity of the language. For this use case, comments might be better than cmnt so that one could hide the chrome and widgets and cruft that form part of modern comment lists. I *like* the idea of this use case, but almost nobody uses the CommentBlocker addon (870 users after 3 versions). So this use case may be too narrow to support introducing core vocabulary. -- Benjamin Hawkes-Lewis
Re: [whatwg] comment element
On Tue, Sep 6, 2011 at 8:02 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: For example, a system might aggregate a user's comments across multiple comment-points. How would that be *independent* reuse and syndication? A comment does not become any more self-contained when considered as a member of the set of one user's all comments. It's reused in a different context (to see what someone has said). This seems a fairly straightforward example to me? Self-containedness is relative. But this does not mean it is empty concept. And if it were, why use it at all? Surely there is a difference between, say, a blog entry or a newspaper article carefully crafted to stand on its own, so that you can read it as such and take a position on it, and a typical blog comment or a comment in an online news system where nobody expects your comments to be in any way understandable outside the context. One can draw all sorts of distinctions; not all of them need to be expressed in markup. Such arguments could be used against _any_ new markup elements (and almost any existing elements - do we really need much more elements thana when we can use metadata, styling, and scripting? :-)). Certainly, but that doesn't reduce the force of those arguments one iota. It does. An argument that would, if it were relevant, apply to all new proposals and even most existing elements is not interesting. The discussion needs to be had about all new feature proposals. In the case of some other elements, this argument by showing that the feature does solve the problem better than other solutions. If the claim is we need to solve a user problem, and we have existing tools/features that solve that problem, then we should ensure any features proposed would solve it significantly better than those existing tools/features. Which user problem in that sense does _any_ of the new elements in HTML5 solve? nav and article can be used to allow users to skip navigation, move to the next block of self-contained content, or move to the next content of the page. section allows authors to express heading levels beyond 6 (and thus allow users to navigate by such headings), and more easily put content from disparate sources together (making it less likely users will be presented with an incorrect heading order). I'm not sure what user problem footer solves, but it's not important to my argument that HTML5 as it stands is perfect. We should be removing elements that don't solve problems, not adding more. (Note I am not saying that comment does not solve problems - I haven't decided that yet. I'm saying we should solve problems and that if we're proposing new markup we should evaluate it based on how it solves problems.) -- Benjamin Hawkes-Lewis
Re: [whatwg] comment element
On 2011-09-07 5:17 AM, Benjamin Hawkes-Lewis wrote:
2011/9/6 Kornel Lesińskikor...@geekhood.net:
Browsing the web with user-submitted comments hidden sounds like a good use
case. There are extensions that do that in various browsers:
https://addons.mozilla.org/en-US/firefox/addon/commentblocker/
https://chrome.google.com/webstore/detail/ckdphbkdjpkpjabcnfogjmlddegeoenc
http://userscripts.org/scripts/show/74340
@class=comment seems to solve this problem fairly well.
Of course! So does class=article, class=header, class=footer, etc.
However, in my understanding the purpose of the new semantic elements in
HTML5 is to provide a consistent mechanism for distinguishing different
types of content in a web page, instead of everyone just using their own
class names and ids. This empowers user agents to do things with the
different types of content, such as skip navigation, transpose articles
to different sites, or generate meaningful document outlines. Of course
we can all just keep using class=comment, but then browsers can't do
anything with comments, since HTML authors will not be consistent with
class names and ids.
As it stands, there's no practical way for a user agent to distinguish
between articles and comments. Even if they use the unappealing rule of
comments are articles within articles, this is hardly an elegant
solution since user-submitted comments are often:
(a) not connected with articles, e.g. facebook status updates; or
(b) are not marked up inside the same region as the article or whatever
is being commented on, e.g. youtube.
Why would we want to distinguish between articles and comments? Because
they are different. Yes, it's possible for users to submit articles, but
this doesn't make them comments!
- Articles are generally the main feature of a web page and the most
important and valuable content on the page. It's true that
user-submitted comments are occasionally valuable, but they're typically
trivial (facebook and youtube again as examples)
- An article can stand alone, without comments, even if those comments
add content (e.g. PHP documentation). A comment, however, needs context,
hence the addition of the 'for' attribute. You would not be able to take
a comment such as Yeah, I love that video!, post it on a page by
itself, and have it make sense. This is what I understand stand-alone
to mean.
- It's unlikely that a user would want to hide an article, but it's
quite possible that they might want to hide comments.
It's not practical to mark up everything that has comments attached to
it with an article tag. As mentioned, comments can apply to links,
images, videos, music, status updates - basically any kind of multimedia
or content. Comments may be like articles in some ways, but they are not
articles, and they shouldn't be bound only to articles. They should be a
separate thing that can reference any other element.
Another useful feature of comments would be the ability to extract
conversations from web pages. One comment could be for an article,
video, link or whatever, but a /reply/ to that comment could be for
the previous comment. With the current spec, this would require placing
an article inside an article inside an article, and so on for however
many replies there are (consider our current email thread, for
instance). This is not beautiful or practical, in my opinion! It would
make nested tables look elegant. But if conversations can be extracted
from a web page, they can be archived, searched, syndicated, reorganised
in different ways (linear vs. threaded views), etc.
As yet another use case, comments are often marked up differently.
Consider this CSS:
/* this CSS applies to articles as well as comments */
article {
background-color: white;
font-size: 1em;
}
/* this CSS is for comments, and overrides the previous definition */
article article {
background-color: silver;
font-size: 0.8em;
}
vs. this:
article {
background-color: white;
font-size: 1em;
}
cmnt {
background-color: silver;
font-size: 0.8em;
}
Which would you prefer to code?
https://addons.mozilla.org/en-US/firefox/files/browse/130567/file/chrome/content/application.jsm#L28
An official bit of vocabulary might solve it a bit better, but
increase the complexity of the language.
I think that the web can bear the weight of one or two more tags :)
For this use case,comments might be better thancmnt so that one
could hide the chrome and widgets and cruft that form part of modern
comment lists.
Actually, we need both. I would suggest cmnts or cmntgroup for
consistency.
I *like* the idea of this use case, but almost nobody uses the
CommentBlocker addon (870 users after 3 versions). So this use case
may be too narrow to support introducing core vocabulary.
--
Benjamin Hawkes-Lewis
Have a great day!
Shaun
