Re: [whatwg] How to use SVG in HTML5?
On Thu, 24 Jan 2008 05:41:58 +0100, Eli Naeher [EMAIL PROTECTED] wrote: Could you elaborate on these barriers? I would really like to see inline SVG. http://annevankesteren.nl/2007/10/svg-html has a high-level overview. The main problem is how the HTML parser as defined by the HTML5 specification needs to be modified and what set of limitations do we impose on the syntax. I also notice that 3.3.3.6 mentions something related: Elements that are from namespaces other than the HTML namespace and that convey content but not metadata, are embedded content for the purposes of the content models defined in this specification. (For example, MathML, or SVG.) Is this section out-of-date? Or does it refer only to elements which have been loaded into the DOM by some means other than being included in the source (e.g. in accordance with 4.8.2, Page load processing model for XML files)? HTML 5 defines processing of HTML5, XHTML5, and documents created using DOM methods. Only the latter two can contain elements from other namespaces at this point. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] How to use SVG in HTML5?
Charles McCathieNevile wrote: On Thu, 24 Jan 2008 04:19:37 +1100, Mathieu HENRI [EMAIL PROTECTED] wrote: James Graham wrote: David Gerard wrote: ... I'd like to be able to drop SVG images into an HTML page as easily as I can a JPEG or PNG. I read over the recently-released HTML5 draft and couldn't work out how I'd do this. What would the HTML to do this look like? What's the equivalent of IMG SRC=foo.jpg for foo.svg? In browsers which support it img src=foo.svg will work (with certain limitations for security reasons). If you want to embed svg inline like you can with XHTML, that's not currently supported... Supporting img src=foo.svg is a requirement of SVG 1.1 [1] ... It is true that you can't use inline markup. As far as I know, img src=foo.svg is only supported in Opera 9.5 betas (maybe webkit nightlies, I forget). It's also bad HTML, since it lacks any kind of fallback. But you can use object data-foo.svg/object (again bad HTML, it should generally have some kind of fallback content - and a size). Unfortunately, of course, IE is still holding you back from doing it on the open web that simply :( object data=foo.svgobject data=foo.pngSmells like Lynx spirit./object/object cheers Chaals -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] How to use SVG in HTML5?
Embedding SVG by reference (thought the img element) is well suited to HTML. SVG was designed for this as stated in Embedding by reference section here: http://www.w3.org/TR/SVG11/concepts.html#UsageOptions I tested Opera's support for SVG through the img element and it incorrectly clips the SVG image. The width and height attributes of the img element need to set the viewport for the SVG image and scale the SVG non-uniformly to fit the viewport. The advantages of using the img element to render SVG over the object element or inline SVG are: 1. Existing authoring tools and CMS can support SVG without major modifications. For example, most CMS that support image libraries are hard wired to generate the img element when an image is selected from an image library. 2. Using SVG through the img element is more accessible solution because existing assistive technologies support the alt attribute whereas support for the object fallback mechanism is limited and support for inline SVG is non-existent. Also, even though SVG supports title and desc elements which are meant to increase accessibility of SVG, most SVG documents do not use them. So having the alt attribute on the img element is more accessible solution than relying on title and desc inside SVG. Regards, -Vlad http://xhtml.com
[whatwg] Form submission progress display by UA (incl. file upload)
Consider a form with a file input. User selects a huge file and hits submit. Most UAs do not display nothing but an animated throbber until the full submit is done and the download progress bar only starts to do anything after the full submit part is already done. An another example could be a long blog article that is being sent over an GPRS mobile connection (with common speeds around 9kbps). I think that WF2 section 5.6 (http://www.whatwg.org/specs/web-forms/current-work/#methodAndEnctypes) should be modified to say something along the lines User agents with interactive user interfaces should inform the user about the progress of the data submission. For example, an UA with a graphical user interface could display a visual progress bar which would be updated once every second; the bar would be initially displayed as empty and would fill over time as the encoded form data set is transmitted. For transmissions that take more than a few seconds UA might in addition display estimated time before done. Rationale: Upload progress monitoring is becoming more important every day as browsers are often used for content authoring, the digital content gets bigger and common user connections are highly asymmetric (e.g. 24mbps downstream, 1mbps upstream in case of ADSL2+). The delay expected by the user for sending a 100MB file could be close to downloading a 100MB which is not the reality. An user in a hurry would hit stop button and retry again after waiting for some time without knowing that upload is in progress. -- Mikko signature.asc Description: OpenPGP digital signature
[whatwg] Reverse ordered lists
On Jan 24, 2008 1:16 AM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: A CMS is a smart engine, it is not limited to composing content from various sources; it is possible (and probably necessary) to do various fix-ups anyway before sending to the user agent. Chris Of course. :) But when you have no control over the back-end because the site belongs to someone else, you can only work with what it gives you! - Jason
Re: [whatwg] Form submission progress display by UA (incl. file upload)
On 1/24/08, Mikko Rantalainen [EMAIL PROTECTED] wrote:
Consider a form with a file input. User selects a huge file and hits
submit. Most UAs do not display nothing but an animated throbber until
the full submit is done and the download progress bar only starts to do
anything after the full submit part is already done. An another example
could be a long blog article that is being sent over an GPRS mobile
connection (with common speeds around 9kbps).
I think that WF2 section 5.6
(http://www.whatwg.org/specs/web-forms/current-work/#methodAndEnctypes)
should be modified to say something along the lines
User agents with interactive user interfaces should inform the user
about the progress of the data submission. For example, an UA with a
graphical user interface could display a visual progress bar which would
be updated once every second; the bar would be initially displayed as
empty and would fill over time as the encoded form data set is
transmitted. For transmissions that take more than a few seconds UA
might in addition display estimated time before done.
My embedded device battery managers will complain about anything that
happens more than once every 30s (they do).
Rationale: Upload progress monitoring is becoming more important every
day as browsers are often used for content authoring, the digital
content gets bigger and common user connections are highly asymmetric
(e.g. 24mbps downstream, 1mbps upstream in case of ADSL2+). The delay
expected by the user for sending a 100MB file could be close to
downloading a 100MB which is not the reality. An user in a hurry would
hit stop button and retry again after waiting for some time without
knowing that upload is in progress.
I think a slightly more beneficial thing would be for the file picker
posting system to be able to tell the user how big the file is and how
long submitting a form should take at some transfer time. I'm not sure
if anything like this is exposed.
http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl
lists a fileSize property. I think it'd be nice if gmail could tell me
that this file will take an hour to upload. I also wonder if it'd be
a good idea to support getting chunks of a file, because if I had a
4gb file, using DOMFile().getAsBinary() would probably crash my
browser. I'd kinda like for gmail to be able to do partial uploads
In order for this to work, there should be DOMString hash() which has
an optional argument for a hash algorithm (md5sum, a const for
md5sum, or maybe an object { processBlock:function(data) {},
getHash:function() }. Otherwise a user could try feeding sequential
blocks from different files.
Currently, file uploading is a kinda syncish process.
As to your actual concerns, gmail already deals w/ uploading in the
background fairly gracefully. And in IE6, there is a progress meter
during the upload (Gecko doesn't show proper progress, but I believe
that's a bug).
I'm not sure I see what value is added by somehow mandating this
feature. Evolving browsers will probably add this feature anyway
through competition.
Re: [whatwg] nextSiblingElement ?
Dnia 23-01-2008, Śr o godzinie 22:50 -0800, Garrett Smith pisze: nextSibling and previousSibling are useful, but not always what I want. nextSibling is all right if you replace UL LI /UL with UL LI /UL . It may look funny at first and WYSIWYG editors know nothing about that but otherwise it works all right and you can get used to it (it is the best solution for me). Chris
Re: [whatwg] How to use SVG in HTML5?
Dnia 24-01-2008, Cz o godzinie 08:50 -0500, Vlad Alexander (xhtml.com) pisze: Embedding SVG by reference (thought the img element) is well suited to HTML. SVG was designed for this as stated in Embedding by reference section here: http://www.w3.org/TR/SVG11/concepts.html#UsageOptions This is a permission from SVG's side: the designer of SVG permits HTML content to use IMG for SVG if HTML allows it. It should not be viewed as an obligation imposed upon HTML though. I tested Opera's support for SVG through the img element and it incorrectly clips the SVG image. The width and height attributes of the img element need to set the viewport for the SVG image and scale the SVG non-uniformly to fit the viewport. The advantages of using the img element to render SVG over the object element or inline SVG are: 1. Existing authoring tools and CMS can support SVG without major modifications. For example, most CMS that support image libraries are hard wired to generate the img element when an image is selected from an image library. They are all wrong (non-compliant). There are two ways to embed an image for all those Internet Explorer users to view: 1. Ask QuickTime to display the image as an object (first time requires administrator privileges) 2. Make it a background image of a suitably sized empty container. It is somewhat hard to make the container be displayed in-line but images for the sake of themselves rarely need such display. As a side effect, the right click download is disabled, which is something many publishers are after. 2. Using SVG through the img element is more accessible solution because existing assistive technologies support the alt attribute whereas support for the object fallback mechanism is limited Limited to what? and support for inline SVG is non-existent. And rightfully so. Also, even though SVG supports title and desc elements which are meant to increase accessibility of SVG, most SVG documents do not use them. So having the alt attribute on the img element is more accessible solution than relying on title and desc inside SVG. I parrot: Most HTML documents do not have it or have some nonsense in it. Which of course is no more an argument than yours, i.e. nil. Regards, Chris
Re: [whatwg] How to use SVG in HTML5?
Dnia 23-01-2008, Śr o godzinie 14:44 -0500, Sam Ruby pisze: On Jan 23, 2008 2:13 PM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: SVG is too heavyweight for the purpose of such tiny presentational enhancements. I can provide counterexamples: http://intertwingly.net/blog/ http://intertwingly.net/blog/archives/ - Sam Ruby All right, I hereby grant you the right to use in-line SVG provided the only element used inside is solid filled path. (No gradients, transformations, mitres, text and such). I remember using VML in this spirit myself. Thanks for the redirection, the pictures are very nice! Chris
Re: [whatwg] How to use SVG in HTML5?
Dnia 24-01-2008, Cz o godzinie 07:34 +1100, Charles McCathieNevile pisze: On Thu, 24 Jan 2008 06:44:59 +1100, Sam Ruby [EMAIL PROTECTED] wrote: On Jan 23, 2008 2:13 PM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: SVG is too heavyweight for the purpose of such tiny presentational enhancements. I can provide counterexamples: http://intertwingly.net/blog/ http://intertwingly.net/blog/archives/ An image is not a replacement for text in the real world, only in Ian's current drafts. Ian never said say that about images in general but about image elements. And your reply is not related to the examples: they do NOT use IMG (correct). Chris
Re: [whatwg] How to use SVG in HTML5?
On 24/01/2008, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: I hereby grant you the right to use in-line SVG provided the only element used inside is solid filled path. (No gradients, transformations, mitres, text and such). I remember using VML in this spirit myself. Thanks for the redirection, the pictures are very nice! This is a good example of why people will want to use SVGs just like any other sort of image: * vector drawing is the right way to do lots of sorts of image * SVG is a standard and increasingly widely-used vector format * Inkscape's a reasonably usable and free vector drawing application that saves in SVG (of a sort) That it's arguably problematic won't stop people from wanting to do it, any more than tag soup being a parsing nightmare will stop people from doing the tagsoup-render-tagsoup-render-looks-ok method of HTML writing. And on a hostile Internet, user agents have to be able to cope well with arbitrary rubbish which may well be malicious, not just badly-formed; I don't see that safely parsing SVG is an intrinsically trickier problem than criminal spammers throwing every piece of toxic waste they can come up with at your user agent. [Inkscape is so prevalent for SVG drawing that Wikimedia has seriously considered using Inkscape in command-line mode as the default SVG renderer rather than rsvg, even if it is half the speed and uses a bucketload more memory. A user agent that handles SVG will likely need to be able to cope with almost anything Inkscape throws at it.] - d.
Re: [whatwg] MessageEvent.domain, document.domain on a page whose URI has no domain (e.g. data:text/html, ...)
On Jan 24, 2008 10:59 AM, Jonas Sicking [EMAIL PROTECTED] wrote: Note that this is a much bigger issue than simply what to return for document.domain. It's basically the question, what security context should data: documents and written-into documents use. The security origin of frames that begin life with the URL about:blank or differs in different browsers. In Firefox and the trunk revision of WebKit, the principal for the frame is aliased to the principal of the frame's parent (or opener, if it is a top-level frame). In IE7, the frame appears to copy the principal. http://crypto.stanford.edu/~abarth/research/html5/empty-frame/ The frame's window.location.href property matches the parent/opener in Firefox, IE, and Safari: http://crypto.stanford.edu/~abarth/research/html5/empty-frame/href.html Adam
Re: [whatwg] ogg vorbis standard
On Thu, 24 Jan 2008, I Holroyd wrote: Setting a free and open source solution as THE STANDARD is the only ethical solution. I believe everyone agrees that the desired solution for a common video codec in HTML5 is one that is freely implementable and royalty free, amongst other requirements. Anyone is free to support it, adapt it and improve it, but no one has to, but we can all be assured that the flow of information we desire is available, without charge, to anyone at all - that is the purpose of standards and especially internet standards. I'm not sure this makes sense -- if not everyone is required to implement the common codec, how can we ensure that everyone can be assured that they can use it in an interoperable manner? Can we make standards ISO compliant Ironically, the only high or moderately high quality ISO standard video codecs that I'm aware of are the MPEG codecs, which are not royalty free. Everyone agrees that we need a free and open codec. However, those are not the only requirements -- we also need a codec that everyone is willing to implement. We are still working on finding such a codec. Thaks for your input, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] nextSiblingElement ?
On Wed, 23 Jan 2008, Garrett Smith wrote: nextSibling and previousSibling are useful, but not always what I want. I usually want to get a siblingElement than a sibling, which might be a text node. One of the following drafts probably already handles your needs: http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html#TreeWalker http://www.w3.org/TR/ElementTraversal/ HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas line styles comments
On Tue, 19 Jun 2007, Philip Taylor wrote: For lineJoin, the term joins is used but not properly defined (except indirectly as where two lines meet). Given the implementations, this should be something like: For each subpath, a join exists at the point shared by each consecutive pair of lines. If the subpath is closed, then a join also exists at its first point (equivalent to its last point) connecting the first and last lines in the subpath. Added something close to that. There are no conformance criteria for rendering lineCap. Fixed, sort of. The definition of 'miter' is incorrect: it seems to say the miter gets truncated into a more-sided polygon if it would exceed miterLimit, but the behaviour of implementations is to revert to 'bevel' rendering instead. The definition of 'round' for lineJoin is slightly incorrect, since it talks about adding a filled arc when it needs to be a filled circle sector (or an arc plus a triangle). Fixed. The definition for 'stroke' says The stroke() method must stroke each subpath of the current path in turn, using the strokeStyle, lineWidth, lineJoin, and (if appropriate) miterLimit attributes. That list should include lineCap. Fixed. The lineWidth attribute gives the default width of lines, in coordinate space units. - why default? Removed. The expression the point where the inside edges of the lines touch doesn't make sense to me. (Actually, it did make sense for a while, but then I realised it was an incorrect sense). Fixed. I think the problem is in being ambiguous about the distinction between geometric lines (which are infinitely thin and just a description of a path through space) and graphical lines (which are a thick filled shape, defined by their edges (which are geometric lines)) - the rendering details are describing how to convert the first sort of line into the second sort of line, but that seems to be made unclear. I believe it would be clearer to use the term line only in the first sense (so ctx.lineTo adds a line to the subpath, and ctx.fill fills the area enclosed by the path's lines, etc), and the term stroke [or a better name, since I don't really like this one, but I can't think of anything else] for the second sense (so ctx.stroke calculates and renders strokes, which are shapes that are based on the path's lines and widths and caps and joins). There also seems to be a danger of confusion between lines (like a single straight/arc/Bézier line segment) and subpaths, like in the definition of what lineCap applies to. Are there any bits that are really still confusing? I'd rather not make sweeping changes to the terminology like this, I'd almost certainly get it wrong and make matters worse. (I agree that this section has suboptimal conformance requirements. It's one of the first sections I wrote for this spec, and it shows. However, I'd like to limit the fixes to blatent mistakes and areas where interop is failing due to the spec.) (Is it worth having diagrams (kind of like http://canvex.lazyilluminati.com/misc/linejoin.png), so normal people can tell what the interesting bits here actually mean? Or is that best left for tutorials and user reference guides?) Diagrams would be great. I plan on doing a pass with adding diagrams and examples much later, once the spec is stable, but feel free to provide unstylised diagrams in the meantime. :-) There are some other issues I'm currently aware of, possibly requiring more complexity: What happens when a stroked path has zero length, in terms of drawing the line caps/joins? In particular, square caps are impossible because the line does not have a defined direction (assuming we're not having dashed paths for now). In Firefox 2 and Opera, nothing is drawn for zero-length paths. In Firefox 3 and Safari, round caps/joins are drawn (because the direction of the line doesn't matter in that case, so the output is well-defined), and nothing else is drawn. I've added a line that says that zero-length line segments and pruned before stroking, which as far as I can tell makes Firefox 2 and Opera's behaviour correct. What happens when a stroked path contains a line with zero length, between non-zero-length lines? As far as I can tell, zero-length lines never have any effect (e.g. line-joins get drawn between two non-consecutive non-zero-length lines if they have only zero-length lines between them, so the earlier suggestion for defining 'join' is wrong) - except when the path has no non-zero-length lines in it, in which case the presence of a zero-width line causes round caps to be drawn in FF3/Safari. (...except in FF3 when it's a zero-length quadratic/Bézier curve). Maybe it'd be best just to require that lines with zero length are never added to the subpath - so if you don't add any non-zero-length ones, the subpath will be empty and won't get drawn, which is slightly
