Re: [whatwg] Expanding datetime
On Jul 30, 2008, at 23:29, Benjamin Hawkes-Lewis wrote: Wrong. Microformats may also be used to mark up events that happened in the past and people who are dead. For example: http://en.wikipedia.org/wiki/Walt_Disney What use case is served by marking up Walt Disney's birthday as bday? Surely people aren't supposed to export Walt Disney's contact information to their address book app and have it remind them to congratulate Walt on his birthday. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
[whatwg] scrollIntoView feedback
(The e-mails included in this reply were all cc'ed to whatwg, but some were also cc'ed to other mailing lists. To reduce cross-posting, I've only included [EMAIL PROTECTED] on this reply, since that was the only list that was included on all the e-mails. If you reply, feel free to respond on any mailing list, but please avoid cross-posting, and include me on the cc list if it's not the whatwg or public-html lists. Thanks!) On Wed, 30 Apr 2008, David Bolter wrote: I have a concern about 3.5.3 Scrolling elements into view: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-interaction.html#scrollintoview In addition to concerns expressed by Brad Fults (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012655.html), I want to raise a concern about the behaviour of scrollIntoView. Specifically I would ask that: 1. scrollIntoView not do anything in the case that the element is already fully visible (possibly in the middle of the viewport), or 2. ensureElementIsVisible to be added as described by Daniel Glazman (http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html) My concern is that with the movement towards rich interactive web interfaces, we are going to be seeing complex widgets that will need to call such functions fairly often, which may lead to a jarring experience if the function always butts the element to the edge of the viewport. It would be a shame to jar users when unnecessary. I realize there is a (hairy) way to do this but it would be nice to have the convenience. As the spec is currently written, user agents are allowed to experiment with different ways to scroll the content into view. I'll happily change the spec to be more in line with what browsers do, if they change. Aside: we would like to recommend authors call such a method when using ARIA's activedescendant (draft spec). Wouldn't that be more appropriate in the ARIA spec? On Wed, 30 Apr 2008, Peter Kasting wrote: I make no formal proposal, but the behavior I would typically want for some kind of a call (perhaps in addition to those above, I don't know) would be: - If the element in question cannot be scrolled so as to make more of it appear in the viewport, do nothing. (For when the element is completely visible, or is larger than the viewport and already taking up the whole viewport). - Otherwise, if the element is not larger than the viewport, scroll such that the element is centered* in the viewport (within the scrolling limits -- if the element is at the bottom of the page, it clearly can't be scrolled up to the middle of the viewport). - Otherwise, scroll the element such that the top of the element is aligned with the top of the viewport. *Perhaps centered is the wrong choice. Another suggestion would be to scroll to a point 1/3 of the way from the top or bottom of the viewport, nearer to whichever edge the element scrolled in from. Also, perhaps the UA's behavior should not be specified in this kind of detail? As far as I can tell, as defined, browsers would be allowed to do all this for scrollIntoView(). On Fri, 2 May 2008, David Bolter wrote: I'm not sure of the intended use cases of scrollIntoView, so for now I still agree with Brad Fults, that horizontal scrolling shouldn't be forgotten here. And if we want scollIntoView to butt the element to the edge no matter what, that's fine, but we shouldn't expect that to be received as the ideal/desired behavior by all. Couldn't we make it optional? It is effectively optional now. Horizontal scrolling is also required. On Wed, 30 Apr 2008, L. David Baron wrote: It seems like authors might actually want different options here for different uses. Aligning things with an edge of the viewport, or with the edge of some other scrollable container, might be useful in some cases, and just ensuring that it is visible might be useful in others. Mozilla has an internal function used to implement a number of different scrolling APIs (including scrolling to named anchors) that has a bunch of options: * scroll into view (no matter where) * scroll to align with a particular edge of the page * scroll only if it's not visible at all I think in many cases these scrolling APIs are about making things that authors can already do (using scrollTop, offsetTop, offsetHeight, offsetParent, and similar properties) easier to do. So I think the main questions to consider for these APIs are: * what capabilities do they provide that can't already be done? * what are the common uses of the existing features for scrolling things into view (perhaps adjusted by how hard it is to do the different possibilities)? (It's also worth thinking about how all of these deal with nested scrollable containers, and about how they deal with the interaction of vertical and horizontal scrolling. The
Re: [whatwg] Proposal for a link attribute to replace a href
Ian Hickson wrote: On Wed, 30 Jul 2008, Simon Pieters wrote: There are also alternative suggestions, like making a contain any element. Unfortunately, none of these end up working (e.g. for this proposal, ap/a would create an unexpected DOM -- we'd have to make /p end tags not optional when the next end tag was an /a, which would be somewhat confusing). The rules for optional end tags are already pretty confusing. I don't think it's a problem to require /p when the p element is the last child of an a element. Ok. Fair enough. I have allowed a elements to surround other (non-interactive) elements. On Wed, 30 Jul 2008, James Graham wrote: I think tableatr also causes problems; being able to link whole table rows seems like one of the major use cases for this proposal. Yes. I don't see how to fix that one. Given that I'm not sure making a transparent is wise. It seems like authors will try to use this feature, get tripped up by the table voodoo and become confused about why it doesn't work for what seems to be one of the most desirable use cases. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] scrollIntoView feedback
On Thu, Jul 31, 2008 at 2:31 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 30 Apr 2008, Peter Kasting wrote: - Otherwise, if the element is not larger than the viewport, scroll such that the element is centered* in the viewport (within the scrolling limits -- if the element is at the bottom of the page, it clearly can't be scrolled up to the middle of the viewport). As far as I can tell, as defined, browsers would be allowed to do all this for scrollIntoView(). I don't read the spec that way. The phrase with the bottom of the element aligned with the bottom of the viewport seems to rule out the possibility of other alignments such as suggested above. If you wish browser vendors to have the freedom to experiment here, perhaps a vague sentence such as the user agent should scroll the element as necessary such that as much of it as possible is visible in the viewport would suffice. My impression was that Firefox 3 changed scrollIntoView behavior precisely to comply with the detailed description currently in the spec. It is effectively optional now. Horizontal scrolling is also required. Now I'm wondering whether I'm looking at the wrong version of the spec, since I don't see any of that. http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#scrollintoviewstill seems to read a lot like I remember it... PK
[whatwg] video element now working in Firefox nightlies
The current version of Minefield (the pre-3.1 nightlies) has Ogg Vorbis and Ogg Theora support. You can try these out using Wikimedia Commons video: http://commons.wikimedia.org/wiki/Category:Video The current MediaWiki video code defaults to everything else first, but load the video then select More ... and you should see the option to try it out, report bugs, etc. Is the video tag doing Ogg Theora in Opera yet? I'm sure Apple and Nokia can join the party at their leisure. - d.
Re: [whatwg] Signatures in HTML5
Andres, Thanks for your long effort in this issue. I know there is many issues of more secure solution and specification for financial transactions. But, it has been processed most of bank transaction and cyber trading in web browser form. So new protocol and new specification is not good solution in actual problem. In real world, financial transactions are already the part of web especially HTML. HTML5 is born because of HTML's innovative usage. If HTML 5 solves actual problems with browser vendors, it can be done. New spec is very expensive for actual problem of many bank and e-government sites as well as browser vendors. Your job is also nessasary if bank or government want more secure solution rather than HTML form method. Channy On Thu, Jul 31, 2008 at 2:41 PM, Anders Rundgren [EMAIL PROTECTED]wrote: Hi Ian, I think this decision is OK because a useful signature facility should IMO not be limited to HTML. It is also more like an application than a set of language constructs, at least in my head. Anyway, FWIW, I intend to continue my Web Signature Crusade in a new forum called Information Card Foundation which is dealing with another highly browser-related security addition that there indeed is a great need for: Getting rid of the plague known as passwords. Actually there are other things that also needs to be done and that is the creation of a standard facility for provisioning cryptographic keys trough the use of a browser. Current schemes (including Mozilla's generateCRMFrequest and Microsoft's CertEnroll) are all over the map as well as lacking many vital features. Such an effort is also in an advanced state in case anyone on the distribution list is interested. Sincerely Anders Rundgren - Original Message - From: Ian Hickson [EMAIL PROTECTED] To: Anders Rundgren [EMAIL PROTECTED]; Michael(tm) Smith [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alexey Feldgendler [EMAIL PROTECTED] Cc: whatwg [EMAIL PROTECTED] Sent: Thursday, July 31, 2008 03:21 Subject: Signatures Over the years a number of e-mails have been sent to the list about signatures and other public key cryptography topics, most of which are quoted below. For a number of reasons, not least of which my lack of expertise in the area, the size of the HTML5 spec today, and the low level of demand for these features, I have decided to not cover this topic in HTML5, and instead rely on other groups to define these features. I include a representative sampling of the e-mails sent to the WHATWG on the topic below, so that if anyone wishes to work on this topic, they can use this feedback. I encourage people interested in this topic to approach the IETF, where work on these issues has historically taken place. On Sun, 29 Oct 2006, Anders Rundgren wrote: It is equally interesting that W3C intends to start a new browser authentication WG but have excluded digital signatures and key provisioning from the charter in spite of the fact that about 10M people today have to use proprietary browser-plugins in order to get their work done. Maybe an answer to that is that this is only happening in the EU which in this particular space is roughly 5 years ahead of the US government and financial industry. On Mon, 30 Oct 2006, Michael(tm) Smith wrote: The use of proprietary mechanisms (mostly ActiveX controls) for digital signatures is common in Korean sites as well, including Korean government sites. On Mon, 30 Oct 2006, Anders Rundgren wrote: That's right. They sure are proprietary; I was not even able to get the Korean e-goverment signature spec since it is secret! On Tue, 31 Oct 2006, Channy Yun wrote: Korean mechanism is same with general pki's. Its structure has been followed by pki standards and browser user-interface for certificates. The different things has own 128bit cryptography algorithm so called SEED and adds digital signature for messages to be legal authorizing. This spec is not secret and gives in http://www.rootca.or.kr/maine.jsp On Mon, 30 Oct 2006, Anders Rundgren wrote: I may have been careless but I could not find the spec of the activeX control (or similar) that is what I refer to as the proprietary solution. I may also have confused Korea with Hongkong who definitely claimed that their scheme requires an NDA. The same goes for the Australian scheme which is not public. BTW, the Swedish and Norwegian government's signature systems are also secret since they are developed by banks. On Wed, 1 Nov 2006, Channy Yun wrote: As you said, we may not get sufficient informations to standardize digital signature. But, in case of Korea, I'll sufficiently give them. The spec. and interface are almost standardized by governmental rules to all vendors. In Korea, the own cryptic algorithm has been encouraged, so vendors couldn't use browser-implemented things such as DES. This is first reason to use
Re: [whatwg] Signatures
Thanks for your follow up about long silence issue. In my understanding, the implementation guide of browsers is most important part of HTML5. As you know, web browsers have offered the authentication of client certificate over SSL per web site. It is widely used by many companies and universities based on VeriSign products or private CA such as MIT. It's more secure than traditional id and password system. It's surely part of user experience of web browser based on PKI technology. In addition, as following requirement has been widely used in European and Asian country with national PKI system for financial transactions. All of them are required of plugin based tool such as active x and java applet. Why do that? Because there is no function in browsers to handle them. The national PKI system has own certificate issuing process to citizen with face-to-face meeting. And it requires to submit ones client certificate for e-government and financial transaction with digital signature per each signature. submit ones client certificate is traditional SSL authentication and digital signature is new requirement. In fact, ActiveX and Java plugin are needed for digital signature. But, digital signature is not new one for web browsers. We already knew and experienced it by Netscape's crypto.signText() and Microsoft CAPICOM dll. If digital signature was required in old browser with cryto.signText, the browser prompted windows that get password of client certificate. After authentication, it returned encrypted message signed by client certificate. If we can submit returned encrypted message in form via SSL, the technical requirement is sufficient for all national PKI system. Especially, Camellia (Japanese and European official cryptographic algorithm) already implemented in Open SSL for web browsers. Most of them is ready. I just wanted to make implementation guide of digital signature in HTML5. If form has signed attribute, web browsers must prompt same window of crypto.signText action and encrypt form data with digital signature, and return it into signedmessage hidden value. If signed form is submitted to server via SSL, web server can decrypt form data signed by client certificate and check validation and insured transaction by each country's law. It's very simple process and actually these are now processed by many country. At last, there is no function and guideline of digital signature in web browser, they cannot help using ActiveX and Java plugin. I think HTML5 must be actual solution in actual problem like this. New standards such as IETF or W3C XSIG are not good solution for real problem right now. Please add sign attribute in form and guide to add digital signature function as like crypto.signText action in HTML 5. If others want to make spec. of more secure than browser based digital signature in HTML5, it can go to IETF or other body. Please reconsider that. Channy On Thu, Jul 31, 2008 at 7:19 PM, Channy Yun [EMAIL PROTECTED] wrote: Thanks for your follow up about long silence issue. In my understanding, the implementation guide of browsers is most important part of HTML5. As you know, web browsers have offered the authentication of client certificate over SSL per web site. It is widely used by many companies and universities based on VeriSign products or private CA such as MIT. It's more secure than traditional id and password system. It's surely part of user experience of web browser based on PKI technology. In addition, as following requirement has been widely used in European and Asian country with national PKI system for financial transactions. All of them are required of plugin based tool such as active x and java applet. Why do that? Because there is no function in browsers to handle them. The national PKI system has own certificate issuing process to citizen with face-to-face meeting. And it requires to submit ones client certificate for e-government and financial transaction with digital signature per each signature. submit ones client certificate is traditional SSL authentication and digital signature is new requirement. In fact, ActiveX and Java plugin are needed for digital signature. But, digital signature is not new one for web browsers. We already knew and experienced it by Netscape's crypto.signText() and Microsoft CAPICOM dll. If digital signature was required in old browser with cryto.signText, the browser prompted windows that get password of client certificate. After authentication, it returned encrypted message signed by client certificate. If we can submit returned encrypted message in form via SSL, the technical requirement is sufficient for all national PKI system. Especially, Camellia (Japanese and European official cryptographic algorithm) already implemented in Open SSL for web browsers. Most of them is ready. I just wanted to make implementation guide of digital signature in HTML5. If form has signed attribute, web browsers
Re: [whatwg] video element now working in Firefox nightlies
David Gerard schrieb: Is the video tag doing Ogg Theora in Opera yet? In experimental builds, yes. I'm sure Apple and Nokia can join the party at their leisure. I assume the latest move by Mozilla (which I think is great, obviously) won't do anything to address the IP concerns of mentioned players. Safari can play back Ogg content with XiphQT installed thanks to being based on QuickTime. A simple click to install 3rd-party components would basically ensure a reasonably reliable cross-browser media compatibility, but it would of course be Apple's decision to implement something like this. Maik
Re: [whatwg] video element now working in Firefox nightlies
2008/7/31 Maik Merten [EMAIL PROTECTED]: David Gerard schrieb: I'm sure Apple and Nokia can join the party at their leisure. I assume the latest move by Mozilla (which I think is great, obviously) won't do anything to address the IP concerns of mentioned players. The IP concerns are blatant FUD and it's ridiculous to describe them in any other terms. - d.
Re: [whatwg] Expanding datetime
Believe it or not, Yes! Consider the couple to be congratulated on their gazillionth anniversary. Is that diamond, gold, platinum? Whatever it is, if your date time system is limited to epoch 1970, you're out of luck. That's why I claim that restrictions (rigorously documented) are OK as long as they are not ludicrous - ludicrous being a gray area, rather than a sharp line - 1970 definitely is, 1900 is probably OK, 1582 is interesting and far less ludicrous, while - is very safe but maybe ludicrous in other ways (prolepsis, locales...). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henri Sivonen Sent: Thursday, 2008 July 31 04:26 To: Benjamin Hawkes-Lewis Cc: 'WHATWG List'; Ian Hickson Subject: Re: [whatwg] Expanding datetime On Jul 30, 2008, at 23:29, Benjamin Hawkes-Lewis wrote: Wrong. Microformats may also be used to mark up events that happened in the past and people who are dead. For example: http://en.wikipedia.org/wiki/Walt_Disney What use case is served by marking up Walt Disney's birthday as bday? Surely people aren't supposed to export Walt Disney's contact information to their address book app and have it remind them to congratulate Walt on his birthday. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] video element now working in Firefox nightlies
David Gerard schrieb: I'm sure Apple and Nokia can join the party at their leisure. I assume the latest move by Mozilla (which I think is great, obviously) won't do anything to address the IP concerns of mentioned players. The IP concerns are blatant FUD and it's ridiculous to describe them in any other terms. - d. Seconded. However I believe this debate has run its course previously. At least I haven't heard any news to the contrary. I think we all knew Mozilla would support Ogg regardless of the final spec. I am curious about the status of Dirac support though, since it was apparently finalised in January. Is this being planned? Would any other vendors care to comment on Dirac? Shannon
Re: [whatwg] video element now working in Firefox nightlies
David Gerard schrieb: The IP concerns are blatant FUD and it's ridiculous to describe them in any other terms. While I do agree that the IP concerns may actually be blown out of proportion (after all the current state of being in a limbo, leaving the field completely to proprietary technology like Flash video, may backfire more than taking the unspecified risk of IP troubles inherent to any technology) yelling at Apple and Nokia most likely won't resolve the situation by itself. Perhaps it makes sense to discuss ways to make installation of 3rd party media components as easy as one simple click to ensure a reasonably user-friendly cross-platform media experience. A common baseline codec built into user agents would of course be a nicer solution, but from what I understand little progress has been made on that topic. So perhaps let's make progress on a nearly-just-as-good solution. Maik
Re: [whatwg] video element now working in Firefox nightlies
2008/7/31 Maik Merten [EMAIL PROTECTED]: David Gerard schrieb: The IP concerns are blatant FUD and it's ridiculous to describe them in any other terms. While I do agree that the IP concerns may actually be blown out of proportion (after all the current state of being in a limbo, leaving the field completely to proprietary technology like Flash video, may backfire more than taking the unspecified risk of IP troubles inherent to any technology) yelling at Apple and Nokia most likely won't resolve the situation by itself. Ignoring IE, Firefox 3.1 will have this Just Work. So, as I said, it'll be a process of them deciding whether there are business reasons to come along at their leisure. Perhaps it makes sense to discuss ways to make installation of 3rd party media components as easy as one simple click to ensure a reasonably user-friendly cross-platform media experience. A common baseline codec built into user agents would of course be a nicer solution, but from what I understand little progress has been made on that topic. So perhaps let's make progress on a nearly-just-as-good solution. That's an implementation detail on their end, really. - d.
Re: [whatwg] video element now working in Firefox nightlies
David Gerard schrieb: Ignoring IE, Firefox 3.1 will have this Just Work. So, as I said, it'll be a process of them deciding whether there are business reasons to come along at their leisure. Yes, business reasons are usually indeed good reasons for businesses ;-) The second-biggest browser vendor choosing Theora may or may not give a good business reason for other vendors to reevaluate the balance between benefits and perceived risks. If for sure welcome the stance of Mozilla and Opera to support royality-free-for-any-purpose formats and I hope other vendors will follow this path. Perhaps it makes sense to discuss ways to make installation of 3rd party media components as easy as one simple click to ensure a reasonably user-friendly cross-platform media experience. That's an implementation detail on their end, really. Yes, but perhaps this implementation detail may lessen the impact of IP concerns if they are genuine and thus increase the chance that the codec question is resolved in a cross-browser way. Maik
Re: [whatwg] video element now working in Firefox nightlies
Maik Merten schrieb: If for sure welcome the stance of Mozilla and Opera to support royality-free-for-any-purpose formats and I hope other vendors will follow this path. This sentence doesn't parse. Patched version: I for sure welcome the stance of Mozilla and Opera to support royality-free-for-any-purpose formats and I hope other vendors will follow this path. Maik
Re: [whatwg] Expanding datetime
Henri Sivonen wrote: What use case is served by marking up Walt Disney's birthday as bday? Surely people aren't supposed to export Walt Disney's contact information to their address book app and have it remind them to congratulate Walt on his birthday. Again, you're thinking entirely in terms of social networking and not in terms of education and intellectual curiosity. I'd imagine more probable applications would be building (or searching) collections of biographical or event data from multiple sources. Let's say you have an application for constructing chronologies, and you're constructing a chronology of (say) the history of animation. You could drag and drop Walt's birthday onto the chronology. Look at this lesson plan for example: Have a collection of images of famous people use as a resource show to the children and discuss who they are and why they are famous. Have a selection of people from the past and present. Use www.Google.co.uk to find images. You could see if they could try and put them in a timeline. http://www.supporting-ict.co.uk/weblinks/historyks1.htm (If you look around, you'll find plenty of timeline-oriented approaches to the past.) Or, maybe you're building a database of animators with film samples. You could pull microformatted biographical information out from across the web and add it to your page. Or, maybe you're a journalist who needs to construct an on this day article. You search for stuff that happened on Disney's birthday, and come across Disney's biography that way. Anyhow, whether such applications of microformats fits how you imagine or would like to dictate how people use microformatted data, TIME as defined cannot cover how microformats are already applied, so let us not pretend that it does. You're free to argue that trying to encode such information is pointless, but that's an argument you'd want to take up with the microformats community and one I cannot support. -- Benjamin Hawkes-Lewis
Re: [whatwg] Expanding datetime
WeBMartians wrote: Believe it or not, Yes! Consider the couple to be congratulated on their gazillionth anniversary. Is that diamond, gold, platinum? Whatever it is, if your date time system is limited to epoch 1970, you're out of luck. That's why I claim that restrictions (rigorously documented) are OK as long as they are not ludicrous - ludicrous being a gray area, rather than a sharp line - 1970 definitely is, 1900 is probably OK, 1582 is interesting and far less ludicrous, while - is very safe but maybe ludicrous in other ways (prolepsis, locales...). For what it's worth, the proposed spec already defines rigorous limits Dates before the year 0 or after the year can't be represented as a datetime in this version of HTML. http://www.w3.org/html/wg/html5/#dates -- Benjamin Hawkes-Lewis
Re: [whatwg] Application deployment
Please explain why you consider concatenating JavaScript sources dirty. I don't necessarily think it's dirty, but any choices that game the system for purely performance reasons seem hackish to me. Concatenating js files for performance reasons is certainly less offensive than css sprites, but it still begs the question: is this always the right choice. For example, let's say I'm using jQuery plus a few plugins. The resources are really separate entities from third parties. Should I have to concatenate them? That said, there is clearly not much interest for this proposal here. I graciously concede :) -Russ On Wed, Jul 30, 2008 at 2:43 PM, Kristof Zelechovski [EMAIL PROTECTED]wrote: Please explain why you consider concatenating JavaScript sources dirty. You can have a library of all JavaScript definitions relevant to your site in one source file and I am not sure what is wrong with it, except that a library should consist of books, but that concept was already broken long ago. Chris -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Russell Leggett *Sent:* Wednesday, July 30, 2008 4:25 PM *To:* Peter Kasting *Cc:* [EMAIL PROTECTED] *Subject:* Re: [whatwg] Application deployment It seems to me that many of the additions to the HTML spec are there because they provide a standard way to do something we are already doing with a hack or more complicated means. CSS sprites are clearly a hack. Concatenating js files are clearly a hack. Serving from multiple sub-domains to beat the connection limit is also a workaround. My proposal is intended to approach the deployment issue directly, because I think it is a limitation in the html spec itself and therefore, I think the html spec should provide its own solution. My proposal may not be the best way, but assuming the issue will be dealt with eventually by some other party through some other means does not seem right either.
[whatwg] overflow of seamless iframes
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded0.html#seamless doesn't seem to say what happens to overflowing content in seamless iframes. Overflowing content seems likely to occur with the default values of 'width' and 'height', in at least the case where content inside the iframe that is wider than the iframe's containing block things like floats inside the iframe I would suggest that the 'overflow' CSS property apply to the handling of overflowing content inside seamless iframes. This seems like it would make them most like blocks. In any case, it seems like this ought to be defined (although if it were defined by making a more general statement of equivalence that might be good, since I suspect a bunch of other similar things are undefined as well). -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] overflow of seamless iframes
On Thu, 31 Jul 2008, L. David Baron wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded0.html#seamless doesn't seem to say what happens to overflowing content in seamless iframes. Overflowing content seems likely to occur with the default values of 'width' and 'height', in at least the case where content inside the iframe that is wider than the iframe's containing block things like floats inside the iframe I would suggest that the 'overflow' CSS property apply to the handling of overflowing content inside seamless iframes. This seems like it would make them most like blocks. In any case, it seems like this ought to be defined (although if it were defined by making a more general statement of equivalence that might be good, since I suspect a bunch of other similar things are undefined as well). My original idea (apparently not well conveyed in the spec) is that it doesn't actually affect the rendering model at all -- it's still an iframe, it just doesn't have a border, and the CSS style sheets cascade into it and properties inherit into it. So the answer would be do the same as with regular iframes, which I guess is to only support overflow: hidden and overflow: visible (and 'auto' mapping to one of those dynamically), as derived from the viewport as for any browser context. Note that the default width and height are adjusted for seamless iframes to match the width that the element would have if it was a non-replaced block-level element with 'width: auto', and the height of the bounding box around the content rendered in the iframe at its current width, respectively. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Question about the PICS label in HTML5
On Tue, 15 Apr 2008, Marco wrote: I've been looking through the HTML5 working draft and I've been trying to find a reference for the use of the current PICS labels. HTML5 currently doesn't define PICS support, but it allows authors to define extensions for meta name and link rel by registering them in the wiki. I noticed that the new specs only give three accepted keywords for the http-equiv attribute, which doesn't include the current pics-label: http://www.whatwg.org/specs/web-apps/current-work/#http-equiv0 Right, http-equiv is now defined really to be just a pragma, as opposed to metadata of some kind, so pics-label wouldn't really fit. Having said that, I was searching within the new specs for a way of accurately describing one's content. I'm somewhat aware of the W3C POWDER WG and the only post that I could find that was recent and relative to this is here: http://lists.w3.org/Archives/Public/www-tag/2008Mar/0114.html The closest type of markup that comes close to describing content that is accepted with the HTML5 validator is the current ICRA label: link rel=meta href=http://yoursite.com/labels.xml; type=application/rdf+xml title=ICRA labels / My question is: what is the direction for describing the type of content you would have within the context of the HTML5 working draft? Either a meta name or a link rel mechanism, probably, or a Microformat using class values. On Thu, 17 Apr 2008, Phil Archer wrote: As of today, PICS remains a W3C Recommendation so if HTML 5 is not going to support it in any way, that strikes me as questionable. PICS continues to be supported in Internet Explorer and, much to my surprise, this feature was updated to work with the current ICRA vocabulary in IE7. This was based on research that MSFT did into its usage which found that 'just enough' people used it to warrant its retention. I don't know whether it will survive into IE 8. We do still issue PICS labels (alongside an RDF-based label, the syntax for which is not standardised). Once HTML5 is completed, I expect PICS will long have been replaced by POWDER or other mechanisms, so I don't propose to make HTML5 specifically support PICS at this time. What do we need for HTML 5? Just the link/rel element. A POWDER link will be something like link rel=powder href=powder.xml type=application/xml / Please register such values at: http://wiki.whatwg.org/wiki/RelExtensions On Thu, 17 Apr 2008, Dan Brickley wrote: http://wiki.whatwg.org/wiki/RelExtensions Erm, 'For the Status section to be changed to Accepted, the proposed keyword must have been through the Microformats process, and been approved by the Microformats community. ' Is that really so? I've adjusted that text to mention W3C standards as being fine too. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] overflow of seamless iframes
On Thu, 31 Jul 2008, Simon Pieters wrote: On Thu, 31 Jul 2008 23:11:08 +0200, Ian Hickson [EMAIL PROTECTED] wrote: My original idea (apparently not well conveyed in the spec) is that it doesn't actually affect the rendering model at all -- it's still an iframe, it just doesn't have a border, and the CSS style sheets cascade into it and properties inherit into it. This makes it basically impossible to style html and body in the outer document (unless you use style=), and moreover, the default 8px margin on body in the iframe will make it look not-so-seamless. Just use a class. I don't really see a sane alternative. Actually grafting the child DOM from the children of the body down into the final flattened tree of the outer DOM would be a huge source of difficulties. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Joined blocks
Something I think is really missing from HTML is linked text (in the traditional desktop publishing sense), where two or more text boxes are joined so that content overflows the first into the second and subsequent boxes. This is a standard process for practically all multi-column magazines, books and news layouts. It is especially valuable for column layouts where the information is dynamic and variable in length and therefore cannot be manually balanced. This is not something that can be solved server-side since the actual flow is dependent on user style-sheets, viewport and font-size. For the sake of disambiguation i'll call this joined blocks, since linking has its own meaning in HTML and the content need not be text. I honestly don't know if this is too difficult to implement, however it has been a standard feature of publishing software such as Pagemaker and Quark Xpress for over 10 years. The markup would be something like: div id=col1img src=logo.png style=float:rightp/pp/pp/p/div div join=col1 id=col2/div div join=col2 id=col3/div When reflowing, block elements are moved as a whole. If the block won't fit then it follows the overflow behaviour of the column. Inline elements are split by line. For backwards-compatibility it must be legal to split the markup over each group member (manual or best-guess balancing). However a HTML5 compliant browser would reflow to other members as though the combined markup originated in box 1. There are two ways to implement this proposal with respect to CSS. 1.) Rewrite the DOM with the new layout. Closing objects that were split and propagating attributes. 2.) Rewrite the CSS parser. Method 1 is probably simpler but has serious issues with the id attribute - since it must be unique and therefore cannot propogate to both halves of a split object. It could also create undesirable behaviour with respect to :first-line, :before and other selectors that the author would expect to apply to the element only once. Method 2 solves most of these issues but it would probably be a significant rewrite of current parsers. I accept this proposal may be difficult to implement but its use case is significant with regards to articles and blogs, especially in an era of user-submitted content and wide screen layouts. Shannon
Re: [whatwg] Joined blocks
On Fri, 1 Aug 2008, Shannon wrote: Something I think is really missing from HTML is linked text (in the traditional desktop publishing sense), where two or more text boxes are joined so that content overflows the first into the second and subsequent boxes. This is a standard process for practically all multi-column magazines, books and news layouts. It is especially valuable for column layouts where the information is dynamic and variable in length and therefore cannot be manually balanced. This is not something that can be solved server-side since the actual flow is dependent on user style-sheets, viewport and font-size. I agree that this would be a useful feature for the Web platform. However, I believe the CSS working group is a better venue for exploring such options. I recommend forwarding your proposal to [EMAIL PROTECTED] -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Joined blocks
I agree this is _mostly_ a CSS issue except that there is semantic meaning to the join attribute beyond layout. The attribute could serve as a guide to search engines, web-scrapers or WYSIWYG applications that two areas of the page should be considered a single piece of content. I am also unsure as to how this might affect other aspects of browser, javascript or DOM behaviour. There may be other uses or side-effects I can't imagine. At any rate CSS cannot associate elements so the join attribute should be considered independent of the style considerations as a means of saying this block follows that one. Nonetheless I will do as you suggest. Shannon Ian Hickson wrote: On Fri, 1 Aug 2008, Shannon wrote: Something I think is really missing from HTML is linked text (in the traditional desktop publishing sense), where two or more text boxes are joined so that content overflows the first into the second and subsequent boxes. This is a standard process for practically all multi-column magazines, books and news layouts. It is especially valuable for column layouts where the information is dynamic and variable in length and therefore cannot be manually balanced. This is not something that can be solved server-side since the actual flow is dependent on user style-sheets, viewport and font-size. I agree that this would be a useful feature for the Web platform. However, I believe the CSS working group is a better venue for exploring such options. I recommend forwarding your proposal to [EMAIL PROTECTED]
