Re: [whatwg] nextSiblingElement ?

[Maciej Stachowiak]

On Jan 23, 2008, at 10:50 PM, 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.

Dom.findNextSiblingElement = function(el) {
for(var ns = el.nextSibling; ns != null; ns = ns.nextSibling)
if(ns.nodeType == 1)
return ns;
return null;
};

The same is true for childNodes.

It would be useful to have:

nextSiblingElement,
previousSiblingElement,
childElements


The W3C's Web API Working Group is working on an "Element Traversal"  
spec that provides functionality like this.


Cheers,
Maciej

Re: [whatwg] Reverse ordered lists

[Krzysztof Żelechowski]

Dnia 23-01-2008, Śr o godzinie 15:34 -0600, Siemova pisze:

> If you mean that a script should be able to use that
> automatically-generated value, I'm sure that's true, but there are
> cases wherein the content creator doesn't have access to the script in
> order to build that in. For example, the very case which inspired me
> to propose this feature involved a list of items generated in reverse
> order by a CMS. 

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

Re: [whatwg] nextSiblingElement ?

[Cameron McCormack]

Hi Garrett.

Garrett Smith:
> 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.
> 
>   Dom.findNextSiblingElement = function(el) {
>   for(var ns = el.nextSibling; ns != null; ns = ns.nextSibling)
>   if(ns.nodeType == 1)
>   return ns;
>   return null;
>   };

There is http://www.w3.org/TR/ElementTraversal/, which specifies just
this.

-- 
Cameron McCormack, http://mcc.id.au/
xmpp:[EMAIL PROTECTED]  ▪  ICQ 26955922  ▪  MSN [EMAIL PROTECTED]

[whatwg] nextSiblingElement ?

[Garrett Smith]

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.

Dom.findNextSiblingElement = function(el) {
for(var ns = el.nextSibling; ns != null; ns = ns.nextSibling)
if(ns.nodeType == 1)
return ns;
return null;
};

The same is true for childNodes.

It would be useful to have:

nextSiblingElement,
previousSiblingElement,
childElements

Garrett
-- 
boxbe is annoying--> I use Boxbe to protect my email, so please keep
this code in your reply: JPV9KTNZ

Re: [whatwg] How to use SVG in HTML5?

[Eli Naeher]

On Jan 24, 2008 8:23 AM, James Graham <[EMAIL PROTECTED]> wrote:

> In browsers which support it  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, although several people have
> expressed an interest in changing that. However there are significant 
> technical
> barriers to overcome at the syntax/parser level.

Could you elaborate on these barriers? I would really like to see inline SVG.

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)?

Thanks,

--Eli

Re: [whatwg] Referer header sent with ?

[Kornel Lesinski]

On Wed, 23 Jan 2008 07:27:16 -, Ian Hickson <[EMAIL PROTECTED]> wrote:


HTML5 doesn't say anything about whether a referer should be sent with
the POST generated by . There is a new attack vector 
opens (as currently being discussed on mozilla.dev.platform) that would
be blocked if the referer were not sent.


Fixed. I also said to not include Cookies or HTTP auth headers.  
Legitimate uses can always include whatever information they want in the  
ping=""

attribute's value itself.


Doesn't that kill use of ping for tracking ad clicks? I think ad providers  
want to have cookies to track individual users across domains, and site  
that serves  is unable to provide that. Maybe ping could allow only  
cookies with a certain name/naming scheme?



I don't think that attack vector discussed on mozilla.dev.platform should  
be taken so seriously. In my opinion case when  enables attack  
(instead of being just one of countless possible attack vectors) is very  
very unlikely:


- If site accepts data from GET as well as POST (e.g. is using PHP's  
register_globals), then  is not needed at all -- a better attack  
can be performed with simple  or .
- If site allows HTML from untrusted source and allows ping to slip  
through, it is very likely that the site can be tricked to allow other  
potentially dangerous attributes or scripts.
- Because not all browsers/proxies/firewalls send Referer header,  
public-facing websites have to accept POSTs without Referer, so forbidding  
Referer for  may not increase security and even make it harder to  
protect against CSRF.


OTOH Referer can help save bandwidth. Without it page may need to include  
its own URL in every  attribute. On pages with lots of links  
(portals, directories) this can noticeably increases size of HTML.


Maybe these problems could be solved with an additional HTTP header in the  
ping request? e.g.:


X-Ping: from="http://example.com/here";, to="http://example.com/there";

This would make it easy to protect against unwanted ping-originated  
requests (one could configure server or set up application firewall to  
filter pings), and URL in  wouldn't have to contain copies of  
page's URL and href.


--
regards, Kornel Lesiński

Re: [whatwg] Reverse ordered lists

[David Walbert]

On Jan 23, 2008, at 7:10 PM, Robert (Jamie) Munro wrote:


Surely it should be numbered with the step.

...

6. Foo
4. Bar
2. Baz


I can see either way being useful in theory, but I haven't seen a use  
case for reverse-ordered list where the the step is not -1 -- nor one  
with negative-numbered list items. Can anybody cite one or propose one?


_
David Walbert
LEARN NC
UNC-Chapel Hill

[whatwg] MessageEvent.domain, document.domain on a page whose URI has no domain (e.g. data:text/html, ...)

[Jeff Walden]

The spec as currently written says that document.domain in a document located 
at a URI with no domain is null:

data:text/html,alert(document.domain);

Safari and Opera both alert the empty string for this; Firefox alerts null.

There's also a domain property on MessageEvent, used with the cross-document 
postMessage API.  The exact value of this property isn't quite clear in the 
current spec (which says the document has no domain but doesn't say what that 
translates into on the MessageEvent interface), but Opera and Safari both agree 
that the domain property should be the empty string when the page that calls 
postMessage is a data: URL.

It seems that, for consistency, document.domain and MessageEvent.domain should 
both be the empty string in this case, for greatest cross-browser compatibility 
with the least change to the status quo, with the only change needing to happen 
in Firefox.

Jeff

[whatwg] Calling HTMLDocument.open() should change the origin of the document to the caller's origin

[Jeff Walden]

The current verbiage describing open() says nothing about the document's origin 
reflecting that of the mutator, which is an oversight which should eventually 
be corrected.  This came up when considering the values of the domain/uri 
properties on a MessageEvent created by a document.open()ed document which 
calls postMessage.  Just making sure this gets in the queue to be addressed...

Jeff

Re: [whatwg] Reverse ordered lists

[Robert (Jamie) Munro]

David Walbert wrote:


On Jan 23, 2008, at 11:39 AM, Siemova wrote:


Very easily:

if start is not specified
if not reverse
start = 1
else
start = number of items * step 



It's not that simple -- the last line should be

start = 1 + ( (number of items - 1) * step)

if it's assumed that the last item of the list is numbered one by default. 


Surely it should be numbered with the step.


Foo
Bar
Baz


Should be:
6. Foo
4. Bar
2. Baz

not:
5. Foo
3. Bar
1. Baz

Robert (Jamie) Munro



signature.asc
Description: OpenPGP digital signature

Re: [whatwg] Reverse ordered lists

[Siemova]

On Jan 23, 2008 3:18 PM, Krzysztof Żelechowski <[EMAIL PROTECTED]>
wrote:

>
> Dnia 23-01-2008, Śr o godzinie 14:57 -0600, Siemova pisze:
>
> > Moreover, and more importantly, that would make the feature terribly
> > inflexible. If you decided to add or remove items -- or, heaven
> > forbid, you wanted to (re)populate your list on-the-fly with a script
> > -- you'd have to keep changing the start value by hand. That would be
> > well-nigh impossible in certain situations, and I think it's a bit
> > unreasonable to expect.
>
> It is straightforward to count the children of an ordered list element;
> the DOM does it automatically
> so that you need not even use a loop to achieve that.
>
> Chris



