Re: [whatwg] Knuth and Plass algorithm; boxes glue penalties
David Young wrote: I'm wondering if anyone is developing web standards and prototypes for web layout using the Knuth and Plass algorithm? It seems like responsive designs could be expressed more simply in a boxes-glue-penalties frame, and responsive layout for JavaScript, CSS, and other things that you put in pre, now, would be tractable with the right HTML/CSS primitives. If you have something like this underway, please get in touch. Prince implements the Knuth/Plass algorithm for breaking paragraphs into lines: http://www.princexml.com/howcome/2010/magic/prince7.pdf For line-breaking, I believe implemtors are looking beyond Knuth/Plass to optimize on a per-page/per-spread, or even per-document basis. Knuth/Plass only looks at a paragraph. However, it seems you're not primarily thinking of line-breaking, but box stacking on a more general basis? -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Use of media queries to limit bandwidth/data transfer
Also sprach Anne van Kesteren: It's not clear that device-width and device-height should be encouraged since they don't tell you anything about how much content area is *actually* visible to the user. Knowing the device width/height could potentially be be used to decide if users should be encouraged to go into fullscreen mode. It's a slim use case, though. Why do media queries support querying the device dimensions? Shouldn't those be changed to be aliases for width and height? Media Queries were thought to be too far along the Recommendation track to be fixed. color/color-index/monochrome/scan/grid are also somewhat dubious in this day and age. There are enough e-ink devices out there for color/monochrome to still make sense. The others could probably be deprecated without missing much. -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] H.264-in-video vs plugin APIs
Also sprach Chris DiBona: I don't think the bandwidth delta is very much with recent (and format-compatible) improvements to the Theora encoders, if it's even in H.264's favour any more, but I'd rather get data than share suppositions. Can you send me a link to raw video for the clip at http://www.youtube.com/demo/google_main.mp4?2 so I can get it converted with the state of the art encoder and we can compare numbers? I'll see if I can get the numbers/video for you on that (and I'll do it off list, for th sake of the whatwg mailing list :-) It's great if you can find information on this. I believe many people on this list would be interested, so I suggest you send it to the list. Cheers, -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Chris DiBona writes: this issue is actually not about submarined patents (more like aircraft carrier patents) or tricky corner cases for the lgpl., but that the internet users prefer more quality in their codecs/megabyte/second. I'm not so sure. YouTube is very popular despite the fact that its video clips resemble the transmission from the moon landing in 1969. And JPEG2000 achieves better pictures/megabyte than JPEG, but internet users are not calling for it. Saving a megabyte here and there is less important than having a video format that is free and open for all to use. Dailymotion.com has understood this and their recent offerings using video and Ogg Theora is laudable [1]. This was exactly what I've been hoping for, and arguing for, since the video element was proposed [2][3]. [1] http://blog.dailymotion.com/2009/05/27/watch-videowithout-flash/ [2] http://people.opera.com/howcome/2007/video/ [3] http://video.google.com/videoplay?docid=5545573096553082541 At Google, you have a unique opportunity to be part of this. You have the video clips, the disks, the processing power, and the talent to launch a service that will firmly establish video and Ogg Theora as the video solution for the web. However, it seems that Google doesn't care much for having a free and open video format. Most of the bits you put out on the web are in patent-encumbered formats, and this doesn't seem to bother you. Rather, you promote patent-encumbered formats in your new experimental service [4]. [4] http://www.youtube.com/html5 The web is based on free and open formats. Google would not have existed without the web. It will be a terrible tragedy if you tip the scales in favor of patent-encumbered formats on the web. We expect higher standards from you. -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Also sprach Daniel Berlin: However, let me ask *you* a question. Why do you rely on the example instead of the actual clause from that part of the conditions? You realize the example has roughly no legal effect, right? It does not add or modify the terms and conditions of the license. I'm a spec guy, not a lawyer. When we write specs, we typically insert specific examples that help clarify the more general conditions in the text. Often, an example will describe a common scenario and state, in simple terms, the outcome. To me, it seems that the LGPL is written the same way. The first two sentences of #11 are general conditions. The third sentence contains a specific example to help clarify what the more general conditions say. Current specs typically state that the examples are non-normative, while the general statements are normative. I do not know if the same rules apply to legal licenses -- LGPL itself doesn't say. As to your question: I'm not really relying on anything. I've merely said that I don't understand your interpretation of #11. You guys would probably be less confused if you actually stuck to the terms of the license instead of trying to parse the examples :) The example in #11 seems fairly clear. Do you see any incompatibilities between the example text and the general clauses? Cheers, -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Also sprach Daniel Berlin: For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. Note that the actual *clause* (not the example) in question says If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. It then gives the patent example as an example of when you could not fulfill your obligations under the license. The restrictive license in the example falls afoul of this condition (part of #10): You may not impose any further restrictions on the recipients' exercise of the rights granted herein. Nothing in any licenses we have with other parties imposes any *further restrictions* on the recipients who get ffmpeg from us. You get *exactly* the same set of rights and obligations we got from ffmpeg. As such, we can simultaneously satisfy our obligations under this license (which again does not require us to pass along patent rights we may have obtained elsewhere, it only requires we grant you the rights you find in terms 0-16 and place no further restrictions on you) and any patent licenses we may have, and do not run afoul of this clause. I get parsing errors in my brain when reading this. While I understand that you do not impose any new restrictions (as per #10), I still don't understand how you can claim that #11 (the first two quotes above) has no relevance in your case. To me, it seems that the example in #11 (the first quote) matches this case exactly -- assuming that Google has a patent license that does not permit royalty-free redistribution. I also understand that the LGPL doesn't explicitly require [anyone] to pass along patent rights we may have obtained elsewhere. However, it seems quite clear that the intention of #11 is to say that you cannot redistribute the code unless you do exactly that. What am I missing? -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Also sprach Daniel Berlin: I get parsing errors in my brain when reading this. While I understand that you do not impose any new restrictions (as per #10), I still don't understand how you can claim that #11 (the first two quotes above) has no relevance in your case. To me, it seems that the example in #11 (the first quote) matches this case exactly -- assuming that Google has a patent license that does not permit royalty-free redistribution. As i've said in other messages, this example doesn't match this case at all, since the patent license was not given to us by the same people who gave us the library The example doesn't mention this as a requirement. *and* our patent license doesn't even say anything about the library used to do encoding/decoding. The example doesn't mention this as a requirement, either. The example only has one if statement: For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. This if statement seems to be true, and I therefore still don't understand your reasoning. I do appreciate your willingness not discuss these matters, though. Cheers, -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Also sprach Chris DiBona: To be clear, there are two situations here: Situation 1: (a) Party A gives Party B a library licensed under the LGPL 2.1 along with a patent license which says only Party B has the right to use it (b) Party B wants to distribute the library to others That's the situation the example in the LGPL 2.1 text is talking about and would likely be a violation. Situation 2: (a) Party A gives Party B a library licensed under the LGPL 2.1 (b) Party B gets a patent license from Party C (c) Party B then distribute the library under the LGPL 2.1 This situation is *not* prohibited by the LGPL 2.1 (see the LGPL 3.0 for a license that does deal with this situation). Under the LGPL 2.1, the fact that Party B may have a patent license with an unrelated third-party is irrelevant as long as it doesn't prevent Party B from granting people the rights LGPL 2.1 requires they grant them (namely, only those rights it in fact received from Party A). Thanks for your willingness to discuss these matters. So, to be clear, you're saying that situation 2 applies in your case? -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Trying to work out the problems solved by RDFa
Also sprach Dan Brickley: My main problem with the natural language processing option is that it feels too close to waiting for Artificial Intelligence. I'd rather add 6 attributes to HTML and get on with life. :-) Personally, I think the 'class' attribute may still be a more compelling option in a less-is-more way. It already exists and can easily be used for styling purposes. Styling is bait for authors to disclose semantics. Cheers, -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
Re: [whatwg] Footnotes
Also sprach Douglas Mayle: As an aside tongue in cheek/ I noticed the new aside element. Isn't aside more of a presentational decision? What's the difference between sidenotes and footnotes other than styling? Would we be better off combining both use cases into a single element with an attribute to provide display hinting? You can describe the presentation of various types of notes in CSS: http://dev.w3.org/csswg/css3-gcpm/#footnotes Indeed, the element itself should't say anything about foot or side or end -- that's a presentational issue. Cheers, -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
[whatwg] a and button
I'd like to have a simple way of using button along with a to create pretty links. This markup works in Opera, Mozilla, and Webkit: a href=http://www.w3.org/;buttonW3C/button/a but it's not valid HTML5 it seems. I propose to make it valid. The inverse (a inside button) only works in Webkit. Cheers, -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] a and button
Also sprach Philipp Serafin: a href=http://www.w3.org/;buttonW3C/button/a What's wrong with button style=text-decoration: underline; color:blueW3C/button It's not a link. I'd like for buttons to work as links so that they take me to a page when I click on them. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] a and button
Also sprach Kornel Lesinski:
It's not a link. I'd like for buttons to work as links so that they
take me to a page when I click on them.
http://www.w3.org/TR/css3-ui/#appearance
a {appearance: button} should do that.
Yes, that's a good proposal. However, it doesn't work in current browsers.
This markup works (in Mozilla, Opera, Webkit), and it looks pretty good:
a href=http://www.w3.org/;buttonW3C/button/a
So, I think HTML5 should describe it.
In current browsers:
form method=get action=url style=display:inlinebutton/form
is very close to a link.
Yes, this works:
form action=http://www.w3.org; style=display:inlinebutton
type=submitW3C/buttonform
But, the markup isn't pretty. Also, I'd like for links to use the a
element.
-hkon
Håkon Wium Lie CTO °þe®ª
[EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] The truth about Nokias claims
Also sprach Maciej Stachowiak: 1) Apple representatives have stated that we are ok with the SHOULD clause remaining. Thanks for clarifying this. Does this mean there is only one member who can't live with the SHOULD? If this is the case, I think the chairs should declare rough consensus and put the wording back in. That will restore faith in HTML5 for many. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Video codec requirements changed
Ian Hickson wrote: I've temporarily removed the requirements on video codecs from the HTML5 spec, since the current text isn't helping us come to a useful interoperable conclusion. I don't think this solves any problem, neither in the short term or the long term. I suggest that the should text is put back in. When a codec is found that is mutually acceptable to all major parties I will update the spec to require that instead and then reply to all the pending feedback on video codecs. Sure, when that happens the text can be revised. But not before. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
[whatwg] minor style issue
I suggest we add this line to the style of our specifications so that
long lines break when necessary:
pre { white-space: pre-wrap }
To see and example of where it makes a differnece, search for The
drag-and-drop processing model in the HTML 5 draft.
Cheers,
-hkon
Håkon Wium Lie CTO °þe®ª
[EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] on codecs in a 'video' tag.
Also sprach Dave Singer: I really think that this conversation has morphed from 'should HTML recommend or mandate codecs' into mostly 'why apple should support ogg/theora'. Even the first question is a pretty tangential one to the design of the tag itself, the CSS, and so on. Surely people have comments or questions on other aspects of our proposal? There is new stuff, new ideas, and open areas, all ripe for discussionwe have engineers standing by, eager to refine and improve the video tag design itself... It's tempting to ask standby crew to spend their idle time adding support for ogg/theora, but I would probably find myself at the receiving end of another 'bad faith' message, so I will not even mention it :-) Seriously, though, I think this group is concerned that having a polished video interface isn't worth much in terms of interoperability unless there is a baseline format. It seems that Mozilla and Opera can be convinced to support a common baseline format (I'm not speaking for either in this message), and that they really would like you guys to join in the quest for a better web. Not just a better video element. Cheers, -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Also sprach Bjoern Hoehrmann: the SVG 1.2 WD requires support for Ogg Vorbis: http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html And as Håkon Wium Lie pointed out in another email, the latest SVG standard already mandates Vorbis support, so half of what is needed is already specified in another major web standard. .. the latter would be more accurately characterized as, in 2004 there was a pro- posal to mandate Vorbis support in a possible future SVG 1.2 Full Recommendation. From 2004 and onwards there has been rough consensus among the 45 or so authors of SVG 1.2 that SVG user agents are required to support the Ogg Vorbis audio format. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)
Robert O'Callahan / Maciej Stachowiak wrote: - Placing requirements on format support would be unprecedented for HTML specifications, which generally leave this up to the UA, with de facto baseline support being decided by the market. It's not unprecedented in W3C; the SVG 1.2 WD requires support for Ogg Vorbis: http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html I think having a single baseline codec will make video immensely more attractive to authors than it otherwise would be. I also believe from the point of view of Mozilla (or any other open source project) Theora is vastly more attractive than MPEG. If we don't ship MPEG and other vendors don't ship Theora, then the video element will be hobbled from the start. Yes, a baseline format seems good for everyone -- users, authors, open source and closed source browsers -- except for vendors pushing a proprietary media platform. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element feedback
Also sprach Laurens Holst: object is *very badly* implemented. It has been a decade since object was first created and browsers STILL don't do it right in all cases (or even in most cases, frankly). Adding more complexity to such a disaster zone is bad design. If the existing problems with object are so severe that it can
Re: [whatwg] Video proposals
Also sprach Robert Brodrecht: Quality, size, etc. have all been goals of the Theora project, so it's not really fair to say that they haven't been considered. There is no technical reason why Theora shouldn't be specified as a baseline format. I think you took that out of context. I wasn't making a judgement about Theora. I'm sure it will get the job done as a baseline codec. I was simply saying that the WHAT WG mailing list discussion went something like: We ought to use an open codec! and someone said, Theora is open! It wasn't quite like that. Opera's experimental build, which was demoed the day the proposal went to the WHAT WG, had support for the video element and a native Theora decoder. Some conscious thinking went into picking Theora in the first place. http://my.opera.com/saito/blog/show.dml/787937 http://coolastory.blogspot.com/2007/03/sv-web-builders-event-world-premier-of.html http://www.youtube.com/watch?v=hUqC1URVytk http://www.youtube.com/watch?v=tKXomOLraXg http://www.flickr.com/photos/biao/406571288/ http://www.flickr.com/photos/mimizone/406561638/ -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element feedback
Also sprach Martin Atkins: If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Right. I think I agree with you. Perhaps we can encourage implementors to add a simplistic UI in case none has been specified? On the right-click menu or somewhere where it doesn't take up space? -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Video proposals
Also sprach Robert Brodrecht: I don't see how you're going to avoid that with video unless you intend to make it a non-pluggable system, which does not seem like a good idea. I think that was the idea. I don't need plugins for certain media files, e.g., GIF, JPEG, and PNG (and maybe WAV, MP3, and MIDI using bgsound in IE if that is still around). If a certain set of cross-platform video codecs could be supported, there would be no need for a plugin. Exactly. What WHATWG has been shooting for, is one common codec. At this point, WHATWG folks want Theora. Yes, it's a likable format. If anyone has better ideas, this is the time to step forward. Apparently, that may still have some licensing issues. Some unnamed vendor has said it's unlikely they will ship a Theora decoder, for whatever reason. Hopefully they will reconsider when Wikipedia starts using it for real. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Video proposals
Also sprach Robert Brodrecht: As I said before, I think we have a lot better chance at getting a common, cross-browser, cross-platform format with MPEG 4. The reason WHAT WG proposed Theora is *because* it is FOSS, not for quality, size, ease of implementation, or anything else (as far as I know). Due to software patents, MPEG 4 costs money. Also, it requires more processing power than many devices have. Who will pay for licenses to OLPC's machines? And, how will the get the power to decode? I think it's vital that we find an open format that the free world can use. If MPEG4 is the alternative, we might as well continue using Flash and object. But it's not a world I want to live in. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Video proposals
Also sprach Benjamin Hawkes-Lewis: Sure. What happens if you're taking old videos of a page because you moved them to a site like YouTube? How would you tell them apart from other content in the page that might require object, like SVG graphics and such? With HEAD requests? A personal spidering tool like wget could pull down all linked videos based on content-type as specified by the server. On a mobile phone, it's expensive and slow to perform HEAD requests. Running personal spiders is out of the question. We should keep in mind that the specs we designs must be usable in many types of enviroments. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Video proposals
Also sprach Geoffrey Sneddon: Yes. If a vendor, for some reason, is unable to support the Ogg codecs, I think it's better that they (a) do not support video, than (b) they support video with proprietary codecs only. Interoperability has more value than conformace. I think forcing browsers to support a codec when it is outdated is wrong. In this context, I think the spec and the codec will be outdated roughly at the same time. Likewise, I think HTML/GIF/JPEG/PNG will all reach, roughly the same age. I have a long-standing bet that computers we buy 40 years from now (the bet was entered into ten years ago) will be able to read web pages from 1997. I think it's time to add video and audio codecs to this select list. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element proposal
Also sprach Maik Merten: I can't comment on how Theora compares to VP6, but I'm pretty sure Theora outperforms H.263 which is said to be used at Google Video or YouTube for compatibility reasons. Thank you for an informative message on video decoders. In the context of codecs, the term performance is most often used to describe compression ratios (at given levels of quality). There is another factor related to performace which is also relevant when picking the best codec for the web: how much processing power does a given format need? I believe, in general, that the higher performace a codec has, the more processing power it requires. As a result, it may be impossible to decode a high-performance video format on some devices. Therefore, on the web, a high-performance format may not be suitable as it excludes devices with limited processing power. On the other hand, these devices may also have limited connectivity so compression is called for. It would be interesting to see a comparison of video quality vs. processing requirements. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Video proposals
Also sprach Laurens Holst: http://www.whatwg.org/specs/web-apps/current-work/#video Correct me if I
Re: [whatwg] Video proposals
Also sprach Ian Hickson: ON THE CODEC ... Given this, I would suggest Ogg Theora be the natively supported video format common to all browsers. It's designed from the beginning to be unencumbed. And implementations for it already exist under licenses that should make everyone happy. A number of other people said similar things about Ogg Theora. For now, the spec says that UAs SHOULD support Theora for video and Vorbis for audio, and SHOULD support the Ogg container format (it's not a MUST because some vendors may have legal reasons why they can't or won't support it, and there's no point making them non-conforming when they have no choice in the matter). I'd rather make video and audio optional so that those who cannot support these Ogg on these elements (for whatever reason) can still comply with the spec. They can also support proprietary codecs through object. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Video proposals
Also sprach Robert Brodrecht: I'd rather make video and audio optional so that those who cannot support these Ogg on these elements (for whatever reason) can still comply with the spec. They can also support proprietary codecs through object. Do you mean make the elements themselves optional to support? Yes. If a vendor, for some reason, is unable to support the Ogg codecs, I think it's better that they (a) do not support video, than (b) they support video with proprietary codecs only. Interoperability has more value than conformace. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element proposal
Also sprach Bjoern Hoehrmann: ++-+-+---+ | SMIL | SVG | IE | WHATWG | ++-+-+---+ beginElement() | beginElement() | beginElement() | play() endElement() | endElement()| endElement()| stop() - | pauseElement() | pauseElement() | pause() - | resumeElement() | resumeElement() | togglePause() - | isPaused| isPaused| state == PAUSED ... I personallay think play, stop and pause are better names. So, sure, don't pick the not-invented-here APIs We didn't really invent play, stop, pause. These words are printed on at least fire remote controls within easy reach of me at the moment. Do you really think using beginElement would be better? The next is compatibility. I want my content to work in as many cases as possible. It goes without saying that WHATWG video works nowhere. I think Any solution that cannot be used with the current high-market- share user agent without the need for binary plug-ins is highly unlikely to be successful. This is an issue. I don't know if will be possible to extend IEx to support video/OggTheora without Microsoft's consent. IEx has proven to be amazingly extensible in the past. We'll see. Even if it turns out to be impossible to use open codecs in IEx, people should still be encouraged to use open codecs. It is hard to find tools that take care of transcoding, they are difficult to use (lack of advise on which settings to use, crude command line interfaces, ...) and using Ogg Theora generally meant considerably reducing the quality while at the same time considerably increasing file size Compared to which formats? I believe Ogg Theora performs better than Flash. Given the video quality of some of the superhits on YouTube, I doubt this is the most important factor, though. So, where does that leave me? Ah, yes, Page xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation; MediaElement Source=example.video / /Page which, too, has the benefit of actually working in my web browser. It also happens to be much simpler than the equivalent HTML5 document. It doesn't work in my browser. What does the code do? -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] audio vs. video
Also sprach Elliotte Harold: If we add a video element, should we for the same reasons add an audio element? Yes. It seems to me these two cases are similar enough to justify similar treatment. Is there any distinction between the two that would suggest audio is inappropriate while video is appropriate or vice versa? I don't think so. Both deserve to be first-class citizens on the web and they are, therefore, entitled to their own element. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element proposal
Also sprach Bjoern Hoehrmann: Opera has some internal expiremental builds with an implementation of a video element. The element exposes a simple API (for the moment) much like the Audio() object: play() pause() stop() May I suggest Opera does not implement features that are incompatible with SMIL, the SMIL implementation in Internet Explorer, and SVG for no extraordinarily good reason? I think we want to make video a first class citizen of the web. That means, IMHO, that there must be a simple way to add video to HTML pages. I don't think one shoulr rely on other languages for this, although I'm perfectly happy supporting those other languages as well. Part of the reason why we could to this so quickly is the work we have done on SVG. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] video element proposal
Also sprach Shadow2531: I think it'd be cool if the video element *just* supported theora. It's an interesting proposal. Traditionally, HTML/CSS hasn't said anything about which image/icon formats to support. Given, however, that (a) our ultimate goal is interoperability and that (b) many video formats are impossible to support on all devices (mostly due to legal issue), I think we should consider your proposal. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Hyphenation
Also sprach Øistein E. Andersen: (By the way, the term `dictionary' used to designate a set of hyphenation patterns that are not, in general, words, is quite confusing.) The term hypenation dictionary is quite common, but I see your point. What would be a better name for the property? hyphenation-pattern hypenation-list hypenation-resource or, perhaps: hyphenationshy;pattern :-) [In TeX], hyphenation can [also] be indicated locally. This is needed in order to hyphenate words like rec-ord/re-cord and is the only level that deals with spelling changes. This can be done by supplying your own dictionary through the 'hyphenate-dictionary' property. You seem to have misinterpreted the intended meaning of `locally'. The two problems are as follows: 1) Given the following sentence: `Don't wait for record companies, record records yourselves.' In order to hyphenate this correctly, explicit hyphenation points (\- in TeX) must be inserted locally, i.e., as part of the words, as follows: `Don't wait for rec\-ord companies, re\-cord rec\-ords yourselves.' shy; is probably the best way to encode this. However, it can be done through CSS as well: Dont's wait for span style=hypenation-dictionary: rec-ord.dicrecord/span companies, span style=hypenation-dictionary: re-cord.dicrecord/span yourself. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Hyphenation
Also sprach Sander Tekelenburg: FWIW, my feeling is that it would be best if there'd be a defined format for hyphenation rules, and browsers would accept such description files as a plug-in. This would allow each language's specialist to write their rules, and share them, without putting that burden on browser authors. (Browsers could of course still be shipped with such rulesets.) This format exists. It was pioneered by TeX and is now widely used by other applications. Here is the OpenOffice repository: http://wiki.services.openoffice.org/wiki/Dictionaries You can plug these into Prince as per: http://www.princexml.com/howcome/2006/p6/p6demo2.html I agree that browsers should read these dictionaries. However, the dictionaries don't have to ship with browsers -- they can be web resources just like style sheets and images are. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Hyphenation
Also sprach Alexey Feldgendler: I would suggest that the first priority is getting a naive hyphenator into browsers. Since you only ever need hyphenation when full-justifying, I would suggest: align: hyphenated; In some typographical traditions, non-full-justified text is sometimes hyphenated. I believe that hyphenation should be a separate property, orthogonal to text-align. Also, there are some common hyphenation options (like the maximum number of consequtive hyphenated lines allowed) that are also worth CSS properties. Prince6 (www.princexml.com) supports these properties: hyphenate: none | auto hyphenate-dictionary: none | url(...) hyphenate-before: int hyphenate-after: int hyphenate-lines: none | int (with a prince- prefix) You can see the properties in use here: http://www.princexml.com/howcome/2006/p6/p6demo2.html Currently, Prince will only hypenate paragraphs with 'text-align: justify'. I agree that hypenation is useful in other cases as well. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
Also sprach James Graham: To take a slight detour into the (hopefully not too) abstract, what do people think the fundamental point of semantics in HTML is? To keep HTML high enough on the ladder of abstraction [1] to remain a media-independent markup language. [1] http://people.opera.com/howcome/2006/phd/#h-37 -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Footnotes, endnotes, sidenotes
Also sprach David Walbert:
On Oct 31, 2006, at 9:30 AM, James Graham wrote:
I think and distinction between footnotes, sidenotes and endnotes
is basically presentational and whilst we should try to ensure that
markup+CSS can create all three appearances we shouldn't treat them
distinctly.
Footnotes and endnotes are identical in content in the context of a
print document and I am not certain how they'd differ even
presentationally on a web page, so yes, I think those can be
considered identical in terms of markup.
I agree. W3C recently published a proposal on how to achieve
footnote/endnote presentations using the same markup [1]. The proposal
is quite simple. Given this markup:
div class=note../div
you would achieve footnoes with:
.note { position: footnote }
ane endnotes with:
.note { position: endnote }
Comments welcome.
Sidenotes, though, is ambiguous. If the term refers to footnotes
that happen to be placed beside the text, then yes, they're identical
semantically to footnotes. But sidenotes may also refer to pull
quotes or callouts -- some small piece of text to be highlighted
rather than additional explanatory information of the sort that would
appear in a sidebar or footnote.
Bert and I used sidenotes extensively in our CSS book [3]. The book
was written in HTML and we used negative margins to achieve the
effects we wanted. Here's some sample code [4], as well as an article
describing the efforts [5].
[1] http://www.w3.org/TR/2006/WD-css3-gcpm-20060919/#footnotes
[3] http://www.awprofessional.com/bookstore/product.asp?isbn=0321193121rl=1
[4] http://people.opera.com/howcome/2005/ala/sample.html
[5] http://www.alistapart.com/articles/boom
Cheers,
-hkon
Håkon Wium Lie CTO °þe®ª
[EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] How not to fix HTML
Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/ This is a classic problem in HTML development: The people doing the work are geeks with computer-science interests who do not understand, for example, newspapers, or screenplays, or, really, print publishing in general. In some obscure way, they disdain print publishing, as the Web is not print. Indeed it isn't, but print has structures the Web doesn't, and it doesn't have them because people like these refuse to acknowledge they exist or simply refuse to consider them. In the development of CSS, I actually think we erred on the side of traditional print-based documents rather than paying attention to computer science problems. For example, the existence of :first-line (which is a classic print-oriented feature) complicated the otherwise simple CSS1. CSS ignored, on the other hand, the interaction with programming languages (JavaScript) for too long. I think the CSS DOM would have been simpler if addressed in CSS2. Speaking for myself, I'm a print guy at heart. I publish newspapers [1], screenplays [2], novels [3] and specifications for print publishing in general [4][5]. All by way of HTML and CSS. [1] http://www.princexml.com/samples/ [2] http://people.opera.com/howcome/2006/ibsen [3] http://www.princexml.com/howcome/2006/slogans/slogans.pdf [4] http://www.w3.org/TR/css3-gcpm [5] http://www.w3.org/TR/css3-multicol -hkon Håkon Wium Lie [EMAIL PROTECTED] http://people.opera.com/howcome [EMAIL PROTECTED] http://www.princexml.com/howcome
Re: [whatwg] css3-fonts: New values for generic font families
Also sprach Nicholas Shanks: I wish to submit two proposals for changes to the generic font families built into CSS. If someone could please forward these to whomever is currently working on the css3-fonts module, I would be much obliged. Why not just follow the guidelines in the CSS3 font module?: Comments can be sent directly to the editor, but the archived mailing list [EMAIL PROTECTED] (see instructions) is also open and is preferred for discussion of this and other drafts in the Style area. 1) That monospace and it's new inverse proportional be 2) The addition of two new generic family classes for the Latin script, namely: blackletter (including fraktur, gotisch, schwabacher, rotunda, old english, c.) uncial (including insular, irish, c.) While I appreciate the convenience this new functionality may have for designers wanting to see text in (say) blackletter, the inconvenience for browser implementors will be disproportionately large. Where will they find these fonts? Will they have to ship fonts with browsers? The current number of generic font families (5) is already stretching it; one might argue that even fantasy and cursive should be dropped as many systems don't offer fonts in these categories. A better way to support interesting fonts is -- IMHO -- for browsers to start supporting TrueType Webfonts. http://news.com.com/Microsofts+forgotten+monopoly/2010-1032_3-6085417.html Cheers, -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Canvas 2d methods
Also sprach Ian Hickson: Anyway, this is all a straw man -- this isn't the reason that the spec doesn't allow this. It doesn't allow this because Safari didn't do it this way in the first place, and changing it would likely introduce bugs (while still not helping authors for some time anyway). It's still early in the life of the canvas element, and we still have the luxury of listening to good proposals. We can deal with the minor problems that arise, and authors down the road will have a more intuitive syntax. I like the proposal. Cheers, -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Mathematics on HTML5
Also sprach Martin Atkins: I would say MathML is not widely used because MathML doesn't work in HTML, personally. If we made MathML work in HTML, possibly with rules that make the syntax easier (by implying tags as I suggested earlier), then that might well change, especially given that one UA already has extensive and high-quality support for MathML. It seems to me that a good path would be to fix up CSS's shortcomings (which have been discussed at length in this thread) so that it is possible to specify math rendering with CSS. It takes years and years to produce new presentational features, write test suites and make them work interoperably. At this stage, any effort that relies on new CSS properties is a decade away from full deployment. By contrast, changing markup on the author side is very easy. So, I'd rather make the markup language CSS-friendly (and author-friendly) than the other way around. Historically, it's a common mistake to develop markup systems without giving much thought to presentation. For example, only when SGML was done did one start efforts to create a style sheet language for it (FOSI/DSSSL). Likewise with HTML. Given that CSS existed when MathML was created, I think the developers made a mistake by not creating a markup language that could be presented using existing CSS properties. Cheers, -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Mathematics in HTML5
Also sprach White Lynx: Making decision is up to WHAT WG, you can follow W3C line that so far brought nothing good to scientific web (which turned into bunch of PDF/PS/DJVU files) or (even without much afforts) you can solve longstanding problem of embedding mathematics in HTML. If WHAT WG will pay attention to interests of mathematical community, we are ready to do essential part of technical work needed to incorporate mathematical markup in HTML 5, like writing DTDs, default style sheets, documentation, test cases etc. I think you make a compelling case for adding math to HTML the simple way. Personally, I'm open to adding it to HTML5. How much would it add to the specification? -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Mathematics in HTML5
Also sprach James Graham: I think you make a compelling case for adding math to HTML the simple way. Personally, I'm open to adding it to HTML5. How much would it add to the specification? I remain sceptical about this. However, if there is a serious effort to replace MathML I believe the resulting language must fulfil the following requirements: The goal is not to replace MathML. At this point there isn't much to replace -- MathML isn't found in HTML in the wild. Aslo, at the spec level, I believe the two can co-exist just like WebForms and XForms can co-exist. I agree with your other points, though -- nice list. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Comment Syntax and Parsing
Also sprach Ian Hickson: This triggers SGML comment parsing mode (which you don't want to be testing) in a number of browsers. Why? The closer we can define the behaviour to be compatible with existing standards mode behaviours, the better it will be for backwards compatibility? This entire discussion started from the developers of all the browsers who implemented the SGML comment mode coming to me and telling me I was stupid for even suggesting that this is how comments should be parsed. The whole point of all this is to simplify comment parsing. Right. And since I run out of memory trying to parse a sentence with the word simple and SGML in it... Oops. Core dumped. -hkon
Re: [whatwg] Web Forms 2.0 submission to W3C
Also sprach Olav Junker Kjær: It is the first step to working with the W3C to move the development of the WHATWG specifications into the W3C fold, while keeping the open nature of the WHATWG development process. Thats cool, but isn't this going to delay the spec for years? No. We're in discussions with W3C about how to best organize the work. The traditional idea - workshop - working group - WD - CR - REC model may not be the best way forward. First, the specification is at a more advanced stage than most submissions, and lots of people have been reviewing it. Second, a healthy community (mostly consisting of this mailing list) has already been established. W3C staff understands these issues and have proposed some ideas for how to move forward that are being discussed. I'm optimistic. I actually agree with W3C that XForms is much more powerful and elegant that WF2, I just think that WF2 is interesting because it has a hope of being practically usable and used on the world wide web in the near future. Without this possibility, WF2 really hasn't much going for it compared to XForms. Or am I to pessimistic? I think you're too pessimistic. There is an immense value in having universally understood models on the web. HTML/CSS/JS/DOM are good examples. The models are not perfect (otherwise we wouldn't be here), but work quite well for an amazing number of use cases. Also, these specifications offer a gentle learning curve which should not be underestimated. Shifting to new models at this stage has enormous costs associated with it. The other point, which Ian has made repeatedly, is that a new model also will be tainted by the time it's implemented and deployed, Partial implementations, bugs, tag abuse -- all of this makes the world a sub-optimal place and there is no reason to believe the next model will be any better than what we're currently stuggling with. Finally, just by looking at the markup of the calculator example, I don't see WF2 being any less powerful or elegant: http://ln.hixie.ch/?start=1110316686count=1 Having said this, I belive WF2 and XForms can and will work together. XForms will find good use on the server side; the model can capture form semantics and do all sorts of data magic there. Clients will continue to be DOM-centric in the future. I also think we will see products that transform rich XForms into rich HTML forms. There are some nice opportunities in this space. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Web Forms 2.0 submission to W3C
Also sprach Anne van Kesteren: FYI, the W3C has just acknowledged receipt of the Web Forms 2.0 draft that Mozilla and Opera submitted (on behalf of the WHATWG). Any reason Apple didn't participate? We tried to submit WF2 in time to be announced at the W3C Plenary meeting in Boston in Feb/Mar. As a result, the submission had to be done quickly and my understanding is that Apple needed more time than we had to review the paperwork. In the end, W3C needed more time than expected to review the submission and we therefore had to keep quiet at the plenary. So, it might have been better to use the time necessary to add more W3C members to the list of sponsors. What really counts, though, is implementations. Really. We'll be publishing another call for comments that takes into account the technical comments that W3C staff sent to us privately as very soon. I saw a call for comments has already been published but not yet announced. Is that made so people can view the diff for the changes that are made not discussed through this mailing list? Is there any specific reason the W3C didn't want to make their comments public? We asked for the technical comments to be sent straight to the editor instead of being part of a formal W3C response. This way we could get them more quickly. I don't mind the comments going public (hey, all is public around here ;) but that's a decision W3C has to make. Also it seems the W3C has a lot of demands that could slow down the process. Will the call for implementations draft be even more postponed or is it still underway? As I said in my previous mail, W3C staff are well aware of the weight of the current W3C process. I'm optimistic, though, I think we will find ways for WHAT WG to work with W3C -- this is good news for both. Overall it seems like a good thing though. Indeed. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] Web Forms 2.0 submission to W3C
Also sprach Dean Jackson: Overall it seems like a good thing though. I think so. Like I said in the comment, the important point for us is to build a single community for improving forms on the Web. I agree with this; I think we have rough consensus in the web community within reach. That doesn't necessarily mean everyone will be sitting in the same room, though, nor that there will only be one specification. I think the CSS/XSL can be a good model. W3C accepted a Member submission [1][2] after a Recommendation had been issued [3] and the two groups have managed to stay inside the same organization. There has been some friction along the way, but the friction has generally been productive. [1] http://www.w3.org/Submission/1997/13/ [2] http://www.w3.org/Submission/1997/13/Comment.html [3] http://www.w3.org/TR/REC-CSS1-961217 -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
