Re: [whatwg] IRC and WWW integration proposal
Gryllida gryll...@gmail.com schrieb am Fri, 1 Feb 2013 15:41:50 +1030:
[…]
It is rather common to have a channel for a website, not just one
page. There are some exceptions of sites which have subsites with a
channel for each. A {IRC, XMPP} channel is an official chat medium
aiming to serve as an official {support, development, contact}
means. For example, https://developer.mozilla.org/en/Themes
irc://irc.mozilla.org/themedev - discussion of theme development for
Mozilla platform http://www.ubuntu.com/* irc://irc.ubuntu.com/ -
official support channel for the distro the w3c network for
individual sections of website - channels for development
collaboration and meetings c
Those relations are not the same. The Mozilla example shows a
*discussion about* the collection described by by the referring
document, the Ubuntu example shows *support for* the software available
at the referring page. The W3C example is probably similar to the
Mozilla example, only that it would refer to discussions about
documents.
I think a protocol attribute might be redundant as it is a part of
the URL.
Indeed.
It may be worth noting that every part of the note I originally sent
is possible to look up and you can try finding proper way to phrase
things (I have no experience in writing documentation of this sort).
I do not understand.
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Re: [whatwg] use of article to markup comments
Bruce Lawson bru...@opera.com schrieb am Sat, 26 Jan 2013 13:30:18 -: In short, why should the spec suggest any specific method of marking up comments? As someone who is interested in semantics and tired of scraping content and applying scrappy heuristics: If it is clear that an article within an article represents a comments one can easily: * programmatically find article comments in HTML * write interoperable stylesheets for comments, using the selector “article article” * use HTML fragments in a document store for content management (I wrote a blog software with a git backend yesterday and plan to add this feature) Without having one interoperable way all that becomes a lot harder. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] metadata attribute for media
Ralph Giles gi...@mozilla.com schrieb am Tue, 11 Dec 2012 17:23:38 -0800: On 12-12-11 4:58 PM, Ian Hickson wrote: […] I don't think we should have an open-ended API without fixed names, because that is a recipe for an interoperability disaster. I agree it would have interoperability issues. My own implementation experience is that the easy thing to do is to mirror whatever representation your playback framework offers, which can result in per-platform differences as well as per-media-format (and per tagging application, etc.). Just doing “the easiest thing” when you are a content-emitter (e.g. a software developer just mirroring what the platform provides) does make it easier for the sender while making it harder for the receiver – it creates “computational dark energy” that has to be consumed somehow at the receiving side, as someone has to map all of these platform-specific conventions onto common semantics. I rather not have a world in which one needs even more JavaScript blobs just to provide basic functionality cross-browser. That said, I'm not convinced this is an issue given the primary use-case, which is pretty much that web content wants to do more sophisticated things with the metadata than the user-agent's standardized parsing allows. If one cares to that extent, and is already handling format differences, dealing with vendor variation on top isn't that much more effort. I disagree, strongly. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] scoped style sheets and @-rules
On Mon, Jan 21, 2013 at 8:39 AM, L. David Baron dba...@dbaron.org wrote:
But I think it's a large amount of extra implementation complexity
to honor @-rules whose purpose is to build global dictionaries (in
particular, @keyframes and @font-face), and I suspect the end result
of honoring them would yield technology that's more confusing for
authors. Anything that can be done by changing the meaning of an
@keyframes or @font-face rule within a subtree could also be done by
declaring a different animation rule or font-family within that
subtree. I suspect the extra clarity from the latter makes it a
better authoring practice anyway, so I don't think implementations
should be required to add support for a feature that it's better to
not use.
You could make the same argument against most of @scoped: you don't need to
define a scoped style for a class, just use a different class name.
It seems more likely that you'd want to use this for font-faces or
keyframes so that you can be sure the name won't collide. For example, a
templating system might output
div
style scoped
@font-face { font-family: font; src: url(font.ttf); }
/style
span style=font-family: font;content/span
/div
where the font URL is dynamically generated and the span is entered by the
user, who's been told that the font-family font will be defined to
something. The template doesn't need to worry about colliding with a
font-family by that name elsewhere (including other instances of the same
template or elsewhere in the document).
I don't know about implementation complexity (though I don't know why
creating a stack of font-face dictionaries would be any more complex than
creating a stack of style rules), but I don't think this is any more
complex for authors than the rest of @scoped.
--
Glenn Maynard
Re: [whatwg] IRC and WWW integration proposal
Usecase 1: This can already be covered by having the bot/engine look for an irc protocol link on the page. Usecase 2 part one: Operating systems already do this. They see an irc:// protocol and ask what to open it with or use their already assigned option. No need for a browser to take this over. Usecase 2 part two: Most browsers offer extension platforms, someone can easily create one to look for irc:// links and display something based on that. I personally am not seeing any major benefit by having the proposed additions added into spec(s). Just more work for developers both on browsers and websites if they chose to support this. -Garbee Usecase 1: I search for python and see a link to their website in search results, and the search engine looks up both title and IRC info - so I see webpage title, and a link to its irc network or channel. Usecase 2: Browsers implement some interface to display IRC channel link or window when user visits a page. Advantages: - The websites will benefit from this and will not have to manually embed qwebirc or Mibbit instances into their webpages anymore[1], leaving the IRC client preference to the user (choose from locally installed clients, or a client provided by the website). - User would not have to skim a page of text to locate and click an irc:// link manually, as such links would be a part of browser interface (an IRC icon like RSS feed icon?).
Re: [whatwg] Assigning media resources represented as DOM objects to a media element
On Sat, Feb 16, 2013 at 1:37 AM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Feb 15, 2013 at 2:43 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Feb 15, 2013 at 10:50 PM, Jonas Sicking jo...@sicking.cc wrote: Also, for what it's worth, I'm holding out hope that we can change createObjectURL to be autorevoking by default. That's what the latest drafts are saying and no implementation has objected, despite repeated pokings. Has any implementation actually taken the plunge? It's a fairly recent change to the spec, so no. I think we should give it a try in Firefox. Ugh, can't we take turns with other browsers or draw straws or something? Or study existing code using createObjectURL to get some data first? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
Re: [whatwg] Assigning media resources represented as DOM objects to a media element
On Sun, Feb 17, 2013 at 8:43 AM, Glenn Maynard gl...@zewt.org wrote: On Fri, Feb 15, 2013 at 2:10 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Even if you get past that, you still have the problem that revoked URLs are useless. It's impossible to do something equivalent to video2.src = video1.src (which works today). True, though cloneNode() should definitely work. On the other hand, .innerHTML works with blob URLs if the URL is still in scope, but would never work here (not something I use often, but I guess some people still do). cloneNode() won't work for autorevoked URLs, because it is defined to only clone attributes and children, not internal state (with a few exceptions for Web compatibility). (Don't tell me that it shouldn't work that way; I argued that long ago and lost :-).) innerHTML-based cloning would work in the same cases cloneNode() would: i.e. not at all for autorevoked URLs or srcObject. Also, getting access to the underlying source object is a valuable feature, especially for MediaStream and MediaSource objects which have interesting APIs on them. I don't know anything about those, but you can always stash a reference to an object on the img, even if img doesn't care about it. img.src = URL.createBlobURL(blob); img.xActualBlob = blob; It's not as nice as having them tied together, but it's not terrible. Yes, you can work around not having an API for this, if you control both the setting and the getting. It's still a workaround. I think the stakes are not that high here. Lack of srcObject can be worked around in most cases. On the other hand adding srcObject is not a big burden --- I don't think it needs to be added to every resource-loading element. It's useful for media elements, maybe img, and dubiously iframe (all of which already have multiple ways to specify the resource to load). Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
Re: [whatwg] IRC and WWW integration proposal
I'll actually follow up my last post with this. Is there any scenario where something can be done with these changes, or any one of them, that today isn't possible with the current specifications? I simply don't see one myself. If you could give a scenario, then could you possibly make an example page and write a polyfill that would show the use-case? It may help us better understand any other use-case that is currently not possible and show us what functionality to look at in order to create something for the (a?) spec that would work. On Sun, Feb 17, 2013 at 4:10 PM, Jonathan Garbee jonat...@garbee.me wrote: Usecase 1: This can already be covered by having the bot/engine look for an irc protocol link on the page. Usecase 2 part one: Operating systems already do this. They see an irc:// protocol and ask what to open it with or use their already assigned option. No need for a browser to take this over. Usecase 2 part two: Most browsers offer extension platforms, someone can easily create one to look for irc:// links and display something based on that. I personally am not seeing any major benefit by having the proposed additions added into spec(s). Just more work for developers both on browsers and websites if they chose to support this. -Garbee Usecase 1: I search for python and see a link to their website in search results, and the search engine looks up both title and IRC info - so I see webpage title, and a link to its irc network or channel. Usecase 2: Browsers implement some interface to display IRC channel link or window when user visits a page. Advantages: - The websites will benefit from this and will not have to manually embed qwebirc or Mibbit instances into their webpages anymore[1], leaving the IRC client preference to the user (choose from locally installed clients, or a client provided by the website). - User would not have to skim a page of text to locate and click an irc:// link manually, as such links would be a part of browser interface (an IRC icon like RSS feed icon?).
Re: [whatwg] use of article to markup comments
On Mon, Feb 18, 2013 at 12:19 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Bruce Lawson bru...@opera.com schrieb am Sat, 26 Jan 2013 13:30:18 -: In short, why should the spec suggest any specific method of marking up comments? As someone who is interested in semantics and tired of scraping content and applying scrappy heuristics: If it is clear that an article within an article represents a comments one can easily: article in article could be a comment. Or it could be something else entirely. Your heuristic may work in many cases, but certainly not in all. If we really wanted to be sure where to find the semantic concept of a comment, we should introduce a meaningful element for it such as comment. Silvia.
Re: [whatwg] A plea to Hixie to adopt main
Stewart Brodie stewart.bro...@antplc.com schrieb am Fri, 14 Dec 2012 14:33:43 +: Steve Faulkner faulkner.st...@gmail.com wrote: Stewart wrote: It doesn't necessarily. I've come across pages that expect the head to be displayed too. e.g. tests at http://meyerweb.com/eric/css/tests/css3/like http://meyerweb.com/eric/css/tests/css3/show.php?p=caption-side Is this a common mark up pattern? I've not gone looking for any other real-world examples - that's the only one I've seen. However, I can't think of any reason why it shouldn't work, as it's just a block box like the body element (usually) is. I have some rules in my user stylesheet for this – among these one that displays the hyperlink with a small orange feed icon for elements matching „link[rel=alternate][title][type='application/rss+xml']“. I use conkeror (a web browser modeled after Emacs – scripting buffers ful of HTML using JavaScript), the configuration can be found here: https://raw.github.com/erlehmann/dotfiles/27cf8d18faad4d8deeb47ebaadcf91ce26357aa6/.conkerorrc When I tried to actually use this for a web page I found that while Gecko (from conkeror) generates Hyperlinks for link elements, WebKit (at least that from Chromium Version 22.0.1229.94) does not. Therefore, I decided against using this styling pattern for my blog sofware. I suggest people test for themselves, as I suspect I may have done something wrong with my user stylesheets in Chromium – it seems counter-intuitive that a link Element does not create a hyperlink: data:text/html;charset=utf-8;base64,PCFET0NUWVBFIEhUTUw%2BPHRpdGxlPkxpbmsgRWxlbWVudCBTdHlsaW5nIFRlc3Q8L3RpdGxlPjxzdHlsZT5oZWFkLGxpbmt7ZGlzcGxheTpibG9ja31saW5rW3RpdGxlXVt0eXBlPSdhcHBsaWNhdGlvbi9yc3MreG1sJ106OmJlZm9yZXtjb250ZW50OidMaW5rOiAnIGF0dHIodGl0bGUpfTwvc3R5bGU%2BPGxpbmsgcmVsPSJhbHRlcm5hdGUiIHRpdGxlPSJGZWVkIiB0eXBlPSJhcHBsaWNhdGlvbi9yc3MreG1sIiBocmVmPSJodHRwOi8vZXhhbXBsZS5vcmcvZmVlZCI%2BYm9keQ0K -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