Ah, good. So can't that be used to set the start value in the first place?
Or is it generated via the actual process of rendering?

If you mean that a script should be able to use that automatically-generated
value, I'm sure that's true, but there are cases wherein the content creator
doesn't have access to the script in order to build that in. For example,
the very case which inspired me to propose this feature involved a list of
items generated in reverse order by a CMS.

- Jason

Re: [whatwg] How to use SVG in HTML5?

[David Gerard]

On 23/01/2008, timeless <[EMAIL PROTECTED]> wrote:

> > Every browser (except IE) *has* SVG rendering.

>That's not true. MicroB as shipped w/ OS 2008 on the N810 (and in OS


Sorry, you're right. I was thinking only of the desktop. Bad move.


> > Firefox 3 will have *accurate* SVG rendering.

> who's promising this?


Read up the thread. I noted that Minefield's rendering is notably
better than FF2's.

(I've been exploring the world of SVG in far too much depth lately.
All SVG renderers suck, but Minefield's suck is on the CPU-pegging
side, not the rendering side.)


- d.

Re: [whatwg] Reverse ordered lists

[Krzysztof Żelechowski]

Dnia 23-01-2008, Śr o godzinie 14:57 -0600, Siemova pisze:

> Moreover, and more importantly, that would make the feature terribly
> inflexible. If you decided to add or remove items -- or, heaven
> forbid, you wanted to (re)populate your list on-the-fly with a script
> -- you'd have to keep changing the start value by hand. That would be
> well-nigh impossible in certain situations, and I think it's a bit
> unreasonable to expect. 

It is straightforward to count the children of an ordered list element; 
the DOM does it automatically 
so that you need not even use a loop to achieve that.

Chris

Re: [whatwg] How to use SVG in HTML5?

[timeless]

On Jan 23, 2008 10:42 PM, David Gerard <[EMAIL PROTECTED]> wrote:
> I think Chris is incorrect in his assertion because clients can be
> presumed to have increasing amounts of rendering power available just
> to make pretty pictures.

please don't assume this. an n800 or n810 does not have much
processing power, and its user would prefer that the device's battery
last longer. Rendering a tiny picture perfectly on the client side
when it could have been rendered server side is not a polite thing to
ask of a resource limited device.

> Every browser (except IE) *has* SVG rendering.

That's not true. MicroB as shipped w/ OS 2008 on the N810 (and in OS
2008 for the N800) does not include SVG rendering.
 (disclaimer: i wrote that
page)

AFAICT IE6 included an old version of Adobe's SVG plugin, and you can
get Adobe's latest plug-in (3.03) if you like.

> Firefox 3 will have *accurate* SVG rendering.

who's promising this?

> SVG is the Right Thing for so many situations. It's all looking promising to 
> me
> so far.

Re: [whatwg] How to use SVG in HTML5?

[Krzysztof Żelechowski]

Dnia 23-01-2008, Śr o godzinie 20:42 +, David Gerard pisze:

> FWIW, my use case is to be able to create images in SVG and just use
> them as ... images, just like I do PNGs or JPEGs. It was also somewhat
> inspired by setting up rsvg for MediaWiki on our work intranet and
> wanting to hit it repeatedly with a hammer ... but relying on
> client-side SVG rendering will have to wait until Firefox 3 renders it
> not only correctly, but without pegging the processor just displaying
> ;-)
> 
> I think Chris is incorrect in his assertion because clients can be
> presumed to have increasing amounts of rendering power available just
> to make pretty pictures. 

That does not necessarily mean 
that the owner of the rendering device would be happy 
to watch the user agent use that power for something inessential 
(battery life!).

Besides, your paragraph 2 directly contradicts paragraph 1: 
the implementations are not mature.

> Every browser (except IE) *has* SVG
> rendering. 

And that means that, optimistically, 
one user in three will have a chance 
of viewing the content as you intended 
(unless your target audience is very specific).

> Firefox 3 will have *accurate* SVG rendering. SVG is the
> Right Thing for so many situations. It's all looking promising to me
> so far.

While it is nice and comforting to have a promise, 
it is wise not to rely on it too much.

Chris

Re: [whatwg] Reverse ordered lists

[Siemova]

On Jan 23, 2008 1:23 PM, Krzysztof Żelechowski <[EMAIL PROTECTED]>
wrote:

>
> Dnia 23-01-2008, Śr o godzinie 12:53 -0600, Siemova pisze:
> > True, that's simplest to implement, but why put the onus on the
> > content author to add things up and specify a start value every time?
>
> If for no other reason, in order to help global warming.
> A HTML document is written once, read lots of times.
> If the author insists that counting the items is an excessive burden
> (it is not; if you cannot count yourself,
> just remove the reverse attribute
> and look at the last item as rendered)
> he could use a generator or a fix-up processor before publishing.
>
> Chris



I agree that counting is not, as a rule, an excessive burden. (In fact, I'm
one of those people dismayed that so many cashiers can't seem to count
change in their heads.) However, considering the setting, I'd still say it's
an *unnecessary *burden when the computer can simplify the process with much
less time and effort.

Moreover, and more importantly, that would make the feature terribly
inflexible. If you decided to add or remove items -- or, heaven forbid, you
wanted to (re)populate your list on-the-fly with a script -- you'd have to
keep changing the start value by hand. That would be well-nigh impossible in
certain situations, and I think it's a bit unreasonable to expect.

Now, if *UAs* wanted to render the list incrementally in ascending order and
then reverse the numbering, that sounds better worth considering, if still
not ideal.

Asking from ignorance: would it be so terrible not to render a reversed list
at all until it has been fully calculated? Or perhaps to have the UA see the
reverse flag, count up the items to determine start value, and *then *render
the list incrementally?

- Jason

Re: [whatwg] How to use SVG in HTML5?

[David Gerard]

On 23/01/2008, Charles McCathieNevile <[EMAIL PROTECTED]> wrote:

> An image is not a replacement for text in the real world, only in Ian's
> current drafts. And where it is, SVG is ideal for having beautifully
> styled selectable interactive text that is lightweight and easy to create
> (or heavyweight and bloated if you use something like inkscape, but still
> easy to create and easy to automagically optimise to something
> lightweight).
> Which is why I disagree thoroughly with Chris' assertion here.


FWIW, my use case is to be able to create images in SVG and just use
them as ... images, just like I do PNGs or JPEGs. It was also somewhat
inspired by setting up rsvg for MediaWiki on our work intranet and
wanting to hit it repeatedly with a hammer ... but relying on
client-side SVG rendering will have to wait until Firefox 3 renders it
not only correctly, but without pegging the processor just displaying
;-)

I think Chris is incorrect in his assertion because clients can be
presumed to have increasing amounts of rendering power available just
to make pretty pictures. Every browser (except IE) *has* SVG
rendering. Firefox 3 will have *accurate* SVG rendering. SVG is the
Right Thing for so many situations. It's all looking promising to me
so far.


- d.

Re: [whatwg] How to use SVG in HTML5?

[Charles McCathieNevile]

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. And where it is, SVG is ideal for having beautifully  
styled selectable interactive text that is lightweight and easy to create  
(or heavyweight and bloated if you use something like inkscape, but still  
easy to create and easy to automagically optimise to something  
lightweight).


