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
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
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
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
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
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
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
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
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/
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
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
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
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
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:
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
15 matches
Mail list logo