Which is why I disagree thoroughly with Chris' assertion here.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Re: [whatwg] How to use SVG in HTML5?

[Charles McCathieNevile]

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
 for foo.svg?
 In browsers which support it  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  is a requirement of SVG 1.1 [1]

...

It is true that you can't use inline markup. As far as I know, 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  (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 :(


cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Re: [whatwg] How to use SVG in HTML5?

[Sam Ruby]

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

Re: [whatwg] More random comments on the putImageData definition

[Oliver Hunt]

On 23/01/2008, at 5:44 AM, Philip Taylor wrote:


On 23/01/2008, Oliver Hunt <[EMAIL PROTECTED]> wrote:

It would be great if putImageData
could take a source region, in addition to the destination.  One of
the primary reasons for using get/putImageData is to allow JS to
rapidly blit data to the screen, however without an ability to blit
only a subregion of the image data the only available options are to
either re-blit the entire imagedata region (which can be expensive  
due

to the need for [un]premultiplying in some (all?) implementations),


((Opera does non-premultiplied colour internally.))
Righto.  There's still the necessary type/range checking involved at  
some point.




or create and populate a new ImageData object which still requires  
more

work than would ideally be necessary.


You can also create a temporary canvas and putImageData once onto
that, and then drawImage sections onto the screen as they are needed.
That lets you draw lots of sections lots of times quickly (since
you're mostly drawing from the optimised canvas surface format, not
from a JS array), which perhaps helps in some (most?) of the cases.
(You still have to do a single putImageData of the whole data to get
it onto the temporary canvas, but if there are parts of the data you
aren't ever using then you just should make the ImageData smaller and
cut out the unused bits.)


Yes, there are many ways you can resolve this if you're willing to  
copy data
around in JS, which is far less efficient than letting you use your  
single backing

buffer, but only (effectively) repainting part of it.

Using a separate canvas also works, but still requires additional  
copying, much more memory, and the use of drawImage which doesn't  
have the same semantics as putImageData.


--Oliver



--
Philip Taylor
[EMAIL PROTECTED]

Re: [whatwg] Reverse ordered lists

[Krzysztof Żelechowski]

Dnia 23-01-2008, Śr o godzinie 12:53 -0600, Siemova pisze:
> On Jan 23, 2008 12:18 PM, Dave Singer <[EMAIL PROTECTED]> wrote: 
> how about assuming that if the source wants it numbered in
> reverse
> order, it knows what it is doing, and can tell the browser
> what
> number to start at?
> 
> it still seems the simplest:  an attribute that gives the
> starting 
> number (default 1) and an attribute that gives the direction
> (increasing or decreasing, default increasing).
> 
> 
> True, that's simplest to implement, but why put the onus on the
> content author to add things up and specify a start value every time?

If for no other reason, in order to help global warming.
A HTML document is written once, read lots of times.
If the author insists that counting the items is an excessive burden 
(it is not; if you cannot count yourself,
just remove the reverse attribute 
and look at the last item as rendered) 
he could use a generator or a fix-up processor before publishing.

Chris 

Re: [whatwg] Reverse ordered lists

[Krzysztof Żelechowski]

Dnia 23-01-2008, Śr o godzinie 15:15 +0100, Dave Singer pisze:
> At 15:03  +0100 23/01/08, Lachlan Hunt wrote:
> >Simon Pieters wrote:
> >>
> >>
> >>The lack of start='' would make the numbers update as the list is 
> >>filled with s. This allows both for simplicitly for short lists 
> >>and correct incremental rendering for large lists.
> >
> >No, the lack of an explicit start attribute would make it start from 
> >the default value: 1.  It would then count down from there:
> >
> >  1. A
> >  0. B
> >-1. C
> >-2. D
> 
> 
> which suggests a pair of orthogonal attributes, as above, the 
> direction ('order'='increasing' or 'decreasing'??) and the initial 
> ordinal value (which should be a number, even if the styling asks for 
> e.g. alphabetic labelling).
> 
> perhaps
> 
> (from a non-expert)

Ordinal numbers should never be negative; they should always have an
alternative representation using letters (spreadsheet-style).

Negative numbers were first justified because they turned out to be
essential for solving cubic equations; anything less sophisticated can
do without them.

If the start value is too small and the ordinal number descends below 0,
the user agent should leave the remaining items unmarked.  
The page will be ill-formed; 
the author is obliged to provide a valid value for the start attribute.

The reverse attribute without a tentatively valid start attribute 
should be ignored.

Chris

Re: [whatwg] How to use SVG in HTML5?

[Krzysztof Żelechowski]

Dnia 23-01-2008, Śr o godzinie 13:42 +, David Gerard pisze:
> Forgive me if this is a simple and obvious question. I note that all
> current browsers (except IE, of course) implement SVG rendering (to a
> better or worse degree). 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
>  for foo.svg?

There is none, and there should not be.  
An IMG element is a replacement for inline text 
that can be rendered at the viewer's option, 
an SVG element is an embedded object of its own.  
SVG is too heavyweight 
for the purpose of such tiny presentational enhancements.

Chris

Re: [whatwg] Reverse ordered lists

[Dave Singer]

At 12:53  -0600 23/01/08, Siemova wrote:
On Jan 23, 2008 12:18 PM, Dave Singer 
<[EMAIL PROTECTED]> wrote:


how about assuming that if the source wants it numbered in reverse
order, it knows what it is doing, and can tell the browser what
number to start at?

it still seems the simplest:  an attribute that gives the starting
number (default 1) and an attribute that gives the direction
(increasing or decreasing, default increasing).



True, that's simplest to implement, but why put the onus on the 
content author to add things up and specify a start value every 
time? Computers are for automating such calculations. If you're 
reversing a list, the default value for start shouldn't be 1 
anymore; that should be the ending value, and the starting value 
ought to be backwards-engineered from it. This is precisely how a 
content creator would expect it to work.


I'm surprised at you, being from Apple as you are. ;) Isn't the idea 
to make using such a function simple and intuitive, even if it has 
to be a little more complicated on the back-end?


complicated is fine.  impossible takes a little longer;  if I don't 
have the end yet, I can't do it right, and the substitutes all seem 
ugly.

--
David Singer
Apple/QuickTime

Re: [whatwg] Reverse ordered lists

[Siemova]

On Jan 23, 2008 12:18 PM, Dave Singer <[EMAIL PROTECTED]> wrote:
>
> how about assuming that if the source wants it numbered in reverse
> order, it knows what it is doing, and can tell the browser what
> number to start at?
>
> it still seems the simplest:  an attribute that gives the starting
> number (default 1) and an attribute that gives the direction
> (increasing or decreasing, default increasing).



True, that's simplest to implement, but why put the onus on the content
author to add things up and specify a start value every time? Computers are
for automating such calculations. If you're reversing a list, the default
value for start shouldn't be 1 anymore; that should be the ending value, and
the starting value ought to be backwards-engineered from it. This is
precisely how a content creator would expect it to work.

I'm surprised at you, being from Apple as you are. ;) Isn't the idea to make
*using* such a function simple and intuitive, even if it has to be a little
more complicated on the back-end?

- Jason

Re: [whatwg] Reverse ordered lists

[Krzysztof Żelechowski]

Dnia 23-01-2008, Śr o godzinie 17:28 +, James Graham pisze:
> The problem that Jonas originally pointed out is that, given browsers do 
> incremental rendering "number of items" is not a known quantity when the list 
> is 
> first rendered. For a pathological example of why this is a problem, imagine 
> a 
> cgi script that just kept spewing out reverse numbered list items, one per 
> second, indefinitely.

This is not specific to lists; any content without incremental rendering
capability would cause this effect.

Chris

Re: [whatwg] Reverse ordered lists

[Sam Arthur Allen]

On Wed, 23 Jan 2008 17:18:56 +0100
"Simon Pieters" <[EMAIL PROTECTED]> wrote:

> On Wed, 23 Jan 2008 16:54:23 +0100, Siemova <[EMAIL PROTECTED]> wrote:
> 
> >> I can only disagree with using negative numbers in a reverse order
> >> list, since I communicate to many people in non-english countries
> >> that use brackets to display negative numbers in their locale. So a
> >> list would appear as:
> >>
> >>1 : Red
> >>0 : Green
> >>   (1): Blue
> >>   (2): Violet
> >>   (3): ...etc...
> >>
> >> and if a long list is printed out on paper, all anybody would see
> >> is:
> >>
> >>  (120): Insert a really long paragraph of text here.
> >> ...
> >>  (121): And one here too
> >> ...
> >>
> >> which, to someone outside of their locale, would appear confusing.
> 
> Not a valid reason to ban negative numbers, IMHO.

On the contrary, I have found that working with people that use a
different locale occasionally frustrating. When I copy text from a
document that uses a different numbering system, I'm frequently
reformatting its text, making work unproductive and time-consuming.

For that reason, I constantly try to avoid negative numbers wherever it
is unnecessary.

Re: [whatwg] Reverse ordered lists

[Dave Singer]

At 17:33  + 23/01/08, Philip Parker wrote:
What about having it render as a standard unordered list ( ie, 
bulletpoints ) until the entire set of items has been received - and 
then re-rendering the list as a numbered type, all properly 
calculated


how about assuming that if the source wants it numbered, in reverse 
order, it knows what it is doing, and can tell the browser what 
number to start at?


it still seems the simplest;  an attribute that gives the starting 
number (default 1) and an attribute that gives the direction 
(increasing or decreasing, default increasing).




James Graham wrote:

Siemova wrote:
On Jan 23, 2008 10:54 AM, David Walbert <[EMAIL PROTECTED] 
> wrote:



It's not that simple -- the last line should be

start = 1 + ( (number of items - 1) * step)

if it's assumed that the last item of the list is numbered one by
default.


Alas, we see the ill effects of my hastiness today! I stand 
happily corrected. In that case, it's even simpler:


if start is not specified
start = 1
if reverse
start += (number of items - 1) * step


The problem that Jonas originally pointed out is that, given 
browsers do incremental rendering "number of items" is not a known 
quantity when the list is first rendered. For a pathological 
example of why this is a problem, imagine a cgi script that just 
kept spewing out reverse numbered list items, one per second, 
indefinitely.


It may be that in practice lists are short enough that they are 
typically rendered all in one go so this wouldn't be a problem. I 
don't think that's obvious, however.



--
David Singer
Apple/QuickTime

Re: [whatwg] Reverse ordered lists

[Philip Parker]

What about having it render as a standard unordered list ( ie, 
bulletpoints ) until the entire set of items has been received - and 
then re-rendering the list as a numbered type, all properly calculated


James Graham wrote:

Siemova wrote:
On Jan 23, 2008 10:54 AM, David Walbert <[EMAIL PROTECTED] 
> wrote:



It's not that simple -- the last line should be

start = 1 + ( (number of items - 1) * step)

if it's assumed that the last item of the list is numbered one by
default.


Alas, we see the ill effects of my hastiness today! I stand happily 
corrected. In that case, it's even simpler:


if start is not specified
start = 1
if reverse
start += (number of items - 1) * step


The problem that Jonas originally pointed out is that, given browsers 
do incremental rendering "number of items" is not a known quantity 
when the list is first rendered. For a pathological example of why 
this is a problem, imagine a cgi script that just kept spewing out 
reverse numbered list items, one per second, indefinitely.


It may be that in practice lists are short enough that they are 
typically rendered all in one go so this wouldn't be a problem. I 
don't think that's obvious, however.

Re: [whatwg] Reverse ordered lists

[James Graham]

Siemova wrote:
On Jan 23, 2008 10:54 AM, David Walbert <[EMAIL PROTECTED] 
> wrote:



It's not that simple -- the last line should be

start = 1 + ( (number of items - 1) * step)

if it's assumed that the last item of the list is numbered one by
default. 




Alas, we see the ill effects of my hastiness today! I stand happily 
corrected. In that case, it's even simpler:


if start is not specified
start = 1
if reverse
start += (number of items - 1) * step


The problem that Jonas originally pointed out is that, given browsers do 
incremental rendering "number of items" is not a known quantity when the list is 
first rendered. For a pathological example of why this is a problem, imagine a 
cgi script that just kept spewing out reverse numbered list items, one per 
second, indefinitely.


It may be that in practice lists are short enough that they are typically 
rendered all in one go so this wouldn't be a problem. I don't think that's 
obvious, however.




--
"Eternity's a terrible thought. I mean, where's it all going to end?"
 -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Re: [whatwg] How to use SVG in HTML5?

[Mathieu HENRI]

James Graham wrote:

David Gerard wrote:

Forgive me if this is a simple and obvious question. I note that all
current browsers (except IE, of course) implement SVG rendering (to a
better or worse degree). 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
 for foo.svg?


In browsers which support it  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, although several 
people have expressed an interest in changing that. However there are 
significant technical barriers to overcome at the syntax/parser level.


Supporting  is a requirement of SVG 1.1 [1]

	" If the user agent includes an HTML or XHTML viewing capability or can apply 
CSS/XSL styling properties to XML documents, then a Conforming SVG Viewer 
*must* support resources of MIME type "image/svg+xml" wherever raster image 
external resources can be used, such as in the HTML or XHTML 'img' element and 
in CSS/XSL properties that can refer to raster image resources (e.g., 
'background-image') "




[1] 
http://www.w3.org/TR/2003/REC-SVG11-20030114/conform.html#ConformingSVGViewers


--
Mathieu 'p01' HENRI
JavaScript developer, Opera Software ASA

Re: [whatwg] Reverse ordered lists

[Siemova]

On Jan 23, 2008 10:54 AM, David Walbert <[EMAIL PROTECTED]> wrote:

>
> It's not that simple -- the last line should be
>
> start = 1 + ( (number of items - 1) * step)
>
> if it's assumed that the last item of the list is numbered one by default.
>


Alas, we see the ill effects of my hastiness today! I stand happily
corrected. In that case, it's even simpler:

if start is not specified
start = 1
if reverse
start += (number of items - 1) * step

Here's hoping I haven't missed something obvious again. ^_^ Regardless, I
think we've shown it's fairly painless to implement.

- Jason

Re: [whatwg] How to use SVG in HTML5?

[David Gerard]

On 23/01/2008, David Gerard <[EMAIL PROTECTED]> wrote:

> Works somewhat in SeaMonkey (gives default specified rendering size of
> image in a small object box with scroll bars) and Safari (gives
> default size in small box with no scroll bars, i.e. top left corner
> only) and best in Minefield (scales image to size of object box,
> scales properly with WIDTH= or HEIGHT=).


Oh, and Opera 9.50 beta build 9745 for Win32 renders it in a box with
scroll bars, and does by far the worst rendering of the original SVG
I've seen ...


> (Minefield uses 100% CPU just displaying my test image, but also
> renders the SVG most accurately of any of them - this image was drawn
> in Omnigraffle but is known to misrender in Firefox, SeaMonkey,
> Safari, ImageMagick, Inkscape and rsvg - proprietary, or I'd link a
> copy. I expect I should create a test case and file a lot of bugs ...)


I shall definitely create a public test case, so as to help Firefox 3
and Opera 9.5 do a good job!


- d.

Re: [whatwg] Reverse ordered lists

[Sam Arthur Allen]

On Wed, 23 Jan 2008 17:18:56 +0100
"Simon Pieters" <[EMAIL PROTECTED]> wrote:

> On Wed, 23 Jan 2008 16:54:23 +0100, Siemova <[EMAIL PROTECTED]> wrote:
>   
> >> I can only disagree with using negative numbers in a reverse order
> >> list, since I communicate to many people in non-english countries
> >> that use brackets to display negative numbers in their locale. So a
> >> list would appear as:
> >>
> >>1 : Red
> >>0 : Green
> >>   (1): Blue
> >>   (2): Violet
> >>   (3): ...etc...
> >>
> >> and if a long list is printed out on paper, all anybody would see
> >> is:
> >>
> >>  (120): Insert a really long paragraph of text here.
> >> ...
> >>  (121): And one here too
> >> ...
> >>
> >> which, to someone outside of their locale, would appear
> >> confusing.  
> 
> Not a valid reason to ban negative numbers, IMHO.  

On the contrary, I have found that working with people that use a
different locale occasionally frustrating. When I copy text from a
document that uses a different numbering system, I'm frequently
reformatting its text, making work unproductive and time-consuming.

For that reason, I constantly try to avoid negative numbers wherever it
is unnecessary.

Re: [whatwg] Reverse ordered lists

[David Walbert]

On Jan 23, 2008, at 11:39 AM, Siemova wrote:


Very easily:

if start is not specified
if not reverse
start = 1
else
start = number of items * step



It's not that simple -- the last line should be

start = 1 + ( (number of items - 1) * step)

if it's assumed that the last item of the list is numbered one by  
default.



_
David Walbert
LEARN NC, UNC-Chapel Hill
[EMAIL PROTECTED]

Re: [whatwg] Referer header sent with ?

[Darin Fisher]

HTTP auth headers may be required to access the internet (e.g., to pass a
request through a proxy server), so this should only apply to the
Authorization request header, right?
-Darin


On Jan 22, 2008 11:27 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> On Tue, 22 Jan 2008, dolphinling wrote:
> >
> > HTML5 doesn't say anything about whether a referer should be sent with
> > the POST generated by . There is a new attack vector 
> > opens (as currently being discussed on mozilla.dev.platform) that would
> > be blocked if the referer were not sent.
>
> Fixed. I also said to not include Cookies or HTTP auth headers. Legitimate
> uses can always include whatever information they want in the ping=""
> attribute's value itself.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] How to use SVG in HTML5?

[Adam Roben]

On Jan 23, 2008, at 9:55 AM, David Gerard wrote:


On 23/01/2008, James Graham <[EMAIL PROTECTED]> wrote:

In browsers which support it  will work (with  
certain

limitations for security reasons).



 is just what I was hoping for, thank you :-) Doesn't
yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield
(Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers
it currently does work in?


This should also work in WebKit nightly builds (available from ).


-Adam

Re: [whatwg] Reverse ordered lists

[Siemova]

On Jan 23, 2008 10:18 AM, Simon Pieters <[EMAIL PROTECTED]> wrote:

> It's also interesting how negative numbers and 0 interacts with different
> list type=''s in different browsers...
>
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Col%20type%3Da%20start%3D-2%3E%3Cli%3Ex%3Cli%3Ex%3Cli%3Ex%3Cli%3Ex%3Cli%3Ex



Huh. One would think UA's should ignore negative start values in
non-numerical cases. For that matter, *any *ordered list type ought to
ignore *all *inapplicable start values. Perhaps that ought to be specified
in the recommendation?



> It was pointed out to me that the start='' attribute (and the
> corresponding DOM attribute) currently defaults to 1. This could, AFAICT,
> reaonably trivially be changed to make it depend on the direction of the
> list and the number of  children.



Very easily:

if start is not specified
if not reverse
start = 1
else
start = number of items * step


- Jason

Re: [whatwg] Reverse ordered lists

[Sam Arthur Allen]

On Wed, 23 Jan 2008 09:54:23 -0600
Siemova <[EMAIL PROTECTED]> wrote:

> On Jan 23, 2008 9:32 AM, Sam Arthur Allen <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, 23 Jan 2008 09:07:02 -0600
> > Siemova <[EMAIL PROTECTED]> wrote:
> >
> > > But then what would someone do in order to begin a list but not
> > > end it? For instance, if they wanted to say:
> > >
> > > "10. Blah
> > > 9. Blah
> > > 8. Blah
> > >
> > > And so forth..."
> >
> > Then in this situation, a start value would be necessary.
> >
> 
> 
> You're right! My apologies for misreading. Earlier I thought for a
> moment you were advocating having no start attribute at all.
> *sheepish grin*

That's ok, I should have made myself clear from the start.

> > Personally, I don't see any problem with allowing list items to be
> > > numbered 0 or negatively, so I think the "1, 0, -1, -2" default
> > > approach would work fine.
> >
> > I can only disagree with using negative numbers in a reverse order
> > list, since I communicate to many people in non-english countries
> > that use brackets to display negative numbers in their locale. So a
> > list would appear as:
> >
> >1 : Red
> >0 : Green
> >   (1): Blue
> >   (2): Violet
> >   (3): ...etc...
> >
> > and if a long list is printed out on paper, all anybody would see
> > is:
> >
> >  (120): Insert a really long paragraph of text here.
> > ...
> >  (121): And one here too
> > ...
> >
> > which, to someone outside of their locale, would appear confusing.
> >
> 
> 
> Aha. Well, your intended audience will understand anyway, right? And
> if any other reader looks at the beginning of the list, or is
> familiar with the context (surely the author would explain the list
> in some fashion), they'll know what's going on. Is that scenario
> really dire enough to prevent negative numbering, particularly given
> how troublesome and unintuitive it might be to figure out how to
> number items that should be negative but aren't allowed to display
> that way?

It's difficult to say, since I can't give any real world situations
where a decremental list has been used with negative numbers.

However, I've talked to quite Indonesians who use brackets for
numbering. Australia has approximately 20,000,000 people, where
Indonesia has around 234,500,000. In Australia, it's a fact that 1 out
of 3 families have access to the internet -- in Indonesia, it's more
like 9 out of 10. Simply put, Indonesians outnumber Australians
when it comes to reading websites. Asian countries are technologically
advanced in areas like that.

And that's just one situation. With the advent of OLPC and the likes,
we'll be seeing more non-english cultures accessing the internet,
especially African and Middle-East countries where their numbering
system is exotic when compared to our own.

Re: [whatwg] Reverse ordered lists

[Simon Pieters]

On Wed, 23 Jan 2008 16:54:23 +0100, Siemova <[EMAIL PROTECTED]> wrote:


I can only disagree with using negative numbers in a reverse order
list, since I communicate to many people in non-english countries
that use brackets to display negative numbers in their locale. So a
list would appear as:

   1 : Red
   0 : Green
  (1): Blue
  (2): Violet
  (3): ...etc...

and if a long list is printed out on paper, all anybody would see is:

 (120): Insert a really long paragraph of text here.
...
 (121): And one here too
...

which, to someone outside of their locale, would appear confusing.


Not a valid reason to ban negative numbers, IMHO.



Is that scenario really dire enough to prevent
negative numbering, particularly given how troublesome and unintuitive it
might be to figure out how to number items that should be negative but
aren't allowed to display that way?


Negative numbers aren't really prevented today. It's also interesting how  
negative numbers and 0 interacts with different list type=''s in different  
browsers...


   
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Col%20type%3Da%20start%3D-2%3E%3Cli%3Ex%3Cli%3Ex%3Cli%3Ex%3Cli%3Ex%3Cli%3Ex


It was pointed out to me that the start='' attribute (and the  
corresponding DOM attribute) currently defaults to 1. This could, AFAICT,  
reaonably trivially be changed to make it depend on the direction of the  
list and the number of  children.


--
Simon Pieters
Opera Software

Re: [whatwg] How to use SVG in HTML5?

[David Gerard]

On 23/01/2008, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> On Wed, 23 Jan 2008 15:55:27 +0100, David Gerard <[EMAIL PROTECTED]> wrote:

> >  is just what I was hoping for, thank you :-) Doesn't
> > yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield
> > (Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers
> > it currently does work in?

> Should work in Opera 9.5 (beta though). If you use  data=foo.svg> it probably works in more browsers.


Works somewhat in SeaMonkey (gives default specified rendering size of
image in a small object box with scroll bars) and Safari (gives
default size in small box with no scroll bars, i.e. top left corner
only) and best in Minefield (scales image to size of object box,
scales properly with WIDTH= or HEIGHT=).

(Minefield uses 100% CPU just displaying my test image, but also
renders the SVG most accurately of any of them - this image was drawn
in Omnigraffle but is known to misrender in Firefox, SeaMonkey,
Safari, ImageMagick, Inkscape and rsvg - proprietary, or I'd link a
copy. I expect I should create a test case and file a lot of bugs ...)

Thank you all!


- d.

Re: [whatwg] Reverse ordered lists

[Siemova]

On Jan 23, 2008 9:32 AM, Sam Arthur Allen <[EMAIL PROTECTED]> wrote:

> On Wed, 23 Jan 2008 09:07:02 -0600
> Siemova <[EMAIL PROTECTED]> wrote:
>
> > But then what would someone do in order to begin a list but not end
> > it? For instance, if they wanted to say:
> >
> > "10. Blah
> > 9. Blah
> > 8. Blah
> >
> > And so forth..."
>
> Then in this situation, a start value would be necessary.
>


You're right! My apologies for misreading. Earlier I thought for a moment
you were advocating having no start attribute at all. *sheepish grin*


> Personally, I don't see any problem with allowing list items to be
> > numbered 0 or negatively, so I think the "1, 0, -1, -2" default
> > approach would work fine.
>
> I can only disagree with using negative numbers in a reverse order
> list, since I communicate to many people in non-english countries
> that use brackets to display negative numbers in their locale. So a
> list would appear as:
>
>1 : Red
>0 : Green
>   (1): Blue
>   (2): Violet
>   (3): ...etc...
>
> and if a long list is printed out on paper, all anybody would see is:
>
>  (120): Insert a really long paragraph of text here.
> ...
>  (121): And one here too
> ...
>
> which, to someone outside of their locale, would appear confusing.
>


Aha. Well, your intended audience will understand anyway, right? And if any
other reader looks at the beginning of the list, or is familiar with the
context (surely the author would explain the list in some fashion), they'll
know what's going on. Is that scenario really dire enough to prevent
negative numbering, particularly given how troublesome and unintuitive it
might be to figure out how to number items that should be negative but
aren't allowed to display that way?

- Jason

Re: [whatwg] How to use SVG in HTML5?

[Anne van Kesteren]

On Wed, 23 Jan 2008 15:55:27 +0100, David Gerard <[EMAIL PROTECTED]> wrote:

 is just what I was hoping for, thank you :-) Doesn't
yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield
(Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers
it currently does work in?


Should work in Opera 9.5 (beta though). If you use data=foo.svg> it probably works in more browsers.



--
Anne van Kesteren

Re: [whatwg] Reverse ordered lists

[Sam Arthur Allen]

On Wed, 23 Jan 2008 09:07:02 -0600
Siemova <[EMAIL PROTECTED]> wrote:

> But then what would someone do in order to begin a list but not end
> it? For instance, if they wanted to say:
> 
> "10. Blah
> 9. Blah
> 8. Blah
> 
> And so forth..."

Then in this situation, a start value would be necessary.

> 
> I guess I'm asking, why recommend artificial and unnecessarily
> narrow constraints? We don't want UAs to force unexpected behaviors
> which would frustrate the end user and make them search (vainly)
> for a workaround if that's not what they wanted, do we?

What I'm looking for, is a _logical_ reverse order list that would
be displayed by default when the site designer or whoever uses it
can't be bothere setting specific list values, which AFAIK is from
X to 1. Also, nobody has to be constrained to anything as defaults
should alwalys be overridden when needed.

> Personally, I don't see any problem with allowing list items to be
> numbered 0 or negatively, so I think the "1, 0, -1, -2" default
> approach would work fine.

I can only disagree with using negative numbers in a reverse order
list, since I communicate to many people in non-english countries
that use brackets to display negative numbers in their locale. So a
list would appear as:

1 : Red
0 : Green
   (1): Blue
   (2): Violet
   (3): ...etc...

and if a long list is printed out on paper, all anybody would see is:

  (120): Insert a really long paragraph of text here.
 ...
  (121): And one here too
 ...

which, to someone outside of their locale, would appear confusing.

> With both "reverse" and "step" we could
> still accomplish what you're talking about, but the spec would
> remain both simpler for UAs to implement and more flexible for
> content creators' use.
> 
> - Jason
> 

> > 
> > On Jan 23, 2008 8:23 AM, Sam Arthur Allen <[EMAIL PROTECTED]> wrote:
> > 
> > > On Wed, 23 Jan 2008 15:03:42 +0100
> > > Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> > >
> > > Actually, the best route I can see is to not have a start
> > > attribute at all but to rely on the browser to automatically
> > > detect the amount of  tags within an
> > >  container and decrement from there. ie:
> > >
> > >  <-- Start count from here.
> > >  Red
> > >  Orange
> > >  Yellow
> > >  Green
> > >  Blue
> > >  <-- Close tag detected, 5  tags counted.
> > >
> > > is rendered as starting from 5:
> > >
> > >5. Red
> > >4. Orange
> > >...etc...
> > >
> > > and using a "step" value, for example, all the browser would need
> > > to do is multiply the total at the  tag, and decrement that
> > > multiplied total by the "step" amount, making:
> > >
> > >   
> > >
> > > render the list as:
> > >
> > >  25. Red
> > >  20. Orange
> > >  15. Yellow
> > >  ...etc...
> > >
> > > It might mean more work for the browsers, but by experience
> > > something like this isn't too hard to implement.
> > >

Re: [whatwg] Reverse ordered lists

[Siemova]

Ah, yes, true enough. For a moment I forgot that. Thank you for pointing it
out.

So default would logically be for the numbering to end at 1. Thus, the code

< ol reverse>
< li>Red
< li>Orange
< li>Yellow
< li>Green
< li>Blue
< /ol>

would display as:

5. Red
4. Orange
3. Yellow
2. Green
1. Blue

If you included step="2", it would display this way:

9. Red
7. Orange
5. Yellow
3. Green
1. Blue

And, if after that you threw a start="4" onto it:

4. Red
2. Orange
0. Yellow
-2. Green
-4. Blue

I guess that's what I was thinking of when I told Sam I don't see a problem
with negative values. But it would only occur in a case where you used a
start value which was lower than the step value times the number of list
items. Otherwise (to repeat myself) a reversed list would end at 1 by
default.

Sounds perfectly reasonable to me.

- Jason



On Jan 23, 2008 8:58 AM, Simon Pieters <[EMAIL PROTECTED]> wrote:

> On Wed, 23 Jan 2008 15:03:42 +0100, Lachlan Hunt
> <[EMAIL PROTECTED]> wrote:
>
> > Simon Pieters wrote:
> >>
> >>  The lack of start='' would make the numbers update as the list is
> >> filled with s. This allows both for simplicitly for short lists and
> >> correct incremental rendering for large lists.
> >
> > No, the lack of an explicit start attribute would make it start from the
> > default value: 1.  It would then count down from there:
> >
> >   1. A
> >   0. B
> > -1. C
> > -2. D
>
> Why? From an authoring perspective I would say that it's more useful to
> have the last item be 1 by default.
>
> --
> Simon Pieters
> Opera Software
>

Re: [whatwg] How to use SVG in HTML5?

[Jonathan Share]

David Gerard wrote:

On 23/01/2008, James Graham <[EMAIL PROTECTED]> wrote:


In browsers which support it  will work (with certain
limitations for security reasons).



 is just what I was hoping for, thank you :-) Doesn't
yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield
(Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers
it currently does work in?



I believe it works in Opera's preview builds.

http://my.opera.com/desktopteam/blog/

First publicly announced on the 12th October

"It is now possible to use an SVG image in an IMG element as well as 
specify one as a background image in CSS"


http://my.opera.com/desktopteam/blog/2007/10/12/neat-thumbnails-instant-searching-and-more

Re: [whatwg] Reverse ordered lists

[Siemova]

But then what would someone do in order to begin a list but not end it? For
instance, if they wanted to say:

"10. Blah
9. Blah
8. Blah

And so forth..."

I guess I'm asking, why recommend artificial and unnecessarily narrow
constraints? We don't want UAs to force unexpected behaviors which would
frustrate the end user and make them search (vainly) for a workaround if
that's not what they wanted, do we?

Personally, I don't see any problem with allowing list items to be numbered
0 or negatively, so I think the "1, 0, -1, -2" default approach would work
fine. With both "reverse" and "step" we could still accomplish what you're
talking about, but the spec would remain both simpler for UAs to implement
and more flexible for content creators' use.

- Jason


On Jan 23, 2008 8:23 AM, Sam Arthur Allen <[EMAIL PROTECTED]> wrote:

Actually, the best route I can see is to not have a start attribute at
> all but to rely on the browser to automatically detect the amount of
>  tags within an
>  container and decrement from there. ie:
>
>  <-- Start count from here.
>  Red
>  Orange
>  Yellow
>  Green
>  Blue
>  <-- Close tag detected, 5  tags counted.
>
> is rendered as starting from 5:
>
>5. Red
>4. Orange
>...etc...
>
> and using a "step" value, for example, all the browser would need to do
> is multiply the total at the  tag, and decrement that
> multiplied total by the "step" amount, making:
>
>   
>
> render the list as:
>
>  25. Red
>  20. Orange
>  15. Yellow
>  ...etc...
>
> It might mean more work for the browsers, but by experience something
> like this isn't too hard to implement.

Re: [whatwg] Reverse ordered lists

[Simon Pieters]

On Wed, 23 Jan 2008 15:03:42 +0100, Lachlan Hunt  
<[EMAIL PROTECTED]> wrote:



Simon Pieters wrote:

   
 The lack of start='' would make the numbers update as the list is  
filled with s. This allows both for simplicitly for short lists and  
correct incremental rendering for large lists.


No, the lack of an explicit start attribute would make it start from the  
default value: 1.  It would then count down from there:


  1. A
  0. B
-1. C
-2. D


Why? From an authoring perspective I would say that it's more useful to  
have the last item be 1 by default.


--
Simon Pieters
Opera Software

Re: [whatwg] How to use SVG in HTML5?

[David Gerard]

On 23/01/2008, James Graham <[EMAIL PROTECTED]> wrote:

> In browsers which support it  will work (with certain
> limitations for security reasons).


 is just what I was hoping for, thank you :-) Doesn't
yet seem to work in Safari 3.0.4, SeaMonkey 1.1.7 or Minefield
(Firefox 3 nightly) 2008012304 on Windows, though. Are there browsers
it currently does work in?


- d.

Re: [whatwg] How to use SVG in HTML5?

[James Graham]

David Gerard wrote:

Forgive me if this is a simple and obvious question. I note that all
current browsers (except IE, of course) implement SVG rendering (to a
better or worse degree). 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
 for foo.svg?


In browsers which support it  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, although several people have 
expressed an interest in changing that. However there are significant technical 
barriers to overcome at the syntax/parser level.


--
"Eternity's a terrible thought. I mean, where's it all going to end?"
 -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Re: [whatwg] Reverse ordered lists

[Sam Arthur Allen]

On Wed, 23 Jan 2008 15:03:42 +0100
Lachlan Hunt <[EMAIL PROTECTED]> wrote:

> Simon Pieters wrote:
> >
> > 
> > The lack of start='' would make the numbers update as the list is
> > filled with s. This allows both for simplicitly for short lists
> > and correct incremental rendering for large lists.
> 
> No, the lack of an explicit start attribute would make it start from
> the default value: 1.  It would then count down from there:
> 
>   1. A
>   0. B
> -1. C
> -2. D
> 

Actually, the best route I can see is to not have a start attribute at
all but to rely on the browser to automatically detect the amount of
 tags within an
 container and decrement from there. ie:

  <-- Start count from here.
  Red
  Orange
  Yellow
  Green
  Blue
  <-- Close tag detected, 5  tags counted.

is rendered as starting from 5:

5. Red
4. Orange
...etc...

and using a "step" value, for example, all the browser would need to do
is multiply the total at the  tag, and decrement that
multiplied total by the "step" amount, making:

   

render the list as:

  25. Red
  20. Orange
  15. Yellow
  ...etc...

It might mean more work for the browsers, but by experience something
like this isn't too hard to implement.

Re: [whatwg] Reverse ordered lists

[Dave Singer]

At 15:03  +0100 23/01/08, Lachlan Hunt wrote:

Simon Pieters wrote:

   

The lack of start='' would make the numbers update as the list is 
filled with s. This allows both for simplicitly for short lists 
and correct incremental rendering for large lists.


No, the lack of an explicit start attribute would make it start from 
the default value: 1.  It would then count down from there:


 1. A
 0. B
-1. C
-2. D



which suggests a pair of orthogonal attributes, as above, the 
direction ('order'='increasing' or 'decreasing'??) and the initial 
ordinal value (which should be a number, even if the styling asks for 
e.g. alphabetic labelling).


perhaps

(from a non-expert)
--
David Singer
Apple/QuickTime

Re: [whatwg] Reverse ordered lists

[Lachlan Hunt]

Simon Pieters wrote:

   

The lack of start='' would make the numbers update as the list is filled 
with s. This allows both for simplicitly for short lists and correct 
incremental rendering for large lists.


No, the lack of an explicit start attribute would make it start from the 
default value: 1.  It would then count down from there:


 1. A
 0. B
-1. C
-2. D


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [whatwg] More random comments on the putImageData definition

[Philip Taylor]

On 23/01/2008, Oliver Hunt <[EMAIL PROTECTED]> wrote:
> It would be great if putImageData
> could take a source region, in addition to the destination.  One of
> the primary reasons for using get/putImageData is to allow JS to
> rapidly blit data to the screen, however without an ability to blit
> only a subregion of the image data the only available options are to
> either re-blit the entire imagedata region (which can be expensive due
> to the need for [un]premultiplying in some (all?) implementations),

((Opera does non-premultiplied colour internally.))

> or create and populate a new ImageData object which still requires more
> work than would ideally be necessary.

You can also create a temporary canvas and putImageData once onto
that, and then drawImage sections onto the screen as they are needed.
That lets you draw lots of sections lots of times quickly (since
you're mostly drawing from the optimised canvas surface format, not
from a JS array), which perhaps helps in some (most?) of the cases.
(You still have to do a single putImageData of the whole data to get
it onto the temporary canvas, but if there are parts of the data you
aren't ever using then you just should make the ImageData smaller and
cut out the unused bits.)

-- 
Philip Taylor
[EMAIL PROTECTED]

[whatwg] How to use SVG in HTML5?

[David Gerard]

Forgive me if this is a simple and obvious question. I note that all
current browsers (except IE, of course) implement SVG rendering (to a
better or worse degree). 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
 for foo.svg?


- d.

Re: [whatwg] Reverse ordered lists

[Simon Pieters]

On Wed, 23 Jan 2008 13:35:38 +0100, Simon Pieters <[EMAIL PROTECTED]> wrote:

That's an interesting point, but I don't see it as a show-stopper.  
Either you allow it to have the wrong numbers while loading, or you make  
reverse ordered lists block layout for a while, or we could use  
something along the lines of:




...which is more of a pain to author but at least can render correctly  
incrementally.


I completely forgot about the start='' attribute. :-) If incremental  
rendering is an issue (e.g. if you use a list that will always have 100  
items) the author can just set the start value explicitly:


   

The lack of start='' would make the numbers update as the list is filled  
with s. This allows both for simplicitly for short lists and correct  
incremental rendering for large lists.


--
Simon Pieters
Opera Software

Re: [whatwg] Reverse ordered lists

[Simon Pieters]

On Wed, 23 Jan 2008 10:41:25 +0100, Jonas Sicking <[EMAIL PROTECTED]> wrote:


How would incremental rendering work? Imagine the following page


A
B
C
D
E
F


If the browser has only received the first three items it would render

3. A
2. B
1. C

a couple of seconds later it receives the rest of the page. It would  
then have to renumber all so far rendered items. This would look very  
strange to the user watching the page as it's loading.


That's an interesting point, but I don't see it as a show-stopper. Either  
you allow it to have the wrong numbers while loading, or you make reverse  
ordered lists block layout for a while, or we could use something along  
the lines of:


   

...which is more of a pain to author but at least can render correctly  
incrementally.



This problem is even worse if the paragraph above contains something  
like:


"Make sure to turn on the power after step 2 below".


Instructions are seldom put in reverse order. ;-)

--
Simon Pieters
Opera Software

Re: [whatwg]

[Mikko Rantalainen]

Brenton Strine wrote:
> [IE8] won't render pages with
> the new standards-compatibility unless you explicitly
> tell it to with this meta tag:
> 
> 

> My thought is this (and I'm hoping other people will come
> up with better ideas). Give HTML the ability to declare
> specific technologies that it uses, such that if a
> browser supports that technology, it makes use of it.
> Sort of like using object detection in javascript instead
> of messing with the user agent string. For example,
> assume an amazing new image format comes out called
> AwesomeImg--Opera 11 supports it, but you're not sure
> when IE will. Maybe IE10. But you don't want to lock your
> site into IE10 mode because it might break in IE10, or
> IE10 might still not support all your features but IE11
> would have.

A feature like that would target a different problem: the problem that
author knows which features are available in different standards but
user agents do not yet support those features. The problem with this
method is that UAs may support "CSS 2.1" and advertise it but there are
bugs. Some content that has been designed for CSS 2.1 would not display
correctly if the UA supports CSS 2.1 but has some - perhaps minor - bug
in the implementation.

The X-UA-Compatible fights with the problem that content authors have no
clue about standards and think that if their content looks correct to
them when they try user agent X, then it's fine. The X-UA-Compatible is
designed so that the content author lists the UAs that he has confirmed
to display the content correctly.

I think the idea is pretty good but the IE8's implementation is
terrible. Instead of the currently proposed "solution" the author should
add X-UA-Compatible: IE=7 to their HTTP headers if they have checked
with IE7. IE8 should use its best standards mode by default and
downgrade to IE7 rendering if and only if the page says that it has been
tested only with IE7. The DOCTYPE switch should be used to switch to
real quirks mode for obviously non-standard content. As it has been
currently designed, the feature must be used to get the best (nearest to
the standard) rendering possible instead of requesting a special set of
quirks which is really needed for old and somewhat incorrectly authored
content.

X-UA-Compatible: IE=X should be considered to mean "I don't know what
I'm doing but nevertheless the content looks the way I meant if you use
Internet Explorer version X".

-- 
Mikko




signature.asc
Description: OpenPGP digital signature

Re: [whatwg]

[Robert O'Rourke]

Christoph Päper wrote:

Brenton Strine:
(...) IE8 'passes' the Acid2 test, but (...) won't render pages with 
the new standards-compatibility unless you explicitly tell it to with 
this meta tag:




Note that 'edge' is actually discouraged and authors should instead 
provide version numbers they successfully tested their documents in. 
(The list may get rather long and incomplete over time, but the QA 
department can finally show off.)






This is just ridiculous now. Why can't MS just use gecko and focus on 
their UI??

[whatwg] More random comments on the putImageData definition

[Oliver Hunt]

Yet more commentary:
I noticed that the behaviour is undefined if putImagedata is provided  
an ImageData object on which the width, height, or data member is a  
getter that throws an exception.


A quick check shows that FFX3 throws a type mismatch -- eg. acts as  
though the field was invalid.


Ooh, and a request for a feature.  It would be great if putImageData  
could take a source region, in addition to the destination.  One of  
the primary reasons for using get/putImageData is to allow JS to  
rapidly blit data to the screen, however without an ability to blit  
only a subregion of the image data the only available options are to  
either re-blit the entire imagedata region (which can be expensive due  
to the need for [un]premultiplying in some (all?) implementations), or  
create and populate a new ImageData object which still requires more  
work than would ideally be necessary.


--Oliver

Re: [whatwg] Reverse ordered lists

[Jonas Sicking]

Robert (Jamie) Munro wrote:

Simon Pieters wrote:

See: http://forums.whatwg.org/viewtopic.php?t=130

Siemova wrote:
I recently wanted to create an OL in reverse order. In scouring the 
web for a solution, I found no simple way to accomplish this, but 
came across a number of other people frustrated by the lack of this 
minor feature.
The easiest, most obvious solution would be to create an attribute 
for Ordered Lists -- let's call it order="" -- which would have two 
possible values: ftl (first to last) and ltf (last to first).



(A boolean reverse="" attribute or so would also work, I guess.)


How about a step attribute that is allowed to be negative?

That way:


A
B


would be:
2. A
1. B


How would incremental rendering work? Imagine the following page


A
B
C
D
E
F


If the browser has only received the first three items it would render

3. A
2. B
1. C

a couple of seconds later it receives the rest of the page. It would 
then have to renumber all so far rendered items. This would look very 
strange to the user watching the page as it's loading. This problem is 
even worse if the paragraph above contains something like:


"Make sure to turn on the power after step 2 below".

/ Jonas